The Roadmap Commitment Trap

Definition

Cagan argues the harm in a conventional product roadmap isn't the list of ideas itself — "if it was just ideas, there's not much harm in that" — it's the label. Put a list of features on a document titled "roadmap," and "no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment." That interpretive shift converts an unvalidated idea into an obligation to deliver, which forces the team to keep pushing a specific solution forward even after evidence shows it doesn't solve the underlying problem — because by then the organization has already promised it.

In the Book

Chapter 22 states what Cagan calls the two inconvenient truths about product work: first, that at least half of all product ideas simply won't pan out — value isn't there, or usability isn't, or feasibility or business viability isn't — and second, that even the ideas that do prove valuable, usable, feasible, and viable typically take several iterations before they deliver the business value expected ("time to money"). He contrasts how weak and strong teams respond to these truths. Weak teams "just plod through the roadmap they've been assigned," and when something doesn't work — which is often — they blame the stakeholder who requested it and schedule another iteration on the same roadmap, or propose a redesign, hoping this time it lands; given enough time and management patience, they can eventually grind their way there. Strong teams instead treat these truths as the reason product discovery exists at all — Cagan calls discovery "the most important core competency of a product organization" — because prototyping and testing ideas in hours or days, rather than weeks or months, changes both the pace and the outcome. Chapter 6's Figure 6.1 traces the mechanism upstream: a pipeline of Ideas → Biz Case → Roadmap → Requirements → Design → Build → Test → Deploy, where the roadmap is negotiated from a business case built on estimated value and cost before any of the four risks have actually been tested.

Cagan doesn't argue that commitments are always wrong — he acknowledges some delivery dates genuinely need to be promised — only that they should be "high-integrity commitments" made after the underlying problem is understood to be solvable, not a byproduct of putting an idea on a planning document.

Why It Matters

A roadmap silently converts a plan — which is supposed to be revisable as new information arrives — into a promise, which is supposed to be kept regardless of new information; once that conversion happens, evidence that the plan is wrong gets absorbed as a delivery problem to work around rather than a reason to change course. Recognizing that a document's format, not its content, is what triggers this shift is the generalizable insight: the same list of ideas framed as a backlog of hypotheses to test behaves completely differently, organizationally, than the identical list framed as a schedule of commitments.