Do I need to be interviewing customers to use this?

In practice yes. A tree filled with opportunities the team assumed looks researched and is not, and that appearance is worse than an empty tree because it stops the questions.

How many opportunities should sit under an outcome?

As many as you have actually heard. The work is choosing which one to target next, so a tree with a single opportunity is not a tree, it is a decision already made.

Where do stakeholder requests go?

Under the opportunity they serve, as a solution. That moves the conversation from whether to build it to what need it meets, and whether anything else meets that need better.

How often should it change?

Every week you talk to customers. A tree that has not changed in a month usually means discovery has stopped.

Discovery

Opportunity solution tree

One measurable outcome at the top, the opportunities you heard in research beneath it, candidate solutions under each opportunity, and the experiment that would settle the riskiest assumption.

What it is

An opportunity solution tree is a picture of how a team believes it will reach an outcome. The outcome sits at the top, the opportunities below it are the needs and pain points that could move it, solutions hang under the opportunities, and experiments hang under the solutions. Teresa Torres published the format in Continuous Discovery Habits.

Its value is that it makes the reasoning visible. A team that jumps from an outcome straight to a feature has usually skipped the opportunity, and once the tree is drawn everyone can see the branch with nothing under it. It also shows when three solutions are competing to serve the same opportunity, which is the moment to compare them rather than build all three.

One rule keeps it honest. Opportunities come from customers, so an opportunity the team invented belongs in the tree only once somebody has heard it said out loud.

When to use it

Your team has an outcome to move and a list of feature ideas with no argument connecting them.
You are running interviews and want somewhere to put what you hear.
Two solutions are being debated and it is not clear whether they serve the same need.
You want to show a stakeholder why a request is not being built yet without simply saying no.

What is in it

The outcome
The tree
Rules that keep the tree honest
The assumption under test this cycle

The template

Owner [name] / Research behind it [number] interviews, [dates] / Updated [date]

The outcome

One measurable outcome at the top of the tree, with its baseline and target. Everything below has to serve this one. If a branch does not, it belongs on someone else's tree.

For example, raise the share of new workspaces with one live integration by day seven from 22% to 40%.

The tree

Opportunities are needs, pains and desires you heard from customers, written in their language. Solutions are things you might build. Experiments are the smallest thing that would tell you whether a solution works.

Outcome. New workspaces reach a live integration by day seven
- Opportunity 1. I do not know which of these integrations my team actually needs
  - Solution. Recommend integrations from the tools already on the account domain
    - Experiment. Fake door on the setup screen for two weeks, measure click through
  - Solution. A short setup interview on first run
    - Experiment. Concierge test with 10 new accounts, run by hand
- Opportunity 2. I got as far as the API key and stopped
  - Solution. One click authorisation for the three most used tools
    - Experiment. Instrument the current drop off first, then prototype with 5 admins
- Opportunity 3. I set it up and I cannot tell whether it is working
  - Solution. A sync status panel with the last successful run
    - Experiment. Show a static mock in five interviews and ask what they expect next

Rules that keep the tree honest

Every opportunity traces to something a person said. Put the interview reference next to it, and delete any branch that cannot carry one.
An opportunity is not a solution with a question mark on it. "Needs a recommendation engine" is a solution. "I do not know which integration my team needs" is an opportunity.
Solutions live under one opportunity only. A solution that appears three times is usually a platform decision rather than a bet.
Compare solutions within an opportunity, never across the whole tree. The comparison is only fair when the need is held still.

The assumption under test this cycle

Name the single riskiest assumption on the tree right now, the experiment that addresses it, and the date you will have the answer. One at a time is the whole discipline.

Assumption	Why it is the riskiest	Experiment	Answer by
Admins will accept a recommendation based on their email domain	The other two opportunities only matter if this one is wrong	Fake door on the setup screen	26 Sep

A tree with thirty solutions and no assumption under test is a wall of sticky notes. The value comes from choosing which branch you are prepared to be wrong about this month.

Questions people ask

Do I need to be interviewing customers to use this?: In practice yes. A tree filled with opportunities the team assumed looks researched and is not, and that appearance is worse than an empty tree because it stops the questions.
How many opportunities should sit under an outcome?: As many as you have actually heard. The work is choosing which one to target next, so a tree with a single opportunity is not a tree, it is a decision already made.
Where do stakeholder requests go?: Under the opportunity they serve, as a solution. That moves the conversation from whether to build it to what need it meets, and whether anything else meets that need better.
How often should it change?: Every week you talk to customers. A tree that has not changed in a month usually means discovery has stopped.