Sunk Cost

Every product team is carrying something it would not start today: a feature nobody opens, a redesign that outlived its evidence, a study that answered the wrong question by week two. What keeps those alive is rarely the case for their future and usually the size of their past. The money and months already spent are the same whatever the team decides next, which is the whole of the sunk cost idea and one of the hardest things in product work to act on. Knowing the term is the first step; building decisions that ignore the past on purpose is the second.

What is a sunk cost?

A sunk cost is money, time, or effort that has already been spent and cannot be recovered whatever happens next. The term comes from economics, where the rule is blunt: because a sunk cost is the same under every option still available, it has no bearing on which option is best, and a rational decision weighs only the costs and benefits still to come. The money spent building a feature is sunk the moment it is spent; whether to keep the feature depends on what it will cost and return from here.

In product work the sunk costs are rarely in cash: they are the quarters of engineering time, the research already run, and the public commitments already made. A cost is sunk when no decision can bring it back, and that is the only test: it does not matter how large it was or how recently it was paid.

What is the sunk cost fallacy?

The sunk cost fallacy is the tendency to continue with something because of what has already been invested in it, when the evidence about the future says to stop. Hal Arkes and Catherine Blumer documented it in 1985 with an experiment in which theater subscribers who had paid full price for season tickets attended more performances than those given the same tickets at a discount: the tickets were identical, and the only difference was how much had been sunk. Evolutionary biologists had named the same pattern the Concorde fallacy a decade earlier, after the airliner that Britain and France kept funding long after it was clear it would never pay back.

Several ordinary motives feed it. Stopping makes a loss final, and people weigh losses more heavily than equivalent gains. Abandoning a project admits that the original decision was wrong, which is uncomfortable in public. Waste feels bad in itself. The fallacy is not a failure of arithmetic but of accounting: the past cost gets booked against the future decision, where it does not belong.

How does sunk cost bias show up in product teams?

Picture a feature that took two quarters to build and that usage data show almost nobody opens. The arguments for keeping it are rarely about its future: it was expensive, the team is proud of it, and removing it would mean admitting the plan was wrong. Those are sunk costs talking. The forward-looking question is what the feature costs to maintain, test, and explain, against what it returns, and by that test a large share of any mature product's surface area would not be built today.

The same pattern appears above the feature level. A product roadmap protects a past bet because reversing it would discredit the planning that produced it. A redesign continues past the point where its own usability sessions turned negative, because so much has been invested in the new direction. Feature creep is partly the residue of such decisions. Each is a decision made on behalf of the past instead of the future, and each looks reasonable from inside because the invested effort is vivid and the alternative is abstract.

How does sunk cost appear in user behavior?

Users carry the same bias into products. Someone stays with an app because of the years of data, playlists, or contacts inside it, even when a better tool exists; the accumulated investment is sunk, but it feels like a reason to stay. A person three pages into a long form is reluctant to abandon it even after realizing it asks for more than they want to give. A half-finished setup gets finished because the first half is done.

That raises a question about which uses are fair. Showing how far a person has come, as a progress bar in onboarding does, is honest information that helps them decide. A cancellation flow built so that quitting feels like throwing everything away exploits the bias against the person's own interest. A pattern that gives the user better information about the future is design, and a pattern that inflates the weight of their past is manipulation.

How does a sunk cost differ from an opportunity cost?

The two are the costs on either side of a decision. A sunk cost is behind it: spent, unrecoverable, and irrelevant to the choice. An opportunity cost is ahead of it: the value of the best alternative that choosing this option gives up. The money already spent on a redesign is sunk; the features the team will not build while it finishes the redesign are the opportunity cost of continuing.

The distinction matters because the sunk cost fallacy usually hides an opportunity cost. A team that keeps a failing project because of what it has invested is spending the next quarter's capacity on it instead of on something else, and that capacity is the real price. The Navigating Trade-offs and Dependencies lesson works through how opportunity costs are made visible during prioritization. A decision is sound when it compares only forward costs with forward value, and opportunity cost is the forward cost people most often forget to count.

How do designers and product managers use the sunk cost concept?

Mostly as a question asked at the right moment. The cleanest form is counterfactual: if this project did not exist and the team knew what it knows now, would it start it today? If the answer is no, the only remaining argument for continuing is the sunk cost. Teams that use the idea well set the question up in advance, since a stopping rule is easier to agree on before anything is invested. Kill criteria name, at the start, the signal that would end a project and the date to check it. A pre-mortem, which Gary Klein described in 2007, asks the team to imagine the project has failed and explain why before it begins, surfacing the risks that later investment will make hard to admit.

In design work the concept shapes how options are framed. A review that lists the cost to finish and the expected value of each direction, without the cost already spent, strips the past out of the comparison. Product discovery done in small, cheap steps keeps the sunk cost at any decision point low, so there is less to defend. The Mental Models for Decision Making lesson treats the sunk cost trap as one of a handful of models a product manager should recognize on sight. The concept earns its place when it is applied early, as a rule for future decisions, rather than late, as a diagnosis.

What does the sunk cost fallacy look like in practice?

Research shows the bias in its purest form, because a study has a visible budget: recruited participants, scheduled sessions, a protocol someone spent weeks on. When the first sessions show the research question was wrong, the pressure to run the remaining sessions anyway comes from that investment alone. The sessions will produce data; the data will not answer the question that matters. The honest move is to treat the early sessions as the finding, redirect the study, and count the weeks already spent as the price of learning that, not as a reason to spend more.

When is continuing not a sunk cost fallacy?

Not every decision to carry on is a mistake, and the concept is misused when it becomes a reflex for cancellation. The test is forward-looking in both directions: if the remaining cost to finish is small and the expected value is real, finishing is the right call, and the amount spent getting here is as irrelevant as ever. A project 90 percent built with a clear path to launch is often worth completing even if, with hindsight, it should never have started.

There are also costs of stopping that are not sunk because they lie in the future: contractual penalties, a customer commitment that has to be honored, the credibility lost by reversing a public plan. Those belong in the comparison, as long as they are counted as future costs and not dressed up as respect for past effort. And some continuation is a deliberate bet under uncertainty, where the early evidence is thin and the cost of a little more UX research is low. The fallacy is specifically the past weighing on the decision; a forward case for continuing, honestly made, is not one.