End of The Road: How To Sunset Technical Products
Every product has a life-cycle, and products reach the end of their usefulness in the markets they compete in. Product managers have a few options. Companies can refresh them or deprecate those offerings. Unless you are a very enterprise company where the goal is to win Gartner for the year or you are able to sell support contracts to the tune of 5 times your support engineer’s pay. I am of the opinion that companies should aggressively cull unproductive features or rework them to deliver cohesive products.
Now, as long as we allowed managers to weld a reaper ax in the office, companies have been sun-setting products ever since the dawn of trade. A wood ax might make way for a shiny bronze ax. Flavorless gum might make their way to Turbo Mint Triple Fresh Gum(tm). It might not make sense for a company to be producing the same Christmas card printed with the year 1998 for every subsequent year. Just because I am cheap I might buy greeting cards from last year, and re-purpose them for the new year. That doesn’t mean that holiday card companies should cater to my whims. For digital products, it might not make sense that companies have to support aging platforms. Technical teams might have to move from a v1 API to a new v2. Or they might finally refuse to support Mac OS 9. When faced with these realities, what is a PM to do nowadays?
In this article, we will get into the reasons why you might need to move on and then making a good plan that fits with the scenario that a product might hypothetically face. Also, to really drive the point home. We will talk about product sunsets that have been done in the wild and discuss considerations for each strategy.
The Why
It’s an unfortunate reality that even the drywall in our very homes has a shelf life. As much as we want to make the same jokes all the time, we should bring them to pasture when the time comes. Ever-present diligence is needed to determine when or if at any time if we should keep on investing in specific initiatives. Sometimes, products keep their utility value at all times and never need to go away. Sometimes, the market moves on. These reasons usually shape our approach to sun-setting. They also inform how aggressive is the transition or if there is even one at all.
Before we even talk about a guide on how to, we must figure out why.
Technical Reasons
As long as there are humans, there will always be a shiny new framework or architecture to build on. It’s a good thing that technology incrementally marches towards the future. As we discover new and better ways to make word processors, some products will fall by the wayside due to progress. Sometimes, mistakes made in the past lead to dead-ends. These issues manifest themselves in different ways, for example, having difficulty to find FORTRAN developers for a dated codebase or the time it takes to add new features becomes longer due to poor architecture. PMs shouldn’t make the call to declare a sunset on tech debt, but these are issues you might see in the field.
Honey, We Broke The API
If an API follows semantic versioning, when a new feature breaks backward compatibility- you should declare a new version. This distinction is important because what a company does next in response is crucial.
Technical Debt Foreclosure
Popularized by Ward Cunningham of Extreme Programming fame. Technopedia defines Technical debt as a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
This leads to a catch-22. Speed and expediency take a front seat in certain stages of product development. Features needed to be shipped regardless of code quality. Products might succumb to a situation where the process of contributing to that product is extremely long and painful because of not paying down technical debt. At this stage, we should and reconsider our involvement.
When you have a team starting fresh. Companies might find their older, more sophisticated products that have a well-defined feature set are on paper inferior to version 2, where you might not be able to reach full feature parity. As someone who had to do a migration from Rails 2 to 4 back in the day- I understand if a band of engineers would threaten mutiny if told they had to maintain that code continuously.
Because Steve Said So
Companies that build on specific platforms are subject to the whims of their dependencies. If not enough work is done to keep those dependencies up-to-date, then those products usually aren’t fit to offer to end-users anymore even though they might still meaningfully provide value to end-users. (This is very common for acquired companies, where the product bought is not core to the business.) There are usually situations where it might take advantage of certain app stores on platforms, even if there are multiple ways to deliver a product to the same audience. Or even better, you used flash, and there is a grudge match happening between two CEOs.
At this stage, companies should evaluate how critical the product is to the portfolio and the amount of staffing available. The technical debt usually means that engineering and product teams can generate a plan where a transition can be made seamlessly. But in a few cases, if you have one engineer overlooking a graveyard where you have little to no users, you might just pull a Google Plus instead.
Market Capture Reasons
We sunset because sometimes, Products don't get any traction. Although we don't get into what traction means in a unique case. Sometimes, its best to leave stuff by the wayside.
A Pyrrhic Victory
Congratulations, you won the market. Now the market is irrelevant because users didn’t want handhelds with a dial-up connection port. In a never-ending quest to get product-market fit, we sometimes don’t exactly know what customers want. Occasionally, we win games that have no reward at all. People who make products sometimes aren’t in tune with the cultural moment, or they don’t see where the wave is headed. They might have paddled too early and were too tired for the wave when it arrived.
No Capture
Sometimes we compete and lose, it happens. There is no fault in trying, but there is a fault in continuing to invest in things that don’t work. If there isn’t enough return on investment or there are competitors that are too nimble or entrenched; concede. Still, sometimes we approach markets where customers are stuck in their solution and can’t leave (more common in the enterprise market), or the new solution isn’t compelling enough to attract users away from the existing offering to be worth it at scale.
Refocusing/Spin-out
A product that does too many things not well enough might not need to say goodbye but might have some of its feature set trimmed down to serve the needs of its users better. In a macro sense, sometimes a company might be doing too much where it doesn’t have the credibility or know-how to execute on that model properly. Or it might make sense to increase adoption by spinning out a feature into its own product or app in its own right to increase adoption. Instagram by Facebook spun out Boomerang initially out of fear of too much feature creep.
Mergers and Acquisitions
Big Company A decided to give slightly Bigger Company B one product that they had in their portfolio because it didn’t make sense that Big Company A was in the cooking business. The ball is on Bigger Company B’s court to rebrand or absorb the product. My favorite is when they buy and then delete the product, R.I.P HipChat.
One no, leading to 1000 yeses
A big customer who needs support for a legacy tool is the barrier to progress. This is more of a customer handling issue- but sometimes companies need to fire bad customers.
Consider The What That Will Be Sunset
Products and features (I have a bias considering features to be their own products in their own right, that’s another post) can be ranked on a scale of how critical they are to your end-users. No longer distributing a toy beer drinking app isn’t the same as announcing a deprecation to an essential on-prem box that may serve government clients. Subtly so, a password manager feature within a browser might not be as important as a password manager product sold as part of an enterprise software suite. Even though products might be similar, the audience that they serve might delay how quickly you can perform a transition. The reason why we spent time on the why is because, the way how to handle a customer during a corporate shakeup is different than spinning up a beta version of a new app to prepare for the old one being deprecated.
Each product life-cycle is much different than each other. Hardware devices massively vary and might be limited to the expected lifespan of what components are offered in the supply chain. (Good luck trying to source 8088 chips at scale nowadays efficiently.) Where, depending on adoption, sometimes unit economics work against you if you don’t have many users. This is especially true for Multiplayer games, where it is common to shut off multiplayer servers if you don’t have enough usage. Speaking of metrics.
A good rule of thumb is, for very critical applications, the time you give for notice for a transition is depending on if customers can keep up with your timelines to move forward. Or you can set up incentive structures to make it so that there is an economic motive to encourage migration to a newer version of the product. It’s common for Operating System vendors to follow this model.
As applications move down the spectrum of importance. You need to consider the drawbacks of migration or deprecation. This is where things branch.
If you are discontinuing a product, if it’s an enterprise offering- you might want to message market alternatives and offer a migration path. Especially if you fit within an ecosystem of products. Doing so will keep your customer base happy and engaged with you even though your company will no longer be solving X for them. (This may vary, ceding market share is a strategic choice) Data Portability might be a big issue. The crux really comes into play if its a migration or End of Life.
For consumer apps, if there were in-app purchases, you might want to consider a potential refund policy. Or maybe a potential offering where you can offer pro features until the end of the application. A great example are the infinite amounts of iOS photo editing apps who believe they can switch to a subscription model.
If you are migrating to a new version of a product where it might not be as simple as running an updater tool. Consider the disruption in workflow and actions that they might have to undertake. How will you message this to the end-user?
Caveats
User patterns on enterprise products might be obscure; it is very much possible that your box running in the corner has been working fine on a company’s intranet, not speaking to the vendor’s servers. Keep in mind that reporting programs are a tiny sliver of usage for some products.
Unique vs. general trends. One jarring pattern coming from observing consumer products to working in the enterprise market is the fact that you could offer a product and be genuinely surprised at the ingenuity on how customers use it. Many times, a feature that shipped that was supposed to address a perceived need actually filled a more critical gap instead. For enterprise users, these products tend to be a significant part of their workflow, so PMs must understand what solution are they really delivering.
You will need to research the activation energy of a consumer to move and migrate to a product. Sometimes customers will use this time to evaluate alternatives. *cough* HyperV Hypervisor to VMWare*cough*
A Hypothetical How and a Timeline
So you measured twice and looked at the data. We are going to jump into some hypothetical examples where we make some timelines. I will introduce 3 fake products that we will design high-level transitory programs.
Window Management App on a new OS won’t work anymore and will be sunset, with no replacement offered by the developer.
A Keynote Presentation Software is announcing Keynote Presentation Software 2, complete rewrite, but reduced feature set
The Social Media Company is announcing that its Meme Generator is going away being replaced with a New Photo Editor. All meme features are supported.
Keep in mind, these scenarios have different goals in mind. Setting our north star is vital. Winding down usage isn’t the only goal. There are secondhand effects that are felt when a company chooses to revamp its products or says goodbye altogether. Redesigns might open up opportunities for competitors, or lead to increased frustration.
All these examples will follow a pattern.
1) Determine the impact
2) Figure out who needs to be notified
3) What actions need to be taken
4) Apply it to a timeline
5) Execute
So for the first example, let’s assume the APIs that the developer we’re using is no longer supported in 3 months in the next release and won’t have a replacement. This app had a creative implementation of the API, so the OS vendor didn’t see fit to give enough warning. Let’s consider this has been run as a hobbyist venture. After the developer takes a moment to shake off the terrible news from the OS vendor’s dev conference, she gets ready to move forward with winding down the application.
Window Tiler
The first step is to determine the impact; usually, if there are more stakeholders involved- this will add more time to the timeline. If it’s an app that serves multiple personas, you’ll need to make sure that every type of user is served. Luckily, the window tiler only has one persona and that is people just wanting to tile their desktop windows. She will want to make sure that all 10,000 are notified. The more users involved, often the process is more complicated. Due to the sunset driven by forces outside her control, she has little to no choice but to keep this in line with the OS vendor. It seems like due to the tight time-frame, many actions will have to be compressed. When working on a timetable, taking this as a chance to survey what needs to be done is a good idea.
The second step is to come up with a communication plan. We need to message the incoming sunset with the justification. Since this is a hobbyist developer- there is no sales team to reach out to. There probably isn’t significant in product notification infrastructure in place. Updating the store listing, a few social media posts, and adding in a product warning should be good enough. Since customers upgrading to the new OS version will be explicitly affected, they should be notified just in case they want to keep using the software. After when she surveys the distribution channels of the product, she updates the store description, telling them about the impact and ships an update with a popup and messaging in the product to mention the effects.
The third step is to assist with customer impact if there are customers who just recently purchased her product. To hear this news must not be the best. She offers refunds for those who bought in the last two weeks and immediately stopped sales. However, staying sales isn’t enough- the software is working perfectly fine as is. She puts a 3-month software support window in place and offers to continue patching the software until it hits its EOL.
Most of these actions are done as soon as possible on the timeline. She continually notifies her user base whenever possible through email lists and updates.
This scenario is mostly straight to the point, small product with sizable users. Just one developer and her customer base. Now, let us see when there is a migration that gets a bit more complex.
Keynote Software
Keynote Presentation Software is a niche but rapidly growing presentation software. Recently they have been multiplying, but they want to expand to other platforms, and it suffers from too many features. They are making Version 2 that will primarily be delivered by a web-app and a cross-platform desktop application- namely, they want to switch to a subscription model.
Unlike last time, the time table isn’t as straight forward. There are a few business decisions that need to be made. Do people who paid for a perpetual license of the product get version 2 for free? How much would it cost to support those customers? Can the company neglect its old users?
Then, you want to determine the feature gap. Understand that users might be ready to jump onto version 2 unless there is the same amount of needs met, and it needs to reach them effectively. The PM looks at their dashboard and notices that some animation features are going neglected, and it would take too much time to maintain. This might be an excellent opportunity to cull some product cruft.
Since this is a pretty mid-sized company, Sales and Marketing need to get some ample time to communicate the new product but also announce the end of support for the old product. Sales need to craft some demos for customers, marketing needs to prepare for messaging a transition.
More-so, you need to determine the end-user impact. What about customers who are midway through making their application. What about backward compatibility? What is in the roadmap that will excite customers to move to the next version? End of the day, companies are rewarded on how well they solve problems.
Knowing this, you can make a timeline. You have a few options. Release Version 2 as a beta while still supporting Version 1. Maybe offer free access to version 2 until all the features that are highly requested get parity. You can take advantage of early adopters in your user base and get early feedback on what is essential to your users.
Then you can incorporate that feedback in the transition.
The PM decides to announce Version 2 with the new features to drum up hype and support. The comms team recommended that the new licensing data is messaged in a separate article not to dampen the good news. This kick starts the timeline for release. After research, you decide that keeping the same file format is essential, but customers need to be clearly kept in the loop about what features are coming or going.
Then you can follow through with your messaging and customer impact mitigations. Keep in mind as a PM, you will need to sell the story and talk to customers. They see through your lies, so make sure you walk the walk in your roadmap and clearly set any expectations. If features are there but implemented differently, have documentation to show how to do it with New vs. Old, maybe have some built-in In Product Guidance or New Product Experience.
Notice how as the company grew and how larger the undertaking, more considerations are added to such a sunset plan?
Now, let’s switch gears to a consumer product.
MemeSoft by The Social Network App
The Social Network Company has MemeSoft in a certain app in it’s portfolio, a built-in Meme Generator that will be going away to a New Photo Editor. The features will still be there- but Meme Generator accounted for most of its usage. Because the company wants to expand the type of content posted on the platform beyond memes, it will be de-emphasized.
Its a little different, it isn’t a strict product migration but there is expected to have significant disruption to end-users. Anything pertaining to redesigns can be a crucial point for a company. Facebook, for its profile page, had 4 significant redesigns that I can recall. Snapchat had 3, one was significantly derided. We will still be thinking in terms of the timeline. Yet, instead of having to think about the business operations like enterprise companies mostly operate in, we will talk about the general audience of the product. The rise of “lean” product thinking means that users are more accustomed to change and more open to it than business users.
Consumer apps have different expectations where you can change things up without much lead-in time, and if things don’t break user numbers won’t fall significantly like SaaS apps. But, if customers don’t find the UX enjoyable or aren’t able to get the utility value that they expected. It’s much easier for them to convince their friends to leave with them. It’s one of the reasons why musical.ly hasn’t changed its design fundamentals and made all the changes mostly under the hood with its algorithms as the product matured.
You can get creative here- maybe provide metric-driven roll-outs. If The B with the new camera works out, you can then roll out to other users? Maybe have A/B/C versions with the end-users. Not every company has the infrastructure to experiment continuously. But the stakes are much lower for these applications.
The company, in this case, decides to roll out the feature initially. The PM of the feature monitors the usage data for three months to determine long-running feedback to make sure that the initial press and usage aren’t only affected in the short term. Engineering and design have a welcome video and popup to message the new flow to the user. The new in-product tutorial with pop-ups let people know where the old photo editor was along with introducing new features.
Metrics Metrics Metrics
Most of this examples have robust roadmaps that will be acted upon from user feedback or company vision. We brushed on metrics slightly, but you should have some meaningful metrics that should be tracked ALWAYS. If you are expecting a deprecation- you will hope that the old product will see numbers drop steadily. If it is a product part of a portfolio, usually, you want to make sure that the product doesn’t affect user numbers in other products. It would have been terrible for Adobe if removing Fireworks meant that all customers stopped using Creative Suite entirely. Luckily for them, Photoshop had significant feature overlap already.
If you are hot-swapping a feature- you might have metrics like time to action or the number of clicks it might take to get to a new feature. We won’t talk about methods of how to influence that, but more so guide you on how to view that product interaction.
Keep in mind how you design your sunset matters. If you have two competing features running in parallel, those readings might not be terribly accurate. What usually works in this case to segment your users in cohorts and then run a test in each sample size as you are testing the expression of your features. This article isn’t focused on experimentation, so we won’t dive too deep into it. If you just takeaway one thing from this section is- don’t track too many things.
Good things to measure are customer sentiment and how well a product fits into their workflow. Sometimes if you have done it right and have a product that already fits, some work will be needed to be done to ensure a smooth transition.
You might want to set up metrics to track feature differentiation, for example, you might have a new product split a feature that used to do two things at once, but now it’s something separate. Tracking feature expression is something that can inform if the transition went well.
More often than not, you perform a sunset as mentioned to trim the fat. Check out user growth before and after to see if the new focus of the product was able to spur adoption. And remember, you might not always get it right the first time around. There are many times where companies have gotten it wrong and walked back timelines that the user base wasn’t ready for.
As your metrics start to plateau, you can use it to inform your actions on how aggressive your migration can be. Start with carrot and transition to stick, but once you are near your deadline, start enforcing a strict deprecation guideline. But if you need more time, always feel free to add it.
This metric should be in line with your product if you are working on a password manager, then time to log in would be the most important. But your assumptions may vary.
Some real-life examples
Now, the execution of products varies often. I always like to supplement ramblings with real-life examples. As a terrible history student doomed to repeat the past, sometimes, we should try follow the few great examples we have. Here are some quick case studies.
Turning the Valve
Sierra On-Line (A Game Publisher) got into a dispute with Valve Software over the licensing of its games at internet cafes. Upon the release of the highly anticipated computer video game Half-Life 2, Valve later rolled out its own DRM software that doubled as a download manager called Steam. It mandated that all Valve Software games had to move over to a “Steam Powered” version to enable online play. It was a highly unpopular move. Internet downloads weren’t exactly fast in 2004, and users protested by switching to pirated versions of their multi-player offerings. They allowed users to use the old versions of their software for up to a year until Sierra shut off their server discovery tool. However, over time, there was a vast roadmap that took customers on a journey for what valve felt was the future of games and social. It improved on its nascent Friends support, eventually adding user-profiles and achievements like their console competitors. Then, the infamous Steam Sale was added to its web-store. (Discounting games up to 90 percent) Since computer video games were headed to digital anyways- the sun-setting of Sierra On-Line lead to the creation of the most popular and profitable PC gaming store thus far, reviving a platform that was declared dead many times by business journalists in the face of video game consoles. Valve Software used a stick first method but was able to sustainably grow its business into one of the largest and most beloved in the world. The mention of “The Steam Summer Sale” is enough to get people ready to shell out their money.
Last Set
The year is 2014, Windows 8 was a disaster and Microsoft is reeling from image issues that stemmed from poor management and market mistiming. Satya Nadella was just named as CEO of Microsoft after leading the Server and Tools division that had a nascent upstart called Azure. Shortly after, he does the unthinkable- announces Office for iPad. Around the same time, the upstart calendar Sunrise is making its rise. A beloved calendar app, its mobile-first design makes it the choice for busy professionals everywhere. Microsoft buys it to revamp its Outlook product on mobile for 100 Million USD. Over some time, it runs independently, this gave Microsoft time to incorporate the product and the engineering teams to work on the revamped Outlook app. When it was ready, it announced that Sunrise will be sunset. Although initially controversial. Concurrently, the new Outlook for iOS was published- and it was well-received. Microsoft gave it’s self the time it needed to make its own offering mature with the expertise it received from the acquisition.
I know I haven’t talked about APIs in practice, but one example I felt that is well managed is Zeit’s Now from v1 to v2.
Delta Operations
Zeit is a developer-focused company that offers a serverless runtime to developers to build production-ready services on its platform. It enables a few things, 1) pay per use functions that can be lower cost than running an instance 2) Offer an instant deployment model where it’s quicker and more comfortable for developers to ship code to. However, it’s a new and nascent field where assumptions change quickly. Now v1 made an assumption that everything will run in a container. However, this proved to be costly and didn’t scale very well. They’re engineers designed a native code runner that would allow users to be better billed on their use. So they announced a v2 API that wasn’t as feature complete but will be left alone until it’s time to sunset the API. In the meantime, its engineers are free to answer any questions near-real time in their spectrum chat to support the needs of its customers.
Final thoughts
There is no “right” way to sunset a product, but there are definitely wrong actions to do. There are some themes here- remain committed to solving a problem accurately, minimize negative impact, and make sure that in the long term, the transition is a net good for the user. Most of all, have fun.
If you liked this article, please clap.
Hailing from Miami, Florida — Angelo Saraceno holds a Bachelor’s degree in Computer Science from Florida International University. He is a Product Manager at an enterprise software company. He spent his time as a undergraduate working in entrepreneurship circles, and traveling the country learning about what it takes to build successful teams and businesses. In his spare time, Angelo enjoys salsa dancing and thinks soccer is the most beautiful thing on this Earth. You can find him on Twitter @ndneighbor. He’d like to know that his DMs are open to chat about killing features.
