A Methodology for Retiring Products

One of the biggest challenges I see product managers face in their career is killing features and products. Much of the product management literature and psyche on the web is spent talking about how to build new products. I did a quick search for “kill a product feature” in Google and noticed that only the top 6 results are about killing features. Most of those posts are spent paying lip service to the exercise with little guidance around how to do it. This signals one of two things for me. Either, product managers never kill anything or killing features is the least glamorous part of being a product manager. I’m inclined to think it’s the latter because in some ways it means that your original hypothesis for building the feature was incorrect and that can feel defeating. It doesn’t have to be that way.

Product management is about creating and curating great experiences for your customers. Otherwise, a product that never removes anything will be guilty of feature creep and bloat. To do a sunset properly, you’ll need to determine if your feature is ready for retirement, plan your timelines and execute with empathy.

Is it time to retire the feature?

Defining if the feature or product needs to be retired can be the hardest part. Ideally, before you’ve built the feature in the first place, you’ve created a hypothesis and defined success metrics for that hypothesis. Should the feature fail those success metrics, then the choice should be much easier. If you don’t have those success metrics, the hard part is going to be defining what a success metric should be. There are so many different questions that could be asked but these are one that I usually ask of myself:

• Does this product have strategic importance for the company?
• Can revenue be directly attributed to this product?
• Are we supplanting this product with another one?
• Qualitatively, do our customers understand how to use this product?

As a word of caution, you need to make sure you socialize the shutdown of a product within your company. Sometimes the biggest users of feature will be your co-workers and they have a direct line to you. This can cause a ton of problems if you don’t give them some advanced warning. Think of this as the pre-game warm up for shutting down this feature amongst your customers. You can test your messaging around why you’re doing it and how to do a migration.

Build a Timeline

We’ve got product that we need to kill. Now what? It’s time to put in the work to do all the pre-planning to make this process seamless. Every sunset that I’ve done boils down four critical dates, at a minimum; immediate shutdown for new users, start date of the sunset for current users, a soft end for killing the feature, and the hard end date for when everyone absolutely has to be off.

1. Immediate Shutdown

Turn the feature off to new customers that sign up for your service immediately. You need to stem the flow of new customers that will come to rely on this feature. This assumes that you’ve removed all of the subsequent discussion of the feature from all of your marketing materials and sales collateral. Don’t forget to tell your sales teams about the shutdown!

2. Start Date for the Sunset Process

This is the date that you want to formally communicate the sunset to customers. I’m a big fan of telling all users of your feature that it’s getting shut down regardless of usage. The last thing that you want to have happen as a customer is for something to get shut off without knowing about it. If you have product documentation, I’d actually recommend you keep the information about the feature in the documentation with warnings around when the feature will be sunset. Other things you’ll want to have:

• Migration path to the new feature, if there is one.
• Documentation on why you’re doing this.
• Recommendations for moving to another service.

3. Soft End Date

The soft end date is meant to be discussed openly and, from a customer perspective, the final date before the feature will be cut off. Inevitably, customers won’t read their email or they have their own priorities that don’t mesh with your timelines for sunset. That’s ok. Customers will reach out to you to ask for more time. Because we’ve built some slack into the schedule, your customers will be grateful. You’ll still have a set of customers that won’t reach out and at this point I usually assess the size of that population. If it’s small enough, maybe it’s worthwhile to reach out to them individually, maybe even by phone if this is a B2B product, rather than by mass email.

4. Hard End Date

This is the time when everyone has to be off. The product documentation is removed and everyone migrated somewhere else. Just like the time during the soft end date, you’ll have to do some outreach. Also, I’d recommend doing more for your customers. If you can do a migration on their behalf, do it. This will result in less product debt over time. I’ve seen sunsets where product managers tried to create forcing functions for people to move to new plans or product. I’d strongly recommend not doing this. Over time the migration will happen slowly but something will inevitably happen where you will have to force your customers to move over, it could be a security vulnerability or retiring infrastructure. It’ll be way easier to reduce your product debt immediately then having it hanging over your head.

Going the extra mile

The four dates I’ve defined are what you need at a minimum. Depending on the length of the sunset, I’d recommend a time interval to send out reminders for your customers. That regular cadence helps to remind customers that the time is coming for the feature to be removed. Do make sure you talk up the seriousness of the end date the closer you’re approaching to that time.

Execute with Empathy

Once everything is defined, it’s just time to execute the timeline. Depending on the seriousness of the sunset, you’ll get a number of customers writing in or taking their cause to social media. You have to be ready to handle this in the best way possible. I can’t stress how important it is to have all of your materials and messages built beforehand because you’ll have a ton of email and communication to do. Treat each one of your customers as a person. Even if the customer doesn’t use the feature that much or at all, they will still have reasons for not wanting to see that feature go. Sometimes those reasons can be emotional rather than rational and you need keep that in mind. Craig Kerstiens really sums up this concept really well.

Sunsets Don’t Have to Suck

Almost any product manager can build great experiences but the really good ones will take care of their customers and build great sunset experiences. I’ve found that there are far and few product managers that can do that. If you have a different take on how to do sunsets, I’d love to hear it. Let’s chat via email or twitter.