Skills / Product-management

Opportunity Solution Tree

Opportunities are needs, pain points, and desires. They are not solutions.

The Opportunity Solution Tree is a visual discovery framework by Teresa Torres that structures product decision-making as a four-level tree: desired outcome at the root, then the opportunity space (customer needs, pain points, desires), then candidate solutions, then assumption tests. It is the operating system behind 'continuous discovery' — the habit of weekly customer interviews that keep teams anchored in real customer needs rather than internal assumptions. It is for product trios (PM, designer, engineer) who want to stop building features nobody uses and start making outcome-driven decisions grounded in evidence.

By Teresa Torres  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisOpportunity Solution Tree

Input

“We want to increase the number of users who complete their first project in our project management tool. Right now only 30% of new users finish a…”

Diagnosis

I can help you build or critique an Opportunity Solution Tree.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Stop jumping to solutions — map outcomes, opportunities, and experiments before you build

The Opportunity Solution Tree organizes product discovery as a four-level visual structure. The root is the desired outcome — the specific business or product metric the team is accountable for moving. The second level is the opportunity space: customer needs, pain points, and desires surfaced through weekly story-based interviews, never solutions. The third level is candidate solutions mapped beneath the opportunities they address. The fourth level is assumption tests — the smallest viable experiments that de-risk each solution before investment. Torres's framework enforces strict rules at each level: opportunities must describe customer experience, not internal features; solutions must be compared and contrasted against the same opportunity simultaneously rather than evaluated in isolation; and assumption mapping forces teams to surface and rank the riskiest beliefs behind any solution before committing to build it. The discipline is continuous: product trios run at least one customer interview per week and update the tree in real time.

The problem

Product teams default to solution-first thinking: they collect customer feedback, skip straight to feature ideas, and build things that don't move the needle. The most common mistake Torres diagnoses is treating solutions as opportunities — writing 'add a dashboard' where the tree should say 'users can't track their progress.' Without a systematic structure separating the opportunity space from the solution space, teams optimize for output over outcome and never know which customer problem they were actually trying to solve.

The solution

Build a living Opportunity Solution Tree that forces outcome-driven thinking at every step — so your team can see the full opportunity space, compare solutions against the same customer need, and test the riskiest assumption before writing a line of code.

You bring

Your desired outcome — the specific metric or business result your team is accountable for
Customer interview notes, verbatims, or synthesized observations from your research
A proposed solution or a shortlist of solution ideas you're considering
Any constraints your team is working within (timeline, technology, team size)

You get

A structured Opportunity Solution Tree mapping outcome → opportunities → solutions → experiments
An Assumption Map for your proposed solution with each assumption rated by likelihood and severity
An Experiment Design Card for your riskiest assumption — the smallest valid test to de-risk it
Story-based interview questions targeting a specific opportunity in your tree

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team has just finished a round of user interviews. Someone summarizes: 'Users want a better onboarding checklist, an in-app tutorial, and easier team invites.' Your PM writes three tickets. Six weeks later, all three ship — and the 30-day completion rate barely moves. Nobody's sure which intervention (if any) addressed the actual problem, and you're back at the start.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Opportunity Solution Tree

“Your desired outcome is pinned at the root of the tree. Three customer opportunities are mapped beneath it — each grounded in a specific story from a real interview, each clearly a customer experience rather than a feature idea. Your two candidate solutions sit beneath the highest-priority opportunity, and their riskiest assumptions have been surfaced and ranked. Before a single line of code is written, a one-week concierge test has already told you which assumption is wrong — saving six weeks of engineering and a round of 'why didn't this move the metric?' postmortems.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Opportunity Solution TreeClaude

Opportunity Solution Tree

I can help you build or critique an Opportunity Solution Tree. To start, I need your desired outcome — the specific metric your team is accountable for moving. This is the root of the tree, and everything else must connect back to it. What outcome are you working toward right now?

We want to increase the number of users who complete their first project in our project management tool. Right now only 30% of new users finish a project in their first 30 days.

