Opportunity Solution Tree

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.

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.

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.