---
name: define-opportunity-tree
description: Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
license: Apache-2.0
metadata:
phase: define
version: "2.2.0"
updated: 2026-07-04
category: problem-framing
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
---
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Opportunity Solution Tree
An Opportunity Solution Tree (OST) is a visual framework for product discovery that connects business outcomes to customer opportunities and potential solutions. Developed by Teresa Torres, it prevents the common trap of jumping straight to solutions by ensuring every feature idea traces back to a customer need and measurable outcome.
## When to Use
- During continuous product discovery to organize learning
- When prioritizing what opportunities to pursue
- To communicate product strategy to stakeholders
- When you have too many feature ideas and need structure
- After user research to connect insights to action
- When aligning team on what outcomes matter most
## When NOT to Use
- You need to score and rank a flat list of known candidates -> use `define-prioritization-framework`; the tree structures discovery, not a ranking exercise
- You have one specific problem to frame for a team -> use `define-problem-statement`
- You are ready to test a single assumption -> use `define-hypothesis`, then `measure-experiment-design`
- The outcome you want to drive is not yet agreed -> set it first with `foundation-okr-writer`; a tree without an agreed outcome decorates opinions
## Instructions
When asked to create an opportunity solution tree, follow these steps:
1. **Define the Desired Outcome**
Start at the top with a clear, measurable business or product outcome. This should be something you can influence through product changes. Express it quantitatively when possible (e.g., "Increase 30-day retention from 40% to 55%").
2. **Identify Opportunity Areas**
Branch out to 3-5 opportunity areas.places where customer needs or pain points could be addressed. Opportunities are not solutions; they're customer problems, needs, or desires. Phrase them from the customer's perspective.
3. **Add Supporting Evidence**
For each opportunity, note the evidence that supports it: user research quotes, behavioral data, support tickets, or market trends. Strong opportunities have multiple evidence sources.
4. **Brainstorm Solutions**
For each opportunity, generate 2-4 potential solutions. Don't self-censor at this stage. Solutions can range from quick experiments to major features. Keep them specific enough to evaluate.
5. **Define Assumption Tests**
For each promising solution, identify the riskiest assumption and design a lightweight experiment to test it. Good tests validate whether the solution will actually address the opportunity.
6. **Prioritize the Tree**
Not all branches are equal. Mark which opportunity and solution you'll pursue first based on potential impact, confidence, and effort. The tree is a living document.you'll iterate as you learn.
7. **Visualize the Structure**
Create a tree diagram showing the hierarchy: outcome at top, opportunities below, solutions beneath each opportunity, and experiments at the leaves.
## Output Format
Use the template in `references/TEMPLATE.md` to structure the output. A complete tree fills every template section: Desired Outcome; Visual Tree; Opportunity Branches; Prioritization; Experiments Backlog; Learning Log; and Next Steps.
## Quality Checklist
Before finalizing, verify:
- [ ] Outcome is measurable and within product team's influence
- [ ] Opportunities are customer-centric (needs/problems, not features)
- [ ] Each opportunity has supporting evidence documented
- [ ] Multiple solutions exist per opportunity (not jumping to one)
- [ ] Assumptions are explicit and experiments designed
- [ ] Prioritization is clear (which branch to explore first)
## Examples
See `references/EXAMPLE.md` for a completed example.