Letting go of bad ideas
The sunken ship fallacy
Yesterday, I spent hours crafting a blog post before, eventually, deleting it.
I decided to write about diversity & inclusion, following a conversation with Meesh Pallo, the People and Culture Manager at Made Tech. During the conversation, I suggested a “gentle warm-up exercise” as an opener for the D&I session Meesh was writing. Meesh kindly asked whether I was recommending a “gentle” introduction because I prioritised the comfort of the attendees over the delivery of the message. It pulled me up short and gave me something to contemplate all week.
It drove me to spend time further educating myself about D&I. It formed the idea of a blog post summarising the things I had learnt and highlighting the mistakes I have made and retrospectively identified.
However, after finishing the first draft, I read it back and realised that the content centred too much around me and my education journey and not enough on the issues at hand. The more I tried to rewrite and restructure the article, the worse it seemed to get, and yet the less inclined I became to abandon the idea.
It took several more rewrites before I eventually admitted defeat and deleted the post.
Sunken cost fallacy
This experience is a prime example of the sunken cost fallacy at work. The more time I had put into the post, the more reluctant I was to delete it.
“The sunk cost effect is the general tendency for people to continue an endeavour, or continue consuming or pursuing an option if they’ve invested time or money or some resource in it. That effect becomes a fallacy if it’s pushing you to do things that are making you unhappy or worse off.”
Christopher Olivola, Psychological Science
The cost in question may be financial, but it might also be energy, time, pain or any other resource. The more you invest in something, the harder it is to abandon it.
The sunken cost fallacy often occurs in product development. It becomes difficult to separate yourself enough to realise you overinvested in the wrong solution or are trying to solve a problem that doesn’t exist. One of the Agile manifesto principals states that you should “maximise the work not done”. It sounds simple in theory but is hard to put into practice.
I’ve written my suggestions for avoiding this cognitive bias below, but welcome any other ideas in the comments!
Focus on value
The simplest way to avoid getting drawn into developing a bad idea is to spend time upfront considering the value it will bring. The end-users define the value of a product. The readers of a blog post determine it’s usefulness!
Anything that doesn’t contribute a reason for a user to purchase, use or read the thing you are creating is what Lean would determine waste.
Understanding what will bring value to other people can only be determined by speaking to them. A fundamental way to build something of value is to identify a users’ problem or need and find a way to address it.
I have worked with several teams who have struggled to let go of ideas, so I assumed that a blog post addressing this will provide helpful content to those who read it.
Prototype for early feedback
For this second version of the blog post, I tested this assumption by asking friends in my target audience (professionals who work in digital and read blogs) their opinion on the concept.
I explained I hadn’t written anything yet, and it was just an idea, so there was no need for them to sugarcoat their responses. By asking for feedback upfront, I prevented wasting time writing a blog post that no one would read.
As the feedback was positive, I then quickly listed the sections in bullet points and shared those for review. I made some amendments based on suggestions and then proceeded to write the content, before sharing again for feedback.
When building a product or service, user testing with prototypes of increasing fidelity is often essential. A low fidelity paper prototype or a sketch may encourage a user to give honest feedback about a concept without being distracted by the detail. It is necessary to use higher fidelity prototypes when you are concerned with testing the content or UI, so moving from low to high fidelity via short feedback loops of learn-test-adapt is often the best solution.
Get unbiased opinions
Another way to reduce the impact of bias on your product or service is to have someone perform user research who is not personally invested.
A good user researcher will try to identify their own cognitive biases and design user research to avoid these, but it’s not always easy to recognise. Having a user researcher excluded from prototyping an idea can help prevent them from becoming invested in its success.
It would have been hard for me to get unbiased opinions if I had shared the finished version of the an article. I suspect people would have told me what they thought I wanted to hear for fear of hurting my feelings. They would likely have known that I would have been disappointed by negative responses despite me saying I wanted honest feedback.
Use timeboxing
Timeboxing can be a great tool to minimise the time you spend on something, forcing you to decide how much you want to invest in an activity. In agile, timeboxing adds constraints to something otherwise open-ended, encouraging a review of progress at a pre-agreed time.
Timeboxing also encourages you to start getting work done immediately. Temporal Motivation Theory shows that time constraints are a critical component of efficiency. In Scrum, the sooner you can inspect a deliverable, the sooner you can adapt it.
Adding a constraint to something is a great way to avoid the sunken cost fallacy because you regularly inspect the thing you are creating to ensure it is still worth proceeding with. It is also a helpful way to prevent overpolishing and timewasting. I used a 5-minute timebox for each section in this blog post, and I found it very effective as a motivation to stop thinking and start writing. It also means I’ve limited the time writing, so I will be much more comfortable throwing the post away if necessary.
Recognise bad ideas
When you have an idea, your natural egocentric biases mean that you are predisposed to believe it is good. One of the purposes of cross-functional teams and extreme programming activities such as pair and mob programming is building upon multiple people’s ideas and knowledge.
Another benefit of collaborative working is that you decouple the value of an idea from your self-worth. This separation can help protect you from being too attached to a bad idea because you are insulated from the emotional fall out by the shared responsibility.
Being able to recognise someone else’s idea as a bad one is also essential. Too often, the HIPPO effect leads to the highest paid person making all product development decisions.
Don’t rely on gut instinct alone
If there is a small voice in your head telling you that your idea, or someone else’s idea, isn’t a good one, then it may be worth examining those concerns. Don’t push down that niggling doubt because you want the solution to be successful or because the person who suggested it is more senior than you. Instead, treat these thoughts as a signal that you may need to validate the idea before spending additional resources on it.
With the original blog post I started, I ignored my intuition and let blind optimism convince me the blog post would work out. With hindsight, I wish I had used that internal voice as a call to prove the idea by speaking to people or doing further reading about the subject.
When it comes to deciding what to prioritise or build for a product, no gut instinct should be relied upon. A gut instinct may offer a direction to investigate, but user research and data are needed to prioritise product requirements. Our past experiences are not enough to inform the future.
Reflect and learn
When you have decided to stop investing in something, it can be helpful to reflect on what led to that decision. Were there opportunities to test the idea earlier? Can you improve the mechanism you use for generating possible solutions (or blog content options)? Do you need to spend time addressing your value statement to make it simpler to prioritise based on your goals?
It is always worthwhile asking for feedback and inviting other peoples’ perspectives to identify ways to adapt and grow that may otherwise have remained as blindspots.
As ever, I would appreciate feedback on this post as I try and improve my writing.
