Opportunity Solution Tree

---
name: opportunity-solution-tree
description: >
  Opportunity Solution Tree (Teresa Torres) mapping outcomes →
  opportunities → solutions → assumption tests. Use when prioritizing
  discovery work, mapping solutions to a problem, or checking whether
  a roadmap moves outcomes.
license: MIT + Commons Clause
metadata:
  version: 1.0.0
  author: borghei
  category: project-management
  domain: product-discovery
  updated: 2026-05-27
  python-tools: ost_validator.py
  tech-stack: opportunity-solution-tree, continuous-discovery, teresa-torres
---

# Opportunity Solution Tree (OST)

Teresa Torres' framework from *Continuous Discovery Habits*. An OST
visualizes the path from a desired outcome to the assumption tests that
will validate or invalidate candidate solutions.

## When to use this skill

- Prioritizing **discovery work** for a quarter
- Structuring **weekly customer touchpoints**
- Mapping **multiple solutions** to one problem (vs jumping to solution)
- Auditing whether **roadmap actually moves outcomes**
- **Coaching** a team into continuous discovery rhythm
- **Pivoting** discovery away from a dead-end branch

## The tree structure

```
                  [Outcome]
                      |
        +-------------+-------------+
        |             |             |
   Opportunity   Opportunity   Opportunity
        |             |             |
     +--+--+      +--+--+      +--+--+
     |     |      |     |      |     |
   Solution Solution ...
        |
   +----+----+
   |         |
 Assumption  Assumption
   Test        Test
```

### Levels
1. **Outcome** — a single, specific, measurable business / product outcome
2. **Opportunities** — customer needs/pains/desires that, if addressed, drive the outcome
3. **Solutions** — candidate ways to address each opportunity
4. **Assumption tests** — experiments validating that the solution will deliver

## Clarify First

