Build an opportunity solution tree with a worked training-platform example, separate user needs from feature ideas, and choose an assumption to test.
An opportunity solution tree connects a product outcome to customer needs, possible responses, and the assumptions worth testing. Its value is the reasoning between the boxes. A tidy diagram built from guesses can look convincing while providing little help with the next product decision.
This worked example follows a team-training platform. Everything in the example is synthetic: the observations, coordinator situations, and proposed screens illustrate how to build and question a tree. They are not customer findings, a validated opportunity, or evidence of a conversion improvement.
Read the tree from outcome to learning
Teresa Torres developed the opportunity solution tree framework. Her Product Talk guide distinguishes the desired outcome, customer opportunities, solution options, and the assumptions to investigate. It also emphasizes using customer evidence before filling the opportunity space.
Our example asks how a training platform might help more teams complete their first training assignment. Before setting a numeric target, the team would need a baseline, a definition of a completed assignment, and a measurement window. “Build an approval feature” is already a solution, so it would be a poor substitute for the outcome.
The tree is not a delivery commitment. A roadmap might communicate when a selected capability is expected; this tree explains why the team is exploring an option and what it still needs to learn. Keep that distinction visible when sharing it with stakeholders who may interpret every box as promised work.
Start with observations before feature names
Imagine three situations from a fictional research exercise:
- T01: a coordinator compares the course schedule with colleagues' locations before deciding whether to proceed.
- T02: a coordinator stops enrollment to assemble course and cost details for a manager's approval.
- T03: a coordinator notices a prerequisite only after starting to assign seats and returns to the course description.
These are example observations, not quotations. In real work, each would need a source reference, participant context, and the relevant point in the session. Use user interviews to understand actual experiences rather than asking people to endorse a feature list.
For T02, a candidate opportunity is: “I need enough information to request approval before committing seats.” A proposed approval dashboard belongs below that opportunity as one possible response. Keeping the need separate allows a simpler course summary or another approach to compete.
For T01, the underlying concern might be schedule suitability, but that interpretation needs checking. It could instead reflect mandatory attendance rules or a coordinator's uncertainty about asynchronous access. Record that uncertainty beside the observation. A tree should expose a weak inference instead of laundering it into a confident customer need.
Build the training-enrollment example
Place the outcome at the top. Beneath it, group the candidate opportunities around what coordinators are trying to decide: whether the training fits the team, whether they have enough information for approval, and whether people are ready to enroll. Attach T01, T02, and T03 to their corresponding branches.
Choose the approval-information branch for the worked exercise. This is an illustrative focus choice, not proof that it is the largest opportunity. In a real team, the choice should reflect the available evidence, relevance to the outcome, and the cost of leaving the problem unresolved.
| Level | Example | What remains uncertain |
|---|---|---|
| Outcome | More teams complete a first training assignment | Baseline, measurement window, and affected audience |
| Opportunity | Prepare an approval request before committing seats | Whether missing information is a meaningful barrier |
| Solution A | A shareable course-and-cost summary | Whether it contains the information approvers require |
| Solution B | A draft approval-request form | Whether teams will use another request workflow |
| Solution C | A clearer schedule and prerequisites preview | Whether clearer existing information is sufficient |
The selected branch connects approval information to three competing solutions and one explicit question to test.
Use Mockitt Whiteboard to arrange the outcome, evidence references, opportunities, and alternatives as connected cards. Keep evidence IDs on the cards rather than storing them only in a separate presentation. The board organizes reasoning; it does not turn illustrative notes into research evidence.
Compare alternatives under the same opportunity
A tree with one opportunity and one solution is often a feature proposal in disguise. Add alternatives that respond to the same need through different mechanisms, then compare their assumptions.
The course summary assumes that coordinators can reuse a compact explanation in their existing approval process. The draft request assumes that adding an in-product workflow will be acceptable. The clearer preview assumes the necessary facts already exist and are mainly difficult to find. These alternatives could lead to very different work even though they address the same apparent obstacle.
Do not vote for the most polished sketch. Ask what each idea would have to get right for the outcome to improve. Separate questions about comprehension from questions about adoption, feasibility, and whether the problem matters enough to change behavior.
A promising mockup can answer only part of that set. Someone understanding a course summary does not establish that their manager will approve the training, that the price is acceptable, or that the team will complete the assignment.
Choose a test that could change the decision
For the summary idea, begin with a narrow assumption: coordinators can identify the information needed for an approval request from the proposed summary. That is more inspectable than “the summary will improve conversion.”
Build a clickable course-summary prototype with the course, schedule, prerequisites, seat count, and a clearly labeled illustrative cost. Ask intended coordinators to prepare an approval request for a realistic situation. Observe what they seek, omit, or need from elsewhere, without telling them which fields they should mention.
- Assumption: the proposed summary supplies the information needed for the stated approval task.
- Evidence to collect: information the participant uses, missing details they request, and how they explain the next step.
- Evidence that would challenge it: essential facts still require another source, or the real approval barrier is unrelated to information.
- Follow-up: revise the summary, explore an alternative, or investigate the opportunity again.
Agree in advance how the team will use the observations. Do not retroactively declare success because participants liked the visual treatment. The prototype is an instrument for examining one assumption, not a substitute for a working approval integration or an outcome measurement.
Keep the tree connected to what you learn
After a research round, attach the new evidence to the relevant branch. Record whether it supports the interpretation, challenges it, or leaves the question open. Preserve abandoned alternatives with a short reason when that history will prevent the team from repeating the same discussion.
If several coordinators need procurement approval outside the platform, do not automatically add a procurement feature. Revisit whether a summary helps their existing process or whether the team lacks evidence about that part of the journey. Conversely, if the missing information is already easy to find, the chosen opportunity may need to be reframed.
Keep the outcome stable long enough to learn, while allowing the opportunity structure to improve. Reorganizing branches can be a sign of better understanding. Continually changing the outcome to fit a favorite solution is a different pattern.
Review the reasoning before committing to delivery
Share the tree with a brief explanation of the outcome, the selected branch, the evidence behind it, and the decision the next test will inform. Invite colleagues to identify unsupported jumps rather than simply adding feature suggestions.
For a facilitated team discussion, use the product discovery workshop agenda to move from that evidence to one selected assumption and an owned next test.
Useful design review questions include: Which observation supports this opportunity? Could another explanation fit? What alternative addresses the same need? What result would make us stop or change direction? Keep those questions attached to the particular branch, not in a generic checklist detached from the evidence.
The practical output is a tree that leads to an actionable learning decision. In this example, that means reviewing the approval-summary assumption before investing in an approval workflow. A completed diagram is the start of that investigation, not proof that the solution deserves to ship.
