Opportunity Solution Tree

The tree reads top to bottom in four layers. At the root sits a single desired outcome — a measurable goal the team is chasing, such as lifting activation or reducing time-to-value. Below it branch opportunities: customer needs, pains, and desires expressed in the customer's own terms, surfaced through continuous discovery. Below each opportunity sit candidate solutions, and below each solution sit the assumption tests or experiments that probe whether the solution will actually move the opportunity.

The structure is deliberately a tree, not a list. A single outcome forks into many opportunities, each opportunity into several solutions, each solution into multiple tests. This branching forces a team to hold more than one option at every level, which is the antidote to committing to the first idea that sounds plausible.

The tree's job is to make discovery decisions visible and challengeable. Because every solution traces upward to an opportunity and every opportunity to the outcome, anyone can ask "which customer need does this serve, and which goal does that need move?" A feature that cannot answer those questions is exposed as orphaned work before it consumes a sprint.

It also reframes prioritization. Instead of ranking a flat backlog of features, the team first compares opportunities against the outcome — assessing which need, if solved, would most move the goal — and only then explores solutions within the chosen branch. Torres calls this "comparing opportunities, not solutions," and it keeps scoring frameworks like RICE honest by ensuring the items being scored are genuine customer needs rather than pre-baked features.

The most common failure is writing solutions disguised as opportunities. "Add a Slack integration" is a solution; the real opportunity is "I lose track of mentions because they live in another tool." When the opportunity layer is full of features, the tree collapses into a backlog and its comparative power is gone. Opportunities must be phrased as customer needs, in customer language, distinct from any one fix.

A second failure is treating the tree as a one-time artifact. It is meant to evolve weekly as new interview evidence arrives — branches get added, pruned, and reweighted. A tree that has not changed in a month is usually a sign discovery has quietly stopped. A third trap is skipping the experiment layer entirely and shipping the first solution under an opportunity, which discards the option-generation the structure exists to enforce.

An opportunity solution tree is only as trustworthy as the evidence under each branch. In practice that evidence — the interview note, the support ticket, the usage signal, the revenue behind the account that raised it — usually lives in separate tools, so opportunities drift from feature ideas back into guesses and outcomes lose their link to actual account behavior.

A product operating system like AIOProductOS keeps that evidence joinable on one shared spine: its Insights feed surfaces feedback next to the Customer-360 record and the revenue behind it, so an opportunity can show which paying accounts raised it before it earns a branch, and the outcome at the root can be tracked against real product analytics rather than a number copied into a slide. The tree stays a discovery tool; the spine keeps the evidence under it current.