Opportunity Solution Trees With Real User Evidence

Product teams love opportunity solution trees. The framework promises clarity: start with an outcome, map opportunities, generate solutions, run experiments. It's elegant on a whiteboard. But most teams build their trees on quicksand—assumptions masquerading as customer insight.

The gap between theory and practice shows up in three places. Teams populate their trees with problems they think exist rather than opportunities customers actually experience. They generate solutions based on internal brainstorms rather than observed customer behavior. And they prioritize branches using gut feel rather than evidence about which opportunities matter most.

This creates a predictable failure pattern. Teams invest months building features that address the wrong opportunities. Or they solve real problems in ways customers don't value. The opportunity solution tree becomes an elaborate justification system for building what the team already wanted to build.

The solution isn't to abandon the framework. Opportunity solution trees work—when they're grounded in actual customer evidence at every node. This requires rethinking how teams gather input, structure conversations, and validate assumptions throughout the discovery process.

Why Opportunity Trees Fill With Assumptions

The typical approach starts with a kickoff meeting. The product manager shares the desired outcome. The team brainstorms opportunities. Someone captures ideas on sticky notes. The group clusters themes and votes on priorities. By the end of the session, the tree has taken shape.

This process feels productive. The team generated dozens of ideas. Everyone contributed. The resulting tree looks comprehensive. But examine the nodes closely and a pattern emerges: nearly every opportunity reflects internal perspective rather than external reality.

Consider a SaaS company building an opportunity tree around improving activation rates. The team identifies opportunities like