How to Sunset a Product – Everything You Need to Know

Sunsetting a product is tricky. Product managers want to make the right decision for the business and not disgruntle any customers or stakeholders in the process.

A product – or feature – can have a smooth, seamless end-of-life with users, teammates, and management fully on board. How? Well, that’s what we’ll cover in this ultimate guide to sunsetting a product.

Topics include:

• What is sunsetting a product?
• What are the reasons why you’d sunset a product?
• What is the difference between sunsetting a product and a feature?
• When is it time to sunset a product?
• The phases of sunsetting a product
• The 7 steps to sunset a product

What is sunsetting a product?

Sunsetting a product is the process of phasing out and retiring a software or feature due to a lack of users, the costs of upkeep, or other business reasons. Also called the end-of-life, sunsetting occurs at the end of the product life cycle. The process involves research, experimentation with feature flags, and communicating the change to users, teammates, and other stakeholders.

Sunsetting a product is also a process of testing and experimenting. It’s not a rash decision and doesn’t have to be a final decision either. Sometimes people keep features because they’re afraid of rocking the boat too much or making the wrong decision.

But here’s the thing: if you remove a feature and no one complains, then it’s all good. If you do remove the wrong feature, you’ll hear about it from people. You’ll hear why the feature was actually valuable and what kind of use cases it helps to support. Then you can reverse the decision – if you follow our steps laid out below!

What are the reasons why you’d sunset a product?

The reasons you would sunset a product will largely depend on the specifics of your offering and business model. But here are five of the most common reasons:

1. Not enough customers use it
2. It’s too costly to maintain
3. It’s built on other technology
4. It’s diluting your value proposition
5. It’s blocking the effectiveness of another feature

1. Not enough customers use it

This is an obvious reason to sunset a product. Every company – no matter how popular or successful – has dusty, little corners of its app that no one uses. You can find these and clear them out.

2. It’s too costly to maintain

Sometimes a feature might get a fair amount of usage, but the costs of customer support or code maintenance are just too high. These features could even be popular with customers, but for the business – they’re a pain in the bum and sometimes quite expensive.

You should focus on maintaining the features that make your product really shine. Supporting a feature that doesn’t add to the bigger picture can waste a lot of time.

3. It’s built on other technology

Sometimes a feature has high usage, but for technical, legal, or regulatory reasons, it must be sunset. Maybe the tech it’s built upon has innovated and no longer supports your feature, or it’s simply not worth keeping up. 

For example, a business metrics product that I used for years was just sunset because it’s built upon Google Analytics. The metrics product didn’t want to continuously upgrade to GA4 and whatever comes next; it was no longer feasible or desirable.

4. It’s diluting your value proposition

Some features might be confusing the reason that your product exists, which confuses your product value. These features tend to draw the wrong types of users or take up valuable time of the right users – who end up using your tool in the “wrong” way.

As a product manager, you’re a curator. Your job is to curate the best features – creating the right ones and removing the wrong ones to build what the product needs to be, at this point in time and according to the overall product strategy.

5. It’s blocking the effectiveness of another feature.

Perhaps a feature in your free version is preventing people from upgrading to a more premium package. Or maybe you have two features that are competing for attention at the same time.

There is such a thing as a cognitive drain on your users! The cognitive overhead of a busy product will hurt your business. You don’t need to solve every problem. Instead, focus on the key jobs that your customers need to get done with your product.

What is the difference between sunsetting a product and a feature?

The difference between sunsetting a product and a feature is the scope of the impact on your users and the business as a whole. The product is, obviously, a standalone product within your larger portfolio, while the feature is a subset or function within a single product. 

In either case, you’re removing something that is no longer providing value for your business.

Ultimately, sunsetting is part of your job as a product person. You need to curate the products in your portfolio – or the features in your product – so that you’ve found the best mix that complements each other well. 

When is it time to sunset a product?

The right time to sunset a product depends on a few different factors, all of which require research, gut checks, and conversations among the team.

Most product managers can rely on their intuition to suggest when a product or feature just isn’t working or is past its prime. That’s great, but it’s not enough to know for sure! Instead, the PM should go about asking questions.

The questions you need to ask range from the micro to the macro. Here are some suggestions:

• How is the product performing?
• How many people are using it?
• How much revenue is it bringing in?
• How much development resources are being used?
• How much customer support is needed?
• What does this add to our value proposition?
• What does this add to our strategic plans?

The last couple of questions is important because they address the bigger picture of your product and your company. You should always evaluate this decision with the full context in mind.

On that note, whether you sunset a particular product or feature also depends on where your business is in the product life cycle. Is it clearly in decline? Are other products replacing it? Do you have something else coming into the maturity stage? Because if not (and maybe this is obvious), then your whole business will go under.

The phases of sunsetting a product are:

Here’s a quick overview of the sunsetting process:

