5 Common Unconscious Biases We See in Product Development

This is the fourth post in a series which is studying the unconscious biases found in product development seen when we are designing products, or software people use, or when trying to uncover precisely what’s wrong with our workplace today. The first in the series can be found here:  https://www.podojo.com/unconscious-bias-the-affinity-bias/

Sunk Cost

Since our previous post was about the Ikea effect, a cognitive bias which is thought to contribute to the Sunk Cost effect, this post we’ll be exploring what the sunk cost fallacy and sunk cost effect are all about.

Sunk Cost Fallacy: Why we care

If our decisions are tainted by the emotional investments we accumulate, then the more we invest in something, the harder it will be to let it go. It’s “throwing good money after bad”, and the logic makes perfect sense- until it gets personal. And of course, in the work that we do, the art of creating product, it is indeed personal.An example of how personal: Imagine you’re creating a product. It’s the last hurdle before the release date, the iterations finishing the final features which are your favorite, the hardest ones to create, the ones the whole team sweated bullets to create are finally done. You demo this, and lo and behold: the customer hates this release. Comparing to your previous demo without this feature set, the customer buzz was fabulous. Walking away from this is walking away from what you believe is your best work, walking away from have been dreaming about, it’s truly killing your darlings.

What is the Sunk Cost Fallacy and Sunk Cost Effect?

The Sunk Cost Fallacy describes a misconception that we make rational decisions based on the future value of objects, investments and experiences. The truth is that our decisions are tainted by the emotional investments we accumulate, and the more we invest in something the harder it becomes to abandon it. The Sunk Cost Effect is the tendency for humans to continue to invest in that which clearly isn't working. People will continue spending time, effort or money to try and fix what isn't working instead of cutting their losses and moving on.

Here’s an example:  A woman is given a ticket to an opera. She finds out that her neighbor has purchased tickets to the entire summer opera series so they decide to ride together. On concert day, the weather is pre-hurricane conditions. The woman who received the gift ticket decides to stay home. The neighbor, not wanting to waste the money spent on the opera series, decides to go.

Both women were faced with the same decision: Will the enjoyment of live opera exceed the discomfort experienced from the weather conditions? Yet, due to sunk cost fallacy, the neighbor who spent the money on season opera tickets is incapable of putting aside the past investment, despite the pre-hurricane weather conditions.

What you can do

Avoid the sunk cost trap Recognize that any investment you've made to date should not be taken into account in future decision making. Evaluate decisions based on future costs and benefits, and be open to realizing a loss, if necessary.

Once you’re in a potential sunk cost dilemma situation, you can’t prevent this. You can mitigate the risk however, thus reducing the impact.

Deliver incrementally

The sunk cost effect happens we costs are incurred before benefits are realized. To avoid this, invest in incremental wins to attempt to sink benefits at the same intervals as you’re sinking your costs.  What this means is don’t wait until the end of an entire release or project end before you reap your benefits. Deliver in increments to create value earlier. Spend the time to make your process and your code reusable.

Break your development into phases, earning your benefit at the end of each phase rather than the end of the entire project. Use agile development methodologies to create value earlier, allowing you to gain partial benefit if costs start to overrun. Switch to time-and-materials billing instead of project-based billing. Encourage your team to make their code and processes as reusable as possible.

Investigate your options

Here’s where you need to get creative: instead of a go/no-go alternative, brainstorm with your team for alternatives. Maybe instead of two options of go or no-go, you have more. Plan this upfront: are there additional “exits” options that can reduce your cost or risk that you could explore if you need to? If you do create multiple paths forward, calculate costs, risks and benefits for each path. This could be something as simple as offering a discounted price for an early release version allowing your team time to execute the pivot for where you really want to go.

Kill your darlings

Frankly speaking, know when to call it quits. If your risk is high or perhaps your costs are overrun, take the loss early while it is still small.