How to kill a feature

Every product person can describe how a feature gets built. Almost none can describe how one gets removed.

That asymmetry compounds. A product accumulates features the way a house accumulates objects: each one arrived for a reason, none of them has an expiry date, and the cost of the pile is paid in a currency nobody invoices — the growing difficulty of every subsequent change.

Removal is a skill. Here’s the version I use.

The signal that a feature should go

Not “low usage”. Low usage is where people start and it’s a bad first filter, because some genuinely important features are used rarely — the export nobody touches until an audit, the setting that matters to four customers who between them are a third of your revenue.

Better signals, in order:

Nobody can state what it’s for in one sentence. If the product owner and two engineers give three different answers, the feature has no owner and no purpose, just inertia.

It’s the reason other things are hard. This is the real cost, and it’s usually invisible until you go looking. A feature that forces every new screen to handle an extra case, or every query to join one more table, is charging you rent on everything else you build.

It has its own support burden and no advocate. Tickets come in, someone handles them, nobody defends it in planning.

It was built for a customer who left. Astonishingly common. The feature outlives the relationship that justified it by years.

The removal that works

The mistake is to treat removal as a single event. It’s a sequence, and skipping steps is what makes people afraid of it.

Measure first, in the dark. Before announcing anything, instrument it properly. Not “was this page loaded” — was the feature completed. Half of what looks like usage is people opening something and backing out. Give it a month.

Find the humans, not the numbers. Whoever does use it, talk to them. Not a survey — a conversation. Twice now I’ve discovered the feature was being used for something entirely unlike its intent, which changed the decision: the thing to build wasn’t a replacement, it was the thing they were actually doing.

Stop the bleeding before the surgery. Remove it from navigation, from onboarding, from the marketing site. New users stop finding it. Existing users keep working. Nothing breaks. This alone often reduces usage by most of what’s left and buys you a clean read.

Announce with a date and an alternative. The alternative matters more than the notice period. “This goes away in ninety days” is an announcement. “This goes away in ninety days, here’s how to do the same thing” is a migration. People forgive the second and remember the first.

Then remove the code. Not just the entry point — the code, the tables, the background job, the config, the tests. A feature that’s disabled but present is the worst state: you pay the maintenance cost and get none of the value. This is the step teams skip, and it’s the step where the actual benefit lives.

The political part, which is the hard part

None of the above is difficult. What’s difficult is that features have sponsors, and removing one can read as a judgement on the person who asked for it.

Three things that help:

Never frame it as a mistake. It was right for the context that existed. Contexts change. “This served us well and the situation moved” is both true and survivable; “this was a bad idea” is neither, even when it’s accurate.

Bring the cost, not the opinion. “I don’t think this is useful” is an argument you can lose to someone more senior. “This feature is why the new billing screen takes three weeks instead of one” is a trade the same person can evaluate. Make the tax visible and the decision usually makes itself.

Give it a graduation, not a funeral. Announce what the removal buys — which thing on the roadmap moves up. A removal with a visible payoff becomes something people support rather than mourn.

The rule I’d give a team

Put a review date on every feature at the moment it ships.

Not a plan to remove it. A date — six months, a year — when someone has to answer, in one sentence, what it’s for and whether that’s still true. Most will pass in thirty seconds. The ones that don’t are the ones you’d otherwise have carried for five more years.

It costs almost nothing and it changes the default. Right now the default is that everything shipped is permanent, which means the product can only grow in one direction. A review date makes permanence a decision instead of an accident.

Products that stay comprehensible do it by removing at roughly the rate they add. Nobody plans for that, which is why so few products stay comprehensible.

The best version of your product is somewhere inside the current one. Getting to it is subtraction.