How to Use an Opportunity Solution Tree

The opportunity solution tree exists to stop a familiar argument: two people defending two features, neither asking which problem either one solves. The tree forces the conversation up a level. Before you compare solutions, you compare the opportunities they address, and before that, you agree on the outcome you are chasing.

The three layers

A tree has a clear structure, detailed in our opportunity solution tree definition.

• Outcome: the single business or customer result at the top, ideally tied to a north star metric. Everything below must serve it.
• Opportunities: the customer needs, pain points, and desires that, if addressed, would move the outcome. These come from research and feedback, not from your imagination.
• Solutions: candidate features or changes that could address each opportunity. Multiple solutions per opportunity is healthy.

The discipline is that you never jump from outcome to solution. You always pass through an opportunity, which keeps the team honest about what problem a feature actually solves.

Where opportunities come from

The opportunity layer is only as good as the feedback under it. If you invent opportunities in a workshop, the tree becomes fiction. Real opportunities come from what customers actually say, repeatedly, across accounts. Kithspark feeds this layer directly, because requests cluster into themes while feedback lineage preserves every account and voice behind each theme. An opportunity backed by forty credited accounts is a fact. One backed by a hunch is not.

Comparing opportunities, not solutions

The tree's real value is the middle layer. Rather than argue which feature is best, you ask which opportunity is biggest. Size each opportunity by reach and value, and the comparison sharpens. When you weight opportunities by the revenue of the accounts behind them, a quiet enterprise pain can outrank a loud but low-value one. Kithspark's value-weighted feedback gives the opportunity layer a real size instead of a vote count.

Generating and testing solutions

Once you pick an opportunity, generate several solutions, not one. The tree expects breadth here, because the first idea is rarely the best. Then test the riskiest assumptions cheaply before committing. The structure keeps a single pet solution from posing as the only option, which is how most roadmaps quietly narrow.

Keep the tree alive

A tree drawn once and abandoned is just a diagram. The point is to revisit it as new feedback arrives, opportunities grow or shrink, and solutions get validated or killed. As requests flow in, the size of each opportunity shifts, and the tree should shift with it. A living tree is a prioritization instrument. A dead one is a poster.

When to use it

Reach for an opportunity solution tree when the team keeps arguing about features without agreeing on the problem, when a single outcome needs many bets, or when a roadmap feels like a list of pet projects. It is heavier than a scoring model, so save it for the spaces where the problem itself is genuinely unclear. For a backlog of well-understood requests, a weighted score is faster and enough.