Opportunity Solution Tree

Use this when you need to connect a desired product outcome to the opportunities (user needs), solution ideas, and assumption tests that will get you there. Based on Teresa Torres' Continuous Discovery Habits framework. The tree gives the team a shared map of the problem space and helps make informed bets on what to build next.

Before you start: If you have raw research data (interview notes, survey results, support tickets), run /research-synthesize first. Its output -- themes with supporting evidence -- feeds directly into this skill as opportunities. Use /assumption-map to identify and prioritize assumptions behind your solutions before committing to experiments.

Framework attribution: The Opportunity Solution Tree is from Teresa Torres, Continuous Discovery Habits.

Process

Step 1: Gather inputs

Ask the user:

1. Desired outcome — What measurable business or product outcome are you working toward? (e.g., "Reduce onboarding drop-off from 60% to 30%" or "Increase weekly active usage by 20%.")
2. Available research — What do you know about users in this space? Provide any of:
   • /research-synthesize output (themes become opportunities directly)
   • Interview notes, survey results, or support ticket patterns
   • Existing personas or JTBD analyses
   • Assumptions the team currently holds
3. Current solutions — What has the team already tried or considered? (Prevents re-inventing and grounds the tree in reality.)
4. Constraints — Any known limitations? (Technical, budget, timeline, regulatory.)

Step 2: Identify which personas this outcome serves

Before building the tree, prompt the user:

Persona check: Which user personas are affected by this outcome? The tree will be stronger if each opportunity is tagged to a specific persona. If you have defined personas (from /persona-create or /persona-draft), name them. If not, briefly describe the key user types involved.

Different personas experience the same outcome differently. A "reduce onboarding drop-off" outcome might create different opportunities for a "New PM" persona vs. an "Engineering Lead" persona.

Step 3: Map opportunities from research

Extract opportunities (user needs, pain points, unmet desires) from the provided research. If /research-synthesize output was provided, map themes directly to opportunities.

## Opportunity Solution Tree — (Outcome)

