Opportunity Solution Tree

Product meetings stall in a recognizable way. Someone says "people find out too late what was left on a document they shared." Someone else says "so let's build notifications." A third person says "everyone turns notifications off anyway." All three are right, and one of them was describing a problem while the other two were describing solutions. Nobody is on the same layer, so half an hour passes and nothing gets decided.

A list of ideas doesn't fix this. The list has "comment notifications" and "read receipts" sitting next to each other, with nothing recording whether those are two ways at the same friction or attempts at two different frictions. So a team builds one of them, sees no reaction, and quietly drops the friction itself. One method failed, and the problem got thrown out along with it.

The opportunity solution tree exists to make that split visible. Problems live on an upper layer, methods on a lower one. With the layers separated, a dead solution doesn't take its problem with it — the problem stays on the branch and the team hangs a different solution in its place.

You fill four layers from the top down. It isn't a diagram you draw once; it's one that grows a little each week.

1. Hang exactly one outcome at the top, and make it a number you're trying to move. "Take the share of signups who return in week one from 34 percent to 45 percent" — current value and target value together. Hang two outcomes and it stops being clear which one a branch below belongs to.
2. Hang opportunities under the outcome. An opportunity is a customer friction standing between you and that number, written in the customer's own words. Not "no notification feature" but "I find out days later that someone left something on my document." The raw material is what you heard in user research and what sits in the support queue. Written that way, every opportunity reads as a sentence a customer could have said out loud.
3. Pick one opportunity to work this quarter. Leave the rest on the tree rather than deleting them. Choose on how many people raised it and how directly it touches the number. Something eight of ten interviewees mentioned, sitting right next to the metric, goes first.
4. Hang at least three solutions under the chosen opportunity. Hang only one and you've decided the answer in advance and borrowed the shape of a tree to dress it up. Three is what lets you pick the cheapest of them, and it makes the comparison explicit: you weigh options against each other over one problem instead of weighing a single proposal against nothing.
5. Hang an experiment under each solution. Start from the assumption that would do the most damage if it turned out false, write it as a hypothesis that can come back true or false, and test that. Show a prototype to five people, or ship the button without the feature behind it and count who presses it.

Once it's drawn, a single sheet reads as "this quarter, for this number, we're working this friction, with this method, verified this way." That's why reporting upward gets shorter for teams that keep one.

It earns its keep when a team is holding several ideas and nobody can say how they connect. A team practicing continuous discovery, talking to customers every week, needs somewhere to put what those conversations produce, and this diagram is that place. On a team running dual-track agile, where discovery and delivery move side by side, the tree is what the discovery track's progress looks like.

Where it doesn't fit is just as clear.

1. Without a number at the top, the tree won't stand. If the outcome is "build a good product," every opportunity belongs under it and none can be cut.
2. Skip it for work with no options. A legal change you must comply with, or a deliverable with a contractual date, gives you no reason to invent three solutions.
3. A big tree stops being readable. Past twenty opportunities, each with solutions hanging off it, the drawing covers a wall and nobody takes in the whole thing. Collapse closed branches and leave only this quarter's expanded. The tree is supposed to be readable at a glance by someone who wasn't in the room, and a wall of branches fails that test.

It also costs upkeep. Draw it once, ignore it for two months, and it's wallpaper. Unless fifteen minutes a week for adding branches and pruning dead ones is actually on the calendar, the day spent drawing it is a day thrown away.

"Are we talking about an opportunity right now, or a solution?"

A request to get everyone onto the same layer.

"That solution is dead, but leave the opportunity above it where it is."

One method didn't work; the problem is still there, so hang a different method on it.

"This quarter we're only digging into the left branch."

We picked one opportunity out of several and the rest are deferred.

At Pagedeck, Mia draws the top two layers at the start of the quarter, and every Thursday Noa and Theo spend thirty minutes reworking branches with her. What they heard from customers that week goes up as a new opportunity or as evidence under an existing one, and solutions whose experiments have finished get marked as passed or dropped.

The decision that comes up most often in that half hour is pruning. When Theo says a solution is two months of work and won't fit the quarter, that branch folds and the team picks again from the two solutions still hanging under the same opportunity. Because the problem stayed where it was, the discussion doesn't restart from zero.

The most common error is writing feature names into the opportunity layer. Even when the instruction is to write customer friction, what actually lands on the sticky note is "comment notifications." Once it does, the solutions beneath it become three variations on how to build that feature, and the possibility that the feature itself is wrong never gets examined anywhere on the tree. Asking "why would they need that?" once usually exposes an opportunity that already has a solution buried in it. The repair is to push that sentence down a layer and write the friction it was serving in the space above.

The second error is treating the drawing as finished. A tree looks like a tidy artifact, so people file it. In practice it's closer to a working log that changes weekly. A tree that stopped being updated still carries solutions abandoned months ago and experiments already concluded, and someone new reads it as current and walks back into a direction that already failed.