Skill292 repo starsupdated 2d ago
define-opportunity-tree
The Opportunity Solution Tree skill creates a visual framework connecting measurable business outcomes to customer needs and product solutions. Use it during discovery to structure feature ideas, prioritize opportunities based on evidence, align teams on strategy, or translate user research into actionable solutions without jumping prematurely to implementation.
Install in Claude Code
Copygit clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/define-opportunity-tree && cp -r /tmp/define-opportunity-tree/skills/define-opportunity-tree ~/.claude/skills/define-opportunity-treeThen start a new Claude Code session; the skill loads automatically.
Definition
SKILL.md
<!-- 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.
More from this repository
pm-changelog-curatorSubagent
|
pm-criticSubagent
|
pm-release-conductorSubagent
|
pm-skill-auditorSubagent
|
pm-workflow-orchestratorSubagent
>-
workflow-customer-discoverySlash Command
Run the Customer Discovery workflow (research -> JTBD -> opportunities -> problem)
workflow-design-sprintSlash Command
Run the Design Sprint workflow (5-day prototype-and-test arc producing a Decider's build/iterate/pivot/stop call)
workflow-feature-kickoffSlash Command
Run the Feature Kickoff workflow (problem -> hypothesis -> PRD -> stories)