The Low-Code IKEA Effect
I linked a few days ago to Packy McCormick’s piece Excel Never Dies, which went deep on Microsoft Excel, the springboard for a thousand internet businesses over the last 30 years. “Low-code” techniques in software have become ubiquitous at this point, and Excel was the proto-low-code environment — one of the first that stepped toward empowering regular people to create their own software. In the mid-80s, if you wanted to make your own software tools, you were in C, BASIC, or Pascal. Excel and its siblings (Lotus 1-2-3, VisiCalc) gave users a visual workspace, an abstraction layer lending power without the need to learn languages.
Today in the low-code ecosystem you have hundreds of products for all sorts of use cases leaning on similar building principles — Bubble and Webflow for websites, Make.com and Zapier for integrations, Notion and Coda for team collaboration, even Figma for designs. The strategy goes hand-in-hand with product-led growth: start with simple use cases, be inviting to new users, and gradually empower them to build their own products.
Excel has benefited from this model since the 80s: give people some building blocks, a canvas, and some guardrails and let them go build. Start out with simple formulas, create multiple sheets, cross-link data, and eventually learn enough to build your own complete custom programs.
What is it about low-code that makes such effective software businesses? Sure, there’s the flexibility it affords to unforeseen use cases, and the adaptability to apply a tool to a thousand different jobs. But there’s psychology at play here that makes it particularly compelling for many types of software.
There’s a cognitive phenomenon called the “IKEA effect”, which says:
Consumers are likely to place a disproportionately high value on products they partially created
IKEA is famous for its modular furniture, which customers take home and partially assemble themselves. In a 2011 paper, Michael Norton, Daniel Mochon, and Dan Ariely identified this effect, studying how consumers valued products that they personally took part in creating, from IKEA furniture, to origami figures, to LEGO sets. Other studies of effort justification go way back to the 1950s, so it’s a principle that’s been understood, even if only implicitly, by product creators for decades.
Low-code tools harness this effect, too. Customers are very willing to participate in the creation process if they get something in return. In the case of IKEA it’s more portable, affordable furniture products. In low-code software it’s a solution tailored to their personal, specific business need. Paradoxically, the additional effort a customer puts into a product through self-service, assembly, or customization generates a greater perception of value than consumer being handed an assembled, completed product.
SaaS companies should embrace this idea. Letting the customer take over for the “last mile” creates wins all around for everyone. Mutual benefits accrue to both creator and consumer:
- Customers have a sense of ownership when they play a role in building their own solution.
- The result can be personalized. In business environments, companies want to differentiate themselves from competitors. They don’t want commodities that any other player can simply buy and install. Certainly not for their unique business practices.
- Production costs are reduced. The product creator builds the toolbox (or parts list, instructions, and tool kit) and lets the consumer take it from there. Don’t have to spend time understanding the nuances of hundreds of different use cases. You provide building blocks and let recombination generate thousands of unique solutions.
- Increased retention! Studies showed that consumers consistently rated products they helped assemble higher in value than already-assembled ones. This valuation bias manifests in retention dynamics for your product: if customers are committed enough and build their own solution, they’ll more likely imbue it with greater value.
The challenge for product creators is to strike a balance — a “just-right” level of customer participation. Too much abstraction in your product, requiring too much building of primitives, and the customer is confused and unlikely to have the patience to work through it. Likewise, when you buy an IKEA table, you don’t want to be sanding, painting, or drilling, but snapping, locking, and bolting are fine. Success is a key criteria to get the positive upside. From the Wikipedia page:
To be sure, “labor leads to love only when labor results in successful completion of tasks; when participants built and then destroyed their creations, or failed to complete them, the IKEA effect dissipated.” The researchers also concluded “that labor increases valuation for both ‘do-it-yourselfers’ and novices.”
Participation in the process creates a feedback loop: the tool adapts to the unique circumstances of the consumer, functions as a built-in reward, and the consumer learns more about their workflow in the process.
Low-code as a software strategy allows for a personalization on-ramp. Its IKEA effect gives customers the power to participate in building their own solution, tailoring it to their specific tastes along the way.