Product Management from MVP to Product-Market Fit

Context: joining a start-up that has launched its MVP but not yet reached Product-Market Fit.

Your Job to be Done: get to Product-Market Fit. Key failure to avoid: the Next Feature Fallacy.

Preliminary

• What's on fire? Is it really on fire, or is there bogus urgency, and/or incoherence? If there's just 1, it might be worth putting out anyway, then having a retrospective that questions the whole context.
• What's the current 5-10-year mission/vision?
• What are the user AARRR stats being tracked?

You need to document the current strategic context thinking, and prioritize discovery/validation on the riskiest parts. (You're starting from the outer-most loop in Quadruple-Loop Product Management.)

Sketch a Lean Canvas with internal folks if there isn't one already

• unlike when creating one in-advance for yourself, I find it best to do in order: Solution (what's our killer-app/key-feature?); Problem (what does it solve?); UVP; user/market (who's it for?) - this leads to market segment/ideal customer conversation.
• if it seems like 1 segment makes up 60%+ of the customers, confirm that by checking whether the Problem, Solution, and UVP fit roughly everyone in that segment. Is that the Ideal Customer implied by your Mission (from your Strategic Context? If not, are you changing your Mission? I think this issue may be at the heart of most zombie startups. If so, then move on to the rest of the canvas.
  • if no single segment is that big, then: sketch-list the key segments; then estimate the % of customers falling into each; then define/compare the Problem, Solution, and UVP for each of the top segments (hopefully 3-5 get to 80% of customers). This might lead to changing the list/definitions of segments. Cycle back through, then make complete canvas for each of the top segments. And start suggesting that serving more than 1 may spread your resources too thin.
• is each customer's segment identified in the company database? If not, is it possible for anyone to map customers to segments based on their data? (Probably not, but worth checking.)
• every box in the canvas is a hypothesis (Thinking in Bets): what evidence is there for each? Which boxes are riskiest?
• check the Rapid Viability Test for your canvas.

Start talking to customers: active, churned, failed, etc. - open-ended Customer Discovery.

• How quickly/confidently can you assign a given customer to a segment? Recognize that this process may lead you to change segment definitions. So start identifying patterns of needs, contexts, vocabulary, etc. for each user - eventually you'll want each pattern as a column in a spreadsheet, with each customer as a row with x for the patterns that apply
• Is the Problem your startup is targeting the Biggest problem for that person? If not, is it still a compelling problem to solve (and what are the problems that are bigger)? What context creates the problems? Are they spending money/time to solve it now, how?
• ask the Sean Ellis very-disappointed question of the current customers. What current feature/attribute is most valuable? What's the most important missing feature, or other shortcoming?
  • How does the very-disappointed score compare across segments? That might be the best ideal customer profile. See (2020-08-04) Rahul Vohra Shares Superhuman's Product Market Fit Framework
• ask the churned/failed users what they chose instead and why, and how that's working for them

Summarize/discuss your results - if you have multiple segments you'll want a comparison table. The goal is to pick a primary/key segment to focus your efforts on.

• is your biggest segment also your most-satisfied? Is this segment addressable? If so, is that segment-TAM big enough to spend 2 years growing into? If so, is there any reason not to make this your key segment?
• revise your Lean Canvas for this key segment/persona
  • does everyone agree on the UVP/positioning? (see Obviously Awesome process)
  • does everyone agree on which boxes are the biggest risks/uncertainties?
    • who "owns" the biggest risks, Product/dev or someone else? Is there an agile way to check those risks?
• can you define the A-ha moment that results in a customer becoming thrilled? Can you define a North Star metric?

Start an Opportunity Solution Tree for your key segment

• get all the (non-tiny) ideas people (inside and out) have mentioned included - it's ok to start with some in a "No Problem" Opportunity branch...
• Did the customer interviews lead you to have an opinion over which Problems/Opportunities are most significant? Do you believe those are the bottlenecks to getting to PMF? Make the tree reflect that.
  • Update: I'm wondering whether the OST is more appropriate to post-PMF situation, because it's a bit more incremental-improvement-oriented, whereas pre-PMF there's so much more uncertainty..... I wonder whether the Logical Thinking Process Goal Tree and other tools are more helpful...
• Have meetings to discuss/update the tree.
  • which Problems are most important to solve?
    • You might not want to decide this until you pick a North Star metric - otherwise, be more clear that you're kinda guessing.
    • You should definitely do some Pirate Metrics analysis before making these rankings...
  • generate more ideas attacking only the top 2 Problems
  • rank those ideas
• user StoryMapping to build happy-path first, even if you don't release it yet
• this is the best detailed walk-through I've ever seen of this process: (2020-08-04) Rahul Vohra Shares Superhumans Product Market Fit Framework
• hot-take: any task/feature that doesn't move you toward product-market fit is Low Priority (other than items that are legally required). If Low Priority items are taking more than 20% of your dev team's time, you need to prioritize better (or you're over-staffed).

Side bits to add in

• Start a writing culture (Org Writing Practices): is there a team-wiki-like doc-space integrated with the issue-tracker (aka confluence for jira)? Get it licensed, get permissions spread, start writing there.
• What analytics tools are available, if any? What user-action-data is being collected?
• Understand the tech stack, sprint process/cycle, QA process, deploy process, etc. If there's a complex architecture, ask if there's documentation/diagrams. Start attending dev meetings (stand-up, etc.)
• Ask everyone you meet with: What's the biggest business risk? What's your biggest pet peeve re the biz?

See also other Agile Product Development recommendations.