Opportunity Solution Tree (OST)
Teresa Torres' discovery framework: desired outcome → 3 opportunities → 3 solutions each → POC selection with feasibility/impact/market fit scoring and experiment design.
Your stakeholder asked for feature X, the exec team wants feature Y, and your backlog already has feature Z — but none of them connect to a business outcome you can actually move. The OST forces the conversation upstream: what outcome are we driving, which three customer problems matter most, and what's the cheapest experiment to learn before building anything?
Who it's for: PMs running discovery, teams adopting continuous discovery, product leads clarifying vague OKRs, founders moving from feature requests to outcomes, UX leads structuring problem-solution exploration
Example
"Build an OST for increasing trial-to-paid conversion from 15% to 25%" → 3 opportunities (no value in trial, pricing unclear, free plan good enough) + 3 solutions each (guided checklist, time-to-value triggers, concierge onboarding) + POC scoring table + A/B test plan
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add opportunity-solution-tree# Opportunity Solution Tree (OST)
Build a Teresa Torres-style Opportunity Solution Tree by extracting target outcomes from stakeholder requests, generating opportunity options (problems to solve), mapping potential solutions, and selecting the best proof-of-concept (POC) based on feasibility, impact, and market fit. Move from vague requests to structured discovery — avoiding feature-factory syndrome and premature solution convergence.
Not a roadmap generator — a structured discovery process that outputs validated opportunities with testable solution hypotheses.
## What is an OST?
Visual framework (from Teresa Torres, *Continuous Discovery Habits*) connecting:
```
Desired Outcome (1)Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Two-phase structured discovery: Phase 1 builds the OST (outcome → 3 opportunities → 3 solutions per opportunity → 9 total solutions), Phase 2 selects the POC using feasibility/impact/market fit scoring and picks an experiment (A/B, prototype, concierge).
Built on Teresa Torres' Continuous Discovery Habits. Pairs with problem-statement, jobs-to-be-done, epic-hypothesis, and discovery-interview-prep.
Quick Start
mkdir -p ~/Documents/OST
mv ~/Downloads/CLAUDE.md ~/Documents/OST/
cd ~/Documents/OST
claude
Provide the stakeholder request, existing context (OKRs, customer research, usage data), and desired outcome. Claude walks through both phases and delivers a complete OST + POC plan.
The Structure
Outcome (1)
↓
Opportunity × 3
↓
Solution × 3 per opportunity (9 total)
↓
POC selection (score feasibility + impact + market fit)
↓
Experiment (A/B, prototype, concierge)
POC Scoring Rubric
| Dimension | 1 | 3 | 5 |
|---|---|---|---|
| Feasibility | Months of work | Weeks | Days |
| Impact | Minimal outcome movement | Moderate | Major shift |
| Market Fit | Customers don't care | Nice-to-have | Actively request |
Pick the solution balancing all three — not just the highest total.
Tips & Best Practices
- Opportunities are problems, not solutions in disguise. "We need a mobile app" is not an opportunity.
- Force 3+ solutions per opportunity. One solution = stakeholders already decided.
- Make outcomes measurable. "Improve UX" is uncheckable; "NPS 30 → 50" is a decision.
- Cap exploration at 3×3. Analysis paralysis kills the framework.
- Every solution maps to an experiment. No experiment = no OST, just a wish list.
Common Pitfalls
- Opportunities disguised as solutions ("we need dark mode")
- Jumping to one solution without divergence
- Vague, unmeasurable outcomes
- Skipping experiment design ("let's just build it")
- Generating 20 opportunities and 50 solutions with no POC selection