**Desired Outcome:** (Measurable outcome statement)
**Date:** (Date)
**Owner:** (User's name/role)

---

### 🎯 Outcome
(Restate the outcome with measurable target and timeframe)

---

### Opportunities

Opportunities are user needs, pain points, or desires discovered through research. Each one is a potential path to the outcome.

#### Opportunity 1: (Opportunity name — concise description of the user need)

- **Persona(s) affected:** (Which personas experience this need)
- **Evidence:** (Where this came from — research theme, quote, data point)
  - "(Direct quote or data point)" — Source
  - "(Supporting evidence)" — Source
- **Strength of evidence:** Strong / Moderate / Weak
- **Connection to outcome:** (How addressing this need moves the outcome metric)

#### Opportunity 2: (Opportunity name)

- **Persona(s) affected:** (Personas)
- **Evidence:**
  - "(Evidence)" — Source
  - "(Evidence)" — Source
- **Strength of evidence:** Strong / Moderate / Weak
- **Connection to outcome:** (How this connects)

#### Opportunity 3: (Opportunity name)

(Same format — aim for 3-6 opportunities)

Step 4: Generate solutions per opportunity

For each opportunity, brainstorm solution ideas. Solutions must be tied to specific opportunities, no floating ideas.

Hard rule: Generate a minimum of 3 solutions per opportunity before evaluating any of them. The first idea is never the best idea. When the team says "we can't think of more solutions," use constraints as creative prompts: "What would you build if you had half the budget? Double the timeline? No engineers? Only one day?" Creativity loves constraints.

### Solutions

#### Opportunity 1: (Name)

| Solution | Description | Effort Estimate | Risk Level | Assumption to Test |
|---|---|---|---|---|
| **S1.1:** (Solution name) | (What the team would build or change) | Low/Medium/High | Low/Medium/High | (The riskiest assumption — what must be true for this to work) |
| **S1.2:** (Solution name) | (Description) | Low/Medium/High | Low/Medium/High | (Riskiest assumption) |
| **S1.3:** (Solution name) | (Description) | Low/Medium/High | Low/Medium/High | (Riskiest assumption) |

#### Opportunity 2: (Name)

| Solution | Description | Effort Estimate | Risk Level | Assumption to Test |
|---|---|---|---|---|
| **S2.1:** (Solution name) | (Description) | Low/Medium/High | Low/Medium/High | (Riskiest assumption) |
| **S2.2:** (Solution name) | (Description) | Low/Medium/High | Low/Medium/High | (Riskiest assumption) |

(Continue for each opportunity)

Step 5: Design assumption tests per solution

For each solution's riskiest assumption, propose a lightweight test. Favor speed over precision — the goal is to learn quickly, not to prove definitively.

### Assumption Tests

#### S1.1: (Solution name) → Assumption: "(Riskiest assumption)"

- **Test type:** (Prototype test / Fake door / Interview question / Data analysis / Concierge / A/B test)
- **What to do:** (Specific steps to run this test)
- **Success signal:** (What result would increase confidence in this assumption?)
- **Failure signal:** (What result would decrease confidence?)
- **Effort to run:** (Hours/days — not weeks)
- **Data needed:** (What you need before you can run this test)

#### S2.1: (Solution name) → Assumption: "(Riskiest assumption)"

- **Test type:** (Test type)
- **What to do:** (Steps)
- **Success signal:** (Expected positive result)
- **Failure signal:** (Expected negative result)
- **Effort to run:** (Time)
- **Data needed:** (Prerequisites)

(Continue for each solution's primary assumption)

Step 6: Recommend next experiment

Based on the full tree, recommend which experiment to run first:

### Recommended Next Step

**Run this experiment first:** (Test name — e.g., "S1.1 prototype test")

**Why this one:**
- **Opportunity strength:** (Is the underlying opportunity well-evidenced?)
- **Assumption risk:** (How likely is this assumption to be wrong? Higher risk = more value in testing early.)
- **Speed to learn:** (Can you get a signal in days, not weeks?)
- **Impact if true:** (If the assumption holds, how much does it move the outcome?)

**What you'll learn:** (Regardless of the result — what does this experiment teach you about the tree?)

**If the test succeeds:** (What to do next — build an MVP? Test the next riskiest assumption?)
**If the test fails:** (What to do — pivot to a different solution? Reframe the opportunity? Dig deeper with research?)

Step 7: Present the tree structure

Provide a text-based tree view showing the hierarchy:

### Tree Overview

🎯 (Outcome)
├── 💡 Opportunity 1: (Name) [Persona: X, Y]
│   ├── 🔧 S1.1: (Solution) → Test: (Test type)  ⭐ RECOMMENDED FIRST
│   ├── 🔧 S1.2: (Solution) → Test: (Test type)
│   └── 🔧 S1.3: (Solution) → Test: (Test type)
├── 💡 Opportunity 2: (Name) [Persona: Z]
│   ├── 🔧 S2.1: (Solution) → Test: (Test type)
│   └── 🔧 S2.2: (Solution) → Test: (Test type)
├── 💡 Opportunity 3: (Name) [Persona: X]
│   ├── 🔧 S3.1: (Solution) → Test: (Test type)
│   └── 🔧 S3.2: (Solution) → Test: (Test type)

Step 8: Review and validate

Ask the user:

• Outcome check: Is the outcome truly measurable? Could the team agree on whether it's been achieved?
• Opportunity coverage: Are the opportunities comprehensive? Are there user needs you've observed that aren't captured?
• Evidence quality: Are the opportunities grounded in real research, or are some based on assumptions? (Flag assumption-based opportunities — they need research before you invest in solutions.)
• Solution creativity: Did the tree generate solutions you hadn't considered? Or are they all things you already planned?
• Assumption risk: Are you testing the riskiest assumption first? (Teams often test the easiest assumption, not the most important one.)
• Persona coverage: Does every opportunity have at least one persona tag? If an opportunity doesn't clearly serve a persona, it might be a team assumption, not a user need.

Adjust as needed. The tree is a living artifact — update it as you learn from experiments.

Related skills

• /research-synthesize — run this first to turn raw research into themes. Themes map directly to opportunities in the tree.
• /interview-plan — if you need more research before building the tree, plan interviews to fill evidence gaps.
• /experiment-design — for assumption tests that need more rigor (especially A/B tests), hand off to /experiment-design for full experiment planning.
• /persona-draft — if you don't have defined personas, draft them before building the tree. Persona tags on opportunities are far more useful with real personas.
• /jtbd-analysis — if you're framing opportunities as jobs-to-be-done, a JTBD analysis provides the language and structure.

Output location

Present the full tree (opportunities, solutions, assumption tests, recommendation, and tree overview) as formatted text in the conversation. The user copies the tree into their project wiki, Notion, or engagement documentation. The tree should be updated as experiments are run and learning accrues.