The IKEA Effect and its Friends : Nemeses of a Product Manager
In 2001, I was working on developing a software licensing system that managed distributed license keys for any software using server based floating licensing mechanism. Yes, Remember the old days of client server architecture and buying software was still not so common as it was expensive. Nostalgia aside, I was a software engineer coding in Java who believed that the system was working fine and my piece of code was working as expected. So, I sent the code for review to my manager ( whom I “later on” started respecting a lot for his programming and analytical skills) who just took a brief look at the code and rejected the whole component within 30 minutes. It was my 20 days of effort that he didn’t care about. Of these 20 days, I had spent last two days continuously working in office with almost no sleep and surviving on pizza, coke and coffee.
I asked him the reasons and he explained that my basic assumption on one of the encryption mechanism was wrong and that I needed to rewrite the whole component. I went back and started working again. Just that, this time I tried to fix it by repurposing the code with a supposedly correct assumption. After a few days, my manager again rejected the code and explained me another issue I wasn’t able to see through. By the third time, I had lost my patience and I argued with my manager thinking that he doesn’t know what he is talking about.
The IKEA Effect
Have you ever faced a situation when you worked very hard on a product or a feature spending weeks and months and then, someone on your team started asking the basis of your fundamental assumptions ?
Most probably, yes. That happens with most of us. But the fun part is when the questions continue and you fail to understand why the team member is asking so many questions. It seems to you that the team member is either being stupid or doesn’t like you or the product you are working on. This is where the “IKEA effect” is taking place.
Prof. Dan Ariely described the “IKEA effect” in his 2011 paper that he published along with Prof. Michael Norton and Prof. Daniel Mochon as “labor alone can be sufficient to induce greater liking for the fruits of one’s labor: even constructing a standardized bureau, an arduous, solitary task, can lead people to overvalue their (often poorly constructed) creations.”
As a product manager, we spend so much effort in building the product requirements and work on achieving the product market fit trying to reduce failure as much as possible. But as we do that, we keep on moving on an iterative path where our effort ( measured as sunk cost) is getting bigger as the days go by. With the sunk cost getting higher, we get into a defensive justification mode whenever some one asks us a seemingly harmless or basic question. This is for a simple reason that we start over valuing the effort we have put in such that we dread to change the path ( if required) as it may lead to delayed timelines or pseudo loss of reputation or supposedly , may get us bad performance rating ( if that ever happens).
The Endowment Effect, Loss Aversion and Status Quo
 |
|---|
Now, as we invest more time and effort, our sunk cost is getting higher making us attached emotionally to the product we are working on. That leads us to another problem called “endowment effect”.
Prof. Daniel Kahnemann, along with Prof. Jack Knetsch and Prof. Richard Thaler explained the endowment effect in his 1991 paper describing it as people tend to value the items they own more highly than they would if those items did not belong to them. If you have invested your time and effort heavily on the product that you are working on, as a product manager, it is natural human tendency to develop an affinity towards the product. Sometimes, it becomes so difficult to separate your own identity from the product. Identify the scenarios when some product managers start calling a product as their baby because they conceptualised the idea and have worked on it day and night.
Both “IKEA Effect” and “Endowment Effect” stem from a basic cognitive bias called “Loss Aversion”. Loss Aversion is described as the fear of loss is greater than the joy of gain.
Assume that the product you are working on is moving very smoothly and is on target for release. While, everything is going good, a colleague on another team ask you some questions about the way feature works and she suggests a change which will result in a change of direction for your product but at the same time, may result in 50% gain in estimated revenue. but the impact of making that change is delay in project release by 6 months.
While we all believe that we think rationally as we are rational people, most of the product managers will still fear the loss and hence, try to avoid the loss by continuing on the path as the fear of losing 6 months can be considered greater than 50% gain in estimated revenue. if the company work culture allows for taking a short term hit in favour of long term benefit, the product manager needs to change the direction but that may result in heartburns in the various teams and significant stakeholder management. So, a risk averse product manager may rationalise the decision of sticking to the course and not change direction, citing Sunk Cost, indirectly justifying the decision and maintaining the status quo.
When this status quo is maintained and the questions get postponed so as to find the answers at later stage, this results in inability of finding the product market fit for many products and then, products pivot at a late stage leading to losses mounting to millions of dollars in so many cases.
Whether it is “IKEA Effect”, “Endowment Effect”, “Loss Aversion” or “Status Quo Bias”, it doesn’t matter if you don’t remember these terms. What matters most is the way these unconscious biases can be avoided by training your subconscious mind to look out for the symptoms. The way you train your mind is by following a simple common sense technique called “First Principle Thinking”.
First Principle Thinking
 |
|---|
“First Principle Thinking” helps you to ask the very fundamentals questions that form the premise of the problem you are trying to solve. Whether it is “Socratic Questioning” method or “5 Whys” of the famous author Simon Sinek, or a child like inquisitive method of asking questions, just go down to base of the problem and why you are really interested in solving the problem. Identify the win-win formula for everyone and do not stop asking the “Why” until you are convinced that there is no further doubt or question that can arise. if a question arises somewhere along the path even after you started, go back to the drawing board for course correction and cut your losses early. This is where when someone said “Fail Fast & Fail Often”.
Long story short: watch out for the feedback signals you receive, even a faintest signal can help you fix the problems early on and recognise the gaps in your plan.
By the way, I did go back to my manager who rejected my code multiple times after a few weeks to understand his explanation once again and that’s when, before explaining the software design, the first thing he taught me was the concept of “loss aversion” and a varied form of “first principle thinking”. That helped me see beyond the personal biases and also, learnt for the first time about something called “cognitive biases”.