Business & 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.