Before building the tree, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **The one outcome** — a single, measurable, bounded outcome (the tree root; "ship X" or "make users happy" produces an invalid tree)
- [ ] **Customer evidence source** — interviews / tickets / analytics that populate the opportunity layer (opportunities must come from research, not the team's imagination)
- [ ] **Engagement type** — net-new tree vs auditing an existing roadmap (net-new builds top-down; an audit maps current solutions back onto outcomes)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

## Workflow

### Step 1 — Pick ONE outcome
A good outcome is:
- Behavioral (something users do) or business (revenue, retention)
- Measurable (specific metric, baseline, target)
- Bounded (this quarter / half)
- Within team's influence

Examples:
- "Increase week-1 activation rate from 28% to 40% by end of Q3"
- "Reduce admin-panel time-on-task by 30%"
- "Lift NRR from 105% to 115% by end of year"

NOT outcomes:
- "Build [feature]" (output, not outcome)
- "Improve user experience" (vague)
- "Hit revenue target" (too high; needs to decompose)

### Step 2 — Generate opportunities (from research)
Opportunities come from **customer evidence**, not the team's imagination:
- Interview transcripts
- Support ticket themes
- Sales objection patterns
- Behavioral analytics
- Survey free-text

Opportunities are **customer problems/needs**, not solutions:
- ✓ "Users abandon during email-verification step"
- ✓ "Admins want to bulk-invite from CSV"
- ✗ "Add a CSV import feature" (that's a solution)

### Step 3 — Cluster + dedupe opportunities
Group similar opportunities. Aim for 3-7 distinct opportunity clusters
per outcome.

### Step 4 — Generate multiple solutions per opportunity
For each opportunity, brainstorm 3-5 solutions. Resist jumping to one.

Multiple solutions matter because:
- It surfaces underlying assumption: which solution best solves this?
- Allows comparison of cost/effort
- Reveals the team has bias toward a specific approach

### Step 5 — Identify assumptions + tests
For each candidate solution, list:
- **Value assumption** — will users want this?
- **Usability assumption** — can users use it?
- **Feasibility assumption** — can we build it?
- **Viability assumption** — is it good for the business?

For each top assumption, design a cheap test (interview, prototype, A/B,
landing page, prefab Wizard-of-Oz).

### Step 6 — Run `ost_validator.py`
Audit for: missing outcome, opportunities written as solutions,
single-solution branches, no assumption tests, tree without recent updates.

```bash
python3 project-management/discovery/opportunity-solution-tree/scripts/ost_validator.py \
  --input ost.json --format markdown
```

### Step 7 — Iterate weekly
OST is a living artifact. Each week:
- Add opportunities from new interviews
- Move opportunities up/down based on evidence
- Add solutions
- Track assumption test results
- Kill solutions that failed tests
- Promote validated solutions to roadmap

## Decision frameworks

### Choosing the outcome

Wrong: "Build the new dashboard" (output)
Wrong: "Make customers happy" (vague)
Wrong: "Hit $20M ARR" (too high; many teams)

Right: One number a team can move. Decompose company OKRs to team-level
outcome. See `project-management/execution/north-star-metric`.

### Opportunity vs solution test

If the statement is a thing to build → solution.
If the statement is a customer pain / desire / need → opportunity.

| Statement | Type |
|-----------|------|
| "Add bulk CSV import" | Solution |
| "Admins want to invite many users at once" | Opportunity |
| "Build SAML SSO" | Solution |
| "Enterprise IT requires SSO to approve purchase" | Opportunity |
| "Replace the onboarding video" | Solution |
| "New users can't find the start button" | Opportunity |

### Sizing opportunities

For each opportunity:
- How many customers experience it (% of base)?
- How severe (workaround cost in time/$)?
- How often (frequency per user)?
- Strategic fit with outcome?

Score = impact × frequency × strategic fit. Prioritize accordingly.

### Multiple solutions discipline

Don't allow single-solution branches. If only one solution comes up:
- Ask: "What if we couldn't build that?"
- Borrow from analogous problems
- Get team brainstorm input
- Look at how competitors solve it

Goal: at least 3 candidate solutions per opportunity worth pursuing.

### Assumption test ladder

For each solution, the cheapest test first:
1. Customer interview / desirability test (~$0)
2. Landing page / smoke test (~hours)
3. Wizard-of-Oz / concierge MVP (~days)
4. Low-fidelity prototype (~1 week)
5. High-fidelity prototype (~2 weeks)
6. A/B test in production (~weeks-months)

Spend the minimum to learn the most.

**AI-generated prototypes compress rungs 4-5.** With AI app builders, AI design tools, and AI coding assistants, a clickable or working prototype can take hours rather than weeks. That makes it tempting to skip rungs 1-3 — don't: a polished prototype of the wrong opportunity is still waste. Use a generated prototype when the assumption under test is usability or desirability, generate 2-3 variants (one per candidate solution) rather than one, and test with real target users against a pre-set threshold. Record the result on the tree node; the winning solution then goes to `execution/create-prd/` (see its Prototype-First Path) for the problem, metrics, constraints, non-goals, and risks the prototype cannot carry.

## Common engagements

### "Help me set up an OST for our team this quarter"
1. Confirm the outcome (1 number).
2. Pull existing discovery evidence; cluster into opportunities.
3. Brainstorm 3-5 solutions per top opportunity.
4. Identify top 3 assumption tests for the quarter.
5. Schedule weekly OST update rhythm.

### "Our roadmap is full of features but outcomes aren't moving"
1. Map current roadmap to OST.
2. Identify orphan solutions (no opportunity → no outcome).
3. Identify gaps (opportunities without solutions in roadmap).
4. Reshape roadmap around outcome-supporting solutions.

### "Audit our discovery practice"
1. Look at the OST: when last updated?
2. How many interviews per week feed it?
3. Are opportunities written as needs (not solutions)?
4. How many solutions per opportunity (1 = under-divergent)?
5. How many assumption tests in progress?

## Anti-patterns to avoid

- **Outcome = output.** "Ship X" is not an outcome.
- **Opportunities = solutions.** Strip solutions out of the opportunity layer.
- **Single solution per opportunity.** Force 3+ alternatives.
- **No assumption tests.** Tree without tests = wishful thinking.
- **Static tree.** Update weekly or it dies.
- **Tree built without customer input.** Designed in vacuum; full of bias.
- **One huge outcome.** Decompose to team-level.
- **All opportunities equally important.** Prioritize explicitly.

## References

- `references/ost-fundamentals.md` — Teresa Torres framework deep
- `references/ost-anti-patterns.md` — common failures + fixes

## Related skills

- `project-management/discovery/identify-assumptions` — assumption surfacing
- `project-management/discovery/brainstorm-experiments` — test design
- `project-management/discovery/customer-interview-script` — interview prep
- `project-management/discovery/interview-synthesis` — turn interviews into opportunities
- `project-management/execution/north-star-metric` — outcome definition
- `project-management/strategy-frameworks/lean-canvas` — strategic context
- `product-team/research-summarizer` — interview synthesis