Features cost money forever
Every feature carries maintenance, testing, support and design constraint. A feature used by 2% of customers can consume a disproportionate share of engineering attention and constrain what you can change elsewhere.
Removing them is legitimate product management. Doing it badly is what damages relationships.
Establish who actually uses it
Instrument before deciding. “Nobody uses it” is frequently wrong, and it is occasionally wrong in the worst way: three customers use it constantly and it is why they stay.
Check usage by account value as well as by count. A feature used by five customers who represent a fifth of your revenue is not a candidate for quiet removal.
Give proper notice
- 90 days minimum for anything customers use in their own workflow
- Individual contact with every active user, not just an in-app banner
- Explain why, briefly and honestly
- Offer the alternative, with help moving to it
- Remind at intervals, and again shortly before removal
Provide a migration path
If there is a replacement, help people move to it — export their configuration, import it into the new thing, or do the migration for them for the handful of accounts affected.
If there is no replacement, say so plainly and help them export whatever data the feature held. Leaving people stranded with data locked in a removed feature is the version customers talk about publicly.
Watch for the retention risk
Contact the highest-value users personally, before the general announcement. It costs a few conversations and it prevents the scenario where a significant customer learns from an email that something they depend on is going.
Occasionally those conversations change the decision, which is a good outcome rather than a failure.
Then actually remove it
Deprecations that never complete are the worst of both worlds: maintenance continues, the constraint remains, and customers learn that your notices do not mean anything.
Set the date, communicate it, and hold it unless something genuinely material emerges.