opportunity-solution-tree

Imported from borghei/claude-skills (project-management/discovery/opportunity-solution-tree/SKILL.md). Install upstream with npx skills add borghei/claude-skills --skill opportunity-solution-tree. Copyright stays with the author (MIT + Commons Clause).

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, settle the inputs below. When one is missing or vague and would change the result, ask about it; when it wouldn't, use a sensible default and say which one you used.

• 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).

Ask about the two or three inputs that matter most for this request, not the whole list. If the user wants a result straight away, produce it and state your assumptions at the top.

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.

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.

Scope & Limitations

In Scope:

• Building an Opportunity Solution Tree (Teresa Torres) from one outcome through opportunities and solutions to assumption tests
• The opportunity-versus-solution test, opportunity sizing and the rule of 3+ solutions per opportunity
• Value, usability, feasibility and viability assumptions per solution, with an assumption test ladder from interview to production A/B test
• A tree audit for outcome quality, opportunities written as solutions, single-solution branches, missing tests and stale trees (ost_validator.py)
• Mapping an existing roadmap onto the tree to find orphan solutions and gaps

Out of Scope:

• Running interviews or synthesizing them into opportunities (see project-management/discovery/customer-interview-script/ and project-management/discovery/interview-synthesis/)
• Designing the experiments in detail (see project-management/discovery/brainstorm-experiments/)
• Defining the company-level North Star (see project-management/execution/north-star-metric/)
• Building prototypes for assumption tests (see project-management/discovery/ai-prototyping/)

Important Caveats:

• ost_validator.py reads a hand-built JSON tree. Flags such as is_customer_phrased and has_evidence are self-reported, so the tool checks structure, not the quality of the evidence.
• Opportunity scoring (impact, frequency, strategic fit) is an estimate the team makes. The tool does not compute it from data.
• The tree goes stale without weekly updates. The validator warns when last_updated is more than 14 days old.

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