Business & Product Management

“People don’t buy what you do; they buy why you do it. And what you do simply proves what you believe.”  (Start With Why by Simon Sinek)

Start with heart

Here are my thoughts on product & business

In the top header image for this page, I’m getting some great energy from the Cotopaxi llama at Outdoor Retailer. I love this picture because it sums up my love of the triple bottom line:  people, planet, and profit. We need all three, and we need to have fun solving problems as a team.

Most of my experience is in event management and software, but I’ve also been a professional genealogist, a print center manager and an ice cream scooper.

My dad taught me the value of hard work led from the heart. I’ve been so fortunate to work with, and learn from, amazing people around the world. This is where I’ll share some things I’ve learned and thoughts that come to mind as I continue my business adventures.

General Business & Product series

General insights into business & product development based on my experience.

"Business Advice From a Dog" series

I wouldn’t trust them with a P&L, but you can learn a lot from dogs.

CROP Business Model series

Concept, Runway, Operations, Profit or Pivot…business cycles are living things.

What I'm Reading (Or Have Read) series

Lessons from great minds influencing business & product.

John Dutton: Bunkhouse Leadership (Take some morals, leave some ethics)

Spoiler alerts: I've been waiting *months* to make sure all of my favorite Duttons survived. The anticipation was real. I might be a little too invested in the life and/or death of a not-real family but I'm gonna forgive myself for that; I have my reasons and my...

Servant Leadership

I am definitely in charge of my two dogs. Aren't I? I mean I'm the one with thumbs here. So how is it that these thumbs are somehow compelled to do things like open doors, dispense treats, food, and water, and scratch behind ears on command and on schedule...and I...


One of the five P's in the Profit (or Pivot) optimization phase of CROP is perspective. Do we have the right perspective on the situation? Our perspective is our view on a situation, and it gives us a framework for interpretation and decision-making. It transfers bias...


Puppies are exhausting. They need so much love and training and constant attention, and yet I love them. I can't foster any more puppies because I just fall in love with them and I have a hard time giving them over to someone else...and there's only so many dogs I'm...

A Modern (Agile) Marketing Mix

The Marketing Mix is rooted in a time when the sale of physical retail goods dominated the markets. In fact they were the markets because the Internet didn't exist when the Marketing Mix was conceived. So that's the paradigm it was framed in. As such, four "P's" were...

Hypothetically This Will Work

I did not like my Chemistry class in High School. In hindsight, it should have been fun. As an adult, I think I would love it. But for me, at the time, it was too much about theory and memorizing formulas and not enough blowing stuff up. I think education has evolved...

5 P’s to Profit…or Pivot

The final area of focus in the CROP model is Profit...or Pivot. How I came across 5 P's for this area is a bit of a long story involving a layover in New York, watching a random hotel TV interview, and a lot of subsequent experience so I'll cut to the chase: in order...

Now is now

My dogs have an amazing ability to be still most of the day. Mostly they nap beside me or at my feet while I work. We go outside a few times a day and they run around, wrestle, and chase sticks; sometimes they chew their toys or chase a ball, and after work we go to...

The 5 S’s of Operations

My first "grown up job" was in Operations, so I have a particular nostalgia for this area of business. In the 6 years I worked preparing for the 2002 Olympic Winter Games I was fortunate to work with some amazing professionals. I was fortunate to work in the...

Paving the Runway

After you've refined your concept, it's time to get ready to launch. I'll call this stage The Runway--because that's what it's called. This is where you get funding and get your product to market. The length of your runway is determined by the resources you have to...

My Approach to Product Management

4 D’s becomes CROP – Concept, Runway, Operations, Profit or Pivot

I love Product Management. It’s the center of the Venn diagram where everything comes together. And as a Director of Product, it’s my joy to share my experience mentoring new Product leaders, growing together. I use analytics to lead with the heart, document, and communicate. Here’s a high-level summary of my approach.  It’s the work-in-progress of many years of reading, attending countless conferences and lectures, being mentored, doing the mentoring, trying and failing, trying and succeeding, kicking ideas around, collaborating with great team members (and, to be completely honest, a few not-so-great ones) and finding my own best practices which I shall continue to refine and improve over time.

