An opportunity solution tree separates three things teams often mix together: the result they want, the unmet customer needs they could address, and the ideas they might build. Without that separation, “add a chatbot” can appear on a roadmap before anyone has explained what problem it would solve.
Use a shared product-planning canvas to keep those connections visible. The example below follows an online course team deciding how to help learners finish their first practice exercise. It works through one branch deeply enough to compare alternatives rather than filling a tree with disconnected feature ideas.
Keep each level of the tree distinct
Teresa Torres describes the method in Product Talk's opportunity solution tree guide. A desired outcome gives the discovery work a direction. Opportunities are customer needs, pain points, or desires. Solutions are possible ways to address a selected opportunity. Assumptions and tests help a team examine why those solutions might or might not work.
“Learners cannot tell what the first exercise expects” is a potential opportunity. “Add a worked example” is a solution. “Learners can use an example to understand the instruction without simply copying the answer” is an assumption worth investigating. Putting all three on the same level makes the reasoning hard to inspect.
An opportunity tree is not a release plan. Its branches contain alternatives, including ideas that may never be built. It is also not evidence by itself: neatly connecting a feature to an outcome does not demonstrate that the feature will produce that outcome.
Define the learning-product outcome
Consider a hypothetical course where learners watch an introductory lesson and then begin a short practice exercise. The team wants more of the people who begin that exercise to finish it. It measures the proportion who submit a complete response among first-time learners who open the first exercise.
That definition still needs an observation window, a rule for incomplete submissions, and a way to exclude test accounts. The team should obtain a baseline from its own data before setting a numerical target. No baseline or improvement percentage is assumed here.
Completion is a product behavior, not proof of learning. Keep an educational guardrail beside the outcome: the exercise must still require the intended thinking. Making the submit button easier to press while removing the task could improve the completion metric and damage the course.
Organize opportunities around learner needs
The following branches are possibilities to investigate in this example, not reported findings from real interviews. In an actual tree, put the source and context beside each opportunity: a research session, an observed attempt, or a support conversation. Leave unsupported ideas visibly separate from established observations.
| Possible learner need | What to investigate | Not yet an opportunity statement |
|---|---|---|
| Understand what a complete answer should contain. | Where does the learner hesitate, and how do they interpret the instruction? | “We need a chatbot.” |
| Find a manageable place to begin. | Does the learner understand the task but struggle to choose a first step? | “Break everything into three screens.” |
| Know how to continue after an incorrect attempt. | What does the learner do after receiving feedback? | “Add more notifications.” |
The first two needs may sound similar, but they suggest different behavior. Someone who cannot explain the task needs clarification. Someone who explains it accurately but cannot start may need help decomposing it. Combining them into “make the exercise easier” loses that distinction.
Product Talk's opportunity-mapping guidance emphasizes understanding the opportunity space. Group needs by their meaning and relationship, not simply by the screen on which someone mentioned them. A learner's difficulty can cross several screens.
Work one opportunity through three alternatives
Suppose research supports the first branch: learners understand the lesson but cannot tell what the exercise expects. The team selects that need for the next investigation. It now compares three different responses instead of treating the first suggestion as the plan.
| Solution candidate | Assumption behind it | Useful observation |
|---|---|---|
| Rewrite the instruction with a clear statement of the expected answer. | The main difficulty is ambiguous wording rather than missing subject knowledge. | Can learners explain the task in their own words and begin an appropriate answer? |
| Show a worked example using a different subject. | Learners can transfer the example's structure without copying its content. | Do their attempts show the intended reasoning on the new subject? |
| Offer a short sequence of guiding questions. | Learners need prompts to identify the answer's components, not a completed model answer. | Can they construct an answer after using the prompts, and where do they still hesitate? |
These alternatives address the same need through different mechanisms. That makes the comparison more informative than choosing between a chatbot for instructions, a reminder for attendance, and a dashboard for instructors. Those features belong to different branches.
The observation is not merely whether a learner says they like the design. Watch what they do with an unfamiliar practice task, then ask about the confusing moments. A prototype can help examine comprehension and usability, but it cannot establish long-term learning or course completion on its own.
Keep inconvenient evidence attached
Imagine the worked example helps some learners begin, but others copy its surface format without understanding the task. That is not an uncomplicated win. Keep both observations beside the solution and consider whether a contrasting example, clearer instruction, or a different approach addresses the problem.
If learners already understand the instruction and stop because the exercise requires material they have not learned, move back up the tree. You may have selected the wrong opportunity. Adding more prompts to the existing branch would refine the wrong explanation.
When several solutions depend on the same uncertainty, such as whether prerequisite knowledge is missing, investigate that uncertainty before polishing each design. An assumption map can help choose among important, weakly supported claims, while the opportunity tree preserves the connection to the learner's need.
Build the tree in Boardmix
Place the outcome at the top of your Boardmix canvas. Add the three learner needs beneath it, leaving room beside each for a source note. Expand only the selected need into the three solution candidates. Under each solution, place the assumption and the observation that would help examine it.
Use a consistent visual distinction between observed needs, hypotheses, and possible solutions. The labels matter more than the colors: someone reading the board later should not mistake an untested suggestion for a research finding. Put discarded options in a separate area with a short reason instead of silently removing the history.
Open a Boardmix board and start with the outcome and the customer evidence you already have. If the first thing you place is a feature request, move it to a solutions area and work upward: which need would it address, and why would addressing that need matter?
