Building a feature takes courage. Deleting one takes something rarer: the willingness to absorb organizational pain for a benefit that’s diffuse, delayed, and hard to measure. Teams that build well are good. Teams that delete well are exceptional. Here’s why the second skill is so much harder to develop.
1. Someone Fought Hard to Build It
Every feature in your product represents a past decision that someone won. They wrote a spec, ran a sprint, defended it in a roadmap meeting, and shipped it. That history doesn’t disappear when usage data suggests the feature isn’t earning its keep. It lives on in the person who championed it, who will now experience deletion as a personal repudiation.
This is not irrational behavior. It’s a natural response to how organizations allocate credit. We celebrate shipping. Nobody gets a performance review that says “removed three features flawlessly this quarter.” Until companies build explicit recognition around productive deletion, the incentives will keep tilting toward accumulation.
2. Usage Data Lies in Complicated Ways
The most common argument for keeping a feature is “people use it.” The most common mistake is accepting that argument without interrogating what “use” means. A feature might show activity in your analytics because it sits one click from something users actually want. They click it, find it useless, and leave. Your data shows engagement. Your user doesn’t feel served.
Conversely, some features have low aggregate usage but represent a genuine dependency for a small, high-value segment. Deleting a power-user feature because it shows 2% adoption can crater retention among the customers who generate outsized revenue. Good deletion requires segmenting your usage data by user type, not just counting clicks. This is harder than it sounds and most teams skip it.
3. The Code Doesn’t Stay Still While You Debate
Here’s the technical reality that makes delay expensive: every week you don’t delete a feature, other code grows around it. New engineers write functions that assume it exists. The feature accumulates dependencies it didn’t have when someone first proposed cutting it. By the time consensus forms, the removal cost has compounded.
Google has written publicly about this in the context of large codebases. Dead code is not neutral weight. It slows down builds, introduces surface area for bugs, and creates cognitive overhead for anyone reading adjacent code. The feature you’re not using is still costing you, just in a currency that doesn’t show up in a product dashboard.
4. Users Announce Themselves Only When You Move to Delete
One reliable phenomenon: you can ship a feature to silence, maintain it for years without a single support ticket, and then announce its removal to an immediate outpouring of complaints. This is not evidence that the feature is beloved. It’s evidence that loss aversion is more motivating than appreciation.
This effect is real and documented in behavioral economics. It also creates a genuine decision-making trap: if the only feedback signal you get is negative (because satisfied users don’t send thank-you emails), you will systematically underweight the case for deletion. Teams need to pre-commit to a framework before they surface the removal publicly, not after.
5. There Is No Clean Line Between “Feature” and “Architecture”
Deletion gets exponentially harder when the feature being cut is load-bearing in ways that aren’t obvious. A settings panel might look like a discrete UI component. Behind it might be a permissions model that three other systems depend on. Removing the panel might be two hours of work. Removing the underlying logic might be a month.
This is why “just delete it” advice from outside the codebase is almost always naive. The surface area of a feature is the small, visible part. The structural commitments it has generated, in database schemas, API contracts, and service interfaces, are the hard part. Any honest reckoning with a deletion decision has to include a cost estimate for the hidden work, not just the visible one. Engineers who write less code per feature tend to leave less of this residue behind, which is one underappreciated reason they’re valuable.
6. Deletion Requires a Kind of Institutional Memory Most Teams Don’t Have
Features often exist for reasons that aren’t in any document. A workaround for a now-fixed bug in a third-party API. A concession made to a specific enterprise customer during a sales negotiation. A compliance requirement for a market the company no longer serves. If you don’t know why something was built, you can’t safely evaluate whether the original reason still applies.
This is an organizational knowledge problem as much as a technical one. Teams with high turnover lose context fastest. The engineer who knows why the flag exists has left. The Slack thread is buried. The JIRA ticket is closed. Deletion in this environment carries genuine risk, not because the feature is valuable, but because no one can reconstruct whether it’s safe to remove. Good engineering culture treats deletion as a first-class activity, which means documenting the “why” of features as carefully as the “what.”
7. The Team That Deletes Well Earns a Compounding Advantage
None of this means deletion is impossible or that teams should avoid it. The opposite is true. Products that accumulate without pruning become slow to navigate for users and slow to modify for engineers. The teams that build a cultural and procedural muscle for deletion ship faster over time, not slower, because they’re working in a cleaner codebase with a product that has a legible surface area.
Strategically, this matters. A smaller, sharper product is easier to explain, easier to sell, and easier to build on. The discipline of asking “what should we remove?” with the same rigor as “what should we build?” is one of the clearest signals that a product team has matured past the stage of just chasing output.
Deletion is where engineering judgment actually lives. Building features proves you can execute. Deleting the right ones proves you understand what you’re building.
