Here's a scene that plays out in product meetings everywhere. The roadmap review is underway, and someone raises the feature that's been in development for fourteen months. Adoption is flat. The underlying assumption — that users wanted this workflow — turned out to be wrong. Someone suggests cutting it.
And then someone else says: "But we've put so much into this."
That sentence ends the conversation. Not because it's a good argument. Because it feels like one.
This is the sunk cost fallacy at work, and it's worth being precise about what it actually is: the tendency to continue an endeavor once an investment in money, effort, or time has been made — even when continuing is irrational. The past investment doesn't change the future math. But it changes how the future math feels, which turns out to matter enormously.
I wrote about this dynamic in a different form a few months back — the opportunity cost angle, the invisible price of staying. Today I want to go deeper on the product-specific version, because the failure mode here is subtler than it looks.
Why Product Teams Are Especially Vulnerable
The sunk cost fallacy hits product decisions harder than most because the investments are so visible. Engineering hours are tracked. Sprint velocity is measured. Someone's career narrative is attached to the feature. The bias is driven by psychological factors including loss aversion, fear of failure, unrealistic optimism, and personal responsibility — and in a product team, all four of those are running simultaneously.
Loss aversion means the pain of writing off fourteen months feels larger than the potential gain of redirecting those resources. Fear of failure means the person who championed the feature has identity wrapped up in its survival. Unrealistic optimism means the team keeps believing the next sprint will be the one where adoption finally clicks. And personal responsibility — the fact that we made this choice — makes it harder to see clearly than if someone else had made it.
The result is a decision-making environment where the forward-looking question ("does this feature create value from here?") keeps getting displaced by the backward-looking one ("can we justify what we've already spent?"). Those are different questions. They almost never have the same answer.
The Concorde Problem, Scaled Down
The canonical example of this trap is the Concorde. By 1965, internal Treasury assessments in Britain were projecting that the aircraft would never recoup its development costs. The economics were clear. And yet a minister in a 1968 parliamentary debate made the case for continuing in terms that should sound familiar to anyone who's sat in a product review: "The investment already made demands that we see this through."
That's not a strategy. It's a feeling dressed up as an obligation.
Your fourteen-month feature isn't Concorde — the stakes are lower, the correction is cheaper. But the cognitive structure is identical. Past investment gets reframed as a claim on the future, when economically it's nothing of the sort. The money is gone either way. The question is only what you do next.
The Nuance Worth Holding
Here's where I want to push back on the standard framing, because there's a real trap in overcorrecting.
IESE Business School researcher Johannes Müller-Trede argues that honoring sunk costs isn't always irrational — and the distinction he draws is useful. Past investment can be a legitimate signal about commitment, reputation, and the value of perseverance. The writer John le Carré's first two books had modest sales; his publisher's continued investment wasn't irrational, it was a bet on a developing talent. The sunk cost wasn't the reason to continue — but it was evidence that someone had already done the work of evaluating the bet.
The failure mode isn't "continuing after investment." It's continuing because of investment, when the underlying logic has changed. That's the diagnostic question for product decisions: has the reason we started this still held up? If the original assumption was "users want this workflow" and the data now says they don't, the investment is irrelevant. If the original assumption was "this will take eighteen months to show value" and you're at month fourteen, that's different.
The sunk cost fallacy is specifically the confusion between these two situations. One is evidence-based persistence. The other is backward-looking inertia that's borrowed the vocabulary of commitment.
The Practical Test
Before your next roadmap review, try this: strip the history out of the conversation entirely. Imagine the feature doesn't exist yet. Given what you know now — about user behavior, about the market, about your team's capacity — would you build it?
If the answer is yes, continue. If the answer is no, the fourteen months don't change that.
The investment already made is not a reason. It just feels like one. And feeling like a reason is exactly what makes it dangerous.