Better Ship It Than Admit It

TL;DR: The sunk cost fallacy makes teams confuse what they already spent with what users need now. The work feels too expensive to stop, so something broken gets shipped just to make the effort feel justified.

You knew it should stop, and you kept going anyway. Not just because the roadmap said so. You kept going because too much had already been spent, and killing it felt worse than shipping something you did not trust.

That is the sunk cost trap. The time and effort are already gone, but they still hang over the next decision. Instead of asking what makes sense now, the team starts asking what might justify what it already spent.

Why teams keep protecting work they should cut

A sunk cost is money, time, or effort you cannot get back. The right decision is supposed to ignore it. Hal Arkes and Catherine Blumer showed how badly people fail at that. Once an investment has been made, people feel the pull to continue even when the evidence says stop. They called it “a tendency to continue an endeavor once an investment has been made.”

Richard Thaler helps explain why. Losses hurt. If you spent months on a feature, killing it feels like making that loss official. Shipping it feels like maybe you can still salvage something. The logic is bad. The pull is real.

The plan may already be gone. The deadline may already have moved. Teams still keep a bad thing alive because they cannot stand to look directly at what it already cost.

That is what makes sunk cost different from roadmap pressure. Nobody even has to be asking for the feature anymore. The work survives because the team itself cannot bear to write off the effort. The past keeps hanging over the decision.

Microsoft shipped Kin anyway

In 2010, Microsoft launched the Kin , a pair of phones aimed at younger users. The company had spent about two years and roughly $1 billion building the platform. Then it shipped a product that lasted 48 days.

What makes Kin useful here is not just that it failed. It is that the warnings were there before launch. In 2012, Wired published internal usability videos showing testers getting stuck on basic tasks and calling the phones frustrating and confusing. The problems were not subtle. Microsoft still shipped.

That is what sunk cost looks like in a product. Too much time. Too much money. Too much work already done. By that point, killing the thing would have meant admitting the loss plainly.

And once a team reaches that point, almost any patch starts sounding attractive. One more sprint. One more pass. One more layer of explanation around the broken part. Not because those moves solve the underlying issue. Because they delay the moment where someone has to say the original investment did not pay off.

What this looks like on product teams

Concorde is the famous version of this pattern. The plane was extraordinary engineering, but the economics had stopped making sense long before the project ended. Governments kept backing it anyway, partly because so much had already been spent that stopping felt like accepting the loss outright.

Kin is closer to the kind of call product teams make. The team had already built the thing. The tests were bad. People got stuck on basic tasks. The product was confusing in ways that were hard to miss.

Then someone says maybe we can patch it instead. Add labels. Add guidance. Add one more pass. Not because those things solve the problem. Because throwing the thing out feels worse than shipping a broken version of it. I have seen teams do this after months of work, after a big demo, after an internal launch date got announced. The feature survives because nobody wants to admit what it already cost.

That is the question here. Forget “did we promise this?” Forget “is it on the roadmap?” Ask this instead: are we still protecting the work because of what it already cost us? I have heard that logic show up as concern for consistency, brand, momentum, and team morale.

This is where teams start dressing up the same decision in polite language. They say the feature is close. They say users will learn it. They say launch will teach them more. Sometimes launch does teach you more. Sometimes the team already knows enough and the extra learning is just cover for refusing to cut the loss.

What to ask before you ship it anyway

Ask one question: if this landed on your desk today with no history attached, would you ship it?

That question strips out the part your brain keeps smuggling in. The hours. The demos. The stress. The calendar damage. None of that helps the user if the thing is still wrong.

Kahneman is useful here because he keeps pushing the same correction: step outside the story you are trapped in and look at the decision from somewhere colder. Past spend is real, but it still does not get to decide anything.

I like this question because it forces the history out of the room for a second. If the thing would not survive first contact today, the months behind it do not make it stronger. They only make it harder to kill. That is usually the moment when the room finally sees the feature as it is now instead of as it looked three months ago.

That is a management problem, not a user problem. Do not hand it to the user.