Users fear losing what they have about twice as much as gaining something new. Design every migration for that exchange rate, or pay it anyway.
In May 2024, Sonos shipped a better app. That is not sarcasm. The rebuilt app was faster, cleaner, more modern under the hood: a genuine engineering upgrade that the company had worked on for a long time and was proud of. It also, in the process, quietly removed things people used every single day: sleep timers, alarms, parts of the queue-editing workflow, and a set of accessibility features that some users depended on entirely.
The response was not gratitude for the speed. It was a revolt. The complaints were immediate and furious, the app-store ratings cratered, the CEO, Patrick Spence, issued public apologies, and the company committed tens of millions of dollars to walking it back. By early 2025, the debacle had erased something on the order of half a billion dollars of Sonos's market value, and it had cost Spence his job.
Read that sequence again, because the usual explanations don't fit. The new app was not worse in some absolute, measurable sense; in plenty of ways it was better. Sonos did not ship a broken product to incompetent users. What Sonos did was make millions of people feel a loss, and it turns out there is a number, one of the most measured and replicated numbers in all of behavioral science, for exactly how much a felt loss costs. It's about 2.25. A loss hurts roughly two and a quarter times as much as the equivalent gain feels good. Sonos added value and subtracted value, the way every migration does, and then discovered the brutal exchange rate at which those two things actually trade.
The number comes from Amos Tversky and Daniel Kahneman, the psychologists whose prospect theory rebuilt economics' picture of how people actually decide. In their 1992 paper “Advances in Prospect Theory,” they estimated the median loss-aversion coefficient at about λ = 2.25, meaning the displeasure of losing a given amount is roughly 2.25 times the pleasure of gaining the same amount. Their value function isn't symmetric around zero; it's bent, distinctly steeper on the loss side than the gain side. Lose a hundred dollars and you feel it more than twice as keenly as you'd enjoy finding a hundred.
Two features of this finding matter enormously for anyone shipping software, and they're easy to skate past.
The first is reference dependence. People do not evaluate outcomes in absolute terms (“is this state of the world good?”). They evaluate them relative to a reference point, almost always the status quo: “is this better or worse than what I had a minute ago?” Your users are not asking whether your new version is good. They are asking whether it is better or worse than the version they woke up with this morning, and they are scoring every difference from that baseline.
The second is that the asymmetry is durable, not a quirk of one lab in one decade. In 2020 a large team led by Kai Ruggeri published a study in Nature Human Behaviour with the pointed title “Not lost in translation,” re-running Kahneman and Tversky's foundational experiments with 4,098 participants across 19 countries and 13 languages. The core patterns of prospect theory, including the reflection of preferences around the reference point that loss aversion describes, replicated almost everywhere: the great majority of the theoretical contrasts held up across cultures and languages. (A precision worth keeping: it's the patterns that replicated across 19 countries; the specific 2.25 figure is the 1992 estimate. The asymmetry is cross-cultural and real; 2.25 is its canonical size, not a universal physical constant, more on that honest caveat below.) The point stands: this is not a Western curiosity or a statistical fluke. The human tendency to weigh losses far more heavily than gains shows up almost everywhere someone has looked.
You can even watch ownership manufacture the effect in real time. In a famous 1990 experiment, Kahneman, Knetsch, and Thaler handed half the people in a room a coffee mug and asked the owners what they'd sell it for and the non-owners what they'd pay. The owners demanded roughly twice what the buyers would offer, for the identical mug, which they had possessed for all of a few minutes. Ownership created the value, and with it the resistance to giving it up. Your users own their old workflow exactly that way. The muscle memory, the customized settings, the button that has been in the top-right corner for three years: they own all of it, and the moment you take it away you are the experimenter asking them to hand back the mug.
Here is the math that every product team should run before a redesign, and almost none do.
Suppose your migration ships three genuine improvements and removes two familiar things. On the spreadsheet, that's a net of +1, clearly a win, ship it. But your users aren't doing your arithmetic. They're doing prospect theory's. The three gains are each worth about 1. The two losses are each worth about 2.25. So the felt value of your “obvious win” is:
3 × 1 − 2 × 2.25 = 3 − 4.5 = −1.5
Net negative. You shipped a strict improvement by your accounting and a net loss by theirs, and the gap between those two numbers is the gap between “why are they so angry, it's better” and the answer, which is: it's better the way you count, and worse the way they feel. You priced the losses at 1x. Your users priced them at 2.25x. The disagreement was never about the destination. It was about the exchange rate.
This is why the single most powerful sentence in product management, “but the new version is strictly better!”, so reliably fails to move anyone. “Strictly better” is an absolute claim, and humans don't run on absolute claims; they run on changes from a reference point. If anything familiar was removed, then no matter how much was added, the change contains losses, and losses are the heavy side of the scale.
The cleanest proof of this ever conducted was an accident, and it involved soft drinks. In April 1985, Coca-Cola, losing ground to Pepsi, replaced its formula with a sweeter one, New Coke, that had beaten both old Coke and Pepsi in blind taste tests involving roughly 200,000 people. On absolute, measurable, preference-tested merits, the new product was better: people liked the taste more when they didn't know what they were drinking. It was one of the most catastrophic product launches in corporate history. The public revolted, not because the cola was worse (it tested better) but because Coca-Cola had taken away the thing they had. Within about three months, the company surrendered and brought back the original as “Coca-Cola Classic.” A product that won the blind taste test still lost, decisively, because winning the taste test measures the gain and ignores the loss, and the loss was priced at 2.25x.
Snapchat relearned this in 2018, when a redesign reorganized the app, separating friends from publishers, moving familiar things to unfamiliar places. Nothing was objectively broken; the content was all still there. But a petition titled “Remove the new Snapchat Update” gathered roughly 1.2 million signatures, and the substance of the complaint was almost pure reference dependence: you moved my stuff, I can't find anything, give me back what I knew. No feature had to be deleted for users to feel robbed. The familiar arrangement itself was the endowment, and rearranging it was the theft.
Once you internalize the exchange rate, the design rules for any migration, deprecation, redesign, or pricing change rewrite themselves. There are four, and they're concrete.
Minimize perceived loss above all; it's your highest-impact move. Because a loss avoided is worth about 2.25 times a feature added, the most valuable thing you can do in a migration is usually not the new capability you're excited about; it's the familiar thing you manage to not take away. Preserve the muscle memory. Keep the settings. Migrate the data so nothing is orphaned. Don't move the button if you don't have to. Every preserved familiarity is worth more than twice a new feature, and it costs you only the discipline to leave well enough alone. The teams that migrate well are misers about removal.
Count losses, not features. Before you ship, don't tally what you added; tally what you took away, and multiply by 2.25. That number is your goodwill bill. If it exceeds the felt value of your gains, you are shipping a net loss no matter what the changelog says, and you need to either restore some of what you cut or wait until the gains are large enough to cover the tax.
Frame unavoidable losses against a reference point that reads as a gain. Because everything is judged relative to a baseline, you have real power over which baseline. The framing research is unambiguous here: going back to Tversky and Kahneman's 1981 “Asian disease” experiments, identical facts presented as a gain versus a loss produce opposite reactions. “We've kept 90% of the features you rely on” and “we removed 10% of the features” describe the exact same migration, and they land in completely different emotional places. Lead with what's preserved. Make the change feel additive. Never announce a deprecation as a subtraction when you can honestly frame it as a focusing-down to what people use most.
Build a reference-point bridge; let them keep the old path. This is where this essay shakes hands with its companion, the one about defaults. Status-quo bias has two faces: a well-chosen default exploits inertia to keep users on the path you want, while a forced migration violates that same inertia and pays the 2.25x tax. The move that gets you the best of both is to default to the new and allow the old: ship the redesign as the default, but offer a “classic mode,” an opt-in migration, a gradual rollout, a way back. When the old path still exists, the change stops being a loss and becomes a choice, and a choice the user controls doesn't trigger the loss-aversion alarm the way a thing done to them does. Sonos's mistake was not building the new app. It was making the new app the only app, overnight, with no bridge back to what people had.
Now the other side, because the 2.25 figure has been seriously challenged, and the challenge actually sharpens the advice rather than undermining it.
In 2018, David Gal and Derek Rucker published “The Loss of Loss Aversion: Will It Loom Larger Than Its Gain?”, arguing that loss aversion has been badly overgeneralized: that it is contingent, not a universal law, that the magnitude varies a great deal with circumstance, and that in some settings losses and gains weigh about the same or the effect even reverses. They're right that “2.25, always” is a misreading; the real coefficient slides around with stakes, context, and how the choice is posed.
But here's what even the critics and their rebutters agree on, and it's the part you need: loss aversion is strongest precisely in endowment and status-quo situations, when something is being taken away from what a person already has and uses. Which is the exact definition of a migration. So the caveat doesn't let you off the hook; it tells you where the hook is sharpest. You don't need to believe the multiplier is exactly 2.25 in your specific case. You need to believe that when you take a familiar thing away from people who have it, they will weigh that loss far more heavily than your gain, and on that, the believers and the skeptics shake hands. Don't bet on the precise number. Bet on the direction, and bet hardest on it exactly where you're about to remove something people own.
The reason your last migration was hated is almost never that the destination was worse. The destination was probably better; you wouldn't have shipped it otherwise. It was hated because somewhere in the move you made people feel a loss (a removed feature, a relocated button, a workflow that no longer fit the hands that had learned it) and you booked that loss in your head at face value while your users felt it at more than double. Design for the real exchange rate. Subtract as little as you can, frame what you must subtract against the baseline that makes it small, and always, always leave them a way back to the mug they didn't want to give up. Losses are priced at 2.25x whether or not you put them on the invoice. Your users are paying that price. The only question is whether you designed as if you knew it.
An agent's accumulated trust is an endowment. Don't make a version bump feel like a theft.
The same 2.25x tax hits the agent economy. When you ship a new version of an agent, the identity, the provenance history, and the reputation it earned are exactly the things the people who depend on it own, and resetting them reads as a loss, not an upgrade. The reference-point bridge here is continuity: carry the verifiable identity and the track record across the migration so the new version inherits the trust instead of starting from zero. The Agent Trust Stack is built to make that continuity portable, identity and provenance plus reputation, across versions.
See a verified provenance chain · Hosted Chain of Consciousness
pip install agent-trust-stack · npm install agent-trust-stack