• Curiosity phase. Asking questions about whether this product needs to be sunset
• Brainstorming phase. Generating ideas of what could change
• Discovery phase. Conducting research and experiments, learning from prototypes
• Communication phase. Giving your team and users a heads up, where applicable
• Development phase. Beginning to make changes in the code – slowly
• Measurement phase. Checking after the change, whether it’s moved the needle or if anyone has noticed

We’ll break down these phases into seven practical steps for sunsetting a product.

The 7 steps to sunset a product

1. Get internal buy-in for your end-of-life plan
2. Prototype and test your options
3. Put it into development with feature flags
4. Track it like a product experiment
5. Communicate to the team and customers
6. Document everything
7. Measure the results

Step 1. Get internal buy-in for your end-of-life plan

Raise the issue with your team as early as possible. You might discover there’s an important reason this product or feature exists! For example, it’s some regulatory thing that only the first developer, now CEO, knows about.

If not, then the task is to get buy-in from stakeholders, including those that might resist such a change.

How to get stakeholders to support sunsetting a product?
This can be very similar to getting buy-in for other product ideas. Talk about what it is that you’re trying to solve, why this particular thing has come up, and the research or data you have to support it.

But end-of-life buy-in can be trickier because some people might feel hurt. Maybe the product is someone’s pet project. Maybe it’s a feature an executive came up with in the early days, or that someone else coded single-handedly. And you want to kill it off!

Here are three tips for getting stakeholder support for sunsetting a product:

• Be sure to frame it not as a loss, but as a curation of your products. You aren’t tossing stuff out, you’re pruning the tool
• Come ready with data and information about the feature – usage stats, how many resources it requires – so they can see how you’ve come to this point
• Finally, remind them that this is an exploratory process and not a final decision. Explain that you’ll test it first and validate your assumptions

Step 2. Prototype and test your options

Start with simple designs like sketches or flow diagrams to imagine how the sunset would take place, and what your product will look like without it. Customer journey mapping and surveys are other ways to test and gather data.

Find out what this change would mean in different facets of the company, from customer success to business metrics to app design. Explore questions such as:

• If we were to remove this, how would that affect our user’s workflow?
• If we remove this money-making product, what would that do to our revenue?
• If we remove that feature, does it make room for other stuff on the page? Do we need to change the way something looks?

And of course, you should check the assumption that people aren’t using it because they don’t need it. Maybe your users don’t actually know about it! Always double-check if the feature is actually something you’d want to keep.

Step 3. Track it like a product experiment

All of these designs and tests should be tracked like any other product experiment. You could add it as an idea in ProdPad and link it to an initiative. Is your initiative to increase coherence within the product? Decrease support costs?

Tracking the sunset experiments allow you to define what you actually hope to achieve from sunsetting in the first place. Capture what you’re trying and what you’re learning.

Equipped with this information, you can push the work through to development.

Step 4. Development and feature flags

The next step is to remove the feature – not by deleting the code immediately, but by hiding the item behind a feature flag. It’s similar to releasing with a soft launch first. This allows for continued real-life testing in a safe environment. Because the code is still there, you retain a lot of flexibility in how you proceed.

If sunsetting turns out to be wrong, you can flip it back easily. If it’s right, you can lock in those changes – and then communicate and document them.

Step 5. Communicate with your team and customers

You should communicate with the wider team the same way you do during a product release plan. They’re already clued into what’s happening thanks to Step #1 when you introduce the idea to everyone. So at this point, it’s about realigning and providing updates and accurate details.

PRO TIP: Don’t forget to tell marketing!

As for communicating with your customers, this is an important step that could happen at different times. Exactly when or how you communicate the sunset to your users depends on your specific situation.

My general advice? Tell users as early on as reasonable. You could test with select customers first by telling them about the sunset plan. You definitely want to give people enough time to move off of it before you actually shut it down. 

Channels for communicating product sunsets to customers include:

• Emails
• In-app notifications
• Change logs
• Blog posts
• Even press releases if it’s really major!

Depending on the popularity of the feature, you might need to warn users multiple times, or it could just be in the release notes. Here is a great example of an end-of-life blog announcement from Microsoft sunsetting internet explorer.

Use your best judgment. If you don’t give customers the right amount of notice, they’ll be annoyed if you take away something that’s useful for them, and they’ll lose trust in you.

Step 6. Document everything!

This step is pretty self-explanatory. Documentation doesn’t mean just development logs and product management records, but also every touchpoint with sales, marketing, support, and customers.

You should get marketing, sales, support, and everyone else involved in this process, so they can update their processes, training, assets, and other documentation.

Step 7. Measure the results

As with anything product related, you should measure the outcomes to see whether the changes you’ve made have the expected impact – or any unintended impact. 

Has usage gone up in the other places that you hoped it would? Did the support team save time thanks to fewer tickets? Is the development team pushing out fewer bug fixes and generally less code related to this area of the product?

Take stock of the results, and log them in a product management tool like ProdPad.