Opportunity Solution Tree

name: opportunity-solution-tree description: Build an Opportunity Solution Tree to connect desired outcomes to customer opportunities, solutions, and experiments. Use when prioritizing discovery work, mapping customer needs to solutions, or deciding what to build next. tags: [discovery, prioritization, product-strategy, continuous-discovery]

Opportunity Solution Tree

A visual framework from Teresa Torres' Continuous Discovery Habits that connects a desired outcome to customer opportunities, potential solutions, and assumption tests — ensuring you build what matters most.

Purpose

Prevent the two most common PM failure modes:

1. Feature factory — shipping features without connecting them to outcomes
2. Analysis paralysis — researching endlessly without converging on action

The OST forces explicit links: Outcome → Opportunities → Solutions → Experiments.

When to Use

• Starting a new quarter or initiative and need to decide what to build
• You have research data (interviews, surveys, analytics) but no clear prioritization
• Stakeholders are pushing features without articulating the customer need
• You want to evaluate multiple solution paths before committing

When NOT to Use

• You already have a validated solution and need execution planning (use PRD instead)
• The problem is purely technical with no customer-facing dimension
• You need a full product strategy (use product-strategy-canvas instead)

The Framework

                    ┌─────────────────┐
                    │ Desired Outcome │  ← Single measurable metric
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
        ┌───────────┐ ┌───────────┐ ┌───────────┐
        │Opportunity│ │Opportunity│ │Opportunity│  ← Customer needs/pain points
        │     1     │ │     2     │ │     3     │
        └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
              │              │              │
         ┌────┼────┐    ┌───┼───┐     ┌────┼────┐
         ▼    ▼    ▼    ▼   ▼   ▼     ▼    ▼    ▼
       Sol. Sol. Sol. Sol. Sol. Sol. Sol. Sol. Sol.  ← Multiple solutions per opp.
         │              │                    │
         ▼              ▼                    ▼
       Exp.           Exp.                 Exp.     ← Assumption tests

The Process

Step 1: Define the Desired Outcome

Identify a single, measurable outcome that the team owns.

Good outcomes:

• "Increase 7-day retention from 32% to 40%"
• "Reduce time-to-first-value from 14 days to 3 days"
• "Increase monthly active usage from 4 to 8 sessions"

Bad outcomes (avoid):

• "Launch feature X" (output, not outcome)
• "Improve the product" (not measurable)
• "Increase revenue" (too broad for one team)

Rules:

• Must be quantifiable with a current baseline and target
• Must be something the product team can influence directly
• Should connect to a company-level OKR or North Star Metric

Step 2: Map Opportunities (3–7)

Opportunities are customer needs, pain points, or desires — NOT features.

Sources for opportunities:

• Customer interview transcripts
• Support ticket analysis
• Usage analytics (drop-off points, low adoption features)
• Survey data (NPS verbatims, CSAT comments)
• Sales call recordings

How to write opportunities:

• Frame as customer needs: "Customers need to ___"
• Use their language, not internal jargon
• Each opportunity should be distinct (no overlaps)

Example (for "increase 7-day retention"):

1. "New users don't understand what the product does in the first session"
2. "Users can't find the feature that solves their core problem"
3. "Users who invite teammates retain 3x better, but few invite"
4. "Users get value but forget to come back (no trigger)"

Step 3: Score and Prioritize Opportunities

Use the Opportunity Score formula:

Opportunity Score = Importance × (1 − Satisfaction)

For each opportunity, rate on a 1–10 scale:

• Importance: How much does this matter to customers?
• Satisfaction: How well is this need currently met?

Select top 2–3 opportunities to focus on.

Step 4: Brainstorm Solutions (3+ per Opportunity)

For each prioritized opportunity, generate at least 3 distinct solutions.

Rules:

• Involve the Product Trio (PM + Designer + Engineer) in ideation
• Include at least one "small bet" (< 1 week) and one "big bet"
• Solutions should address the opportunity from different angles
• Don't evaluate yet — diverge first

Example (for "No trigger to return"):

1. Weekly email digest with personalized highlights
2. Mobile push notifications for relevant activity
3. Slack integration that surfaces insights in daily workflow
4. Gamification: streaks and progress milestones

Step 5: Design Experiments (1–2 per Promising Solution)

For each promising solution, identify the riskiest assumption and design a fast test.

Four assumption categories (UVFV):

• Value: Will customers want this?
• Usability: Can customers figure it out?
• Viability: Can we sustain this business-wise?
• Feasibility: Can we build this technically?

Experiment types (cheapest first):

For each experiment, define:

• Hypothesis: "We believe [solution] will [outcome] because [rationale]"
• Success metric: What number proves/disproves the hypothesis
• Duration: How long to run
• Sample size: How many users/participants needed

Step 6: Visualize the Full Tree

Produce a complete OST summary:

## Opportunity Solution Tree

### Desired Outcome
[Outcome with baseline → target]

### Prioritized Opportunities
1. **[Opportunity name]** — Score: X.X
   - Solution A: [description]
     - Experiment: [type] testing [assumption]
   - Solution B: [description]
     - Experiment: [type] testing [assumption]
   - Solution C: [description]

2. **[Opportunity name]** — Score: X.X
   - Solution A: [description]
   - Solution B: [description]
   - Solution C: [description]

### Parked Opportunities (lower priority)
- [Opportunity] — Score: X.X (revisit next quarter)

### Next Steps
1. [First experiment to run]
2. [Second experiment to run]
3. [Decision point / review date]

Key Principles

• Opportunities, not features — the tree maps customer needs, not your roadmap
• Compare solutions — never commit to one solution without considering alternatives
• Test before building — use the cheapest experiment that gives confidence
• Continuous, not one-time — update the tree weekly as you learn
• Product Trio ownership — PM + Designer + Engineer co-own the tree

Anti-Patterns

References

• Torres, Teresa. Continuous Discovery Habits (2021)
• Opportunity Score (Ulwick)
• Product Trio concept