In over 10 years of Product Management experience with startups and scaling businesses, I agree with the 4 D’s of Agile Development: Discover, Design, Develop, Deliver. (More about the 4D’s here). First, we discover and define the problem to be solved. Next, we design a solution our team can tackle to test the hypothesis. We think deeply and do extensive research, formulating a hypothesis of how to solve the problem with a minimum amount of work–our MVP. We work with the Design team to work through the questions and issues, documenting requirements and creating wireframes and high fidelity prototypes. Then we work with our Engineering teams to develop and deliver it, watching the impact carefully to test the hypothesis.  The 4 D’s (Discover, Design, Develop, Deliver) mirror the CROP (Concept, Runway, Operations, Profit or Pivot) framework I’ve been developing.


Concept (Discover) -> The 6-page Product Narrative

In the Concept/Discovery stage, the Product Manager identifies a problem to be solved. Every day, I process Discovery data: I listen to users/customers, evaluate analytics and funnels, watch session replays, talk to Sales and Customer Service. I monitor OKRs, revenue and other KPI reports.  In a sea of data, the problem isn’t getting information. The trick is to separate the signal from the noise and prioritize the most impactful opportunities. When we find the signal, we generate a hypothesis. What is the most beneficial thing we could do to address the problem? What metrics would that influence/how will we know whether it worked or not? Where is the intersection of impactful, delightful, intuitive, and easy to develop? What are the assumptions we’ve made? What are our competitors, industry, adjacent (and/or non-adjacent) collolaries doing? I start a 6-page written product narrative to think through the issues and formulate the Concept.


Runway (Design) -> The PRD and Kickoff Deck

Now it’s time to get on the runway, revving up and preparing for lift off. I iterate through documentation, starting with the Product Requirements Document (PRD). The PRD changes often while I’m on the runway. First, I map out the user flow and wireframe. Ideally, I do the user flow and wireframes myself because it helps think through the issues. What is THE ONE THING the user wants to do here? What’s next? What if they do a different thing? What if it fails? What’s the happy path here and what is the sad path? What could go wrong? What are the questions and issues? What is the full CRUD (Create, Read, Update, Delete) path here and what are the implications? I need to think these things through so I can communicate them, and wireframing helps me do this. I’ve worked with some really great designers and while it’s such a luxury to turn problems over to them and say “The problem is x, my hypothesis is y…what should we do?” I’ve found that I really need to at least think things through myself and diagraming the journey and the wireframes helps. I bounce ideas and check in with stakeholders often along the way to ensure that we’re on track.

These discoveries all go into the Product Requirements. Along the way, I need to meet with the Architect and/or at least my tech lead. I bounce things off them for feasibility and viability. What libraries do they know of? What do they see technically? Are there big red flags here? Is there a faster/easier way to test the hypothesis? What does the MVP really look like? We refine things together, ideally having Design, Product and Engineering all in the room to iterate together. These begin framing Engineering Requirements. Ideally, I prefer the Engineering team own the Engineering documents and link them all from the PRD.

I refine the 6-page Product Narrative, with emphasis on de-risking the 4 product risks: value, viability, feasibility, and usability. Along the way, I begin a kickoff/overview deck which can be easily circulated to stakeholders, executives, and other interested parties.  I learned to use the SCORE format for this: Situation, Considerations/Complications, Options, Recommendation, and Exhibits. 

What in the end looks like a seamless foregone conclusion is a bit of an iterative mess. A smooth runway is the outcome of a lot of deep thinking and it’s worth it. 


Operations (Develop) -> The Backlog