Good — that's a clean desired outcome: increase first-project completion rate within 30 days of signup. Now let's build out the opportunity space. What do you know about why new users don't complete their first project? Share any customer interview notes, support tickets, or observations you have — even rough ones. I'll help you sort them into opportunities (customer needs, pain points, desires) and flag anything that's sneaking in as a solution.

Here's what we've heard: users say they don't know where to start, they get confused by all the settings, some said they wish there was a checklist, and a few said their team wasn't using the tool so they abandoned it.

Let me sort these into the opportunity space. Three of these map cleanly to customer experiences:

Opportunity 1: New users don't know what action to take first (orientation pain point)Opportunity 2: New users feel overwhelmed by unfamiliar configuration options (cognitive load)Opportunity 3: New users can't get their team to adopt the tool alongside them (social/coordination need)

One item — 'they wish there was a checklist' — is a solution request, not an opportunity. The opportunity underneath it is probably Opportunity 1 (users don't know what to do first). I'd keep it off the opportunity layer and let it compete as one of several possible solutions to that need.

Which of these three opportunities do you want to prioritize first? We can look at reach, impact, and saturation to decide.

I think the team adoption one is huge — we know from churn data that solo users almost never stick around. Let's work on that opportunity.

Solid. So our target opportunity is: New users can't get their teammates to start using the tool alongside them during their first project. Now, what solutions are you considering for this? List everything — even half-baked ideas — and I'll help you map them against this opportunity and start extracting assumptions. Torres's guidance here is to always compare multiple solutions against the same opportunity simultaneously rather than falling in love with one idea before testing it.

We've talked about: in-app team invite flow during onboarding, a 'bring your team' email sequence, and a shared project template that makes collaboration obvious from day one.

Good — three solutions, same opportunity. Let me build your Assumption Map for the most promising one. The shared project template carries interesting assumptions. Here are the four I'd stress-test:

| Assumption | Type | Likelihood | Severity if Wrong ||---|---|---|---|| New users will recognize the template as 'designed for a team' | Desirability | Medium | High || Users can share a project link with teammates before those teammates have accounts | Feasibility | Low | Critical || Teammates will create accounts when invited mid-project rather than asking to use a different tool | Desirability | Low | Critical || Completing a template together constitutes enough value to establish a usage habit | Desirability | Medium | High |

The two 'Low likelihood / Critical severity' assumptions are your testing priority. The riskiest is assumption 3 — you're betting teammates will onboard just because someone shared a project link. Want me to design the smallest valid experiment to test that before you build anything?

Yes — what would that experiment look like?

Here's your Experiment Design Card:

Assumption being tested: Teammates will create accounts when a project is shared with them during onboarding.

Experiment type: Concierge test (manual, no engineering required)Method: When a new user signs up this week, a team member manually sends their listed teammates a personal email with a link to a sandbox version of the shared project. No in-app mechanism — just simulate the experience.Success metric: ≥40% of invited teammates create an account and open the project within 48 hours.Sample size: 10 new signups (50 invited teammates total).Timeline: 1 week.Decision rule: If ≥40% activate → build the in-product invite flow. If <40% → interview non-activating teammates to find out what blocked them before writing a line of code.

This test will tell you whether the core desirability assumption holds — without touching your codebase.

Reply to Opportunity Solution Tree…

What the skill is doing

01OST Construction

02Opportunity vs. Solution Classification

03Opportunity Prioritization

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

OSOpportunity Solution Treetyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We want to increase the number of users who complete their first project in our project management tool. Right now only 30% of new users finish a proj…9:14✓✓

I can help you build or critique an Opportunity Solution Tree.9:14

To start, I need your desired outcome — the specific metric your team is accountable for moving.9:15

This is the root of the tree, and everything else must connect back to it.9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

OST Construction

Builds a four-level Opportunity Solution Tree from your desired outcome and customer interview input. Structures the opportunity space hierarchically (parent opportunities and sub-opportunities), maps your candidate solutions to the opportunities they address, and populates the experiment layer with assumption tests. Produces a diagram you can use in team planning sessions.

◦ MethodBased on Torres's four-level tree definition: outcome (root) → opportunity space (customer needs, pain points, desires) → solutions → assumption tests, as defined in Continuous Discovery Habits.

CapabilityC-02

Opportunity vs. Solution Classification

Audits a list of items — backlog entries, HMW statements, customer quotes, feature requests — and classifies each as an opportunity (customer experience) or a solution (product response). Flags mislabeled items and rewrites them into correct framing. This is the most common mistake Torres identifies in teams new to the OST.

◦ MethodApplies Torres's definitional rule: 'Opportunities are needs, pain points, and desires — they are not solutions.' A stated need like 'users want one-click export' is actually a solution; the underlying opportunity is 'users need to get their data out of the product quickly.'

CapabilityC-03

Opportunity Prioritization

Evaluates the opportunities in your tree using Torres's prioritization criteria: how many customers experience this opportunity (reach), how much it matters to them (impact), and how well existing solutions already address it (saturation). Produces a ranked shortlist of the highest-leverage opportunities to address next.

◦ MethodBased on Torres's opportunity prioritization guidance in Continuous Discovery Habits, which explicitly warns against picking the 'biggest pain point' without accounting for saturation — how well competitors or existing features already serve that need.

CapabilityC-04

Assumption Mapping

Extracts the key assumptions underlying a proposed solution and organizes them on a two-axis map: likelihood (how confident are we this is true?) vs. severity (how badly do we fail if it's wrong?). Surfaces the quadrant of assumptions that are both uncertain and critical — your testing priority. Outputs a filled Assumption Map you can bring into a sprint planning discussion.

◦ MethodImplements Torres's assumption mapping methodology from Continuous Discovery Habits: identifying desirability, viability, feasibility, and usability assumptions, then stress-testing them before committing to build.

CapabilityC-05

Experiment Design

Takes the riskiest assumption from your Assumption Map and designs the smallest viable experiment to test it — before you invest in building. Specifies the experiment type (customer interview probe, smoke test, prototype, concierge test), the success metric, the sample size, and what you'll do with each result.

◦ MethodGrounded in Torres's principle that teams should test assumptions with the lightest-weight method possible, using the assumption's position on the map (high uncertainty + high severity) to select the appropriate experiment type.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Opportunity Solution Tree Diagram

A structured four-level tree showing your desired outcome at the root, opportunity space branches below it (parent and sub-opportunities), candidate solutions beneath each opportunity, and assumption tests at the leaves. Use it in sprint planning, roadmap reviews, and team discovery rituals.

OutputD-02

Assumption Map

A two-axis grid plotting your solution's key assumptions by likelihood (how confident are we this is true?) and severity (how bad if wrong?). The top-left quadrant — uncertain and critical — is your testing backlog. Includes one row per assumption with type (desirability / viability / feasibility / usability) and recommended test method.

OutputD-03

Experiment Design Card

A single-page test plan for your riskiest assumption: experiment type, success metric, minimum viable sample, timeline, and decision rule (what result means proceed vs. pivot vs. kill). Designed to fit in a single team standup.

OutputD-04

Story-Based Interview Guide

A set of interview questions targeting a specific opportunity in your tree — phrased to elicit specific past stories rather than opinions or hypotheticals. Includes an opening prompt, follow-up probes, and a reminder of what to listen for (needs, pain points, desires) vs. what to ignore (solution requests).

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Teresa Torres

Teresa Torres is the author of Continuous Discovery Habits (2021) and creator of the Opportunity Solution Tree framework, widely adopted across the product management community. She has coached hundreds of product teams at companies including Spotify, Intercom, and Netlify, and writes the Product Talk blog, one of the most-referenced resources in modern product discovery practice.

Status · Inspired by Teresa Torres’s work — not yet claimed. Are you Teresa Torres?

Primary sourceS-01

Continuous Discovery Habits (2021)

by Teresa Torres

Author of Continuous Discovery Habits (2021); product discovery coach to teams at Spotify, Intercom, and Netlify; founder of Product Talk.

Read the original ↗

Citationproducttalk.org

In the build queue

Be first to run it.

Opportunity Solution Tree is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI want to build an Opportunity Solution Tree. My desired outcome is increasing 30-day first-project completion from 30% to 50%. Here are snippets from our last three customer interviews — can you help me map the opportunity space and make sure I'm not smuggling solutions in as opportunities?