Opportunity Solution Tree Template
Every tree template says opportunities should come from research. This one makes each branch name the interviews it came from, and counts them.
Free download · No account needed
Teresa Torres, who created this artifact, is direct about the constraint: keeping the tree to opportunities heard in customer interviews is what guarantees a team is working on real unmet needs. Opportunities that arrive through tickets or analytics usually lack the context that makes them safe to act on. Every template you can download repeats that instruction. None of them gives you a way to check whether you followed it. A tree that broke the rule looks exactly like one that kept it.
So that is the only thing this pack adds. Every opportunity names the specific sources it came from, with dates, and the count is the verdict. Five or more distinct sources is established. One is a quote. None at all is a solution somebody wanted, written upwards and drawn as a need. The threshold is not invented: a bootstrap study of thematic saturation put the median at six interviews before new information dropped below five percent of the total.
Then the second pass runs upward, tracing every roadmap item back to an opportunity and every opportunity to the outcome. In the worked example the six best-evidenced opportunities held 72 percent of the evidence and 22 percent of the effort. Putting two interviews in front of the fourteen engineer-weeks resting on two sources costs two days, which is under three percent of the build being checked. Sits under the strategy the tree serves, next to the outcome it hangs from and ahead of the roadmap it feeds.
What is in the pack
A source column, listed by name rather than counted
Interview numbers, ticket clusters, recording identifiers, each with a date. Not a note saying it came from research.
Thresholds written down before the list is read
Five or more sources is established, two to four is thin, one is a candidate, none is a solution in the wrong layer. Applied equally to every branch.
An upward trace from the roadmap
Every item traced to an opportunity, and the ones reaching nothing split into correctly off-tree work and genuine orphans.
Evidence share against effort share
One division per row, and the output most likely to change a decision. It is usually the first time anybody sees the drift.
A recency check that takes ten minutes
When the tree was last restructured against how many sources postdate it. Well-evidenced and stale is a real state and a count hides it.
The tree written as prose, not drawn
On a canvas a branch with one aside and a branch with fourteen interviews are the same size box. In a sentence they are not.
How it works
- 1
Send the outcome
One measurable thing with a baseline and a target. The tree and the research come next.
- 2
Cite every branch
Specific sources by name, with dates, working down from the branches carrying the most effort.
- 3
Trace the roadmap up
Every item to an opportunity, and every opportunity to the outcome. The ones that reach nothing are the finding.
- 4
Compare the shares
Evidence share against effort share, then three moves rather than a rebuilt roadmap.
Frequently asked questions
What do I need before this is useful?
One outcome with a baseline and a target, the tree if it exists, everything the research produced, and the current roadmap with rough effort against each item. Raw interview notes beat summaries, because a summary has already dropped the attribution this pack runs on.
What if we do not have a tree yet?
That is a cleaner start, not a worse one. Building from the research means the opportunities arrive with their citations already attached, which is the right way round. The two passes are the same, and the upward trace from the existing roadmap still finds the orphans.
Why is one source not enough?
Because a single mention establishes that somebody said it, not that it is a pattern. The published work on saturation counts sources for exactly this reason. A single-source branch is not deleted here, it is marked as a candidate with the next interview named, which is a cheap thing to settle.
Does this mean support tickets and analytics do not count?
They count and they are recorded as a different kind of source. A ticket cluster tells you something happens and not why, and a feature request tells you somebody asked for a solution. A branch resting only on those is a candidate rather than a disqualified one.
Will this tell me to cancel work?
No, and a register that did would be ignored. The output is three moves: a discovery slot for the best-evidenced branch, two interviews in front of the largest bet resting on the thinnest evidence, and the orphans labelled. That second move cost two days against 70 engineer-days in the example.
How is this different from prioritisation?
It answers a prior question. Nothing here scores opportunities against each other or ranks them by reach and effort. It establishes which branches have earned a decision at all, and scoring comes after that. A ranked list of unevidenced opportunities is still unevidenced.
How often should the tree be re-cut?
Whenever enough new research has arrived to move it, which the recency check makes visible. In the worked example the tree had not changed shape in five months while 13 further interviews were conducted, and a tree that has stopped changing has stopped being a discovery artifact.
Find out how many of your branches have research behind them
Send the outcome, the tree and whatever the research produced. What comes back first is the count: how many opportunities are established, how many are one quote, and how many are solutions in the wrong layer.
Check my tree against the research