Opportunity Solution Tree

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

```markdown
## 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)](https://jobs-to-be-done.com/opportunity-score)
- [Product Trio concept](https://www.producttalk.org/product-trio/)

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