Opportunity solution tree: how to build one from real interview stories

An opportunity solution tree is a one-page map that starts with one outcome your team is trying to move, branches into the customer needs that could move it, then into a few solutions for one of those needs, and ends in the assumption tests that tell you which solution works. Teresa Torres created the opportunity solution tree in 2016 (Product Talk), and the part that decides whether yours is useful is the middle layer: the opportunities, which have to come from customer interviews.

Most trees that fail look fine from a distance. The outcome is reasonable, the solutions are clever, and the opportunities turn out to be feature ideas wearing a customer's hat. This post is about building the tree so that does not happen. For where the tree fits in the wider process, read our post on product discovery. For the research that comes before it, read generative research.

1. Pick one product outcome before you draw anything

Write a single outcome at the top, and make it a product outcome: a change in what customers do or feel inside your product. Torres separates three kinds (Product Talk): business outcomes, which measure the company's financial health; product outcomes, which measure customer behavior in the product; and traction metrics, which track use of one feature. Teams often do not know how to move a business outcome directly, and Torres calls traction metrics too narrow in scope to be good discovery outcomes.

Set one outcome per team. Torres gives that as a general rule, and if two teams share an outcome she suggests splitting it by customer segment or by step in the customer journey. Changing the target number does not need a new tree. Her example: raising the share of new users who reach the product's key moment from 22% to 25%, and later to 30%, stays on the same tree, while changing which moment counts, or switching to acquisition, starts a new one.

Short version: one team, one outcome, written as something customers do.

2. Hold three or four interview stories before you draft the opportunities

Do not start the opportunity layer from a whiteboard. Torres lists three prerequisites for a first tree: a theory of who your customer is and what you offer them, a clearly defined outcome, and three to four story-based interviews (Product Talk). She is blunt that you should not skip them.

A story-based interview asks about one specific past event, using a prompt like "Tell me about the last time you..." (Product Talk on customer interviews). The reason is that people overestimate how often they do things when they describe their general habits, while a specific recent story shows what they actually did. Our post on customer interview questions has more prompts in this style.

After each conversation, Torres suggests a one-page interview snapshot: a photo of the person, a memorable quote, a few quick facts, a small map of the story, the opportunities that came up and any other insights (Product Talk). The opportunities box on each snapshot is the raw material for your tree. If the box is empty, the interview was probably about your product instead of their week.

Support tickets, sales calls and survey comments can feed the tree, but treat them as leads. Torres notes they lack context and suggests using them to decide what to ask in the next interview (Product Talk). A ticket that says "export is broken" tells you a moment hurts. It does not tell you why the person was exporting at 11pm.

3. Build the opportunity space from an experience map, not a list

Map the steps your customers go through, then hang opportunities off the step where they happened. Torres describes four moves (Product Talk):

1. Draw one experience map that covers the stories from all your interviews.
2. Turn the key moments on that map into your top-level opportunities.
3. Put each specific opportunity from your snapshots under the moment where it occurred.
4. Work through one branch at a time, sorting opportunities into parents, children and siblings.

The top of the tree should stay stable as you learn more, and most of the change should happen lower down as branches get more detail. Add customer segments as a top layer only when you serve two distinct groups, such as both sides of a marketplace.

Here is a made-up example. A bookkeeping app for small landscaping companies sets this outcome: more new accounts finish reconciling their first month within 14 days. Four interviews later, the experience map has moments like "crews buy supplies," "receipts reach the office" and "month-end close." Under "receipts reach the office," the team hangs a parent opportunity from Dana, who runs a nine-person crew: "I can't keep track of crew receipts." Its children are more specific: "I don't know which job a receipt belongs to" and "Receipts arrive as photos in a group text, two weeks late."

The parent is too big to act on. The children are the right size to pick from.

4. Write each opportunity as the customer's problem, then check it has more than one answer

Write opportunities in the customer's voice, about their situation. Torres's test is simple: if there is only one way to address it, it is a solution in disguise (Product Talk).

In the made-up example, "Let crews snap receipts in the app" fails the test, because it names the fix. "Receipts arrive as photos in a group text, two weeks late" passes: you could build in-app capture, auto-import from a shared phone album, give crews a company card that pulls transactions directly, or change the weekly routine so the office collects receipts every Friday. Some of those are not even software, which is a good sign the opportunity is framed well.

Opportunities can be needs, pain points or desires. Torres counts all three (Product Talk). A desire such as "I want to know if this job made money before I quote the next one" belongs on the tree as much as a complaint does.

5. Choose one target opportunity, and leave effort out of the choice

