<!-- AUTO-GENERATED by export-plugins.py — DO NOT EDIT -->

---

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?

Opportunity	Importance	Satisfaction	Score
Don't understand product	9	3	9 × 0.7 = 6.3
Can't find core feature	8	4	8 × 0.6 = 4.8
Few invite teammates	7	2	7 × 0.8 = 5.6
No trigger to return	8	2	8 × 0.8 = 6.4

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):

Type	Duration	Example
Customer interviews	1–2 days	"Would you use X?" (with mockup)
Fake door / smoke test	2–3 days	Button that measures click-through
Prototype test	3–5 days	Figma prototype with 5 users
Concierge MVP	1–2 weeks	Manual version of the feature
A/B test	2–4 weeks	Live feature with control group

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

Avoid	Why	Instead
One solution per opportunity	No comparison = confirmation bias	Always generate 3+ solutions
Jumping to A/B tests	Expensive and slow for early validation	Start with interviews or prototypes
Outcomes you can't measure	Can't tell if you succeeded	Define baseline + target metric
Opportunities as features	"Build a dashboard" is a solution, not a need	Reframe: "Users need visibility into X"
Stale tree	Discovery is continuous, not quarterly	Review and update weekly
Skipping scoring	Everything feels equally important	Use Importance × (1 − Satisfaction)

---

References

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

<!-- Source: .faos/custom/skills/business/opportunity-solution-tree/SKILL.md -->