Opportunity Solution Trees
A way to show why you are building this and what else you considered, on one page.
Somebody asks why you are building the thing you are building. You have an answer, but it takes four minutes and involves a spreadsheet of interview quotes, two Slack threads and a decision from a meeting in August. Meanwhile the person asking has a different idea and no way to see how it compares to yours. This is the gap an opportunity solution tree: A map from a desired outcome down through customer opportunities to the solutions you might test. fills. It is a picture of your reasoning that fits on one page.
Teresa Torres describes it as a visual structure with four layers. The shape is simple. The discipline it enforces is not.
The four layers
- Outcome (one)
- The single business result this team is accountable for this period. Increase the share of trial accounts that complete a first real transaction. One outcome, not three, or the tree cannot help you choose.
- Opportunities (several)
- Customer needs, pains and desires that stand between people and that outcome, phrased in the customer's terms. These come from interviews. They are not features and they are not internal goals.
- Solutions (several per opportunity)
- Ways you might address a specific opportunity. Multiple per opportunity, always, because a single solution under an opportunity means you have not explored, you have decided.
- Assumption tests (several per solution)
- The small experiments that check what has to be true for a solution to work. This is where discovery stops being a discussion and starts producing evidence.
Two rules make the tree useful rather than decorative. First, an opportunity must be phrased as something a customer experiences, not something you want. 'I cannot tell whether my payout arrived' is an opportunity. 'Improve payment transparency' is an internal goal wearing an opportunity costume. Second, every opportunity needs at least three candidate solutions before you pick one. The point of the tree is to make the alternatives visible, and an opportunity with one child is just a feature request with extra ceremony.
Worked example
Dabba, a food delivery app
Outcome: increase the share of first time customers who order again within 30 days. One branch of the tree read like this. Opportunity: 'I ordered once, it arrived cold, and I have no idea whether that was bad luck or normal.' Solutions under it: show realistic delivery time bands based on that restaurant's actual history rather than a flat estimate; offer a one tap resolution on the order card when something goes wrong; surface a 'kept hot' badge for restaurants using insulated bags; prompt a second order with a small credit after a reported problem. Assumption tests for the first solution: do customers notice the band at all (five minute unmoderated test on a prototype), and does the restaurant level data actually predict lateness well enough to show (analysis on existing data, two days, no engineering). The second test failed. The data was too noisy for half the restaurants. That branch was killed in a week rather than a quarter, and the one tap resolution went first instead.
That is the tree earning its keep. Not by picking the winner, but by making a cheap disqualification possible before anybody wrote production code.
One page, four levels
Where trees go wrong
- Opportunities that are solutions. 'Needs a mobile app' is a solution. The opportunity underneath it is something like 'I need to check on this while I am away from my desk', which mobile is one answer to.
- Opportunities invented in a meeting. If it did not come from a customer conversation, mark it as a hypothesis and go check it. Trees full of guesses look exactly like trees full of evidence, which is the danger.
- One solution per opportunity. This is the most common failure and it means the tree is documenting a decision rather than supporting one.
- Never pruning. A tree that only grows becomes a wall of possibilities nobody reads. Delete branches when you kill them, or grey them out with the reason, which is more useful.
- Treating it as a document. It is a working surface. If it has not changed in a month, either nothing is being learned or nobody is updating it, and both are bad.
A roadmap says
- Here is what we are building.
- Here are the dates.
- Alternatives are not shown.
- Changing it looks like failure.
A tree says
- Here is the result we want and the customer needs in the way.
- Here is what we are testing, and what we already ruled out.
- Alternatives are visible, including the ones we killed.
- Changing it is the point, and the reason is written down.
The tree does not replace your roadmap. Leadership still needs a roadmap and dates, and you should give them one. The tree is what you bring when someone asks why, and it is how you answer the stakeholder who arrives with a favourite idea. Rather than debating their idea against yours, you add it to the tree under the opportunity it addresses, next to the three solutions already there, and the conversation becomes about which of four things to test first. That is a much better argument to be having.
Start with one branch. Take the outcome you are already accountable for, write the three customer needs you are most confident about from recent interviews, and put three solutions under the one you think matters most. An hour of work. You will notice immediately which opportunities you cannot evidence, and that list is your interview agenda for the next month.
Quick check
An opportunity in your tree has exactly one solution under it. What is the problem?
The takeaway
An opportunity solution tree makes your reasoning and your rejected alternatives visible, which is what turns a roadmap debate into a question about what to test next.
Try this tomorrow
Draw one branch of a tree for your current outcome: one customer need in the customer's own words, three different solutions under it, and one cheap test for each. Bring it to your next prioritisation discussion instead of a list of features.
Answer the check above, then bank the day.
Where this comes from
- Continuous Discovery Habits, Teresa Torres
- Inspired, second edition, Marty Cagan
Discovery is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.