How To Communicate A Feature Sunset
Removing features often causes anger among users. How to do it the right way.
As product managers, we are constantly striving to improve our products, innovate, and meet the evolving needs of our users.
Often, we fall into the trap of adding features as a default solution. However, there are also reasons to remove features:
Low feature adoption
Feature redundancy
Strategic shifts
Features do not solve the problem
In these cases, it may make sense to remove (or sunset) a feature rather than modify it or add new functionality.
Retiring a feature requires careful planning and execution to ensure a smooth transition for both your team and your users. In this blog post, I will explore the art of sunsetting a feature and provide a comprehensive to-do list for software product managers to successfully navigate this process.
Set up a default process
The first thing you should do is set up a standard process for sunsetting. This will help you follow the same process each time you remove functionality. Once you have a standard process in place, you will benefit from
Faster decision making due to standardized coordination
Ability to delegate to others on your team
Understanding within your organization of how to proceed
The best way to share the process is to write it down. Use a PDF, a Confluence or Notion page, or any other way you can easily share it with interested colleagues.
I also recommend including a diagram or flowchart. This makes the process easier to digest.
For internal and external communication steps in the process, define the appropriate channels: Slack, email, forums, or whatever you use internally. Use email, message boards, forums, paper mail, in-app notifications, blog posts, or social media to reach your users and ensure they receive the information.
Communicate early
Removing a feature will be very hard on the people who use the feature. They may be few in number, but they depend on the feature. To take them with you on the journey, do the following
Give everyone enough time to understand the impact and look for alternatives. It is often better to keep the product available for two more months than to remove it quickly and leave people without a solution. You will need to communicate with multiple groups of people:
Internal departments: Sales, Marketing, Support, Success, Training, and other departments need to know in advance that the feature will be removed. You may need to adjust messaging, create new marketing materials, stop inviting customers to use the feature, and so on. Start with internal departments.
Close partners: Sales partners, whitelabel partners, API consumers, and other close partner companies should be the next step. Their business or product may be affected, so they need a fair chance to adapt.
Only then can you inform your customers.
This means you need at least three separate moments of communication, unless you decide to separate the communication even more. When should you communicate? It is a good idea to work backwards from the time of the sunset. It can work like this:
Removal of the feature: October 1 (planned).
Customer notification: June 1st (= four months before sunset).
Partner notification: April 1st (= six months before sunset).
Internal communication: February 1st (= eight months before sunset).
The timing is up to you, just build it into your standard process.
How and what to communicate
First, do the recipients a favor and explain why you plan to remove the feature. Clearly explain the reasoning behind the decision and the timeline. This will go a long way: People will understand, empathize, and be less likely to complain. It shows you care about your users.
Show alternatives. This is one of the most important parts of your communication for all the people who rely on this functionality. What can they use to solve the problem in the future? It might be a different workflow, it might be a different alternative place in your product. It may be that the functionality cannot be replaced one by one, but a similar solution exists.
Lead your users to a solution! It may be another tool, a no-code integration, or even a competitor's product. Create comprehensive documentation, FAQs, or video tutorials to guide users. Establish dedicated support channels, such as a dedicated email address or chatbot, to address user questions and concerns quickly.
If necessary, offer the ability to save or export data to another service or their own hardware.
You can usually ease the pain by offering migration tools (if applicable) or discount codes for those affected.
Be sure to include the end of support date if it differs from the end of sale or availability date.
What comes next
This article is about communicating a feature sunset. However, after the announcement, you should do the following
Monitor the back channels to support, forums, or wherever people are talking about the sunset.
Monitor usage of the feature closely: It should spike as people want to know what this is all about. Then it should drop off as people move on to other solutions. If usage does not decline as quickly as you hope, you may want to consider delaying the sunset for a while.
Remember, a successful feature sunset is not just about removing a piece of functionality from your product—it's an opportunity to demonstrate your commitment to delivering the best user experience and optimizing your product's value proposition. By approaching the sunsetting process strategically and empathetically, you can strengthen your relationship with your users and position your product for future growth.
What I read
This is separate section of this newsletter. I will list some of the best articles I read on the internet. They may or may not be related to the topic of this article. I will keep a list of the best articles (currently >650) at https://www.digital-product-management.com. These are today’s picks:
The Art of Product Management: Why and How to Develop the Essential Human Skills.
Google course: Generative AI learning path: Content on generative AI products and technologies, from the fundamentals of Large Language Models to how to create and deploy generative AI solutions.
Metrics are answers. What are the questions? There's no point in tracking metrics unless they provide you with information on decisions or questions or goals.
Very helpful article! Great point to separate end of support from the sunset process.