Beware the Sunk Cost Trap

“I’ve invested too much to quit now.” 

This phrase is commonly heard in investing, gambling, and pretty much any activity that requires investment before one sees an unguaranteed return, including product development. 

However, the rationale behind such thinking is flawed. When the return is no longer relevant or clearly unachievable, the cost you’ve incurred should not be factored into the current decision. 

Yet, most people have trouble calling it quits, as they want to avoid wasting their prior investment — resulting in even bigger losses. 

This irrationality is called the Sunk Cost Fallacy, and it’s one of the deadliest traps in product management.

How can the sunk cost fallacy hurt a product?

Here’s a common misconception among product teams:

“If we’ve started building a feature, we should finish it. If we’ve launched it, we should keep it. It can’t hurt, anyway. Otherwise, our effort will be a waste.”

First of all, shipping the wrong feature CAN have a net negative impact on your product through feature cannibalization or increased complexity. This is why unshipping is sometimes beneficial. 

But even if that isn’t the case, what you should always be thinking about is opportunity cost. In other words, what could you have done with your time instead? Product teams that prioritize high-impact work will always beat teams that don’t.

Another way the sunk cost fallacy can hurt a product is by misguiding teammates with “false wins.” When team members keep building new ideas on top of initiatives that should’ve been killed, your product will eventually collapse. 

Why does the sunk cost fallacy happen?

In the context of product management, the sunk cost fallacy usually occurs for a combination of reasons:

  1. No success criteria Most product teams don’t have a proper framework for evaluating feature success. Even when they think they do, the criteria are often arbitrary. When there is no clear indicator of whether a feature has succeeded or failed, the default action is to continue on the same course.
  2. Protecting self-esteem Nobody likes to see their effort turning to dust. It can be a huge blow to their self-esteem. That’s why once someone has committed to a project, they tend to cherry-pick only the positive signals to justify its continuation. 
  3. Not knowing how to validate ideas early The more you have invested, the harder it is to quit. Many product teams say they follow the Lean Startup approach of validating ideas early via MVPs. However, 9 times out of 10, the MVPs they’ve built are far from “minimal”.
  4. “Sacred Cow” ideas When a product team is assigned a solution to execute rather than a problem to solve, they might assume that upper management has gone through intensive planning, which makes the idea too valuable to give up. Besides, they don’t really have a choice to change direction anyway.

How can product teams combat the sunk cost fallacy?

Pre-mortem & Post-mortem

Get into the habit of evaluating features objectively by implementing pre-mortem and post-mortem meetings.

A pre-mortem asks the team to define what success for a particular feature will look like, why it might fail, and what to do in each scenario before the development even begins.

As a rule of thumb, your success metric should reflect why you build that feature in the first place. For example, if you believe a feature is a must-have for your enterprise users, then the success metric should be something like “70% adoption rate among companies with 1000 employees”.

A post-mortem is where the team evaluates how this feature actually performed, why it failed or succeeded, and what to do next. Because you’ve laid out the criteria beforehand, it’ll be a lot harder to cherry-pick the result.

It is important to give the feature time to show its effect. If you call a post-mortem meeting immediately after launch, all you can talk about is the development process (output) and not the impact (outcome).

Expand idea validation methods

Challenge your team to validate ideas as early as possible, ideally without writing a line of code. For example:

  • Smoke test — create a fake CTA or landing page to assess user interest.
  • Wizard of Oz test — manually operate a high-fidelity prototype to verify design usability.
  • Concierge MVP — offer a human-operated service to gather user feedback.

Although these methods don’t offer the same level of validation as a real feature, they let you gather useful insights for a fraction of the cost. The less you have put in, the easier it is to change direction. 

You can’t expect your team to master a wide array of idea validation methods overnight, so be sure to dedicate time toward training in parallel. 

Foster a good product culture

Giving up feels terrible, even if it’s indeed the right decision. The only way to mitigate this damage to team morale is to foster a good product culture.

Make sure your team understands that product management is about creating value, not shipping features. Instead of viewing an unsuccessful feature as time lost, view it as valuable learning (and not in a “pity” way). 

Over time, whenever people have to kill an initiative, they’ll begin to think, ‘Hey, it’s good that we found out what doesn’t work. We can now divert our resources to trying something else!’

Of course, building a culture is hard. If you are a product leader, it is your responsibility to promote the right mindset through mentorship and processes. Most importantly, you must lead by example and not fall into the sunk cost trap yourself.

But here is the tricky part…

It’s not always easy to determine whether a feature didn’t work because it was a bad idea or because you didn’t invest enough. In the second scenario, giving up too early will, in fact, throw your valuable work down the drain. 

Although there isn’t a hard-and-fast rule, here are two factors you can consider to determine which is the case.

  1. Expected rate of return — Not every initiative will generate returns at the same rate. For example, it might take only a month to see the impact of an onboarding flow revamp, but it will take years for a new developer platform to gain traction. 
  2. Degree of the shortfall — How far is the result from your definition of success? Was the bar set too high? Are there any signals that validate your hypothesis? 

In many situations, a correct answer does not exist. 

Sometimes you win by cutting losses ruthlessly. Other times, you win by persevering in a vision despite not seeing early results. The point is to be aware of this fallacy so that you can make the most deliberate decision in each unique context.

Share this post
Share on twitter
Share on linkedin
Share on email

Hi, I’m Austin!

I love exploring new ways of building and growing products. If this sounds like your cup of tea, feel free to follow me or subscribe.

Hi, I’m Austin!

I write about product management, SaaS, growth, plus anything that comes to mind during hot showers.