
Opportunity Solution Trees
- 315 installs
- 43 repo stars
- Updated March 7, 2026
- pmprompt/claude-plugin-product-management
opportunity-solution-trees is an agent skill that maps customer opportunities to solution options using Teresa Torres Opportunity Solution Trees for developers and PMs who need testable discovery scope before delivery.
About
opportunity-solution-trees is a pmprompt/claude-plugin-product-management skill implementing Teresa Torres's Opportunity Solution Tree with four levels: desired outcome, opportunities, solutions, and experiments. The agent helps articulate a single measurable outcome, extract three to seven customer-framed opportunities, prioritize with Opportunity Score (Importance × [1 − Satisfaction]), brainstorm at least three solutions per opportunity with Product Trio input, and design fast assumption tests for value, usability, viability, and feasibility. Engineering leads and PMs reach for this skill when discovery feels like a feature backlog, when stakeholders disagree on what problem to solve, or when continuous discovery needs a shared visual map tied to OKRs.
- Outcome-to-opportunity mapping
- Solution option branching
- Assumption and experiment framing
- Discovery prioritization structure
- Shared artifact for product alignment
Opportunity Solution Trees by the numbers
- 315 all-time installs (skills.sh)
- +16 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #866 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pmprompt/claude-plugin-product-management --skill opportunity-solution-treesAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 315 |
|---|---|
| repo stars | ★ 43 |
| Last updated | March 7, 2026 |
| Repository | pmprompt/claude-plugin-product-management ↗ |
How do you map customer opportunities to product solutions?
Map customer opportunities to solution options using Opportunity Solution Trees to narrow discovery, align bets, and define a testable product scope.
Who is it for?
PMs and tech leads running continuous discovery who have customer research and need to compare solutions before locking roadmap scope.
Skip if: Commodity requirements with a fixed spec, teams skipping customer research, or decisions where the solution is already chosen.
When should I use this skill?
User mentions opportunity solution tree, OST, Teresa Torres, or mapping customer opportunities to measurable outcomes.
What you get
Hierarchical Opportunity Solution Tree with outcome, prioritized opportunities, solution branches, and experiment hypotheses with success metrics.
- Opportunity Solution Tree diagram
- Prioritized opportunity list
- Experiment hypotheses with success thresholds
By the numbers
- Uses a 4-level Opportunity Solution Tree structure
- Targets 3–7 customer opportunities mapped to one outcome
- Requires at least 3 solutions brainstormed per prioritized opportunity
Files
Opportunity Solution Trees
Domain Context
The Opportunity Solution Tree (Teresa Torres, Continuous Discovery Habits) is the backbone of modern product discovery. It prevents teams from jumping to solutions by forcing them to first map the opportunity space.
Structure (4 levels):
1. Desired Outcome (top) — The measurable business or product outcome you're pursuing. Should be a single, clear metric (e.g., "increase 7-day retention to 40%"). This comes from your OKRs or product strategy.
2. Opportunities (second level) — Customer needs, pain points, or desires discovered through research. Frame them from the customer's perspective: "I struggle to..." or "I wish I could..." Prioritize using Opportunity Score: Importance × (1 − Satisfaction) (Dan Olsen).
3. Solutions (third level) — Possible ways to address each opportunity. Generate multiple solutions per opportunity — don't commit to the first idea. The Product Trio (PM + Designer + Engineer) should ideate together.
4. Experiments (bottom) — Fast, cheap tests to validate whether a solution addresses the opportunity. Use assumption testing (Value, Usability, Viability, Feasibility).
Key principles:
- One outcome at a time — don't try to solve everything
- Opportunities, not features — never let customers design solutions
- Compare and contrast — generate at least 3 solutions per opportunity
- Discovery is not linear — loop back if experiments fail
- Continuous, not periodic — update the tree weekly
Input Requirements
- A desired outcome or business metric to improve
- Customer research data (interviews, surveys, analytics, feedback)
- Optionally: existing opportunities or solution ideas to organize
What It Is
Use the Opportunity Solution Tree (OST) to connect a business outcome to the customer opportunities that drive it, then compare solutions and tests. The tree forces you to separate needs from ideas and keeps discovery tied to delivery.
When to Use It
- Structure discovery around customer opportunities
- Tie customer needs to measurable outcomes
- Compare multiple solutions for the same opportunity
- Keep continuous discovery aligned with the roadmap
- Create a shared view of priorities with stakeholders
When Not to Use It
- You are not doing customer research
- The solution is already decided
- The work is a commodity requirement with no real options
- You only need a quick one-off decision
Core Structure
- Outcome: the business result you are responsible for achieving
- Opportunities: unmet customer needs, pains, or desires
- Solutions: multiple ideas that address one opportunity
- Experiments: tests that validate the riskiest assumptions
Process
Follow this step-by-step process to build and use an Opportunity Solution Tree:
Step 1: Define the Desired Outcome
- Confirm or help articulate a single, measurable outcome at the top of the tree
- Make it specific (e.g., "increase 7-day retention to 40%" not "improve retention")
- Tie it to your OKRs or product strategy
Step 2: Map Opportunities
- From customer research, identify 3-7 customer opportunities (needs/pains/desires)
- Frame each from the customer's perspective ("I struggle to...", "I wish I could...")
- Group related opportunities into themes
- Avoid solutions disguised as opportunities (e.g., "needs a dashboard" → "struggles to understand performance")
Step 3: Prioritize Opportunities
- Use Opportunity Score (Importance × [1 − Satisfaction]) or qualitative assessment
- Focus on the top 2-3 opportunities
- Consider: impact on outcome, frequency, intensity of pain
Step 4: Generate Solutions
- For each prioritized opportunity, brainstorm 3+ solutions
- Include perspectives from PM, Designer, and Engineer (Product Trio)
- Resist the "first idea" trap — compare and contrast before choosing
Step 5: Design Experiments
- For the most promising solutions, suggest 1-2 fast experiments
- Specify: hypothesis, method, metric, success threshold
- Prefer experiments with "skin in the game" (Alberto Savoia) over opinion-based validation
Step 6: Visualize the Tree
- Present the full OST in a clear hierarchical format
- Use indentation, bullets, or a visual tool
- Make it easy for stakeholders to scan and understand
Step 7: Iterate Weekly
- Review the tree every week as you learn from interviews, analytics, experiments
- Kill solutions that don't validate
- Explore new branches as you discover new opportunities
Further Reading
- The Extended Opportunity Solution Tree
- What Is Product Discovery? The Ultimate Guide
- Product Trio: Beyond the Obvious
- Continuous Product Discovery Masterclass
- Continuous Discovery Habits by Teresa Torres (book)
Related skills
FAQ
What are the four levels of an Opportunity Solution Tree?
opportunity-solution-trees implements Teresa Torres's four levels: desired outcome at the top, customer opportunities second, multiple solutions third, and validation experiments at the bottom. The skill walks PMs through each level from research inputs.
How many solutions should each opportunity have?
opportunity-solution-trees requires at least three solutions per prioritized opportunity before selecting one. The Product Trio—PM, designer, and engineer—should ideate together to avoid committing to the first idea.