The Roadmap Ate the User

TL;DR:
Roadmaps start as bets and quietly become mandates. Escalating commitment means the more you've built, the harder it gets to change course, even when you should. The FBI spent $170 million on software it never deployed. Your roadmap is doing a quieter version of the same thing.

At some point on almost every project, the roadmap stops describing what you’re building and starts dictating it. Nobody announces this. Nobody decides it. But somewhere between the first sprint and the third roadmap review, the question shifts from “what does the user need?” to “how do we hit the commitments we already made?” You stop building for the person outside the room. You start building for the document pinned to the wall.

This is not laziness. It is psychology doing exactly what psychology does.

The trap you built yourself

Barry Staw named the mechanism in 1976. He called it escalating commitment: the pattern where decision-makers who bear personal responsibility for a failing course of action commit more resources to it, not fewer. His experiment with 240 business students showed that people threw good money after bad with the most force when they felt that original responsibility was theirs. The worse things got, the harder they doubled down.

“Persons committed the greatest amount of resources to a previously chosen course of action when they were personally responsible for negative consequences.”

Barry M. Staw

This is the mechanism running underneath your roadmap conversation. The longer you’ve owned a direction, the more evidence you need to change it, and the less you actually weigh that evidence when it arrives. The roadmap becomes a record of past commitments, and past commitments become the strongest argument for future ones. You’re not reasoning forward. You’re defending backward.

The planning fallacy compounds this. Kahneman and Tversky identified it in 1979: people underestimate how long things will take and overestimate the benefits of completing them, without exception. In a 1994 study, psychology students predicted finishing their theses in an average of 34 days. The real average was 55. Nobody predicted they would go over. Nobody. The optimism is not ignorance. It’s structural. You focus on how the plan should go, not on how similar plans actually went. And once you’ve built a roadmap on optimistic assumptions, you spend the rest of the project trying to rescue those assumptions rather than revising them.

When the evidence doesn’t change anything

The FBI spent five years and $170 million building the Virtual Case File system, a software project meant to modernize its paper-based case management. Engineers flagged serious problems. External reviewers flagged serious problems. At one point a security engineer named Matthew Patton posted a public warning about what he saw as crippling mismanagement. The FBI and SAIC removed him from the project within days. The evidence kept arriving. The project kept going. In April 2005, the FBI abandoned VCF without deploying it. People had warned them, again and again. Nothing changed until there was nothing left to change.

This is what escalation looks like when it runs its full course. It doesn’t look like stupidity. It looks like commitment. It looks like resilience. Inside the organization, the people who kept going despite the problems felt they were doing the right thing, protecting their team’s work, honoring the contracts, proving the skeptics wrong. The psychology felt like dedication. The outcome was $170 million of nothing.

The FBI case is extreme. Your version is quieter. It looks like a feature that every user test says nobody uses, but it ships anyway because it was on the roadmap. It looks like a flow that research says is broken, but you launch it anyway because you’re behind schedule and changing it now would push Q3. It looks like a decision made six months ago that nobody wants to revisit because revisiting it means admitting the six months were a mistake.

The specific cost to design

What makes this so damaging for designers is that roadmaps don’t just crowd out good decisions. They crowd out the questions that would surface them. When the roadmap is fixed, you stop asking “what should we build?” and start asking “how should we build what we said we’d build?” The user problem that sits underneath the roadmap feature becomes invisible. You optimize the feature. You never re-examine the problem it was meant to solve.

Kahneman called this the inside view: judging a project by its internal logic and stated goals rather than by reference to how similar projects have actually performed. The inside view is seductive because you know your project in detail, and that detail feels like control. You know the edge cases, the tradeoffs, the reasons you made each choice. What you lose is the outside view: the base rate for projects like yours, the pattern of similar decisions in similar organizations with similar confidence, the fact that about half of students who predicted finishing a 34-day project in 34 days actually took 55.

The antidote is not more willpower. It is a structural interruption.

How to break the loop

Set a date in the calendar. Not a shipping date, not a review meeting, but a specific moment where the only question on the table is whether the original problem framing still holds. Call it what you want. Some teams call it a direction check. Some call it a kill switch. The name doesn’t matter. What matters is that it happens before you’ve gone so far you can’t afford to ask.

The question is not “are we on track?” That question locks you into the roadmap’s logic. The question is “if we were starting this today, knowing what we know now, would we build this?” If the answer is yes, you ship with more confidence. If the answer is anything other than a clear yes, you have just caught escalation before it finished eating your budget.

The roadmap is not the product. It is a bet on what the product should be. Bets go wrong. The cost of updating a bet is always lower than the cost of defending one that stopped being right six months ago.

This is the uncomfortable thing about roadmaps: they are most dangerous exactly when they feel most reassuring. When everything is planned and committed and sequenced, that’s when you are most likely to have stopped building for the user and started building for the document. The user doesn’t care about your roadmap. They care whether the thing works.