Everyone that has attended some of my recent sessions knows that I have used IKEA as an example in a few occasions. There are genuinely many exciting things about IKEA’s business model and organisation. However, today’s topic is not directly attributable to IKEA but only named after it.
So, What is the IKEA Effect? As Wikipedia describes it, The IKEA Effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. In other words, we humans tend to over-value the fruit of our labour.
This effect has been know to marketers for many years, but it wasn’t formalised until 2011, when a group of researchers, including famous behavioural economist Dan Ariely, published the results of their studies focusing on how labour can induce greater liking for the fruits of our work. Participants in these studies associated a disproportional amount of value to their self-assembled flat pack furniture. When asked to bid on furniture, they were willing to pay 63% more for their self-assembled one versus pre-assembled. This effect is quite interesting as it applies not just to creative work, but also prescriptive and straightforward labour without room for customisation also presents this effect.
This effect has been put to work in many products, from easy-cooking packaged recipes to software products that help you to get started with simple tasks and sample data. However, the effect completely breaks down if there is not completion of the job. In other words, we need to feel we have accomplished something; otherwise, the IKEA effect disappears.
By now, you have probably realised that this cognitive bias can be useful in the Business Applications world. In my personal experience, there are two crucial areas where this effect can have a profound impact and help us deliver successful projects.
The first one is related to ownership and the transfer of knowledge to internal teams as we embark on new Dynamics 365 deployments. I believe that we can ensure the long-term success of new technology in an organisation by involving, from the very beginning, internal technology teams and users and giving them ownership of the solution. For example, seconding an internal team of IT and business users to work on the implementation of a business application alongside external vendors can trigger the IKEA effect, and make them value more the solution. This value, in turn, can help with the broader adoption across the organisation as now we have peers advocating for the new solution. Likewise, if the internal IT teams are involved from the start and take ownership of the platform, they are more likely to continue to find ways on how this new technology can solve additional business challenges, helping the organisation to maximise the value of the investment and avoid stagnation.
The second aspect is directly related to the Power Platform. There is much discussion – and some controversy – over the concept of the Citizen Developer. However, looking at the IKEA effect it could be easy to infer that users will place a disproportionally higher value on their self-created PowerBI Reports and Power Apps against anything that we can provide as an IT team. Thus, these ‘self-service’ tools can deliver a profound impact on the ROI of our technology investments.
In summary, I believe that looking for smart ways to include users in the building process of our Business Applications can unleash the IKEA effect and increase the perceived value and adoption of our solutions. With the Power Platform and the low-code and declarative tools we have, we should be able to figure out ways on which users can participate in the build process and increase their perceived value of the solution. However, we also need to be careful as this effect is a double-edged sword and it can contribute to the Sunk Cost effect – where we continue to waste money and resources on failing projects – and the Not Invented Here syndrome – where we disregard good ideas developed elsewhere.
I have seen the result of the IKEA Effect manifesting in some clients where internal teams have taken ownership of the platform after the initial implementation, and continue to invest on it and deploy it to solve new business challenges beyond the original scope. What is your experience? Have you seen this effect before?