opportunity-solution-tree

Opportunity Solution Tree (OST)

Teresa Torres' Opportunity Solution Tree prevents building features that don't matter. It ensures every solution you build is connected to a real user pain and a business outcome you care about.

The Framework

Desired Outcome
└── Opportunity 1 (user pain / unmet need)
│   ├── Solution A
│   │   ├── Experiment 1
│   │   └── Experiment 2
│   └── Solution B
└── Opportunity 2
    └── Solution C

Outcome: A measurable business goal (OKR-level: "Increase trial-to-paid conversion by 15%") Opportunity: A user pain, unmet need, or desire (discovered through research) Solution: A product change that might address the opportunity Experiment: The smallest thing you can build to test if the solution works

Workflow

Step 1: Define the Desired Outcome

> I'm building the OST for: [product/feature area]
>
> Help me define 1 crisp desired outcome. It should be:
> - Measurable (has a metric)
> - Achievable within the quarter
> - Aligned with business goals
>
> Context: Our goal is [business context]. Key metric: [current baseline].

Keep one outcome metric, then decompose it into two to four leading input metrics the team can move weekly. The outcome is usually lagging; for each input, state the causal contribution you expect and how the team can influence it. This preserves one outcome at a time while allowing several diagnostic and actionable inputs beneath it.

Step 2: Map the Opportunity Space

> Now let's map the opportunity space for this outcome.
>
> Based on [user research / support tickets / interview data / NPS feedback]:
> > [paste data here]
>
> Identify the top 5-7 user opportunities (pains, needs, desires) that, if addressed,
> would most directly improve [outcome metric].
>
> Format as a prioritized list with a one-sentence "when I [situation], I struggle to [pain]" statement for each.

Step 3: Generate Solutions

For each top opportunity:

> For the opportunity: "[opportunity statement]"
>
> Generate 5-7 possible solutions. Include:
> - Conventional solutions (what everyone would build)
> - Lateral solutions (unexpected approaches)
> - Low-tech or process solutions (not just feature builds)
>
> For each, estimate: effort (S/M/L), confidence (Low/Med/High), impact potential (Low/Med/High)