Opportunity Solution Trees: a worked example

The fastest way to understand an Opportunity Solution Tree is to build one. Definitions only take you so far, so in this post we'll build a complete OST for a realistic product — from the outcome at the top to the assumptions you'd test at the bottom.

If the framework is new to you, read What is an Opportunity Solution Tree? first. This post assumes you know the four layers — outcome, opportunity, solution, assumption — and goes straight to applying them.

The setup

Meet Rota, a shift-scheduling app for restaurants. Plenty of managers sign up, but a lot of them never get their team actually using it. Leadership cares about revenue retention; the product team has been handed an activation problem.

1. Start with one clear outcome

A useful product outcome measures customer behavior the team can influence — not a feature, and not a lagging business metric like revenue. (If that distinction is fuzzy, see outcomes vs outputs.)

Outcome: increase the share of new restaurants that publish a schedule in their first week from 32% → 50%.

Publishing a first schedule is a leading indicator of retention: a manager who gets their team onto a real schedule has felt the product work. One outcome, clearly measured. That's the root of the tree.

2. Map the opportunity space from research

Opportunities are customer needs, pains, and desires — discovered in interviews, not invented in a meeting. After a dozen onboarding conversations, patterns showed up:

"I signed up on Friday and just… didn't know where to start."
"Building the team roster the first time took forever."
"I made a schedule but couldn't tell if my staff actually got it."

Those cluster into three opportunities hanging under the outcome:

"I don't know what to do first."
"Setting up my roster the first time is tedious."
"I'm not sure my team received the schedule."

Notice these are phrased as customer problems, not features. That discipline is what keeps the tree honest.

3. Pick one target opportunity

You can't solve everything at once, and trying to is the most common way discovery stalls. Weigh each opportunity by how much it moves the outcome, how many customers hit it, and how confident you are it's real.

Here, "I don't know what to do first" wins — it blocks every other opportunity downstream. Nothing else matters until a manager gets moving.

4. Brainstorm several solutions

For the target opportunity, generate multiple solutions so you can compare instead of marrying the first idea:

A guided setup checklist.
A three-step "publish your first schedule" wizard.
A pre-filled sample schedule the manager edits instead of starting from a blank grid.

5. Break solutions into assumptions — and test the riskiest

Every solution rests on assumptions that must hold for it to work. Take the sample-schedule idea:

Desirability: managers would rather edit a sample than build from scratch.
Feasibility: we can generate a believable sample from signup data.
Viability: editing a sample actually leads to more published schedules.

The riskiest is desirability — if managers don't want a sample, nothing else matters. So test that first, cheaply: show a prototype to five managers, or run a fake-door that offers "start from a sample" and measure who clicks. No engineering required yet.

The finished tree (which is never finished)

Outcome → three opportunities → (under the target) three solutions → (under the chosen solution) three assumptions, one of them now under test. That's a complete branch. As results come in, you prune dead solutions, promote what works, and revisit the other opportunities. The tree is a living artifact, not a one-time diagram.

Common mistakes to avoid

An outcome that's really an output — "ship the onboarding wizard" is a thing you build, not a behavior you change.
Opportunities that are solutions in disguise — "add a checklist" is a solution; the opportunity is the underlying need.
Boiling the ocean — one target opportunity at a time.
Skipping the tests — an untested assumption is just an opinion with a box around it.

Build your own

Create a free tree and map your own outcome. The first one takes an afternoon; after that, it becomes the way your team thinks.