Every product has one. A feature that shows up in dashboards as "active," that a handful of customers mention by name, that some engineer spent real weeks building. And yet, when you look at it honestly, it makes the product worse.
Killing it is the hardest decision you'll make — and often the best one.
The first trap is the metrics. A feature with consistent usage looks healthy. But usage and value are different things. People use workarounds, too. People use features because they exist, not because they solve the problem well.
Ask a different question: if you were building the product from scratch today, would you include this feature? If the answer is no, you're maintaining it out of obligation, not conviction.
There's a useful distinction between load-bearing features and familiar ones. A load-bearing feature is structural — remove it and workflows collapse. A familiar feature is just there. People know where to click. They have muscle memory. But muscle memory is not dependency. Offer those same users a cleaner path to the same outcome, and most will take it within a week.
How to tell the difference: talk to the customers who use it and ask what job they hire the feature to do. If they describe the job clearly and no other part of your product does it, the feature is load-bearing. If they pause, or describe something your product already handles elsewhere, you're looking at familiarity.
Features don't sit quietly on a shelf. Every feature you keep has a maintenance cost, a cognitive cost, and an opportunity cost.
Maintenance cost is obvious — bug fixes, compatibility work, edge cases that surface during unrelated changes. Less obvious is cognitive cost. Every feature a new user encounters is a decision point. "Should I use this or that?" More surface area means more confusion, longer onboarding, and more support tickets that start with "what does this button do?"
Then there's opportunity cost. Engineers working on a feature that shouldn't exist aren't working on the thing that should. Product managers writing documentation for a deprecated workflow aren't thinking about the next good idea. The feature becomes a tax on everything around it.
The hardest version: a feature that a small, vocal group loves but that actively confuses everyone else. You're optimizing for five accounts at the expense of five hundred.
Killing a feature badly is worse than keeping it. The communication matters as much as the decision.
Three principles that hold up:
Give people time. Nobody likes a surprise. Announce the timeline, make it generous enough that people can adjust, and stick to it. Changing the date — either direction — signals you're not confident in the decision.
Explain the why, not just the what. "We're removing Feature X" creates anxiety. "We're removing Feature X because it conflicts with how we're building Y, and Y will do the job better" gives people something to hold onto. Respect your users enough to share the reasoning.
Offer a bridge. If the feature did a real job, show people how to accomplish that job after the removal. A migration guide, a new workflow, a direct conversation with affected accounts. The goal isn't to make the removal painless — some friction is unavoidable — but to make it navigable.
One more thing: don't apologize for the decision. Apologize for any inconvenience, yes. But framing the removal as a mistake you're making suggests you don't believe in it. If you don't believe in it, don't do it.
The industry celebrates shipping. Launch posts, release notes, changelog entries — all additive. Nobody writes a blog post titled "we removed three things this quarter." But subtraction is where product maturity lives.
A product that only adds features eventually does many things poorly. The best products do fewer things with more clarity. That clarity isn't an accident. It's the result of someone making a hard call, absorbing the short-term complaints, and watching the product get simpler, faster, and easier to explain.
Every feature you kill is a statement about what you believe the product should be. That's harder than building something new. Building is fun. Removing requires you to sit with the discomfort of telling a customer "no, we won't maintain this anymore" and meaning it.
Put this on your quarterly review: what would we remove if we weren't afraid of the reaction?
The features that survive that question are worth keeping. The rest are candidates. Not all should go at once — sequencing matters, and trust is finite. But having the list changes how you think about your roadmap. It stops being purely additive and starts being editorial.
Ship when you should. Un-ship when you must. The product you end up with is the one you were willing to edit.
Be the first to comment.
0 comments
Loading comments...