When to Kill a Feature (And How to Make That Call)
Every product team has one. The feature nobody uses, but the sales team defends because they promised it to a customer in 2022. The dashboard widget that shows up in 3% of sessions. The export format that three enterprise clients asked for, got, and then never touched. Knowing when to kill a feature is one of the hardest calls a PM makes.
Killing features is hard not because the decision is complex, but because the politics around it are. Everyone who wanted the feature built still remembers wanting it. Nobody wants to admit it didn’t work. The call gets made badly in two directions, both common: too fast, before usage data has actually been checked, forcing a walk-back after a key account complains — or about a year too slow, sitting on a feature everyone already knows is dead because nobody wants the conversation with sales. The slow version costs more, by a wide margin, and it’s the mistake PMs make most often.
The Feature Nobody Uses, But Everyone Defends
The pattern is almost always the same. Feature gets built for a specific reason — a sales request, a competitive pressure, a genuine user problem that turned out to be narrower than expected. It ships. It gets announced. It doesn’t get adopted. And then, because nobody explicitly kills it, it becomes part of the product permanently.
Permanently means the engineering team has to maintain it. Every refactor has to account for it. Every new feature has to coexist with it. The documentation team has to document it. The support team has to answer questions about it. The cost of a feature that nobody uses isn’t zero — it’s an ongoing tax paid every single sprint.
Teams underestimate this badly, and often. At one $4M ARR SaaS company, a bulk import feature was used by fewer than 2% of customers. The engineering lead estimated it consumed roughly 15–20% of support volume, mostly from edge cases the feature handled badly. It had been built for one key account that churned six months later. Once killed — carefully, with a migration path — support tickets dropped by about a fifth within two months.
Signals That Tell You When to Kill a Feature
No single signal is definitive. You’re looking for a pattern.
Usage is low and hasn’t grown. “Low” is relative — a feature used by 5% of your enterprise customers might be critical; 5% of freemium users doing a throwaway action probably isn’t. The key question is: are the right users using this, and is adoption trending in any direction? If it’s been flat at low usage for two or more quarters, that’s a real signal.
The users who use it aren’t your target users. Sometimes, a feature keeps a cohort of customers alive who don’t represent your ICP. If killing the feature would churn those customers, but none of them would become the customers you’re trying to grow, that’s worth acknowledging directly.
It’s creating disproportionate support or maintenance costs. Track this explicitly. Support ticket tags, engineering time spent on bug fixes, and test coverage burden. Features that consume engineering time out of proportion to their value are the easiest cases to make.
It conflicts with where the product is going. This is the hardest signal to act on because it requires confidence in your direction, but it’s often the most important one. A feature that made sense for who your users were 18 months ago might be actively confusing to who your users are now.
Your team has stopped improving it. If a feature hasn’t been touched — no improvements, no bugs fixed, no roadmap items pointing to it — for two or more quarters, it’s already been informally deprecated. You’re just not saying so.
A sixth signal worth naming, because it’s the one teams miss most often: the feature only survives because it shows up well in a sales demo, not because customers actually use it after they buy. The internal pitch is familiar — “we can’t kill it, it’s a differentiator in the deck” — for a comparison-table feature that fewer than 1% of paying accounts had opened in six months. A feature that closes deals but goes unused post-sale isn’t earning its keep; it’s a marketing asset wearing a product feature’s maintenance cost. If that’s the real reason to keep something alive, say so plainly, and decide whether a screenshot in a sales deck would do the same job for less ongoing engineering cost.
How to Actually Decide When to Kill a Feature
The decision isn’t just “does this feature earn its keep.” It’s “what’s the cost of killing it versus the cost of keeping it.”
Cost of keeping it: engineering maintenance, support burden, product complexity (cognitive load for users navigating a feature-bloated product), and documentation.
Cost of killing it: churned users who depend on it, engineering cost of the deprecation and migration path, and internal political capital spent convincing stakeholders.
For most features in the “nobody uses it” category, the math isn’t close. The ongoing carrying cost beats the one-time kill cost within a few quarters. Intercom’s own writeup on sunsetting features puts it bluntly: features nobody uses are the definition of useless, so they have to go — the harder work is doing it with minimal customer impact, not deciding whether to do it at all.
The trickier case is a feature used by a vocal minority — maybe 8% of users, but they generate 30% of your Slack community posts. These users will be loud. Plan for that. Their noise doesn’t mean the decision is wrong; it means your communication needs to be better than average. Underestimating this is common: a power-user export format used by maybe fifteen accounts, all in the same customer Slack community, gets deprecated with what looks like plenty of notice, and still draws a week of pointed feedback — not because the decision was wrong, but because one announcement went out instead of three, on the mistaken assumption that reading it once is the same as absorbing it.
The Feature Deprecation Checklist
Run through this before making a final call. If you’re weighing this decision against ten other competing asks on the roadmap, the same triage logic in our guide on how to prioritize when everything is urgent applies directly.
| Criteria | Question to Answer | Threshold |
|---|---|---|
| Usage | What % of active users used this in the last 90 days? | Under 5% of target segment is a strong kill signal |
| Trend | Is usage growing, flat, or declining? | Flat or declining for 2+ quarters = proceed |
| Support cost | What % of support tickets relate to this feature? | Disproportionate cost (>2x usage share) = strong case |
| Strategic fit | Does this feature align with where the product is in 12 months? | No = consider kill regardless of usage |
| Replacement path | Can users accomplish this goal another way (in-product or externally)? | Yes = kill is easier; No = need migration or communication plan |
| Affected accounts | Are any high-value or at-risk accounts dependent on this feature? | Yes = escalate before deciding; engage CSM |
If you’re answering “kill” to four or more of these, the decision is probably already made. The checklist is mostly about making sure you haven’t missed anything before you announce it.
How to Communicate a Feature Kill (Internally and to Users)
Internally: the hardest conversation is usually with sales. They sold something that you’re taking away. The frame that works: “We’re removing this so we can make the core product better, and here’s the alternative.” Have the alternative ready before you have the conversation, not after.
With the team: don’t frame it as failure. Frame it as a signal. “This feature told us something about what our users actually needed. That information is valuable. We’re using it.” The team that built the feature built it in good faith; the deprecation isn’t a verdict on their work.
With users: give more notice than you think you need. 60–90 days is standard. Be specific about what’s changing and when. Provide a clear alternative or migration path. Don’t bury the announcement — if you make it hard to find, you just create a wave of surprised customers on the removal date. And whatever you do, don’t write the deprecation notice in the same tone as a feature announcement — those are completely different communication jobs.
Handling conflicting feedback from users and sales is especially acute here. Sales wants to keep the feature for retention; users who don’t use it are indifferent; the team that built it has feelings. The PM’s job is to make the call with data, communicate it clearly, and absorb the discomfort.
If the feature being killed was controversial when it was built — and there was a postmortem or retro that flagged risks at the time — use that document. It’s proof that the team saw the risks, made the best call with the information available, and is now updating based on evidence. That reframe matters.
What Happens If You Don’t Kill It
The product gets heavier. Navigation gets worse. New users encounter features that confuse them or that don’t apply to them. Engineers slow down because the surface area of the codebase is larger than it needs to be. Technical debt compounds.
More concretely: the signal that your product is hard to navigate doesn’t usually come from power users. It comes from people who tried the product and left. Features that exist for 3% of your users are visible to 100% of your prospects. That tax is real, and it’s underreported. Lenny Rachitsky’s checklist for sunsetting a feature makes a similar point from the other direction — the cost of keeping something alive rarely shows up in a single metric, which is exactly why it’s so easy to keep deferring the decision.
There’s also an organizational cost that’s easy to miss because it never shows up on a roadmap: every feature you never kill quietly raises the bar for what “done” means on the next one. New engineers inherit code they didn’t write and don’t fully understand context for. New PMs inherit tickets tagged against a feature nobody can explain the original rationale for anymore. It’s not unusual to onboard onto a codebase where a full third of the support macros reference a feature that’s effectively been dead for over a year — nobody made the call, so nobody cleaned up after it, and every new hire has to independently rediscover that it doesn’t matter.
The feature you should look at right now: pull your analytics. Find the three features with the lowest 90-day active usage among your target segment. For each one, answer the checklist above. If you can do that analysis in the next two days, you’ll know whether you have a kill candidate sitting in your product right now — and whether it’s the fast-and-clean kind or the vocal-minority kind that needs a communication plan before anything else happens.
References
- Lenny’s Newsletter — “When to Sunset a Feature”
- Intercom — “How to Sunset a Feature”
- Perri, M. (2018). Escaping the Build Trap. O’Reilly Media.
