Adding a feature is a story of optimism. Someone had an idea, a team built it, users (theoretically) wanted it. Removing a feature is a story of failure, regret, and almost guaranteed conflict. That asymmetry is not a quirk of engineering culture. It is a structural bias baked into how teams measure progress, manage risk, and avoid blame. And it quietly degrades products that should be getting better.
The case for deletion is almost never made
When a team proposes building something new, it gets a roadmap slot, a design review, an estimate, maybe a launch announcement. When someone proposes removing something, the burden of proof inverts entirely. You need to explain who uses it, how often, what they’ll do instead, and whether you’re absolutely certain no one important depends on it. The default answer is always “leave it.”
This creates an obvious ratchet. Features accumulate. The product grows heavier. Navigation becomes archaeology. New users arrive and face a surface area that was designed for five different eras of the product simultaneously. The team that built the original feature is often gone, so no one fully understands it. That uncertainty becomes the strongest argument for keeping it: what if something breaks?
Technical debt is the boring version of the real problem
Most conversations about bloated products frame it as a technical debt issue. That framing is too narrow. Yes, unused features carry maintenance costs: they need to be tested, documented, kept compatible with infrastructure changes, and occasionally updated when dependencies shift. Those costs are real. But the more serious damage is cognitive.
Every feature in a product is an implicit promise to users that this thing matters, that it’s supported, that it belongs. A settings panel with forty options doesn’t tell users they have control. It tells them the product doesn’t know what it is. The cognitive cost of a cluttered interface isn’t just annoyance. It erodes trust in the product’s judgment. When you remove something confidently, you’re not just clearing code. You’re making a statement about what the product actually is.
Google famously shut down Google Reader in 2013, a product with millions of passionate users. The decision was controversial and loud. But it reflected a judgment that maintaining a product the company wasn’t investing in was worse for users long-term than a clean removal. You can debate the specific call, but the logic is sound. Half-maintained features are worse than absent ones.
The political economy of removal
Here’s the real reason deletion is hard: the costs and benefits land on different people. The engineer who removes a feature owns the risk if anything goes wrong. The PM who signs off absorbs the complaints from users who lose something they used. But the benefits, a cleaner product, reduced maintenance burden, faster onboarding for new users, diffuse across everyone and show up slowly. No one gets credit for the absence of future bugs.
This is why the cost of a single engineer compounds in ways teams rarely account for. Every feature that stays alive has someone, somewhere, spending time keeping it alive. Multiply that across a product that hasn’t done serious pruning in three years and you’re looking at meaningful engineering capacity committed to the past instead of the future.
The teams that do this well treat removal as a first-class engineering activity with the same rigor as addition. They track feature usage with the same seriousness they track bugs. They set explicit thresholds: if fewer than X% of active users touch this in six months, it goes on a deprecation list. They communicate removals with the same care as launches.
The counterargument
The reasonable objection is that usage data doesn’t tell the whole story. A feature used by 2% of users might be used by your highest-value customers. Removing it could trigger churn that dwarfs the maintenance savings. Power users often rely on capabilities that look invisible in aggregate metrics because their workflows run deeper than what surface analytics capture.
This is true. It’s also frequently used as a reason to never remove anything, ever, which defeats the point. The answer isn’t to ignore the concern. It’s to actually investigate it before defaulting to inaction. Talk to the users. Understand the workflow. If the feature genuinely serves a critical segment, keep it or find a better replacement. But that conversation should happen deliberately, not as an assumption that blocks the discussion from starting.
The teams that get this right distinguish between features that are load-bearing for important users and features that are load-bearing only because no one has bothered to check. Most bloat falls into the second category.
What restraint actually looks like
The best product decisions aren’t always visible. A product that feels fast, focused, and obvious got that way because someone made hard calls about what didn’t belong. That work is invisible by design.
If your team celebrates shipping but has no process for sunsetting, no metrics for feature health, and no cultural permission to propose removal, you’re building a product that only moves in one direction. That’s not momentum. That’s accumulation. Finishing fewer things can mean more actually gets done, and the same logic applies to features: a product that does fewer things well is harder to build and far better to use.
Deletion isn’t failure. It’s editing. And like most editing, it’s harder than the first draft.
