Marty Cagan and Chris Jones of the Silicon Valley Product Group put a number on the waste built into most roadmaps: most industry analysts place the share of roadmap features and projects that generate a positive return on investment in the 10 to 20 percent range. Read that again. For every ten items a team ships this quarter, eight or nine do nothing measurable for the business. That is not a prioritization problem. It is a definition problem, and the missing definition is the line between a feature and a product.
The distinction is old and precise. In 2012, Ben Horowitz's internal Netscape memo "Good Product Manager/Bad Product Manager" went public on the Andreessen Horowitz blog, and it drew the line in one sentence.
Good product managers focus the team on revenue and customers. Bad product managers focus the team on how many features a competitor is building.
A feature is a unit of work. A product is a unit of value, measured by what a customer does differently after you ship it and what that does for the business. A roadmap that lists features is tracking the wrong unit.
The Failure Mode Has a Name
Silicon Valley Product Group calls the organizational version of this a "feature team": the product manager receives a prioritized list of items to build, and responsibility for whether the feature actually creates value and holds up as a viable business investment stays with whoever requested it, not with the team building it. Nobody owns the outcome. Everybody owns the ticket.
Melissa Perri named the resulting pattern in her 2018 book "Escaping the Build Trap": a "feature factory" measures itself by output shipped rather than outcomes achieved. It looks productive. Velocity charts go up. Release notes get longer. None of that tells you whether the business is healthier than it was last quarter, and the 10 to 20 percent figure above is what that gap costs when nobody is watching it.
Outcomes on the Roadmap, Not Output
Josh Seiden's 2019 book "Outcomes Over Output" makes the fix concrete: organize the roadmap around measurable changes in customer behavior, not a list of things to build. A feature roadmap answers "what are we shipping." An outcomes roadmap answers "what will customers do differently, and what will that do for revenue or retention." Those are different documents and they belong in different review meetings.
Amazon built a mechanism to force the second kind of thinking before a single line of code gets written. Colin Bryar and Bill Carr describe it in "Working Backwards", published in 2021: the PR/FAQ process requires a team to draft a mock press release and customer FAQ for a proposed feature before building it. The exercise fails fast when a feature has no story: no customer who wants it, no problem it solves, no reason anyone would notice it shipped. That failure is cheap on paper. It is expensive after three sprints of engineering time.
The Test for Your Roadmap This Week
- Take the next five items on your roadmap and ask one question of each: what customer behavior changes, and what business metric moves, if this ships.
- If the honest answer is "engineering gets to close the ticket" or "sales asked for it," you are looking at a feature request, not a product decision, and it does not belong on the same list as the roadmap items tied to revenue or retention.
- Write the one paragraph case for value and viability before the ticket gets created, the way a PR/FAQ forces it, and assign ownership of whether the metric moves, not just whether the code ships.
None of this means features are worthless. Products are built from features. The failure is treating the feature list as the roadmap instead of treating it as the implementation detail of a roadmap built on outcomes. Given that only 10 to 20 percent of roadmap items apparently clear that bar today, the work this week is not writing new features. It is going back through the current roadmap and killing the ones that cannot answer the question.