domains / business / opportunity-solution-tree / opportunity-solution-tree

opportunity-solution-tree

Skill card

combined

Both copies describe the same four-level Opportunity Solution Tree, but they are not interchangeable. The phuryn copy is a concise, self-contained procedure that adds the Opportunity Score formula (Importance × (1 − Satisfaction)) and specific experiment design fields (hypothesis, method, metric, success threshold). The deanpeters copy is an interactive facilitation skill that adds a two-phase process (generate OST, then select a POC), explicit anti-patterns, when-to-use/when-not-to-use guidance, and a dependency on a separate workshop-facilitation protocol. Crowning one would hide the other's real alternative workflow and scoring/facilitation constraints.

Repositories

Other copies

Combined skill

---
name: opportunity-solution-tree
description: "Build an Opportunity Solution Tree (OST) to structure product discovery — map a desired outcome to opportunities, solutions, and experiments. Based on Teresa Torres' Continuous Discovery Habits. Use when structuring discovery work, mapping opportunities to solutions, or deciding what to build next."
---

## Opportunity Solution Tree (OST)

A visual framework for structuring continuous product discovery. Connects a desired **outcome** to customer **opportunities**, possible **solutions**, and **experiments** to validate them.

### 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 the team is 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. These are problems worth solving — not features. Frame them from the customer's perspective: "I struggle to..." or "I wish I could..." Prioritize using Opportunity Score: **Importance × (1 − Satisfaction)** (Dan Olsen, *The Lean Product Playbook*). Normalize Importance and Satisfaction to 0–1.

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. "Best ideas often come from engineers."

4. **Experiments** (bottom) — Fast, cheap tests to validate whether a solution actually addresses the opportunity. Use assumption testing (Value, Usability, Viability, Feasibility risks). Prefer experiments with "skin-in-the-game" (Alberto Savoia) over opinion-based validation.

**Key principles:**

- **One outcome at a time.** Don't try to solve everything. Focus the tree on a single desired outcome.
- **Opportunities, not features.** "Never allow customers to design solutions. Prioritize opportunities (problems), not features."
- **Compare and contrast.** Always generate at least 3 solutions per opportunity before choosing. Avoid the "first idea" trap.
- **Discovery is not linear.** Loop back if experiments fail. Kill solutions that don't validate. Explore new branches.
- **Continuous, not periodic.** Update the tree weekly as you learn from interviews, analytics, and experiments.

### Anti-Patterns (What This Is NOT)
- **Not a feature list:** Opportunities are problems customers face, not "we need dark mode"
- **Not solution-first:** Don't start with "we should build X"—start with "customers struggle with Y"
- **Not waterfall planning:** OST is a discovery tool, not a project plan
- **Not a one-time exercise:** OSTs evolve as you learn from experiments

### When to Use This
- Stakeholder requests a feature or product initiative
- Starting discovery for a new product area
- Clarifying vague OKRs or strategic goals
- Prioritizing which problems to solve first
- Aligning team on what outcomes you're driving

### When NOT to Use This
- When the problem is already validated (move to solution testing)
- For tactical bug fixes or technical debt (no discovery needed)
- When stakeholders demand a specific solution (address alignment issues first)

### Instructions

You are helping a product team build an Opportunity Solution Tree for **$ARGUMENTS**.

### 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

### Process

1. **Define the desired outcome** — Confirm or help articulate a single, measurable outcome at the top of the tree.

2. **Map opportunities** — From provided research, identify 3-7 customer opportunities (needs/pains). Group related opportunities. Frame each from the customer's perspective.

3. **Prioritize opportunities** — Use Opportunity Score or qualitative assessment to rank. Focus on the top 2-3.

4. **Generate solutions** — For each prioritized opportunity, brainstorm 3+ solutions from PM, Designer, and Engineer perspectives.

5. **Design experiments** — For the most promising solutions, suggest 1-2 fast experiments. Specify: hypothesis, method, metric, success threshold.

6. **Select a proof-of-concept** — Evaluate the most promising solutions based on feasibility, impact, and market fit. Recommend the best starting point for a POC.

7. **Visualize the tree** — Present the full OST in a clear hierarchical format.

Think step by step. Save as markdown if substantial.

---

### Further Reading

- [The Extended Opportunity Solution Tree](https://www.productcompass.pm/p/the-extended-opportunity-solution-tree)
- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery)
- [Product Trio: Beyond the Obvious](https://www.productcompass.pm/p/product-trio)
- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)