Method
A simplified OST session that maps strategic outcome to opportunity areas and candidate solutions, then identifies where evidence is needed next.
Choose this if
This method works when connecting outcomes, opportunities, and solution options.
Pack = one session you can run now. Workspace = a saved thread for method choice, planning, and shareable outputs.
What Workspace helps you carry forward
Artifact preview
Opportunity-solution tree
Prioritise · Moderate
Decide fit before you spend session time.
Room fit check
Best when outcomes are already visible enough to anchor the room, but the path from opportunities to options is still too messy or politically compressed. This room has enough of the right conditions for the method to hold without extra ceremony.
Primary risk: The tree becomes a tidy taxonomy of ideas with no real evidence gaps or decision logic.
The core facilitation flow, with enough structure to run the method confidently in the room.
Standard setup for Mixed in remote delivery.
Total planned time: 120 min
What happens
Define one measurable outcome for the tree.
Facilitator does
Write the outcome as a measurable change in customer behavior or condition, not a product delivery or business metric. Ask: 'How will the customer's life or work be different?' If the outcome is a revenue target or a feature ship date, push for the user behavior underneath it.
Participants do
Write the outcome as a behavioral statement: what will customers do more of, less of, or differently if the team succeeds? If you're holding a business metric, ask what user behavior that metric is a signal of, and write that behavior as the outcome.
Output / signal of success
Opportunity-solution tree
Watch for
Outcome is set as a business target without a clear user behavior connection.
Recovery tip
If the proposed outcome is a business metric without a user behavior attached, ask: "What would a user do differently if we achieved this?" Write the behavior change as the outcome. Revenue growth is a result of user behavior — the outcome the team can influence is the behavior, not the result.
What happens
Translate insight themes into opportunity statements.
Facilitator does
Keep opportunities at the user need level — things customers struggle with or want to become true. Reject solutions masquerading as opportunities. Each branch should be expressible as 'customers need to be able to...' or 'customers currently struggle to...' Draw a clear visual hierarchy from outcome to opportunity.
Participants do
For each branch, test whether your statement can be expressed as "customers currently struggle to..." or "customers need to be able to..." If it can't, it's probably a solution or a problem statement rather than an opportunity. Rewrite it in user need terms before placing it on the tree.
Output / signal of success
The board has distinct opportunity areas that name what users can't do, don't know, or won't do — not what the product should build.
Watch for
Opportunities are features or solutions rather than user needs.
Recovery tip
For any opportunity written as a feature or solution, ask: "What user gap makes this solution relevant?" Write the gap, not the solution. The opportunity branch must be expressible as "customers currently can't/don't/won't..." before it belongs on the tree.
What happens
Attach candidate ideas to each opportunity.
Facilitator does
Generate multiple solution options per opportunity branch before evaluating any. Require at least two alternatives per branch to prevent the tree from becoming a plan for a single predetermined solution. Write solutions as hypotheses — 'if we do X, customers will be able to Y' — not as commitments.
Participants do
Write solutions as hypotheses: "If we do X, customers will be able to do Y." Each solution branch must be testable before it becomes a plan commitment. If a solution can't be written as a testable hypothesis, it's not a solution yet — it's an aspiration.
Output / signal of success
Each opportunity branch has at least two distinct solution options written as testable hypotheses. The tree cannot have any single-solution branches — a branch with one solution has already converged and the comparison value of the OST is lost.
Watch for
Only one solution is added per opportunity, eliminating the comparison value of the tree.
Recovery tip
Stop adding solutions. Ask: "If solution A was ruled out tomorrow, what would be the alternative approach to this opportunity?" Write that as solution B. A genuine alternative prevents the tree from becoming a delivery plan for one predetermined solution.
What happens
Mark branches by confidence and next tests.
Facilitator does
Score each opportunity by evidence quality (how well the team understands it) and impact potential (how much it contributes to the outcome). For the highest-scoring opportunities, ask which proposed solution has the strongest evidence of customer value. Flag assumptions that need testing before building.
Participants do
Score opportunities by evidence quality (how well the team understands the user gap) and by impact potential (how much this opportunity moves the outcome metric). High-evidence, high-impact opportunities are the first discovery priorities. Low-evidence, high-impact opportunities are the research priorities.
Output / signal of success
The tree has 2–3 selected opportunity branches with recommended first solutions and named assumptions to test. The evidence quality score is visible per branch so the room can see which areas are research-ready vs hypothesis-only.
Watch for
Prioritisation is driven by solution preference rather than by opportunity strength.
Recovery tip
If prioritization is stalling because everyone has a different favorite, shift to evidence: "What do we actually know about this opportunity?" The branch with the weakest evidence gets deprioritized regardless of enthusiasm until a test is designed to close the gap.
Prepare the room, the evidence, and the working surface so the session can stay focused on synthesis.
One clearly stated outcome metric and at least a rough set of opportunity themes from prior discovery work — even informal evidence is enough to start. If no prior discovery exists, the opportunity branches will be team hypotheses rather than evidence-based gaps. The tree is still useful in this case but the session output should be labelled as a hypothesis map requiring validation, not a prioritised discovery plan.
Target outcome metric
Optional
Opportunity themes
Optional
Tree canvas
Optional
Confidence markers
Optional
Operational context note
Optional
Bring examples, pain points, or service evidence the room can point to quickly.
Remote facilitation choreography
Required
Pre-plan handoffs, breakout usage, and how people rejoin the main board.
Shared digital board with timer and voting
Required
Keep instructions and voting visible at all times.
OST canvas
Keep the output usable, then use the recovery guidance when the room starts drifting.
What this does not produce
The OST produces a structured discovery frame — a way of connecting an outcome to the opportunities and solutions that might achieve it. It does not validate whether the opportunities are real or whether the solutions work. Every branch of the tree is a hypothesis until tested. Teams that move from the OST directly to a delivery sprint without a validation step treat hypotheses as commitments.
Failure mode
Why it happens
Product teams instinctively frame in solution language. "Users need better onboarding" sounds like an opportunity but has already narrowed the solution space — it points toward improving onboarding rather than asking what user progress is blocked and why. The solution direction arrives before the opportunity is genuinely understood.
Recover now
If this happens, apply the substitution test: rewrite the opportunity as "users currently can't/don't/won't..." If the completion doesn't work cleanly, the statement is still solution-led. "Users can't complete onboarding without assistance" is an opportunity. "Users need better onboarding" is a solution brief.
Prevent next time
Next time, before Step 2 opens, write the user gap sentence frame on the board and require every opportunity branch to complete it before going on the tree.
Failure mode
Why it happens
Teams know which solution they want to build before they enter the session. The OST becomes a documentation exercise rather than a genuine exploration — each opportunity gets one "obvious" solution, and the tree is used to justify a plan that was already formed rather than to explore the space.
Recover now
If this happens, for every single-solution branch, enforce a second solution before continuing. Ask: "If solution A were ruled out tomorrow due to cost, regulation, or technical constraint, what would you explore instead?" Write that as solution B.
Prevent next time
Next time, make "minimum two solutions per opportunity" a visible rule at the start of Step 3. Branches with one solution cannot be scored or prioritised.
Failure mode
Why it happens
In rooms with strong product opinions, solution ideas arrive before opportunities are fully mapped. When it's time to prioritise, the room effectively votes for their preferred solutions and post-hoc justifies the opportunity strength. The tree looks rigorous but reflects pre-existing preferences.
Recover now
If this happens, score opportunities before solutions. Cover the solution branches and ask: "Based on evidence strength and impact potential alone, which user gap is most important to address?" Let the opportunity score drive the solution exploration, not the other way around.
Prevent next time
Next time, run the evidence quality and impact scoring in Step 4 with the solution branches hidden. Reveal them only after opportunity priorities are agreed.
Change the shape of the session only after the fit and runbook are clear.
Standard variant for Mixed in remote delivery. Waypoint is adapting timing, facilitation emphasis, prep, and recovery guidance here, but the room still needs final tailoring to the exact stakes and participants.
Use this after you have checked the fit and know you want to carry the method forward.
The pack is the fastest way to run this now. Use the links below when you need prep, sharing, or a saved reference point.
Guides
The book improves lightweight opportunity trees by forcing the room to test whether each branch reflects a real interpretation, rival explanation, or evidence gap rather than just a tidy decomposition of favored ideas.
Open this when you want stronger rationale before choosing the method or taking it into the workspace.
A judgment-discipline brief on how to stop polished discovery outputs from outrunning the evidence beneath them by exposing assumptions, testing rival explanations, and showing confidence honestly.
Sources and references used in this method page.
Torres, T. Continuous Discovery Habits.
LUMA method library for collaborative prioritization practices.
Reviewed 2026-02-27 by Discovery Waypoint Editorial Team