The IKEA Effect is a cognitive bias that sees people place a disproportionately high value on products that they have created. As you may have guessed, it’s named after the Swedish retailer famous for their self-assembly products.
The IKEA Effect was identified and named by professors at Harvard Business School, Yale and Duke in 2011 – however they conceded that product designers and marketers had been aware of the existence and impact of this bias for decades.
These professors conducted a series of experiments using IKEA furniture, origami and Lego to discover whether consumers would pay a higher price for products that required self-assembly. They found that test subjects were willing to pay 63% more for a completed piece of IKEA furniture that they had assembled themselves, compared with the pre-assembled components for that same piece of furniture.
Further experiments with Lego and origami produced similar results – that subjects placed a higher monetary value on items that they had fully or partially created.
The IKEA Effect finds that people are likely to attribute a higher value to items that they have laboured on. We’d expect to see similar results to the experiments mentioned above from teams working on software, products and processes – all of which involve time, effort and ideas.
While all stakeholders may not be involved in the actual ‘assembly’ of a product or piece of software, engaging them early in the process will increase the value they attribute to that project, effectively increasing engagement.
The agile approach provides a framework that supports this way of working. If you’d like to brush up on this, a good starting point is Elabor8’s Allen Strier’s blog post, Burger launch: project delivery and the agile shift.
The same principle rings true for development teams. In his blog post on feature factories, John Cutler mentions the “culture of handoffs” – where teams are essentially excluded from the development process and asked to produce items that are ‘ready for engineering’ (ready to be implemented).
While this approach may work in some cases, a development team without a clear product vision will find it challenging to operate. The vision creates alignment, provides direction and serves as a guide in times when decisions need to be made.
The Art of Agile Development by James Shore and Shane Warden mentions the importance of the product vision: “If the details are perfect but the vision is forgotten the software will probably fail.”
What to takeaway
A product vision created through problem exploration and experimentation that is clear, focused, and well understood will resonate more deeply across the team, increasing employee motivation and instilling a sense of ownership – compared with a set of requirements handed over during a 30 minute project kick-off meeting. In this scenario, the IKEA Effect can be used to engage stakeholders throughout, and create a stronger team culture.
Something to be mindful of when driving team engagement using the IKEA Effect is effort justification. Effort justification is the tendency to attribute greater value to an outcome that a person exerted effort on.
Using the furniture assembly scenario mentioned in the introduction, effort justification would see a person paying an exorbitant amount for a chair they have assembled, even though there are other chairs in the market that are more comfortable, nicer looking or sturdier.
This tendency to assign value based on the effort expended on an item goes some way to explaining why we often find it difficult to pivot and change directions on something we have already invested time and effort on.
For example, changing software when we discover that the program that we have implemented does not meet the requirements that we need it to.
An unchecked attachment due to effort justification can easily result in sunk-cost fallacy – when someone continues to invest in an unsuitable product, process or technology, failing to recognise that it was a poor investment and is unlikely to deliver the desired outcome.
What to takeaway
To manage the impact of effort justification, something I find effective with my teams is the use of spikes – short, time-boxed pieces of work to run investigations, research or even prototyping.
Treat spikes as a technical reconnaissance – an opportunity to evaluate whether to commit or to pivot, but not to justify already existing biases. A clearly defined goal and acceptance criteria will support objective decision making.
Used effectively, spikes can be learning opportunities for the entire team. I find it best to follow a spike with a team discussion to share and evaluate the outcome.
Like any cognitive bias, the key with the IKEA Effect is awareness – it can be either your friend or your foe. The aim of this blog was to give you some insights into magnifying its positive effects and dampening any negative impacts on teamwork.
Use it to your advantage and bring people on the journey by getting them to participate on the build. But be aware of the potential for poor decision making when you have people who are overly invested in and attached to what they have built.