Agile Pantry
Model

Opportunity Solution Tree

From Teresa Torres

A visual map from a desired outcome, through the customer opportunities that could drive it, to candidate solutions and the experiments that test them.

Meeting time 0.25 h/wkLearning curve Some practice

Helps with

late feedbackunclear priorities

Pairs well with

Continuous User InterviewsHypothesis-driven ExperimentsProduct Goal

Why it exists

Connect what the team builds to real customer needs and a business outcome, so discovery stays focused and solutions get compared instead of chosen on gut feel.

Why it works

Keeping the problem space (customer opportunities) separate from the solution space stops teams jumping to their first idea. Comparing several solutions for the same opportunity, and testing their riskiest assumptions cheaply, reduces the chance of building the wrong thing.

Before you start

  • A measurable outcome the team can influence.
  • Regular contact with customers, ideally weekly interviews.
  • The team is allowed to choose solutions, not just deliver a fixed roadmap.

Don’t use it when

  • The roadmap is fixed and the team has no say in what to build.
  • The work is mostly operational or service work.

Set it up for your context

If your team…Then
Just starting discoveryOne outcome, and opportunities drawn only from interview notes.
A large, fuzzy opportunity spaceBreak opportunities into smaller sub-opportunities until one is small enough to act on.
Several teams share an outcomeEach team keeps its own tree under the shared outcome.

How to introduce it

  1. Agree one outcome, expressed as a metric.
  2. Interview customers every week and capture each opportunity you hear.
  3. Arrange opportunities into a tree under the outcome, and choose one to target.
  4. Generate at least three solutions for it, and list their assumptions.
  5. Test the riskiest assumptions with small experiments, then choose.
  6. Revisit the tree every week.

Variations

Team tree
Built and owned by the product trio: product, design and engineering.
Assumption mapping
Plot each solution’s assumptions by importance and evidence to pick what to test first.

Common failure modes

Opportunities invented in the office

You’ll notice The tree reflects internal opinions, not customer evidence.

Fix Only add opportunities you heard in an interview.

A feature list in disguise

You’ll notice Opportunities are phrased as solutions.

Fix Phrase opportunities as customer needs or pains, and keep solutions at the bottom.

Output as the outcome

You’ll notice The top of the tree says “launch feature X”.

Fix The outcome must be a behaviour or metric, such as “increase weekly active teams”.

Signs it’s working

  • Every solution in progress traces back to an opportunity and the outcome.
  • Some solutions are dropped because a test said no.
  • The outcome metric moves.

What it costs

Setting up
Half a day to agree the outcome and draw the first tree.
Ongoing
About an hour a week, plus customer interviews.

How it connects

Sources