Context: CEO (or equiv) is concerned about Product team/process ROI.

• This is an adaptation of Product Management from MVP to Product-Market Fit for bigger orgs, part of Agile Product Development

Key failure to avoid: the Next Feature Fallacy.

The most common problems are (in order)

• unclear/unaligned/unfocused strategic context
• structure/process that isn't based on cross-functional product teams with agency
• teams are not working in a truly agile way

Strategic alignment

Preliminary

• What's the current 5-10-year mission/vision?
• What are the user AARRR stats (incl/esp Bounce-rate) being tracked?

You need to document the current strategic context thinking, and prioritize discovery/validation/execution 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/products. 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 separate 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? (Even if you're aiming for a single Ideal Customer type, you'll get some non-Ideal ones.) 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?

Turn strategy into more specific Product Plans

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...
  • do more idea generation, for Solutions attacking only the top 2 Problems (it's ok if an idea ends up getting moved to a different problem, the point is to try to focus on the top 2)
  • rank those Solutions
  • use vibe prototyping, starting from the top-ranked, to
• user StoryMapping to build happy-path first, even if you don't release it yet
• here is the best detailed walk-through I've ever seen of this process: (2020-08-04) Rahul Vohra Shares Superhuman's 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).

Team Agency

Each team is a two-pizza team in size, but has all the skills/roles on it needed to move ideas to execution and production: devs, product management, design (might be <1FTE, might be >1FTE, depending on the situation).

Each team has a sticky scope/mission. At any given time, they have a single north-star metric to aim at.

Team scopes are defined to minimize cross-team dependencies.

Team Agility

Each team must (see (2018-07-20) Jeffries How To Impose Agile)

• maintain a ready-to-ship, integrated, working, tested product all the time, containing all the solutions that the team has chosen to be in the product.
• delivering changed running, tested, shippable software every two weeks (for most SaaS teams, I think they should be delivering up to daily)

Each team have sufficient unit tests and acceptance tests to quickly/automatically validate working software to support frequent delivery.

All this is to just create the foundation for product ideation and execution.

Also...

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.