Opportunity Solution Tree Template

A feature backlog lists things to build. An OST explains why you are building them. The tree connects every solution to an opportunity (customer need) and every opportunity to a measurable outcome. This structure prevents "feature factory" mode where teams ship features without knowing whether they move the needle. When stakeholders ask "why are we building this?", the tree gives you the answer.

Start with 3-5 opportunities per outcome. Fewer than 3 suggests you have not explored the problem space enough. More than 7 makes the tree unwieldy and hard to prioritize. You can always add opportunities as you learn more from customers. The goal is to have enough breadth to make a real choice about where to focus.

Use the evaluation criteria in Part 3 to make the decision evidence-based rather than opinion-based. Score each opportunity on customer evidence, impact, frequency, and feasibility. If scores are close, run a small experiment on each and let the results decide. The tree makes disagreements productive because everyone can see the reasoning.

You can start with assumptions, but label them clearly as assumptions rather than validated opportunities. The value of the tree drops significantly without customer evidence. An OST built on internal opinions is just a repackaged feature backlog. Aim to validate each opportunity with at least 5 customer data points (interviews, support tickets, or behavioral data) within 2 weeks.

Weekly. After every discovery activity (interview, experiment result, usability test), update the tree. Add new opportunities. Prune invalidated solutions. Move experiments that worked into the "ready to build" column. A static tree posted on a wall and never updated is discovery theater. The tree should be your team's living map of the problem space. ---