The reading room · Digna Legi
Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Dr
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Evidence is sampled with gaps, so completeness, repetition, and the full quality of the guide cannot be judged confidently.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Original article ↗ · about 21 min (text estimate)
Why read this
Product discovery stays clearer when outcomes, customer opportunities, candidate solutions, and assumption tests remain separate instead of collapsing into feature debate.
AI brief · Checked against source text
The main idea
An opportunity solution tree is a visual map from a desired business outcome to customer opportunities, possible solutions, and tests of the assumptions behind those solutions. Its force comes from keeping distinct things distinct: outcomes define scope, opportunities capture customer needs or desires, solutions propose responses, and assumption tests reduce risk before delivery. The author argues this keeps teams aligned while discovery remains iterative and messy.
Some background helpful. Basic product discovery vocabulary: outcomes, customer interviews, roadmaps, assumptions.
Go a little deeper
Opportunities are not feature requests
The central discipline is refusing to let a proposed action masquerade as customer understanding. The author’s test is whether there is more than one way to address the statement. If not, it is probably a solution in disguise. Asking why the customer wants it can expose the underlying need, pain point, or desire, which then admits multiple possible responses.
The outcome sets the useful boundary
The top of the tree is not decorative; it determines what belongs in discovery. The author distinguishes business outcomes, product outcomes, and traction metrics, preferring product outcomes because they are close enough for a team to influence while broad enough to support meaningful discovery. Feature-level traction metrics are treated as too narrow for this role.
Interview evidence is used to manage synthesis risk
The author recommends starting the opportunity map after three or four customer stories: enough to avoid overreacting to one conversation, not so many that the team stalls. The tree is then revised after each additional batch. This makes the map a living synthesis artifact rather than a one-time workshop output or a brainstorming canvas.
Small target opportunities enable comparison
The tree pushes teams to choose one small target opportunity, then compare several solutions for it. That sequencing matters: effort belongs at the solution level, not the opportunity level, because the same opportunity may have both hard and simple answers. The author links this to limiting work in progress and making better compare-and-contrast decisions.
A case from the article
Google Reader’s missing business value
The author uses Google Reader to show why the tree starts with business value even though the opportunity space is customer-centered. Google Reader is described as beloved and heavily used, yet shut down because it did not create enough value for Google. The example illustrates the article’s core tension: customer value alone does not guarantee long-term viability.
How the case is made
The case is made through a practical taxonomy, procedural guidance, and product-team observations, with examples such as Google Reader and Dark Sky.
Where the idea has limits
The method depends on good inputs: the author explicitly says teams need a target customer theory, a defined outcome, and several story-based interviews before building the tree.
A question to take away · from Digna Legi
Where are you currently treating a solution preference as if it were already a validated customer opportunity?
What the original adds
The source adds detailed operational guidance: how to split outcomes across teams, revise the tree after interviews, choose target opportunities, handle stakeholder detail levels, and connect trees to roadmaps and vision.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.