Opportunity Solution Tree Mapping

An opportunity solution tree is a visual map connecting a desired outcome to customer opportunities, possible solutions and the assumption tests used to investigate them. Teresa Torres developed the framework to help product teams make their discovery reasoning visible.

A request to “add a chatbot” already contains a proposed solution. The underlying opportunity might be that a new learner cannot find a suitable place to start. Separating those statements makes other responses possible, including a better starter lesson or a guided route through existing material.

The four parts of an opportunity solution tree

Torres’s guide to opportunity solution trees describes four levels. The lines between them express reasoning to investigate, rather than proof that a solution will cause the desired outcome.

Level	What belongs here	Example for a learning product
Outcome	A measurable change the team wants to influence	More eligible new learners complete a first lesson within seven days
Opportunities	Customer needs, pain points and desires relevant to the outcome	A learner is unsure where to start
Solutions	Alternative ways to address a selected opportunity	A short starter lesson, a goal-based route, or a human recommendation
Assumption tests	Activities that investigate what must be true for a solution to work	Observe whether a learner can identify and attempt a suitable first task

The diagram shows a selected branch rather than a completed map of everything the product could do. “Hard to make time” remains a separate opportunity; it does not need a speculative solution attached just to make the drawing look finished.

Start with research, rather than a feature list

Bring a clear outcome, a defined customer group and research about real situations. The customer interview method can help the team investigate a recent experience instead of asking people to imagine what they might want.

An opportunity should describe the customer’s situation without requiring a particular implementation. A feature request can point toward a useful research question, but it does not establish the underlying need by itself.

Proposed statement	How to treat it
Add a chatbot	A solution candidate; investigate what prompted the request
Customers need a chatbot	The same solution disguised as a need
New learners are unsure which lesson fits their goal	A possible opportunity; attach the research that supports this interpretation
Increase first-lesson completion	An outcome, not a customer opportunity

In Discovering Solutions, Torres distinguishes interviewing to discover opportunities from assumption testing to evaluate solutions. Keep both activities visible. Agreement in a workshop cannot replace either one.

The learner’s words in this illustration are part of the hypothetical example below, not a quotation from a real study.

Worked example: helping a new learner start

This example is illustrative. The situations and planned tests are invented to explain the method, not reported research results.

A team wants to improve the share of newly enrolled learners who complete a first lesson within seven days. It defines the eligible cohort and completion event before discussing ideas. This keeps the outcome distinct from “launch an onboarding redesign.”

For this scenario, assume the team has research notes describing people who browse a catalogue but cannot tell which lesson suits their goal. It treats “find a suitable starting point” as the target opportunity and keeps “fit study into the day” as a different branch.

The first idea is a chatbot. Before selecting it, the team compares three other ways to address the starting-point opportunity:

Candidate solution	Assumption to investigate	Possible test
Short starter lesson	A small first task helps a learner understand how to begin	Give a participant a relevant goal and observe their attempt with a focused prototype
Goal-based guided route	Learners can recognize their goal among the offered routes	Observe route choices and ask what the participant expects to do next
Human recommendation	A conversation reveals enough context to recommend a useful first lesson	Try a limited concierge experiment, recording the help provided

The tree illustration shows the first two candidates. The third makes the manual alternative explicit. None has been validated simply because it fits beneath an opportunity node.

Suppose a test participant can choose a route but still does not attempt the first task. Record that behavior before explaining it. The task may be unclear, the time commitment may be wrong, or the chosen opportunity may be incomplete. Those are different explanations to investigate.

A successful route-choice test also would not establish seven-day completion or paid retention. The team needs to connect evidence from the focused tests with later product behavior. Use product experimentation to plan that broader sequence.

Plan tests for assumptions, not votes for features

For each candidate, ask what must be true about customer behavior, usability, delivery, economics or other important constraints. Use assumptions mapping to identify consequential beliefs that have little supporting evidence.

Torres’s assumption-testing guide explains why investigating specific assumptions can help teams compare alternatives without building each complete solution first. A test may involve a prototype, existing behavioral data or a focused technical investigation; the assumption determines the activity.

Write the task, observation and decision in the experiment sheet. Record what happened and what remains uncertain in the learning sheet. Do not use an experiment label as a substitute for specifying the evidence you need.

The workshop instructions below provide a 90-minute format for organizing this work with a team. Research and tests happen beyond the meeting; the session does not manufacture evidence.

Keep the tree current

Update the relevant branch when new research changes the opportunity or a test changes your view of a solution. Torres recommends revisiting the opportunity space after roughly three or four customer interviews; the calendar interval depends on the research cadence. Do not wait for a quarterly review when the team has already learned something that changes its decision.

Keep evidence links, dates, open questions and the reason for the current focus alongside the map. Include product, design and engineering perspectives in the reasoning, then use stakeholder review to surface constraints and questions rather than approve every node.

Opportunity solution tree vs. roadmap

A tree explains the possibilities being investigated and the reasoning connecting them. A roadmap communicates intended direction or commitments over time. Moving a solution onto a tree does not commit it for delivery, and a tidy map does not establish its impact.

Use the tree to explain why the next investigation matters. Use the roadmap to communicate what the team currently intends to do, with uncertainty represented honestly.

Common questions about opportunity solution trees

Can we create a tree without customer research?

You can draw an initial hypothesis map, but label its opportunities as assumptions. Gather evidence before presenting it as a research-backed opportunity space. The workshop is useful for exposing gaps; it cannot fill them through brainstorming alone.

Does every opportunity need a solution?

No. Keep unexplored opportunities visible and focus the current investigation. Filling every branch can encourage speculative work and hide which decision matters now.

Is the tree finished after the workshop?

No. It should change as the team’s understanding changes. A useful outcome from the session is a clearer next investigation, named owners and a record of the assumptions still unresolved.

Get a head start