Killing a feature is harder than shipping one. The team built it. Some customers depend on it. The PM who championed it is still around. The data shows it's barely used, but "barely" is doing work — there are real users, however few, who'd notice. So the feature lingers, accumulating maintenance debt, distracting the engineers from what comes next. The cost of keeping it isn't zero. It's just spread out enough that nobody adds it up.
Three signs it's actually time. First: the feature's usage is below 5% of users and hasn't moved in two quarters despite attention. ("Despite attention" matters — features grow with marketing, and a feature that hasn't grown with marketing has probably saturated its audience.) Second: a meaningful percentage of the engineering team's bug-fixing time goes to this feature. The 80/20 rule applies here too: a small set of features tends to generate most of the support load, and the under-used features that ship with most of the support load are the clearest kill candidates. Third: the feature blocks something the team wants to build next — it has architectural tendrils into surrounding code that make every new project slower.
When two of the three are true, kill it. But the killing isn't the hard part; the announcement is. The customers who do use the feature, even the small number, will feel betrayed. The way to write the announcement is short, direct, with empathy and zero defensiveness. "We're sunsetting feature X on date Y. Here's why. Here's what the alternative is. Here's how to migrate. We know this is disruptive for a small number of you, and we're sorry." The mistake is to wrap the announcement in marketing language or product-positive spin. The customers can see through it instantly, and they remember the spin longer than they remember the feature.
The hidden upside of killing features deliberately: it builds credibility for the team's roadmap. If the team has shipped, killed, and replaced features in the past, customers trust that the new thing the team is talking about will get the same attention. If the team never kills anything, the roadmap looks like an accumulator — every new thing is added to the previous things, the maintenance burden grows without bound, and the team's velocity quietly declines. The teams that ship the fastest in year five are usually the ones that killed the most aggressively in year three.