Think Build Implement Repeat
SaaS & Product

How to Retire a Feature Without Losing the People Using It

Last updated:

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

  1. 90 days minimum for anything customers use in their own workflow
  2. Individual contact with every active user, not just an in-app banner
  3. Explain why, briefly and honestly
  4. Offer the alternative, with help moving to it
  5. 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.

Frequently asked questions

How much notice is enough?

90 days for most features, longer for anything customers have built process around or integrated with. API deprecations generally need more, since customers have code to change.

What if a customer refuses to move?

Understand what the feature does for them. Sometimes there is a workaround; sometimes the honest answer is that your product is moving away from their use case, which is worth saying kindly and early.

Should we charge to keep a legacy feature running?

It is occasionally appropriate for a large customer with a genuine dependency, and it does not remove the maintenance constraint. Price it to reflect the real cost, including the drag on future development.

Can we remove something in beta without notice?

Technically yes if it was labelled experimental, and customers rarely read those labels. A short notice period costs little and preserves goodwill.

Keep reading

Maintaining a feature nobody uses?

Instrument it first — the answer is often surprising. Happy to talk through how to retire it without churn.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

SaaS DevelopmentCustom Software Development