How to Sunset a Product Feature
Every feature you ship carries a hidden cost: code to maintain, bugs to fix, support questions to answer and a little more clutter for every new user. Removing a feature can be one of the best things you do for your product, but done carelessly it can anger your most loyal customers. This guide walks you through how to sunset a product feature calmly, from the decision to the final switch-off.
Key takeaways
- Decide with evidence: usage data, cost to maintain and how the feature fits your strategy.
- Talk to the customers who use the feature most before you announce anything.
- Give clear notice, a firm date, a reason and a path forward, such as an alternative or a data export.
- Switch off in stages, watch support and churn closely, then clean up the code and the help docs.
Startups are good at adding things. Each new customer request, sales deal or bright idea can turn into a new setting, report or integration. A year or two later, the product is heavier, slower to change and harder to explain. Sunsetting, sometimes called deprecating, is how you take weight back off.
Late June is a natural moment for this kind of housekeeping. Many teams are reviewing the first half of the year and planning the second, and a quieter summer stretch can give you room to run a careful wind-down before autumn launches.
Signs a feature should be retired
Not every little-used feature needs to go. Some are rarely used but important, like an annual report or an account recovery option. Look for a combination of these signals instead.
- Low and falling usage. Only a small share of active accounts touch it, and that share keeps shrinking.
- High maintenance cost. It breaks often, blocks upgrades to other parts of the system or depends on a third-party service you would like to drop.
- Support drag. It generates a steady stream of confused tickets or bug reports.
- Strategic mismatch. It serves a customer type you no longer focus on, or it overlaps with a newer, better feature.
- Security or compliance risk. Older code paths can be harder to keep secure and harder to align with privacy rules.
Score it before you decide
Give each candidate feature a simple score from 1 to 5 on usage, revenue linked to it, maintenance cost and strategic fit. A feature with low usage, low linked revenue, high cost and poor fit is an easy call. A mixed score deserves a conversation rather than a quick decision.
Common mistake
Looking only at the percentage of users. A feature used by a handful of accounts might be used by your largest customers, and losing even one of them could hurt. Always check who uses the feature, not just how many.
Plan the sunset step by step
Once you have decided, work through a simple sequence. Writing it down keeps product, engineering, support and sales on the same page.
- Confirm the decision and the owner. Name one person who owns the sunset from start to finish.
- List affected customers. Pull every account that used the feature in recent months, with usage levels and plan type.
- Talk to heavy users first. Call or email your top users personally. Learn what job the feature does for them and whether there is a workaround.
- Choose the path forward. Decide whether you will offer an alternative feature, a data export, a partner tool or simply a clear explanation.
- Set the timeline. Pick an announcement date, a date when new users can no longer access it and a final switch-off date.
- Prepare materials. Write the announcement, the in-app notice, the help center update and a support macro for common questions.
- Announce and remind. Send the announcement, then follow up as the date approaches.
- Switch off and clean up. Turn the feature off, remove the code, update documentation and close the loop with customers.
Pro tip
Hide the feature from new signups first. That stops the problem growing while you work with existing users, and it gives you a quiet test of whether anyone new even notices it is missing.
How much notice to give
There is no single right notice period. It depends on how deeply the feature is woven into customers' work and what your terms of service say. A small cosmetic option might need only a few weeks. Something customers rely on for daily operations, reporting or integrations deserves considerably longer, often a few months.
Before you set a date, check your own customer contracts and terms. Some business agreements promise specific features, notice periods or service levels. If you are not sure what you have committed to, ask a qualified legal professional. This article is general information, not legal advice.
Think about data
If the feature stores customer data, plan what happens to it. Will customers be able to export it, and in what format? Will you delete it after the switch-off, and when? In the UK and EU, data protection rules under GDPR shape how long you keep personal data and how you handle deletion, so check the current guidance and update your privacy notice if anything changes.
A feature sunset plan template
Copy this table into your planning doc. It works for a single feature or for a batch you are retiring at once. The dates, account counts and features below are made up for illustration.
| Feature | Accounts affected (example) | Reason | Path forward | Announce | Hidden for new users | Switch-off | Owner |
|---|---|---|---|---|---|---|---|
| Legacy PDF report builder | 42 | Replaced by new dashboards | New dashboards plus CSV export | 2027-07-01 | 2027-07-01 | 2027-10-01 | Product lead |
| Old chat integration | 9 | Partner API being retired | Email notifications and webhook | 2027-07-08 | 2027-07-08 | 2027-09-15 | Engineering lead |
| Custom theme editor | 17 | High bug rate, low use | Three preset themes | 2027-07-15 | 2027-07-15 | 2027-09-01 | Designer |
Write the announcement
A good sunset message is short, honest and useful. It answers four questions: what is changing, when, why and what the customer should do now. Avoid vague phrases like "streamlining our experience" without explaining what that means for them.
A copyable notice
Adapt this to your product and tone:
Template: feature retirement email
Subject: We are retiring [feature name] on [date]
Hi [first name],
We wanted to let you know early: on [switch-off date], we will retire [feature name]. You are getting this message because your account has used it recently.
Why: [one or two honest sentences, for example "Few customers use it, and maintaining it slows down improvements to the reports most of you rely on."]
What you can do: [alternative feature or workaround]. You can export your data any time before [date] from [location].
Need help? Reply to this email and a real person on our team will help you move over.
Thank you for using [product]. We know change takes effort, and we are here to make it easier.
Repeat the key details inside the product with a banner or notice next to the feature itself. Many people skim email, but they will see a note in the place they actually use.
Pro tip
Send reminders at sensible intervals, for example when you announce, about halfway through the notice period and a week before the switch-off. Each reminder should restate the date and the action to take.
Handle pushback with care
Some customers will be unhappy, and that is normal. Treat their feedback as useful information, not as an attack. Thank them, acknowledge the inconvenience and explain the reasoning again in plain language.
- Listen for the underlying job. Often a customer does not need the exact feature, only the outcome it delivered. Your alternative might cover that with a little guidance.
- Offer hands-on help. For key accounts, a short call or a migration session can turn frustration into goodwill.
- Consider a short extension. If a valuable customer needs a bit more time, a private extension can be fair. Keep it rare and time-limited.
- Brief sales and support. Give them a short internal FAQ so they answer consistently and do not promise anything you cannot keep.
Hypothetical example
Imagine Tomas, who runs a small project management startup. His team decided to retire a rarely used time-reporting screen. Before announcing, Tomas called the eight accounts that used it most. Two said they used it only to export hours each month, so the team added a simple export button to the main timesheet view. When the notice went out, those customers already had what they needed, and the switch-off produced almost no support tickets. (Tomas and his company are made up for illustration.)
Switch off, then clean up
On the final date, turn the feature off in stages if you can, for example for a small group of accounts first, then everyone. Watch support volume, error logs and cancellations closely for a couple of weeks.
Then finish the job. Remove the dead code and any feature flags, retire related database tables once data handling is settled, delete or redirect help articles, update screenshots in onboarding and marketing pages and tell your team it is done. A half-removed feature can cause as many problems as the original.
Common mistake
Leaving old help articles and marketing pages live. New visitors read about a feature they cannot find, and support pays the price. Search your site and help center for the feature name before the switch-off date.
Your feature sunset checklist
- Score the feature on usage, revenue, cost and fit
- List every affected account and identify heavy users
- Check customer contracts and terms for commitments
- Decide the alternative, export or workaround
- Set announce, hide and switch-off dates
- Write the email, in-app notice, help update and support macro
- Send reminders before the switch-off
- Switch off in stages and monitor support and churn
- Remove code, flags, data and old documentation
Frequently asked questions
Should I tell customers why I am removing a feature?
Yes, briefly and honestly. People accept change more easily when they understand the reason. You do not need to share internal numbers, but a clear sentence about focus, quality or cost goes a long way.
Can I just quietly remove a feature nobody uses?
If usage is truly zero, a quiet removal plus a help center update may be enough. If even a few accounts use it, tell them directly. Quiet removals that someone does notice tend to damage trust more than the change itself.
Should I offer refunds or discounts?
It depends on what customers paid for and what your terms say. If a feature was part of a paid add-on or a specific promise, consider a credit or refund. For general features, good migration help is usually more valuable than a discount.
Related reading
The bottom line
Sunsetting a feature is a sign of a product team that knows what it stands for. Decide with evidence, talk to the people affected, give clear notice with a real alternative and clean up properly once it is gone.
Pick one feature this week that costs more than it gives, fill in the template and start the conversation with your heavy users. Your product, your team and your future customers will all be lighter for it.
