Opportunity Solution Tree Template

The outcome sits alone at the top and states the one measurable result the tree exists to move, for example activation rate or 90 day retention, not a feature or a project name. Below it, opportunities branch out as the unmet needs, pain points, or desires that stand between users and that outcome, phrased as problems rather than solutions, so a team can hold several live at once without committing to how any of them gets solved. Each opportunity then branches into two or more competing solutions, forcing an explicit choice instead of pursuing whichever idea reached a roadmap first, and each solution's riskiest assumptions become the experiments at the bottom of that branch, sized to run before a full build starts.

A single branch example: outcome, increase weekly active accounts. Opportunity, new users cannot tell which of the product's three modes fits their team on day one. Two competing solutions branch off that opportunity: an interactive setup quiz, or a persona based template gallery. The setup quiz branch carries one experiment, a five question prototype tested with ten new signups this week, before either solution gets built for real.

Use this template at the start of a discovery cycle, whenever a team has more candidate opportunities than it can act on and needs a shared, visual way to compare them rather than debating from memory in a meeting. It also works as a standing artifact a product trio updates weekly, so new user research adds branches instead of restarting the whole map from a blank page each time.

Fill it in top down, not bottom up. Write the outcome first and get explicit agreement on the metric before opportunities go up, because a tree built around a vague outcome like improve the product produces opportunities nobody can prioritize against each other. Pull opportunities from real user research, interview notes, and support themes rather than an internal brainstorm, then group near duplicate opportunities into one branch instead of letting the tree sprawl sideways.

The most common mistake is skipping straight to solutions and opportunities and building the tree backward from a feature someone already wants to ship, which turns the exercise into a justification exercise rather than a discovery one. A second common mistake is treating the tree as a one time workshop artifact instead of a living map, so it goes stale within a month while the team's actual understanding of the problem keeps moving.

Builders Camp's Discovery Expert Track teaches this exact mapping method, alongside the assumption mapping template used to size the experiments at the bottom of each branch. The tree template itself lives in the Builders Camp templates library, included in every Membership alongside 48 other templates and every bootcamp and track needed to use them well.