The simple version
Building a feature generates enthusiasm and signals momentum. Deleting one generates complaints, political resistance, and the creeping fear that you’re making a mistake nobody will forgive. That asymmetry explains why most software products accumulate features until they collapse under their own weight.
Why addition feels safe
Engineering teams are rewarded for shipping. Product managers earn credibility by delivering requests. Designers get recognition for new surfaces. The entire incentive structure of a software organization points toward creation. Deletion, by contrast, produces no artifact anyone can celebrate.
This isn’t irrational behavior. When you add a feature, the people who wanted it notice. When you remove one, the people who used it, even rarely, feel something taken from them. Behavioral economics has a name for this: loss aversion. The pain of losing something consistently outweighs the pleasure of gaining something equivalent. Feature removal hits users exactly where that asymmetry bites hardest.
The organizational pressure compounds this. If a feature existed long enough to acquire a stakeholder, removing it means overruling someone who fought to build it. Nobody wants to tell a colleague their work was a mistake. The social friction alone is enough to keep dead features on life support for years.
The hidden cost of keeping things
Every feature a team keeps is a commitment. It needs to be tested when the codebase changes. It needs to be considered when designing new flows. It creates surface area for bugs. It shows up in documentation, in support tickets, in edge cases that slow down future development.
As deleting code makes software more reliable, the same logic applies to features. The absence of a thing cannot break. A feature that nobody uses still participates in every system change, silently taxing every engineer who touches the code around it.
This is the argument teams rarely make explicitly because it requires accepting an uncomfortable truth: the feature cost resources to build, and it costs resources to maintain, and if it isn’t earning its keep, it’s a liability. Sunk cost reasoning, the impulse to protect past investment by keeping it visible, is the enemy of honest product thinking.
Google has removed dozens of products over the years, including Reader, Inbox, Stadia, and many others, and while each removal generated a wave of criticism, the alternative would have been resources spread thin across a graveyard of underdeveloped tools. Apple, notoriously, killed the floppy drive before users were ready, killed the headphone jack before users wanted to, and in each case absorbed the backlash in exchange for a cleaner product architecture.
The political problem nobody talks about
Product decisions don’t happen in a vacuum. At most companies above a certain size, the conversation about removing a feature quickly becomes a conversation about whose judgment matters and whose doesn’t.
If the feature was built at the request of a major customer, removing it means telling that customer their needs have been deprioritized. That conversation typically goes through account management, then sales leadership, then sometimes the CEO. What started as an engineering hygiene decision becomes a boardroom negotiation.
If the feature was championed by an executive who has since moved on, removing it means implicitly criticizing a decision made above the pay grade of everyone in the room. Nobody says this out loud. But everyone feels it.
And if usage data supports removal, that data still has to survive contact with anecdote. One customer who shouts loudly about a feature they need, even if analytics show they’ve used it twice in three years, can reverse a well-reasoned decision made by a team that spent weeks gathering evidence.
How to actually do it
The teams that remove features successfully tend to do a few things consistently.
First, they define what success looks like before a feature ships. If you don’t know what you’re trying to achieve, you can’t know when a feature has failed. Usage thresholds, retention impact, support ticket volume, whatever the relevant metric is, it needs to be agreed on early, not invented retroactively to justify a decision already made.
Second, they distinguish between features nobody uses and features a few people depend on heavily. A feature used by two percent of users who would churn without it is a different problem than a feature used by two percent of users who barely notice it. Segment before deciding.
Third, they communicate the removal as a choice with a rationale, not an apology. Users respond better to confidence than to hedging. “We’re removing this to focus on X” lands differently than “We know this may be inconvenient and we’re sorry but after careful consideration…” The latter signals that the team isn’t sure of its own decision.
Fourth, they migrate affected users when possible. Stripe has a reputation for maintaining backward compatibility even as it evolves its API, but when it does deprecate something, it provides migration paths and transition timelines. That approach treats users as partners in the change rather than victims of it.
The real test of product judgment
Anyone can add. Addition requires only enthusiasm and capacity. Removal requires clarity about what a product is actually for, confidence in that clarity despite opposition, and the willingness to absorb short-term pain for long-term coherence.
The products that earn lasting loyalty tend to be the ones with opinions. They say yes to some things and no to others. That selectivity requires a team willing to remove as deliberately as it builds, to treat the product as something that should be shaped, not merely accumulated.
This is, in the end, a question of what work actually means. Shipping a feature checks a box. Deciding a feature shouldn’t exist anymore requires a harder kind of reasoning, one that doesn’t generate a changelog entry anyone will celebrate. That’s exactly why so few teams do it well.
