When you remove a feature, complaints spike before they settle — that's an extinction burst

You deprecate a feature. The data was clear: almost nobody used it, it cost you maintenance, it cluttered the interface. You ship the removal feeling confident. Then the day it lands, your inbox lights up. The support queue fills. Weirdly, your logs show a burst of people trying to use the thing you just removed — hammering the button that no longer does anything. A vocal group is genuinely angry. Your stomach drops and the instinct arrives fully formed: revert it, we got this wrong.

That instinct is often wrong, and behavioral science can tell you why — and, more usefully, what shape the fallout will take and when to actually judge it.

Behavior that has been reliably rewarded builds an expectation. Press the button, get the thing. When the reward suddenly stops — extinction, in the language of operant conditioning — the behavior does not politely fade. First it intensifies. This is the extinction burst: a temporary spike in the frequency and force of the behavior right after the reinforcement disappears. You already know it from the outside. The elevator “close door” button that seems slow, so you jab it five more times. The vending machine that takes your money and gives you nothing, so you push the buttons harder and faster before you finally give up and walk off. The burst is the nervous system testing whether the rule really changed, or whether trying harder brings the reward back.

There’s a companion effect worth knowing: spontaneous recovery. Even after the behavior fades, it can briefly reappear later, out of nowhere — a straggler wave of “hey, where did X go?” weeks after you thought it was settled.

Translate this into how you ship removals.

The spike is evidence of prior habit strength, not proof you were wrong. The people making the most noise are frequently your most engaged users — precisely the ones who’d built the behavior deepest, so their extinction burst is the loudest. Volume of complaint in the first days measures how ingrained the habit was, not whether removing it was correct.

Read the timeline before you react. The honest shape is a jump, a peak, and a decay. If you revert during the peak, you’ve taught your users something corrosive: that loud enough complaints reverse decisions. You’ll pay for that lesson on every future change. Decide before you ship what “settled” looks like — what metric, at what level, after how many days — and hold your nerve until the curve gets there.

Soften the extinction; don’t cut cold. A burst that slams into a wall is worse than one that lands on a ramp. Announce ahead of time. Point the dead button at the replacement path so the reward looks moved rather than vanished. Migrate the behavior instead of amputating it, and the burst is shorter and quieter.

Know when the burst isn’t a burst. Sometimes the noise never decays, because the behavior was actually load-bearing and you misread the usage data (an important workflow can be low-frequency and still essential). The only way to tell the difference honestly is to have named your “settled” threshold in advance — so you can distinguish a habit dying from a genuine mistake, instead of deciding under the pressure of an angry week.

The burst is the sound of a habit dying. It’s loud, it’s brief, and it is extremely easy to mistake for a mistake. Bring a stopwatch, not a panic button.