Opportunity Solution Tree: From Outcome to Experiment

What is it, and how do you read it?

The tree has a root, a branch of opportunities, and under each opportunity, branches of solutions. Each solution in turn has assumptions that can be tested. Product Talk describes it as a diagram that links the desired outcome with the opportunities that drive it, the candidate solutions, and the tests that validate those solutions.

The reading order matters. You start with the outcome, then look for opportunities, then solutions, and finally tests. If the team starts from the solution it already wants to build and draws the tree backwards, it loses its meaning.

Why does this matter for a junior designer?

Because almost every team has a list of features it wants to build and few have a clear reason for each one. A junior who can answer “which customer opportunity does this screen solve?” has an argument that goes beyond opinion. It is a way to ask the hard question without sounding like criticism.

The tree also forces you to separate discovery work from delivery work. Designing a solution without having looked at the opportunity is how many features nobody uses get built.

How do you build it, from the top down?

1. Define a product outcome. As a general rule, Torres likes to see a product outcome at the top of the tree: it measures a customer behavior in the product or a customer sentiment about it, while a business outcome measures the health of the company. “Customers send their first invoice in under a day” is more useful than “increase revenue”. Each team sets its own outcome.
2. Gather opportunities from customers. Opportunities should come from story-based interviews. Product Talk asks for three or four of these interviews before you start your first tree. To structure those conversations, the jobs to be done framework is a good complement.
3. Organize opportunities as an experience map. Group opportunities by moments in the customer’s journey, rather than in a flat list.
4. Pick one opportunity and generate solutions. Work one branch at a time. For the chosen opportunity, Product Talk recommends considering more than one solution and choosing three to explore. Avoid brainstorming solutions across the whole tree at once.
5. Identify the riskiest assumptions. Break each solution down into its underlying assumptions, prioritize which to test first, and test the riskiest ones from each idea. Ask what must be true for it to work, and design the cheapest test to check it.
6. Update the tree with each result. If an experiment fails, the tree tells you whether to change the solution, the opportunity, or even the outcome.

The Lean UX Canvas works through the same idea from hypotheses, and it can be a useful step before this when the team is not yet clear on its problem.

How do you tell an opportunity from a solution?

It is a common confusion. According to Product Talk, an opportunity is the underlying customer need, pain point, or desire, and a solution is a product, a service, or a feature offered to address it. The opportunity does not say how to fix it.

A simple test, which Product Talk itself proposes: ask whether there is more than one way to address the statement. If there is not, it is probably a solution in disguise. “We need an export button” is a solution. “Customers have to move their data to another tool every month” is an opportunity, because it leaves several ways to address it.

As a practical rule of thumb, before writing each opportunity, define what evidence would confirm it, for example, several customers mentioning it without being asked.

When should you NOT use the tree?

• When there is no clear outcome. Without a measurable goal in customer behavior, the tree fills up with ideas and no direction.
• When no interviews feed the opportunities. Writing opportunities from the team’s intuition produces exactly what the method is meant to prevent.
• When the decision is about one item. If there is only one thing to build and no room to compare, the tree adds work without learning.
• For the whole company. Torres does not recommend it: as the scope widens, the tree gets too unwieldy. She proposes one outcome, and one tree, per team.

Example

Illustrative example: an invoicing app team wants customers to get paid faster.

• Outcome: customers send their first invoice within a day of signing up.
• Opportunities: they do not know which data is required to comply with tax rules; they resend invoices by hand because the client never opened the email; they do not understand why an invoice was rejected.
• Solutions for the third opportunity: a notice with the reason for the rejection; a direct link to resend; a summary of errors on the main dashboard.
• Test for the notice: show it to ten customers with a sample rejected invoice, and measure how many fix it without help.

The tree does not say which of the three solutions wins. It says which one deserves a test first, and what result would confirm it.

To connect this logic with the metrics you watch, the article on KPIs helps you choose measurable outcomes.

Common mistakes

• Drawing the tree top-down starting from the solution the team already wants to build.
• Writing opportunities without talking to customers.
• Treating a solution as if it were an opportunity.
• Using interviews to vet solution ideas instead of discovering opportunities. Torres describes it as one of the biggest mistakes she sees teams make.
• Basing the tree on a single interview. Qualitative research does not give a representative sample, and the wider the range of people you talk to, the more variation you uncover.
• Ruling out an opportunity too early, before assessing its effort.
• Getting bogged down in research without making any decision.

Sources

• Product Talk, Opportunity Solution Trees
• Product Talk, Glossary: Opportunity Solution Tree
• Product Talk, No single right way (2021)