Opportunity Solution Tree

---
name: opportunity-solution-tree
description: Use when deciding what to build next — which problem to solve — rather than specifying a solution you've already chosen. Triggers on "opportunity solution tree", "OST", "what should we build", "prioritize discovery", "Teresa Torres", "continuous discovery", "which problem to work on".
---

# Opportunity Solution Tree

The OST is a decision-making framework, not a brainstorming tool. It forces a single outcome at the root, which prevents the team from optimizing for the wrong goal or splitting attention across objectives.

## Required inputs

1. **Desired outcome** — a single, measurable business metric the product team can influence. If the team gives you two outcomes, push back: run separate trees or pick the one with the shorter feedback loop.
2. **Opportunity input** — interview notes, support tickets, retention data, or churn analysis. The tree reflects what customers actually experience; don't let it become a brainstorm of what the team thinks customers want.
3. **Time horizon** — discovery sprints (weekly experiments) vs. larger bets (quarter-level). Affects how many nodes to map and how deep to go.

## Tree structure

```
[Desired outcome]
├── Opportunity 1 (unmet need or pain)
│   ├── Solution A
│   │   └── Experiment: [assumption to test] → [cheapest test]
│   └── Solution B
│       └── Experiment: [assumption to test] → [cheapest test]
├── Opportunity 2
│   └── Solution C
│       └── Experiment: [assumption to test] → [cheapest test]
└── Opportunity 3
    └── Solution D
        └── Experiment: [assumption to test] → [cheapest test]
```

## Layer 1 — Desired outcome

One metric. One direction. One team.

- Must be a lagging indicator the team owns (trial-to-paid conversion, 30-day retention, activation rate)
- Avoid vanity metrics (signups, page views) that don't connect to business health
- Avoid inputs (ads spend, content published) that the team controls directly — those aren't outcomes

## Layer 2 — Opportunity nodes

An opportunity is an unmet customer need, pain point, or desire — not a solution, not a feature, not an idea. Opportunities come from evidence: interviews, support tickets, session replays, churn data. If an opportunity has no evidence, label it as an assumption and mark it for validation before building a solution branch beneath it.

Cluster and deduplicate. Two interviews saying the same thing in different language are one opportunity, not two.

**Opportunity statement format:** "Customers struggle to [specific task or experience] when [context], which means they [consequence]."

Example: "Customers struggle to understand their first bill when switching from a trial to a paid plan, which means they cancel before the charge resolves."

## Layer 3 — Solution branches

Solutions are how you might address an opportunity — not the final spec. Keep them brief: a named concept, not a PRD. One opportunity can have multiple solution branches; they're hypotheses, not commitments.

Rule: **never start building a solution until you've identified the assumption that would kill it if wrong.** That assumption becomes the experiment.

## Layer 4 — Experiments

The cheapest test that would change your mind about the solution.

- **What's the assumption?** ("Users will pay X more per month for this")
- **What's the test?** ("Fake door CTA → measure click-through"; "5 prototype walkthroughs"; "1 week of manual fulfillment")
- **What outcome kills the solution?** ("If fewer than 30% click, the demand signal isn't there")

Experiments are not user interviews — they produce evidence that a specific solution is worth building. Interviews belong in the opportunity layer.

## How to prioritize opportunities

Use three lenses:

1. **Frequency** — how many customers experience this? (interview count, ticket volume)
2. **Magnitude** — how much does it cost them when it happens? (time, money, risk)
3. **Strategic alignment** — does solving it pull the North Star metric?

Don't prioritize by which solution is easiest to build — solution complexity is irrelevant until you've validated demand.

## Mermaid output (optional)

```mermaid
graph TD
  A["Desired outcome: [metric]"] --> B["Opportunity: [pain]"]
  A --> C["Opportunity: [pain]"]
  B --> D["Solution: [concept]"]
  D --> E["Experiment: [test]"]
  C --> F["Solution: [concept]"]
  F --> G["Experiment: [test]"]
```

## When the tree reveals you shouldn't build anything yet

If opportunities are vague, unsupported by evidence, or all cluster around "users don't understand the product" — the work is more discovery (interviews, session replays), not tree-building. An OST built from assumptions is just a roadmap with extra steps.

## Anti-patterns

- **A solution disguised as an opportunity** — "build a mobile app" is not an opportunity; "users can't access [X] on the go, costing them Y" is
- **Too many outcomes at the root** — collapse to one or run two separate trees
- **Skipping the experiment layer** — a tree without experiments is a guess pyramid, not a discovery framework
- **Mixing granularity** — "reduce churn" and "fix the billing email" aren't at the same level; the second is a solution to the first
- **Treating OST as a planning artifact** — it's a living document; prune branches where experiments failed