Traditional Product lifecycle identifies four phases of Product development: Inception, Growth, Stabilization, and Decline. However, an alternative can be proposed. We believe that initially, the team will add features to launch and grow the product like there is no tomorrow (The product's "Big Bang"), then comes a phase of technical improvements ("Future-proofing"), and finally, a moment where the founder can contemplate removing features ("Maturity").
In today's article, we're exploring when to remove features and how to best perform this process. For some of the founders, this phase might be far away, but eventually, the product will be stable enough that the user experience will benefit not from another risky experiment but from simplifying the product. Let's jump right to it and pose the fundamental question:
When to remove features?
To add to the intro below, the phases listed are not mutually exclusive. There is nothing wrong in a situation where the founder issues new functionalities while removing old ones. However, in the initial fight for relevance and profit, there probably won't be any time to dedicate resources to removing anything unless it is vital to the product's survival. Only once the product's winning formula is found can the rest of the product align to fit the equation. Is there a sense in removing anything in the first place, as work done might benefit someone? Well, "The whole is better than the sum of its parts." Thus, when crafting a more final, user-friendly, easy, and responsive version of your product, you may find that some of the puzzle elements no longer fit. Thus, let's explore different scenarios when removing a feature is justified, starting with:
Low Usage
If data shows that customers rarely use a feature, then it's worth considering axing it. There are two reasons to do this in this scenario: Simplifying the interface and making it easier to find more popular options. But simplification is also beneficial under the hood! If the product's code has one less dependency and QA engineers have one fewer feature to consider when testing a new release, that saves countless development hours for more productive work. Since users don't use the soon-to-be-remove feature, it does sound like a win-win scenario. The best example here is the infamous Google Graveyard, with dozens of products killed due to low usage.
Negative Impact on User Experience
Now, all the arguments from the previous case still apply and have one more benefit: Improving overall user experience. Usually, this happens after a failed A/B test, but also, a once-popular feature may simply age poorly and, once beloved, may become hated. A scenario probably alien to any founder is when a feature is released, kept, and hated because of the insistence of corporate overlords. In that case, the feature is removed the moment a new management comes in with a different vision. A great example here would be Skype and its "Stories" feature mimicking the same functionality in Instagram. Not only did it never fit the communicator in the first place, but users hated it.
Archaic implementation
The technology develops every year and functionalities that used to be manual can now be easily automated. So, if you can solve a certain user problem automatically, without any user input, why bother with a dedicated feature in the first place? An example of a feature being removed due to advancements in automation is the Timeline feature in Windows 10. Microsoft axed this feature in Windows 11, as similar functionality became available through Microsoft Edge and other more automated solutions.
High Maintenance Costs/Performance Issues
Now, there may be a feature that is used, even beloved, but when it hurts product responsiveness or the bottom line, sometimes there will be no choice but to remove it. We predict that unless Large Language Models become cheaper to run, shortly we will see an AI backstep era, where lots of chatbot support will be removed from products due to high cost. Another great example is when Reddit introduced changes to its API. This was beneficial for Reddit in two ways: it managed to kill several free competitors that used its content but didn't provide Reddit-associated ad revenue. It also lowered the cost of running the API service, as it was no longer utilized as much. Granted, the API wasn't removed per se, but it's the next best thing that will come back to in this article.
Shift in Product Strategy
Sometimes products and features will be killed as the company changes strategy, vision or simply decides to focus on one thing and avoid distractions. An example here would be the "Trending Topics" feature on Facebook. It was initially designed to help users discover popular conversations across the platform, but it was eventually removed. This change was part of a broader shift in Facebook's strategy to promote community engagement and trustworthy news over viral content.
Regulatory or Compliance Issues
In some cases, changes in laws or industry standards can make a feature non-compliant, and removing it is the only way. A lot of video games had to remove "gambling-like" features when the regulators started pushing back on such an exploitation. Of course, this is a drastic example of a feature that would have come to be in an ideal world, but changing regulations can also affect less sinister elements of the product.
Technical or Product Debt
Now, some features may have been added with a very poor technical or user interface implementation. Rather than fixing or updating it, sometimes it is best to leave it behind and again, save countless development hours. Nothing is stopping the founder from reinstating the feature in a more state-of-the-art state, that will no longer jeopardize the product's technical health.
Security Concerns
This is a consideration that is growing more prevalent as time goes by, and both security and privacy are in the spotlight of any product. The cases where products had to remove features to protect their users were more akin to earlier Internet. A great example would be the situation where a system could tell a user if a certain email was registered or not on a specific site using a password recovery tool. While it doesn't sound as bad at first, it poses a significant danger to individuals in the context of unsafe sites. Journalists could probe the sites to uncover popular people using the site, while external bad actors could even register a popular figure on the platform to slander someone.
Better Alternatives
This case is mostly about when, due to different reasons, a company is running two versions of a product or feature at the same time and finally decides to focus on one of them. Just a few days ago, OpenAI announced that it would close its image generation engine, DALL E-2, and keep the newer DALL E-3.
Now that we have listed the circumstances that might lead to removing a feature let's figure out how to do it optimally.
How to remove the feature?
Well, there are only two scenarios: When your users will care and when they won't. Let's start with the second one: In such a scenario, when you have absolute certainty very few users utilize the feature and, better yet, your user base outright hates it, you can… simply remove it! In such cases, just include information on your update release notes, and that's that. You may want to organize a post-mortem meeting to understand what went wrong with a feature that at some point was deemed a great investment and how to prevent similarly poor decisions in the future.
However, if you are removing features that users rely on and adore, things become messy. The key to doing this successfully is giving users time to "cope with the loss." Make a public statement about the product, social media, and/or email about your plans to remove a certain feature and your reasoning for that. Include a timeline, ideally several weeks old, to allow the users to adapt to the new world without the feature in question.
Based on a few recent examples in the industry, you may also need to consider those quite troublesome additional actions:
Refunding users
This was the way that Google Stadia, Google's venture into cloud gaming, wasn't as bad as it could be. Google decided to refund every dollar users invested in the platform that promised to be there for the longest time. However, when Google decided to shut it down, it also meant that users would lose the games purchased in the dedicated virtual store. While players still lost progress and thus time on Stadia games, they at least got their money back, limiting the outrage. If the feature you are planning to remove also came with additional payments, refunding those might be crucial to keeping users' trust and the good name of the company.
Allowing users to download their data
Another example from Google: Before shutting down its social network, Google+ provided users with the option to download their data, including their profile information, posts, and photos. This allowed users who relied on the social network for their content to at least keep it once it was down. This uncovers the additional feature of removing a feature: you may need to issue development of new features to remove the overarching feature in the safest (PR-wise) way possible.
Pushing users to an alternative provider
You may decide users need certain features, but not wanting to support them yourself. That means you can partner up with a competitor and share your users for a much easier payment. This was a case with Samsung's cloud storage which closed and offered users to switch to OneDrive instead.
Closing words
Not all products make it a point where the founder can have the luxury of removing features. Of course, by this, we mean cases where it is a well-thought-thru choice, not a government-issued ultimatum. Regardless, we believe that removing features should not be seen as a failure. Doing so is similar to a blame game when something goes wrong with the product. Instead, it's about looking towards the future to ensure the product is in the best possible state and provides the users with an optimal experience.
