Effort Moat

Honour what people have built, so their progress remains useful and recognisable.

What it is

Effort Moat is the honouring half of a two-part idea: once a user has put something into the product—saved work, a tailored setup, a history, a collection—Effort Moat is what makes that contribution visible, reusable, and worth having made. Its companion, Investment, is the asking half: eliciting the contribution in the first place. The two are easy to blur because they sit on either side of the same relationship, but a change that only asks for more setup without ever paying it back is Investment without its other half, and it reads to the user as busywork rather than progress.

A code editor that remembers your custom keybindings, your open tabs, and your recent files across sessions is running Effort Moat correctly—the effort of configuring it once keeps paying rent every time you open it. A form that asks you to re-enter preferences you already gave it is failing at the same job.

Why it works

The underlying mechanism is the IKEA effect described in Investment and Continuity: people value things more, and more durably, when they built them themselves and the result actually works. That valuation is what makes a product feel like “my workspace” instead of “a tool”—but per that concept, the feeling is earned only when effort visibly returns as utility. Reflect the saved work, restore it on return, and the attachment is real; let it disappear or lock it away, and the same effort that should have built loyalty produces resentment instead, because the user did the work and got nothing durable back for it.

Skip this and you get switching anxiety without switching prevention: users worry about losing what they built—a real cost named in Jobs-to-be-Done—but the product hasn’t actually made staying worthwhile, only made leaving inconvenient, which is a weaker and more resentful bond than an earned one. Overdo it in the wrong direction and Effort Moat curdles into hostage data: streaks that punish absence, exports that don’t work, “your data” that turns out to require you to keep paying to see it. The test this card keeps returning to is whether leaving means giving up something genuinely useful, not whether leaving has been made deliberately hard.

When to use it

• After users create, organise, configure, or contribute something meaningful
• When preferences, history, or saved work can make the next session better
• In re-entry moments where a useful recap can restore context
• When Personalisation can make the product adapt to explicit user choices

Do

• Reflect meaningful investment through saved work, timelines, recaps, and useful defaults
• Make completed setup immediately pay off in the experience that follows
• Preserve user input through autosave, version history, and clear recovery paths
• Make portability and account controls easy; Trust Building strengthens attachment more than lock-in does

Don’t

• Add tedious setup merely to create commitment
• Use streak loss, badges, or social status to make leaving feel costly
• Hide, delete, or hold user-created work hostage
• Treat accumulated data as proof of loyalty when it no longer serves the user

Founder Tip

The strongest moat is not “you cannot leave”; it is “leaving means giving up something genuinely useful you chose to build here”.

Make It Yours

1. Map meaningful investment

   • What do users create, curate, learn, or configure that improves future use?
   • Which effort is currently invisible once the task is complete?

2. Make the payoff immediate

   • What useful result appears as soon as setup or contribution is finished?
   • Can a new default, saved view, or recommendation demonstrate that the product learned something helpful?

3. Protect ownership

   • Can users retrieve drafts, undo accidental changes, export their work, and understand how it is used?
   • Where could a loss of data or context turn investment into distrust?

4. Check for real value

   • Do users with more saved work get better outcomes, or are they simply more locked in?
   • What would make a first-time user want to build a little more because the benefit is clear?

Related concepts

• Investment and Continuity
• User Agency
• Jobs-to-be-Done

Further reading

• The IKEA Effect: When Labor Leads to Love — foundational research on valuing successful self-made work.
• The “IKEA Effect”: When Labor Leads to Love — freely available paper with the study’s boundary conditions.
• On the Sunk-Cost Effect in Economic Decision-Making: A Meta-Analytic Review — explains why designing around sunk costs is ethically risky.
• 10 Usability Heuristics for User Interface Design — supports user control, recovery, and protection of effort.

Agent skill

• Primary command: /productfeeling friction — honour saved work and context so return paths stay low-effort without lock-in
• Related commands: /productfeeling trust, /productfeeling anti-patterns, /productfeeling states, /productfeeling delight
• When the agent should load this TTP: “saved work”, “return visit”, “progress recap”, “personal setup”, “export and portability”
• Companion handoff: Impeccable — recaps, saved views, and recovery UI; DocSlime — data portability, export, and account-control requirements
• Feeling north star this TTP serves: continuity through earned value, not hostage data
• Anti-goals: tedious setup for commitment, streak punishment, hidden or held user work, sunk-cost retention
• Reference path: skill/reference/friction.md