As a Certified Scrum Product Owner I have strong opinions about how to manage a backlog. 😂  I love Jira mostly for its templating but also because of its integrations with Confluence and other utilities such as Miro. The principles of good Product Ownership apply to really any issue tracker such as Clubhouse (now known as Shortcut), YouTrack, etc., though: be clear, consistent, and as concise as possible in your communication. I create ticket templates for anything user-facing (features and bugs) as well as investigations so I can be consistent and I follow the inverted triangle method: start with the big picture (user story for feature work/expected behavior for bugs) and drill down to the details. I’ve been doing this for a long time, so I’ve gotten fast at it but I’ve found that new Product Owners do well with this method as well because it trains them to think about the desired outcomes ahead of the desired actions. (As Product Managers we’re responsible for the “what” and the “why”; we leave the “how” up to the ones doing it, but it’s good housekeeping and servant leadership to keep track of all the details) For back end work I let the developers tell me what the ticket should say or let them make it themselves. Many Product Managers don’t write tickets. I am the complete opposite. I train and expect my Product Owners/Managers to write good tickets for three reasons:

1. The Product Manager is ultimately accountable for the success of the product. So IMO, the Product Manager is ultimately accountable for the communication of what success looks like. I expect the PM to use the INVEST model for user-facing tickets, tell compelling user stories, write out detailed acceptance criteria using the Gherkin given-when-then model, and include drawings and notes. The PM/Product Owner is responsible for ensuring that all tickets meet the agreed upon Definition of Ready. So they should do the ticket writing.

2. The backlog is where the pedal meets the metal. It’s in the Product Manager’s best interest to control the vehicle. When the PM knows the contents of every ticket, they can easily prioritize them, scope them, etc. Maybe you can get away with bad tickets because you have really good engineers with a long history with the product, but I take pride in my work and I like to write (and train my teams to write) good tickets myself. That’s just my take on it.

3.  The less time Engineers spend writing, thinking about and/or trying to interpret tickets, the more time and brain power they have to do their job: writing the code.

So I prefer to maintain the backlog myself, and keep it ready 2 sprints ahead, or >1 week ahead for Kanban. I use t-shirt sizing for epics, and story points measuring complexity (not time) on fibonacci for each sprint backlog item. Doing it this way makes it easier to measure, track, and report velocity with a few caveats: not all story points are created equal and there will be unexpected twists. Tech debt doesn’t typically get sized, and investigations are typically just a 1, as well as any non-complex and yet time-consuming tasks such as data washing. So just because a team accomplished 25 points in one sprint doesn’t mean the next 25 points will take only one sprint. Velocities and sprint plans are estimates, not promises. 


Profit or Pivot (Deliver) -> The Release Plan

 In preparation for a release, there are a few important things I make sure happen as we prepare to deliver. I put these in the Release Plan:

1. I make sure we have analytics in place, with baseline measurements where possible. While generating a hypothesis in the Concept stage, I visualized what success would look like. I need to make sure I can measure it. I also ensure that we have a method in place to measure and report ancillary metrics. I put any A/B testing in place, define cohorts, and ensure that other appropriate actions are taken and communicated to all interested parties.

2. A testing plan. Even with a testing team, the PM should ensure should have a solid testing plan. What data sets will we use? What happy and sad paths  User Acceptance Testing (UAT) should be documented? Clear acceptance criteria makes testing easier, but no matter who else has tested it I like to test things myself to ensure that things do, indeed, meet expectations and/or I create tickets to close the gap now or later.

3. Go-to-market (GTM) plan. In close coordination with the Marketing team, I make sure the who, what, and when is communicated well ahead of time, and then confirmed as the feature goes live. If there is a feature toggle, I ensure that any groups are set up correctly, and then when everything is ready I flip the toggle.

And then I watch. Was my hypothesis correct? Are the users I intended to serve finding the benefits we planned, and is it translating into the numbers we expected? Quantitative and qualitatively, is this work a success? Where do we need to go from here? The CROP cycle starts again.

This is what I do, and I love it.


My Experience

An interviewer once asked me what my first job was, and I had to think about it. Would that be babysitting? Or when I volunteered as an ice cream scooper at the local theater? Or would it be my first paying job? (Also scooping ice cream, thanks to the expert scooping techniques I developed as a volunteer.)

