The statistic everyone cites, and where it came from
You have seen the number. Sixty-four percent of software features are rarely or never used. It appears in product decks, agile training, and consultancy pitches, usually attributed to a Standish Group study of two thousand projects across a thousand companies.
Mike Cohn investigated it and contacted the Standish Group directly. The figure came from a keynote given by Jim Johnson at the XP 2002 conference in Sardinia. The underlying data was a study of four internal applications.
Four.
There is better data pointing the same way. Pendo's 2019 Feature Adoption Report, using aggregated anonymised usage across hundreds of customer products over three months, found that around 12% of features generated 80% of daily usage volume, with roughly 80% of features rarely or never used. That is a vendor report rather than independent research, and it is a substantially larger sample than four applications.
So the honest position: the direction is well supported, the famous number is not. Most of what gets built sees little use. Nobody has established the precise proportion, and citing 64% as though it were a finding repeats a claim about four applications from 2002.
The framework in this article exists to reduce that waste. It deserves an accurate account of the problem it addresses.
What the tree is
Teresa Torres set out the Opportunity Solution Tree in Continuous Discovery Habits. Four levels, connected.
The outcome sits at the root. One measurable business or product outcome the team is working toward. Not a feature, not a project. Something like reducing time to first successful order, or increasing repeat purchase within ninety days.
Opportunities branch beneath it. Customer needs, pain points, and desires that, if addressed, would move that outcome. These come from customer conversations, not from internal brainstorming. They are framed in the customer's terms.
Solutions branch beneath opportunities. Candidate ways to address a specific opportunity. Several per opportunity, deliberately.
Assumption tests sit beneath solutions. The specific things that must be true for a solution to work, and how each will be checked.
The structural rule is the framework: every node must connect upward. A solution that cannot be traced to an opportunity, and an opportunity that cannot be traced to the outcome, does not belong on the tree.
What the structure actually enforces
Three things, none of which happen reliably without it.
Traceability. The most common product failure is a feature arriving with no line back to a business outcome. It came from a sales escalation, a competitor's release, or a senior person's opinion. On a tree it has nowhere to attach, and the absence is visible rather than arguable.
Comparison instead of evaluation. Torres's argument here is the sharpest part of the method. Teams typically evaluate one solution at a time — is this good enough to build — which produces a bias toward yes. Generating several solutions for the same opportunity forces comparison, and comparison produces better choices than sequential evaluation.
Opportunity selection as an explicit decision. By separating opportunities from solutions, the tree makes visible that the team chose which customer need to address. Most backlogs conceal that choice inside a list of features.
Continuous, not periodic
Torres's framing of continuous discovery is specific: weekly touchpoints with customers, conducted by the team building the product, involving small research activities, in pursuit of a desired outcome.
Each clause matters.
Weekly rather than quarterly. Research conducted in blocks produces insight that is stale by the time it is used.
By the team building the product. Not by a research function that hands over findings. Insight degrades in transfer, and the people making the trade-offs need the raw material.
Small activities. Continuous means frequent and light rather than occasional and heavy.
In pursuit of an outcome. Discovery without a target produces interesting findings nobody acts on.
The evidence
Documented practitioner method. The Opportunity Solution Tree comes from Torres's coaching practice across many product teams. It is internally coherent and widely adopted. There is no independent controlled research showing that teams using it produce better outcomes than teams that do not, and nobody claims otherwise.
What supports it indirectly is the adjacent evidence: usage data consistently showing that a minority of features carry most of the value, and the broader finding across experimentation programmes that most ideas do not work. A method that forces traceability and comparison is a reasonable response to both.
Under the grading used across this series, use it because the logic holds and the discipline is cheap — not because it has been shown to outperform.
Six rules that make it work
1. One outcome per tree. Multiple outcomes produce a diagram, not a decision structure. If the team is genuinely accountable for two outcomes, that is two trees, and probably a scoping problem.
2. Opportunities come from customers. An opportunity nobody has heard a customer describe is a hypothesis wearing customer clothing. Trees populated from internal opinion inherit every internal bias.
3. Opportunities are needs, not solutions. "Customers cannot find their order history" is an opportunity. "Add an order history page" is a solution. Teams collapse the two constantly, which removes the comparison step entirely.
4. At least three solutions per opportunity considered. Fewer means the team is evaluating rather than comparing, and evaluation biases toward approval.
5. Assumptions get named and tested, not assumed. Desirability, viability, feasibility, usability. The cheapest test that could disconfirm, run first.
6. The tree is revised weekly. It is a working artefact. A tree drawn once and pinned to a wall has become decoration.
Where it goes wrong
Solutions get retrofitted onto opportunities. The team knows what it wants to build and constructs the branch above it to justify the decision. The tree then documents the reasoning rather than producing it — a failure mode this series has now encountered in almost every framework.
Opportunities are internal wishes. Populated from stakeholder requests rather than customer conversations, the tree formalises the same politics it was meant to interrupt.
It replaces the outcome decision. The tree assumes the outcome is correct. Choosing the wrong outcome produces a well-structured tree pointing at the wrong target, and the framework has nothing to say about it.
Discovery does not actually happen weekly. The structure without the cadence produces a diagram maintained from memory.
One solution per opportunity. The most common practical failure, and it removes the comparison mechanism that gives the tree most of its value.
Diagnostic: is the tree doing work?
Six tests.
There is exactly one outcome at the root, and it is measurable.
Every opportunity can be traced to something a customer actually said.
At least one opportunity has three or more solutions under consideration.
Nothing currently in development is missing from the tree.
The team has spoken to a customer in the past week.
An assumption test has caused a solution to be dropped.
Test four is the fastest audit available. Anything being built that does not appear on the tree either has no traceable outcome, or the tree is not being used.
What this produces
A backlog where every item can answer why.
That is the practical output, and it changes two conversations. The first is prioritisation, which becomes a discussion about which opportunity to address rather than which feature to build. The second is the one with leadership, where "why are we building this" has a structural answer rather than a defensive one.
The deeper value is in what gets stopped. A tree makes orphaned work visible — the features that arrived through escalation or opinion and connect to nothing. Most organisations have several in flight at any time and no mechanism for noticing.
Frequently asked questions
What is an Opportunity Solution Tree?
A visual structure connecting one measurable outcome to customer opportunities, then to candidate solutions, then to the assumption tests that check them. Every node must trace upward, which makes untethered work visible.
Is it true that 64% of features are never used?
The commonly cited figure came from a 2002 conference keynote based on a study of four internal applications. Larger vendor data from Pendo found around 80% of features rarely or never used, with 12% generating 80% of usage. The direction is well supported; the specific famous number is not.
What is the difference between an opportunity and a solution?
An opportunity is a customer need or pain point stated in the customer's terms. A solution is a way of addressing it. Collapsing the two removes the comparison step, which is where most of the framework's value sits.
How many solutions should we consider per opportunity?
At least three. Fewer means the team is evaluating a single option rather than comparing, and single-option evaluation biases toward approval.
How often should the tree be updated?
Weekly, alongside customer contact. Torres's definition of continuous discovery specifies weekly touchpoints conducted by the team building the product. A tree updated quarterly is a diagram.
Does the framework tell us which outcome to pursue?
No. It assumes the outcome is already chosen and correct. Selecting the wrong outcome produces a well-structured tree aimed at the wrong target, and that decision belongs upstream.
How is this different from a PR-FAQ?
A PR-FAQ tests whether one significant idea is worth committing to. An opportunity tree governs an ongoing stream of decisions against a single outcome. They operate at different scales and are complementary.
Sources
Torres, T., Continuous Discovery Habits (2021)
Cohn, M., investigation into the origin of the Standish Group feature usage figure, including direct correspondence with the Standish Group
Johnson, J., Standish Group, keynote at XP 2002
Pendo, 2019 Feature Adoption Report — aggregated anonymised usage data across hundreds of products
Structure your next phase
Zerologic works with product and leadership teams to connect what gets built to the outcome it is supposed to move — and to make untethered work visible before it ships.
Talk to us: partners@zerologic.io · zerologic.io
