Skip to main content
Marketing & Product

The Sunk-Cost Trap in Roadmap Prioritization: Why Engineering Cost Already Spent Should Never Factor Into a Kill Decision

A feature that's had six months of engineering investment feels harder to cancel than one with two weeks in it — even when the remaining, forward-looking case for both is identical.

Key Takeaways
  • The sunk-cost fallacy is the tendency to let past, unrecoverable investment influence a forward-looking decision, even though that investment is gone regardless of the choice made now
  • Roadmap kill decisions are especially vulnerable to this because engineering effort is visible, trackable, and easy to frame as being wasted if a feature is cancelled
  • The only economically relevant question for a continue-or-kill decision is the forward-looking cost and expected value from this point forward, independent of what's already been spent
  • Reframing the decision explicitly as if the feature were starting from zero today strips out the sunk-cost pull and tends to produce a cleaner answer

A SaaS team has invested six months of engineering time into a feature that early usage data suggests won't meaningfully move retention or expansion revenue. The forward-looking case for finishing it is weak — a similar amount of remaining effort would likely produce more value applied elsewhere. The feature ships anyway, because six months feels like too much to have wasted. This is the sunk-cost fallacy operating exactly as it's defined: letting an unrecoverable past cost influence a decision that should only be evaluated on what happens from this point forward.

Why this shows up so persistently in roadmap decisions specifically

Engineering effort is unusually visible and trackable compared to many other kinds of organizational investment — sprint points, months of a team's time, a specific dollar figure attached to headcount cost, all make the size of past investment concrete and easy to reference in a room. This visibility is exactly what makes the sunk-cost pull stronger in roadmap decisions than in many other business contexts: it's hard to say "we're abandoning six months of work" out loud without it feeling like an admission of failure, even when abandoning it is the economically correct call given what's now known.

The past cost is genuinely irrelevant to the forward-looking decision — not just psychologically, but arithmetically

The six months already spent cannot be recovered by any decision made today, whether the feature ships or is cancelled — it's gone in both scenarios. The only cost that should factor into a continue-or-kill decision is the remaining cost to finish, weighed against the expected forward value of finishing versus the expected value of redirecting that same remaining effort elsewhere. Whether the remaining cost is small because six months are already sunk, or the remaining cost is large because the project barely started, is irrelevant to this comparison — what matters is only the remaining cost and the remaining expected value, on both sides of the comparison.

A useful reframe for stripping the sunk-cost pull out of the room

Asking the team "if this feature had zero engineering effort invested in it today, and we were deciding fresh whether to spend the remaining estimated effort on it versus something else, what would we choose" removes the emotionally loaded framing of "wasting" past effort and replaces it with the actual decision being made — a forward-looking allocation of remaining resources. If the honest answer to that reframed question is that the team wouldn't choose to start this feature today given everything currently known, that's strong evidence the sunk-cost fallacy, not a genuine forward-looking case, is what's keeping the feature alive.

Why this matters more at the margin than most other roadmap biases

Sunk-cost-driven continuation doesn't just waste the remaining engineering effort on the low-value feature — it's an opportunity cost against whatever else that same effort could have produced, which is usually the more consequential loss. A team that ships three additional weak features because each one individually felt too far along to cancel has, in aggregate, spent a meaningful fraction of its total capacity on low-value work it would never have chosen from a genuinely forward-looking starting point.

What this means for how kill decisions should actually be made

  • Evaluate continue-or-kill decisions purely on remaining cost versus remaining expected value, explicitly excluding what's already been spent
  • Use the zero-investment reframe ("would we start this today, from scratch, given what we now know") as a standing check before continuing a struggling feature
  • Watch specifically for language in prioritization discussions that references how much has already been invested as a reason to continue — that's the fallacy surfacing directly
  • Recognize that killing a feature isn't wasting the past investment — the investment is already spent either way; killing it is protecting the investment still to come

None of this makes canceling a feature easy — there are real organizational and morale costs to reversing course publicly. But those costs are a separate, legitimate consideration from the sunk engineering cost itself, which should carry zero weight in the actual forward-looking arithmetic.

sunk cost fallacyroadmap prioritizationproduct decision makingSaaS product teamsfeature kill decisions