You're in a product review meeting. The feature has missed its adoption targets for three quarters running. The engineering team has quietly stopped believing in it. Two of your best PMs have privately told you it should be cut.
But someone opens with: "We've put eighteen months into this."
And just like that, the conversation shifts. Not toward the future — toward the past. Toward protecting what's already gone.
The Past Doesn't Have a Vote, But It Shows Up Anyway
The sunk cost fallacy is one of those concepts everyone nods at and almost no one actually escapes. The definition is simple enough: costs already incurred and unrecoverable shouldn't influence future decisions. Only expected future costs and benefits should drive the choice.
The reason it persists anyway is psychological, not logical. As behavioral design researcher Tom de Bruyne describes it, the fear of admitting a loss is so overwhelming it overrides rational thinking. Stopping a project makes the loss concrete and final. Continuing preserves the illusion that the loss can still be recovered. That feeling is powerful enough to override any spreadsheet.
Kahneman and Tversky's Prospect Theory gives us the mechanism: losses feel roughly twice as painful as equivalent gains feel good. When you kill a feature, you're not just making a product decision — you're forcing everyone in the room to feel that loss all at once, with no escape hatch.
So the meeting continues. The revised plan gets approved. The feature lives another quarter.
Why Product Decisions Are Especially Vulnerable
Every domain has its sunk cost traps, but product management has a few structural features that make it worse than most.
First, product work involves visible investment. The team has shipped iterations. There are user interviews, design files, sprint retrospectives. The work is legible in a way that makes abandonment feel like erasure rather than redirection.
Second, product managers are professionally rewarded for evangelism. As ProductPlan's co-founder Jim Semick notes, PMs are naturally passionate about their initiatives — motivating others around a vision is central to the role. That same quality that makes a PM effective at building momentum makes it psychologically harder to be the one who calls it.
Third, the accountability layer. De Bruyne points out that stopping a project raises uncomfortable questions about who approved it, who championed it, who let it run this long. Continuing is a way of deferring that reckoning. The sunk cost fallacy, in organizational settings, disguises itself as loyalty, perseverance, and responsibility.
AI product work has made this even sharper. SFAI Labs argues that AI projects fail the sunk cost test more reliably than any other category of software work right now — because progress signals arrive late, prompt and model investment feels like forward motion, and by the time outcome quality is measurable on a real evaluation set, the budget is half gone and the team has emotional ownership over the work. The trap closes before anyone sees it closing.
The Failure Case Is the Meeting You've Already Sat In
Here's where the mental model breaks down in practice: knowing about sunk cost fallacy doesn't protect you from it. The bias operates below the level of explicit reasoning. You can be fully aware that past investment is irrelevant and still find yourself arguing for continuation — just with better-sounding justifications.
I'd argue the real failure mode isn't ignorance of the concept. It's the organizational ritual that makes the fallacy invisible. When a steering committee meeting opens with a summary of what's been spent, the frame is already set. The question has become "how do we protect this investment?" rather than "what decision produces the best future outcome?" The sunk cost has been invited into the room as evidence.
The fix isn't a framework — it's a structural intervention. SFAI Labs' 30-day kill rule is one version: force a binary go/no-go decision before emotional ownership calcifies. The specific mechanism matters less than the underlying principle — decision reviews should be structured around forward-looking criteria set before the investment begins, not backward-looking summaries of what's already been spent.
If the criteria for killing a feature are defined when the feature is greenlit, "we've put eighteen months into this" stops being an argument. It becomes what it always was: a description of the past, not a reason to continue.
Try This: Before your next product review, write down the three conditions under which you would kill the feature being reviewed. Do it before the meeting, before you hear the status update. If you can't write them down — if the feature feels unkillable by definition — that's the signal worth paying attention to.