An opportunity solution tree is a diagram with one outcome at the top, the customer problems that could move it underneath, and the things you might build hanging off those.
It exists to stop a single conversation that wastes more product time than any other, which is the argument about two features that are answers to different questions. Drawn on a tree they sit under different branches, and the argument becomes a choice about which problem is worth solving rather than which solution somebody prefers.
What are the four levels?
Outcome, opportunity, solution, experiment, and each level answers to the one above it.
The outcome is the single measurable change you are trying to produce this quarter. One, not four, because a tree with four roots is an organisation chart.
Opportunities are the needs, pains and desires that, if addressed, would move that outcome. They are phrased as customer problems and they never name a feature.
Solutions are the things you could build for one opportunity. Several per opportunity is the point, because a branch with one solution under it is a decision that has already been made.
Experiments are how you find out whether a solution actually addresses the opportunity before you build all of it.
What is it for, in practice?
Making the shape of your reasoning visible, so other people can disagree with the right part.
When a stakeholder objects to a roadmap, the objection is usually at one of those levels and nobody knows which.
On a tree it is obvious whether they think the outcome is wrong, the opportunity is not real, or the solution will not work. Three very different conversations that otherwise all arrive as this feature is a bad idea.
The second use is spotting the branch with no opportunity above it. Most backlogs contain work that cannot be attached to any customer problem at all, and drawing the tree is the cheapest way to find it.
Where does a feature request fit on the tree?
At the solution level, almost always, which is the whole difficulty.
People send you solutions. A request is somebody's answer to a problem they did not describe, so putting it on the tree means working backwards to the opportunity it implies and checking whether that opportunity is real.
Sometimes the answer is that the problem is genuine and the proposed solution is the third best one available.
This is why a board that keeps the conversation attached to the request is worth more than a board that only counts. The reasoning behind an ask is what lets you place it, and the reasoning lives in the comments. The comments sit on the request here rather than in a separate system.
Does a vote count belong on an opportunity solution tree?
As evidence for an opportunity, not as a decision about a solution.
Forty people voting for the same request tells you something real, and what it tells you is that a problem exists, not that their proposed fix is the right one.
Read at the opportunity level a vote count is useful evidence. Read at the solution level it is a popularity contest with a diagram drawn around it.
The sharper version of that evidence is the revenue behind the people who voted, because an opportunity that matters to accounts paying you is a different proposition from one that matters to a hundred people on a free tier.
How the weighting works is written out with the code behind it, and what the demand figure is made of is printed in full.
Is it worth drawing for a small team?
Once a quarter, on a whiteboard, and never as a document anybody maintains.
The value is almost entirely in the drawing rather than the artefact. A tree kept up to date in a tool becomes another surface to groom, and the teams that get the most from the idea tend to draw it, argue, decide, photograph it and throw it away.
What survives afterwards is the ordering, and that lives where the requests live. A public board with the reasons attached is the durable half, and the tree is the meeting that produced it. How the board and the roadmap sit on one page here is written out separately.
14 days, a card at signup, then $9 or $39 a month.
