How to Know When to Kill a Feature (Before Your Team Gets Too Attached)

There is a specific kind of meeting that happens at every product team eventually. Someone raises the question of whether a feature that was built 18 months ago, that maybe 3% of users touch, that costs two sprints per quarter to maintain, should still exist.

And then the team spends an hour not deciding to remove it.

The engineer who built it is in the room. The PM who wrote the PRD is in the room. The customer success person who promised it to a client is in the room. Nobody wants to be the one who kills something they helped create.

This is the sunk cost fallacy applied to product development, and it is one of the most expensive problems in product management. Features that should be removed stay. The codebase grows heavier. The product becomes harder to navigate. Engineering velocity slows. And the PM who should be shipping new things is spending two sprints per quarter maintaining something 3% of users use.

The Problem with Waiting Until It's Obvious

Most feature removal decisions happen too late. They happen when the usage data is so bad that it cannot be ignored, when a major refactor makes the feature impossible to maintain without rewriting it, or when a new strategic direction makes the feature obviously contradictory.

By that point, the feature has already been a drag on the team for quarters. The opportunity cost has been paid many times over.

The concept of kill criteria addresses this by shifting the decision backward. Instead of asking "should we remove this?" when things are clearly bad, you ask "under what conditions would we remove this?" when you ship it. You set the threshold before anyone has built an identity around the feature. You make the removal decision easy because it was already made.

What Kill Criteria Actually Look Like

A kill criterion is a specific, measurable condition that triggers a removal conversation. It is not "if it's not working." That's too vague to act on. It looks more like:

"If fewer than 5% of active users interact with this feature in any session within 90 days of launch, we revisit removal."

"If this feature generates more than X support tickets per month relative to its adoption rate, we evaluate removal."

"If maintaining this feature requires more than one sprint per quarter, we evaluate whether the usage justifies the cost."

The specific thresholds will vary by product and feature type. What matters is that they are set before launch, written down, and reviewed on schedule. Locking kill criteria at launch and revisiting quarterly is the most practical cadence for most product teams.

In my experience, the teams that do this well treat kill criteria the same way they treat launch criteria. Both are conditions. Both require the same rigor. The asymmetry, where launch gets criteria and removal doesn't, is where the sunk cost accumulates.

The Four Signals That Justify Removal

When no kill criteria were set at launch, these are the signals worth taking seriously:

Usage that has declined for three or more consecutive months. A feature that was used and is now not being used is telling you something. Single-month drops can be noise. Three months of decline is a pattern.

Maintenance cost that is disproportionate to adoption. If a feature used by 3% of users requires the same engineering overhead as a feature used by 40% of users, the unit economics are wrong. The cost calculation includes engineering upkeep, support burden, and opportunity cost, meaning the features you are not shipping because you are maintaining this one. Opportunity cost is the most underweighted factor in feature removal decisions.

Strategic misalignment. Features built for an earlier version of the product strategy sometimes survive strategy pivots. If a feature made sense for a market segment you have since deprioritized, its continued existence is a residual commitment to a direction you have already moved away from.

Cannibalization of a more important feature. Sometimes two features compete for the same user behavior. One is better. One is the old version. Keeping both creates confusion and splits usage between them. When a feature negatively impacts the adoption of a more strategically valuable one, removing the weaker one often accelerates adoption of the stronger one.

What the Big Examples Actually Teach

Twitter Fleets and Google Inbox are the two most cited examples of major feature sunsets. The lesson people usually draw from them is that even big companies get it wrong.

The more useful lesson is about what removal signals look like in practice. Twitter Fleets showed consistently lower engagement than tweets despite significant placement prominence. Google Inbox was beloved by a segment of power users but couldn't justify the cost of maintaining a parallel email experience at Google's scale.

Both were removed not because they were broken but because the math of continued maintenance no longer made sense given strategic priorities and usage patterns. The decisions were right. The timing is what's worth debating.

In both cases, removal came after the signal was undeniable. The question for most product teams is not whether to remove underperforming features. It is whether you can build the discipline to do it earlier, before the cost compounds.

How to Remove a Feature Without Losing Customers

The removal itself matters. A feature sunset done poorly damages customer trust even when the removal decision was correct.

The right sequence: identify who uses the feature and how often, communicate the removal timeline before it happens rather than after, provide a migration path if the use case is legitimate and ongoing, and give enough notice that affected users can adapt.

In my experience, most customers who use low-adoption features are not deeply dependent on them. They found a workaround long ago. The vocal ones are the exception, not the rule, and they are usually the ones who will find a workaround fastest.

What customers do not forgive is removal without warning. A feature that disappears without notice makes users feel like the product is unpredictable. A feature removed with 60 days of communication, a clear reason, and an alternative path makes users feel like the team knows what it is doing.

The Real Cost of Features You Keep

Every feature in a product is a commitment. It needs to be documented, tested with every release, supported by customer service, and explained to new users. A product with 200 features is harder to onboard than one with 50. It is harder to navigate, harder to explain in a demo, and harder to maintain.

In my experience, the products that feel cleanest are the ones where every feature was kept deliberately, not by default. The question behind most great products is not "what should we add?" It is "what do we have the discipline to remove?"

Kill criteria are how you build that discipline before the sunk cost makes the decision harder than it should be.