Pick one small opportunity to work on and leave the rest alone for now. Torres recommends choosing once you have a rough first draft, and warns against spending hours polishing it (Product Talk). The tree will change after the next few interviews anyway.

Compare candidates on four groups of factors she lists: opportunity sizing (how many customers have it and how often), market factors, company factors and customer factors. Do not judge effort yet. Effort belongs to solutions, and an opportunity that looks hard often turns out to have an easy fix once you start brainstorming. Ruling it out early is how teams end up building only the obvious.

Go one level down the tree from the moment you are tempted to pick. A child opportunity like "I don't know which job a receipt belongs to" gives you something to design for. A parent like "receipts are a mess" gives you a quarter of meetings.

6. Brainstorm for the target only, then carry three solutions forward

Generate ideas for the target opportunity and nothing else. Torres warns against brainstorming across the whole tree (Product Talk), since the point is to stay focused on the target. Ideas for five problems at once also tend to be shallow ideas for each.

Then pick three solutions to explore. Torres recommends comparing more than one idea, and says it matters most when the solution is risky, when the opportunity is one where you want to stand out from competitors, or when the problem needs an inventive answer. She admits teams do not always have time for it. If you take fewer, know you are trading away the comparison.

In the made-up example, the three might be: tag each receipt to a job with one tap at capture, suggest the job from the GPS location of the purchase, and send the crew lead a Friday text listing untagged receipts. They differ enough that testing them will teach the team something.

7. Break each solution into assumptions, and test the risky ones for all three

Every solution rests on assumptions, and the bottom layer of the tree is where you test them. Torres sorts assumptions into five types (Product Talk):

It is easy to list assumptions of only one or two types, so go through all five on purpose. For the GPS idea, a desirability assumption is that crew leads want job suggestions. A feasibility assumption is that purchase locations are precise enough to tell two nearby job sites apart. An ethical one is that crews are comfortable with location data being attached to their purchases.

Test the riskiest assumptions for all three ideas, including the one you like least. Do not test desirability by asking "Do you want this?" Torres calls that an unreliable signal (Product Talk), and suggests demand tests and questions about past behavior instead. Our post on problem interviews vs solution interviews covers why a pleasant reaction to a demo proves little.

When the results come in, make one of three decisions Torres describes (Product Talk): drop ideas and generate new ones, refine one idea and move it toward delivery, or choose a different target opportunity. Each of those is a normal outcome. A failed test that sends you back up the tree is the tree doing its job.

8. Most broken trees fail in one of six ways

The first five are problems Torres flags in her guide (Product Talk). The sixth is our own addition, drawn from her point that the tree is a living document. Here is the fix for each:

1. Made-up opportunities. The team skipped the interviews and filled the middle layer from memory. Fix it by running three or four story-based interviews and redrafting.
2. One interview treated as a trend. The most recent call, or a single sales conversation or ticket, rewrites the tree. Fix it by waiting for the pattern across several stories before moving branches.
3. Several outcomes at the top. Every branch competes with every other. Fix it by choosing one outcome per team.
4. One tree for the whole company. Torres does not recommend it. Give each team its own tree, and use a company-wide metric tree or experience map to connect them instead.
5. Still a mess after six to eight interviews. Torres treats this as the point to get help structuring the tree. Prevent it by revisiting the opportunity space every three to four interviews, which is roughly every three to four weeks if you interview weekly.
6. A tree drawn once and framed. It stops matching what you know after the next few interviews. Fix it by going back to the tree each time new evidence arrives, such as a failed test, and deciding whether to refine the solution, switch opportunities or change the outcome (Product Talk glossary).

The last one is easy to fall into, because a finished-looking diagram is very satisfying to present and slightly less satisfying to tear up.

9. Skip the tree if you cannot talk to customers every week

The tree depends on a steady supply of interview stories. Torres recommends talking to at least one customer every week (Product Talk), and the revisit rhythm in section 8 assumes it. A team that interviews once a quarter will draw a tree once and never revise it.

It also does not fit when someone else has fixed the solution already, such as a contract that specifies the feature, or when you do not yet have a theory of who your customer is. In that last case, do generative research first and come back to the tree when you can name the customer and the outcome.

If your customers are busy professionals who rarely answer a cold ask, recruiting is usually what breaks the weekly habit. Torres suggests trying without an incentive first and adding one only if needed (Product Talk). When you do need one, Instant Expert lets you invite specific people, such as chief product officers or AI product management experts, to a short paid call, and you pay only if they book.

Start today with a blank page: write your team's outcome at the top, read your last three interview notes, and write down every need, pain point or desire you find in the customer's own words. That list is the first draft of your tree. To turn notes into opportunities faster, see how to analyze customer interviews.