Topics include:<\/p>\n\n\n\n
- What is sunsetting a product?<\/li>
- What are the reasons why you\u2019d sunset a product?<\/li>
- What is the difference between sunsetting a product and a feature?<\/li>
- When is it time to sunset a product?<\/li>
- The phases of sunsetting a product<\/li>
- The 7 steps to sunset a product<\/li><\/ul>\n\n\n\n
What is sunsetting a product?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Sunsetting a product is also a process of testing and experimenting. It\u2019s not a rash decision and doesn\u2019t 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\u2019s the thing: if you remove a feature and no one complains, then it\u2019s all good. If you do remove the wrong feature, you\u2019ll 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 \u2013 if you follow our steps laid out below!<\/p>\n\n\n\nWhat are the reasons why you\u2019d sunset a product?<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
- Not enough customers use it<\/li>
- It\u2019s too costly to maintain<\/li>
- It\u2019s built on other technology<\/li>
- It\u2019s diluting your value proposition<\/li>
- It\u2019s blocking the effectiveness of another feature<\/li><\/ol>\n\n\n\n
1. Not enough customers use it<\/h3>\n\n\n\n
This is an obvious reason to sunset a product. Every company \u2013 no matter how popular or successful \u2013 has dusty, little corners of its app that no one uses. You can find these and clear them out.<\/p>\n\n\n\n
2. It\u2019s too costly to maintain<\/h3>\n\n\n\n
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 \u2013 they\u2019re 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\u2019t add to the bigger picture can waste a lot of time.<\/p>\n\n\n\n3. It\u2019s built on other technology<\/h3>\n\n\n\n
Sometimes a feature has high usage, but for technical, legal, or regulatory reasons, it must be sunset. Maybe the tech it\u2019s built upon has innovated and no longer supports your feature, or it\u2019s simply not worth keeping up. <\/p>\n\n\n\n
For example, a business metrics product that I used for years was just sunset because it\u2019s built upon Google Analytics. The metrics product didn\u2019t want to continuously upgrade to GA4 and whatever comes next; it was no longer feasible or desirable.<\/p>\n\n\n\n
4. It\u2019s diluting your value proposition<\/h3>\n\n\n\n
Some features might be confusing the reason that your product exists, which confuses your product value<\/a>. These features tend to draw the wrong types of users or take up valuable time of the right users \u2013 who end up using your tool in the \u201cwrong\u201d way.
<\/p>\n\n\n\nAs a product manager, you’re a curator. Your job is to curate the best features \u2013 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<\/a>.<\/p>\n\n\n\n
5. It\u2019s blocking the effectiveness of another feature.<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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\u2019t need to solve every problem. Instead, focus on the key jobs that your customers need to get done with your product.<\/p>\n\n\n\n
What is the difference between sunsetting a product and a feature?<\/h2>\n\n\n\n
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. <\/p>\n\n\n\n
In either case, you’re removing something that is no longer providing value for your business.<\/p>\n\n\n\n
Ultimately, sunsetting is part of your job as a product person. You need to curate the products in your portfolio \u2013 or the features in your<\/a> product \u2013 so that you’ve found the best mix that complements each other well. <\/p>\n\n\n\n
When is it time to sunset a product?<\/h2>\n\n\n\n
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\u2019t working or is past its prime. That\u2019s great, but it\u2019s 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:<\/p>\n\n\n\n- How is the product performing?<\/li>
- How many people are using it?<\/li>
- How much revenue is it bringing in?<\/li>
- How much development resources are being used?<\/li>
- How much customer support is needed?<\/li>
- What does this add to our value proposition?<\/li>
- What does this add to our strategic plans?<\/li><\/ul>\n\n\n\n
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<\/a>? Because if not (and maybe this is obvious), then your whole business will go under.<\/p>\n\n\n\nThe phases of sunsetting a product are:<\/h2>\n\n\n\n
Here\u2019s a quick overview of the sunsetting process:<\/p>\n\n\n\n
- Curiosity phase.<\/strong> Asking questions about whether this product needs to be sunset<\/li>
- Brainstorming phase. <\/strong>Generating ideas of what could change<\/li>
- Discovery phase. <\/strong>Conducting research and experiments, learning from prototypes<\/li>
- Communication phase.<\/strong> Giving your team and users a heads up, where applicable<\/li>
- Development phase.<\/strong> Beginning to make changes in the code \u2013 slowly<\/li>
- Measurement phase. <\/strong>Checking after the change, whether it\u2019s moved the needle or if anyone has noticed<\/li><\/ul>\n\n\n\n
We\u2019ll break down these phases into seven practical steps for sunsetting a product.<\/p>\n\n\n\n
The 7 steps to sunset a product<\/h2>\n\n\n\n
- Get internal buy-in for your end-of-life plan<\/li>
- Prototype and test your options<\/li>
- Put it into development with feature flags<\/li>
- Track it like a product experiment<\/li>
- Communicate to the team and customers<\/li>
- Document everything<\/li>
- Measure the results<\/li><\/ol>\n\n\n\n
Step 1. Get internal buy-in for your end-of-life plan<\/h3>\n\n\n\n
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\u2019s 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\u2019s pet project. Maybe it\u2019s 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:<\/p>\n\n\n\n- Be sure to frame it not as a loss, but as a curation <\/em>of your products. You aren\u2019t tossing stuff out, you\u2019re pruning the tool<\/li>
- Come ready with data and information about the feature \u2013 usage stats, how many resources it requires \u2013 so they can see how you\u2019ve come to this point<\/li>
- Finally, remind them that this is an exploratory process and not a final decision. Explain that you\u2019ll test it first and validate your assumptions<\/li><\/ul>\n\n\n\n
Step 2. Prototype and test your options<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
- If we were to remove this, how would that affect our user\u2019s workflow?<\/li>
- If we remove this money-making product, what would that do to our revenue?<\/li>
- If we remove that feature, does it make room for other stuff on the page? Do we need to change the way something looks?<\/li><\/ul>\n\n\n\n
And of course, you should check the assumption that people aren\u2019t using it because they don\u2019t need it. Maybe your users don\u2019t actually know about it! Always double-check if the feature is actually something you\u2019d want to keep.<\/p>\n\n\n\n
Step 3. Track it like a product experiment<\/h3>\n\n\n\n
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<\/a>. 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\u2019re trying and what you\u2019re learning.
Equipped with this information, you can push the work through to development.<\/p>\n\n\n\nStep 4. Development and feature flags<\/h3>\n\n\n\n
The next step is to remove the feature \u2013 not by deleting the code immediately, but by hiding the item behind a feature flag. It\u2019s similar to releasing with a soft launch<\/a> 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\u2019s right, you can lock in those changes \u2013 and then communicate and document them.<\/p>\n\n\n\n![\"Bringing](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2022\/10\/Idea-Archive-1-1024x705.png\")
<\/figure>\n\n\n\nStep 5. Communicate with your team and customers<\/h3>\n\n\n\n
- Be sure to frame it not as a loss, but as a curation <\/em>of your products. You aren\u2019t tossing stuff out, you\u2019re pruning the tool<\/li>
- Brainstorming phase. <\/strong>Generating ideas of what could change<\/li>
- Curiosity phase.<\/strong> Asking questions about whether this product needs to be sunset<\/li>