Ultimately, I consider my first “real” job to have been with the 2002 Olympic Winter Games in Salt Lake City. I learned so much over the course of 6 years, 3 CEOs, 35 departments and 25 venues. Whenever I can’t sleep at night I still run through the list of event stakeholders in my head (“Accommodations, Accreditation, Broadcast, Ceremonies…”) until I fall asleep. Working with Mitt Romney, Fraser Bullock, and the team from Bain near the end was an amazing learning experience.

I learned even more when I started my own family history business. I was also managing a FedEx Office (then known as FedEx Kinkos) to bring in stable income during the first rocky years, and I learned so much there as well.

And then one day I found myself in software development. I started as a subject matter expert in family history and when we lost our CTO shortly after taking a round of funding, I jumped at the opportunity to become a de-facto Product Manager and Scrum Master. Another learning opportunity!

I fell in love with product and software development. That was over 10 years ago and it’s been an amazing decade. I’m thrilled to have learned so much and I’m looking forward to learning so much more. Each experience shapes my character and gives me unique insights and skills. One of my favorite quotes sums it up:

“Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!”

Miscellaneous Skills

  • Team leadership
  • Product Management (strategy/business)
  • Product Owner (tactical/backlog)
  • Software development lifecycle
  • Backlog refinement & management
  • Jira, YouTrack, etc.
  • Agile, Scrum, and Kanban development
  • Confluence, PRD & MRD development
  • Customer development
  • User Testing
  • Excel (advanced)
  • Tableau
  • Photoshop & Illustrator
  • UX & UI design (UX)
  • Wireframing 
  • Interactive prototype development 
  • Microsoft Visio (and similar)
  • HTML & CSS
  • Some JavaScript
  • Some PHP
  • Some VueJS
  • Some Python & Pandas

    Certified Scrum Product Owner and Certified Scrum Master

    “Aren’t those roles mutually opposed?” you might ask. Yes and no, I would answer. It’s the Scrum Master’s role to remove obstacles and champion the Scrum values of Transparency, Inspection, and Adaptation within the dev team. The Product Owner’s role is to propel vision, value, and validation, maximizing the work performed.

    Sometimes those responsibilities cause conflict, especially if/when the Product Owner isn’t in sync with the team. But not all teams have the luxury of a Scrum Master to help identify and remove obstacles. That’s where a savvy Product Owner can help. So I chose to understand, and become certified in, both roles. And I’ve learned quite a bit about software programming as well, because cross-training is catalytic.

    As I see it, the Scrum Master is like the sweeper in curling, scrubbing the ice ahead of the stone while the Product Owner is responsible for maximizing the work performed and setting that stone on the right trajectory. When you understand the roles and responsibilities of each member of the team, and when you cross-train, you not only gain a deeper empathy for the other team members, you develop a shorthand and improved communication. You have a frame of reference you can draw from.

    So I recommend all Product Owners and Product Managers at least take an immersive Scrum Master course, if not completely cross train with certification. I think it’s also important to take at least one JavaScript course and take an idea from original concept to minimally interactive prototype–preferably with a modern library such as React, Vue, or Angular–to gain insight into the work processes, vocabulary, and best practices of their dev team. I know I’ve enjoyed and benefited from the insights learning Vue has given me!

    In this way, like an Olympic curling team, we can all work together to send the stone down the slippery ice, communicate, and slide that product right into the target zone to create compelling solutions to customer pains.

    Curling is hard.


    Ice is slippery. So is product development. Good teams make it look easy by excelling at their individual roles, and at the same time understanding and trusting other team members to communicate through the play.

    Here, in my metaphor,  the stone (increment/dev team) is cast by the Product Owner with an eye to the center of the target, maneuvering around other stones in its way. Then the Scrum Master scrubs the ice to remove as much friction as possible from the path as the stone continues towards the target.

    Together, the Scrum Master and Product Owner maximize the play to win as a team.

    Subscribe to Business & Product

    I write stuff when it comes to me, usually about once a week or so. If you’d like to be notified when there’s new business & product content, feel free to add your email address below. (I won’t share your information.)

    Oh hi there! 👋 It’s nice to meet you.

    Would you like to be notified when there's new business & product stuff here to read?

    I don’t spam! Read my privacy policy for more info.