i

Description

An IKEA store

Source

author not stated · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

The IKEA effect

What we build with our own hands seems better, and more valuable, than the same thing built by someone else.

In brief

• What: effort invested in a deliverable increases its perceived value, beyond its quality.
• Why: effort justifies attachment, provides a sense of competence, and we know we are the author of the outcome.
• Detect: defending in-house code, refusing to remove it, harsher judgment of others' work.
• Avoid: anonymous reviews, criteria set in advance, disposable prototypes, a third-party perspective.

On this page

1. Definition
2. The mechanism
3. Where you encounter it
   1. In project management
   2. In management
4. Famous cases
   1. “The IKEA effect: when labor leads to love” 2012
   2. The effort heuristic 2004
   3. Reassuring yourself by building 2012
5. Detection signals
6. Avoidance reflexes
7. With AI: detect, fix, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to incorporate into your practices
   5. How to integrate them
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

Fictitious illustration

The IKEA effect refers to the tendency to assign disproportionate value to objects we helped make ourselves, even in a modest way. The name comes from the flat-pack furniture brand; it was proposed by Michael Norton, Daniel Mochon, and Dan Ariely in a 2012 paper.

The effect does not depend on actual quality: an object assembled roughly is rated higher by its author than an identical object already made by someone else. It is close to The endowment effect (we value what we own), with one difference: here, value comes from effort invested.

The mechanism#

• Effort as a signal of value. We often judge a thing's quality by the work it required. Kruger and colleagues (2004) showed that the same poem or painting is rated higher when people think it required more effort: this is the effort heuristic.
• The sense of competence. Successfully building something strengthens self-image, and that pride carries over to the object. Mochon, Norton, and Ariely (2012) showed this: the sense of competence provided by building explains the added value; reinforcing self-image beforehand reduces the value assigned to one's own creation, while threatening it pushes people to build more themselves.
• An investment to protect. The more we gave, the more we hold on. This is the territory of Sunk costs: abandoning what we built means admitting effort was lost.
• One condition: seeing it through. In experiments, the effect disappears when the work is abandoned or destroyed: completion is what matters.

Where you encounter it#

In project management#

• Code review: the author defends their solution as if their person were being criticized; they judge others' code more harshly than their own.
• Redesigns and rewrites: refusing to remove a bulky in-house module, or conversely wanting to rewrite everything so “it's ours.”
• Architecture: an architecture designed by the team is judged suitable by the team, even when a standard approach would do better (see The “Not Invented Here” syndrome).
• Prototypes and mockups: a prototype that was supposed to be thrown away becomes the product's foundation because it cost weeks.
• Internal scripts and tools: the tool written over one weekend “as a quick fix” is defended for years against a better-maintained product.
• Documents: the author of a specification rereads their text leniently and no longer sees its ambiguities.

In management#

• Organization: a manager who designed a process or team structure defends it against clear evidence; their predecessor's reorganization would already be “due for review.”
• Evaluating one's own work: the plan, strategy, or dashboard you built is judged more favorably than someone else's.
• Participation and buy-in: conversely, the effect is useful. A decision built with the team is defended better by the team; but that buy-in can also blind people to its limits.
• Hiring: a manager who trained an employee may overestimate them, like their own handiwork.

Famous cases#

Detection signals#

• “It's our tool” or “it's my code” before any evaluation.
• A component is defended by the age of the investment rather than by its actual use.
• The solution's author is the only one calling it “simple” or “sufficient.”
• Code reviews reveal disproportionate defensive reactions.
• The disposable prototype has been in production for two years.
• Months or days of work are counted to justify value.

Avoidance reflexes#

1. Separate the work from the author. In review, talk about code, specification, decision—not the person. Anonymous reviews strengthen this separation.
2. Set criteria before evaluating. Performance, maintenance cost, readability, risks: rated with the same grid for the in-house solution and alternatives.
3. Have a third party evaluate it. Someone who did not take part in building gives a less colored opinion, which can then be compared with the author's.
4. State that a prototype is disposable—and dispose of it. Say it from the start, set its retirement date, do not evolve it into a product.
5. Ask the customer question. “If this tool already existed off the shelf, would we build it today?” If the answer is no, the IKEA effect is likely.
6. Measure value, not effort. Evaluate what the deliverable brings, not what it required.
7. Use the effect where appropriate. Involving the team in the decision improves buy-in; however, be careful not to confuse buy-in with correctness.

With AI: detect, fix, mitigate#

Prompts to incorporate into your practices#

1. No-nonsense reviewer. To evaluate work you produced yourself (without confidential data).

You are a demanding reviewer with no connection to the author. Evaluate the work below using these criteria: [list: clarity, robustness, maintenance cost, risks, fit to need].
For each criterion, give a rating from 1 to 5 and the specific evidence (passage, line, or argument) that justifies it.
Start with the most important weaknesses. Do not try to reassure, and do not rephrase strengths before finishing the weaknesses.

Work: [code, document, or description]

2. Start from scratch. When you're unsure whether to abandon or replace what you've built.

Here is what we built: [description], to address this need: [need].
If this did not exist today, what would you do to address this need, with currently available means and products? Compare with our solution while setting aside effort already invested (count it neither for nor against).
State under what conditions it would be reasonable to keep our solution, and under what conditions it should be replaced.

How to integrate them#

• Before a review: the author runs prompt 1 on their work, then reads the weaknesses before meeting colleagues.
• Before a redesign: prompt 2 provides a discussion baseline that does not depend on the solution's history.
• In a retrospective: examine whether attachment to a deliverable delayed a decision.

Precautions#

• Do not paste proprietary code, personal data, or confidential documents into an unauthorized tool.
• AI lacks your product's context and constraints: its critiques are leads, not a verdict.
• An assistant easily agrees with what you submit; if everything is “very good,” rewrite the prompt to require flaws.

Limits#

• The experiments focus on simple, low-value objects, with participants often being students and with modest stakes: extension to a multi-year software system is plausible, but has not been measured as such.
• The effect has benefits: pride in work well done, engagement, and buy-in for what has been built together all drive quality. The problem is not attachment, but the judgment that depends on it.
• It is sometimes confused with other effects (endowment, sunk costs, cognitive dissonance): in practice, several operate together, and they cannot always be separated.

Sources and verification#

• Norton, Mochon & Ariely (2012), “The IKEA effect: When labor leads to love”, Journal of Consumer Psychology, 22(3)
• Mochon, Norton & Ariely (2012), “Bolstering and restoring feelings of competence via the IKEA effect”, International Journal of Research in Marketing, 29(4).
• Kruger, Wirtz, Van Boven & Altermatt (2004), “The effort heuristic”, Journal of Experimental Social Psychology, 40(1).

See also#