Sunsetting a Product Feature

Product Managers are inevitably fallible, and features you once thought would be something your customers would embrance, end up being ‘dead-wood’. That feature is not given nearly attention you have envisiged, and you decide to put it out to greener pastures. It happens, every company does it, big and small, like we just saw this week, when Facebook shut down it’s Parse services, but how does one go about sunsetting a product feature?

While the feature isn’t extremely popular, you still have certain number of customers using that feature, and you need to ensure minimal customer impact whilst also preventing your app from becoming bloated. Of course, to make sure your feature is indeed a candidate for deprecation, conduct the following:

Determining the feature is indeed ‘dead-wood’


Through your analytics tool, and feature metric-tracking, you should be able to assert how many users (as a percentage) use that feature, compared to the rest. If its a specific plan tier (i.e free tier), a specific function (i.e follow a user), note down the %. 

The percentage of course needs to be based over-time, rather than indefinitely, so set a baseline for what you determine to be frequently (i.e once a day, once a week, once a fortnight). The importance is you are looking for retentative usage metrics, not acquisition usage metrics


In addition to percentage of users, assert how lucrative that feature is as a percentage as well, over a specific period of time, such as a quarter or year. This will then allow you to determine firstly how insignificant the revenue is, and secondly, that the revenue is indeed falling over time.


You need to ask yourself, and more importantly, ask your customers why they weren’t using it. Send a Mailchimp survey, or within the app, ask your users a quick one or two question survey, which will help assess whether it’s due to function or awareness. This will also help answer whether you have done all you can to make the feature aware, or the feature in fact addresses a tangible customer need. 

If after those steps you determine that the feature should be deprecated, it should be done delicately, with minimal disruption, and maximum forewarning. You start off by not allowing new users (those who have just signed up or haven’t used the feature) access to the feature. 

For existing users, you then send out an email explaining that you are removing the feature, and why you are removing it, giving them ample time to backup or transition. Facebook with it’s Parse deprecation is giving its users up to one year to transition out. Ideally, you should provide them with a utility and guidance on how they can migrate out data from that feature, if applicable (i.e a calendar). You can also give those users some suggestions on alternative tools available that can solve that need, which in the case of Parse, Facebook recommended Amazon AWS or Microsoft Azure. 

So to summarise, ensure you provide a clear and concise message letting the users know: * that you are sunsetting the feature; * when you are going to sunset the feature (precise date), * why you are doing it; * alternative solutions; * migration guidance and tools for users to get out the data; 

Determining to sunset a product feature properly, with due diligence, and then managing existing user expectations properly, with clear and concise communication is key to deprecating a feature. If you fail to do it properly, you raise the prospect of users becoming disgruntled, unsettled and concerned that other features they rely on may fall unexpectedly as well. 

Loose the feature without loosing your customers, that is the key lesson!

Leave a Reply

Your email address will not be published. Required fields are marked *