First What, Then How – How to Not Give In to the Sunk Cost Fallacy

One of the hardest decisions a leader has to make when building a product is to evaluate all of the options of how it should be built and make the best choice. It is still more difficult when there is a legacy product or significant time and money has been invested to date and you’re faced with potentially starting over.

I was recently talking with a CEO who had close to three years invested in a particular application that had served an older customer base quite well, but was not sufficient to take to market as the next-generation version of the application. The struggle to hang on to the investment already made was making it difficult for the product team to design the next version without those constraints.

I recommended that he think of the decision in two distinct parts: First What, Then How. It immediately clarified the path forward and we were able to move on.

First What

Deciding what product you need to build is a function of talking to customers, looking at the market, and identifying a gap to be filled that you’re uniquely qualified to fill. It has nothing to do with assessing what’s already been built and understanding how it might fit. Easily said, but very very hard to do, particularly when you see all of the money and time invested in a previous version or different product.

The problem with bringing previous work into the picture is that you’re constantly trying to fit the next decision into the last one, and they may not be at all related. In economic lingo, this is called the Sunk Cost Fallacy or Escalation of Commitment, and the cost can be extremely high.

Instead, when you are making those critical early decisions about your product, focus on the “what” and let the how go out of your mind for the moment. It doesn’t mean that you operate without constraints in this first phase, however. All of the rules of building only what is required to prove product-market fit still apply.

Then How

Once you’ve done the work with your prospects, built a prototype or maybe just some wireframes and you’ve settled on what needs to be built, it’s appropriate to start thinking about the “how.” Here’s where you get to look at the current assets of the company and see how they apply to the new product you’re thinking about.

Work side by side with your development team to understand the ramifications of each scenario:

• What does it mean if we start over from scratch?
• What can we salvage?
• Do we have the skills on our current team if we need to use different tech?

Developers, as a general rule, love to start over from scratch. I always loved the opportunity to wipe the slate clean. There’s something about getting a “do-over” that very satisfying because you get the chance to clean up all the bad decisions you made the last time. However, if the company has invested heavily, there’s a fiduciary responsibility to take stock of what’s been done and make the most use of it possible. Your role is to push back (skillfully and tactfully) on each recommendation and understand exactly why that’s the path being proposed.

Your ability to synthesize what you’re hearing from the development team with the needs / reality of the business is what makes or breaks this process. Getting defensive or irrational will make everyone retrench and get their necks up about their position.

Just Remember

• The decision about what product you build should be based on serving the customer needs first. If you get this wrong, nothing else matters.
• Once you’re clear on what needs to be built, then evaluate the current assets of the company (previous products, other prototypes) and use as much prior work as possible.
• Never let the fact that you’ve invested in one direction already affect the next best decision. Those dollars and minutes are spent, regardless of how you move forward.

Your Assignment

As you’re making product decisions over the next few weeks and months, pay attention to your level of commitment bias. How much of the path you’re choosing is based on the path you’ve chosen in the past? Take notes during product meetings with your team about how much of the discussion centers around what’s already been built rather than what’s the right next decision.

Discuss the concepts of Escalation of Commitment and Sunk Cost Fallacy with your team, and agree to hold each other accountable as you move forward.

First What, Then How.

Did you find this article useful? Please share it with someone else today who you know could benefit from what you’ve learned.