How to Deprecate a Feature
As product managers, we're responsible for driving the long-term success of our products. Many times, that means shipping new functionality to address customer pain points and to capture new market opportunities.
But, sometimes the highest-leverage action we can take is to remove functionality instead. After all, products can become bloated over time as they accumulate features, making the product harder to use, more expensive to maintain, and more challenging to innovate on.
In this guide on how to deprecate a feature, we share a clear framework for identifying when to deprecate a feature and how to deprecate it successfully. We also provide real-world examples of well-known product organizations that have skillfully deprecated features, and we discuss some exceptions to the typical deprecation process.
The feature deprecation framework
The feature deprecation framework has five key steps:
Identify low-usage and low-value features
Determine the costs of maintaining the feature
Analyze switching costs for removing the feature
Communicate the deprecation to users
Execute the deprecation and track results
Let's dive into each step in more detail.
Step 1: Identify low-usage and low-value features
The first step is to pinpoint which features in your product are not pulling their weight. These are features that are rarely used by customers and that don't provide significant value when they are used.
To identify low-usage features, analyze your product analytics. Look at feature adoption rates, usage frequency, and user journeys. Features that have low adoption rates (e.g. less than 5% of your user base) and infrequent usage (e.g. less than once per month per user) are prime candidates for deprecation.
But usage data alone doesn't tell the full story. A feature could have low usage but still provide high value for a specific subset of users or for a particular use case.
That's why it's crucial to also assess the value that each feature provides. Conduct user interviews, surveys, and feedback sessions to understand how users perceive and derive benefit from each feature. Features that users deem as unimportant, redundant, or frustrating are good contenders for removal.
When assessing a feature's value, consider if there are better ways to perform the same task, either within your product or through third-party solutions. If a feature can be effectively replaced with an alternative that's faster, more reliable, or less costly to maintain, that's a strong signal for deprecation.
Step 2: Determine the costs of maintaining the feature
Once you've identified potential features to deprecate, the next step is to quantify the costs of keeping those features in your product. Every feature, no matter how small, carries ongoing costs:
Engineering effort to maintain and debug the feature's code
Design effort to account for the feature in user flows and interfaces
Product management effort to prioritize and improve the feature
Support and success effort to help users with feature-related issues
These costs can really add up, especially for complex or expansive features. Work with your cross-functional partners to estimate the person-hours and financial costs associated with sustaining each feature.
In particular, pay attention to features that require disproportionate effort relative to their usage and value. For example, a feature used by only 1% of your user base but consuming 20% of your engineering team's time is a strong candidate for deprecation.
Also consider the opportunity cost of maintaining low-value features. The time and resources spent on upkeep could be better invested in developing new, high-impact capabilities that differentiate your product and delight users.
Step 3: Analyze switching costs for removing the feature
Before you decide to definitively remove a feature, consider the potential consequences and switching costs for your users and your business.
From the user perspective, assess how disruptive removing the feature would be:
Will deprecating the feature break key workflows or integrations?
Do users have viable alternatives to achieve their goals without the feature?
How steep is the learning curve for adopting those alternative solutions?
You need to be confident that removing the feature won't irrevocably damage the user experience or your product's value proposition.
If deprecating a feature would leave users without a critical capability, it's usually best to improve or replace the feature rather than remove it outright.
From the business perspective, forecast the impact that deprecating the feature could have on your KPIs and bottom line:
Would removing the feature put revenue at risk by churning paying customers?
Could deprecation hurt user growth by deterring prospective customers?
Is there a chance competitors could capitalize on the gap left by the removed feature?
The switching costs for your business need to be substantially lower than the maintenance costs of keeping the feature. If deprecation jeopardizes your product's competitive positioning or financial stability, you should explore alternatives like pivoting or revamping the feature.
Step 4: Communicate the deprecation to users
If you've decided that deprecating a feature is the right call, the next crucial step is communicating the change to your users. Your goal is to be as transparent, empathetic, and helpful as possible to foster user trust and acceptance.
Strive to craft an honest message conveying the reasoning behind the deprecation that speaks clearly in customer language they will understand. While customers may not always be happy you're removing functionality, they deserve a direct explanation of why it's necessary for the product's evolution.
Provide a clear timeline for when the feature will be discontinued and what will happen to any user data or settings associated with the feature. Give users ample lead time to prepare for the change - at least 30 days notice, if not more for business-critical features.
Most importantly, equip users with recommendations for how to transition away from the deprecated feature. Share alternative features or integrations they can leverage, and provide guidance or hands-on support to help them adapt their workflows.
Use every reasonable communication channel to notify customers, including in-app messages, email, blog posts, release notes, and direct outreach from account managers. The earlier and more frequently you communicate, the smoother the deprecation will go.
Here’s an example from Sourcegraph of a deprecation email:
Hi [name],
Over the last year, Sourcegraph has invested in building a managed version of our code intelligence platform for our customers. We did this in 2 ways: first, we developed a single-tenant, managed version of Sourcegraph, and second, we significantly expanded Sourcegraph.com.
After experimentation and great customer feedback, we have decided that a single-tenant version of Sourcegraph is the right solution for serving our customers. We are increasing our focus on this solution as the future of Sourcegraph Cloud, and as a result, we will also be returning Sourcegraph.com to its original purpose: searching open source code. You can read more about the changes in our blog.
This decision means we’ll be sunsetting some beta features on Sourcegraph.com, including personal repository syncing. On August 1, all clones of personal repositories (public and private) will be removed from the service. If you have any personal repositories currently synced to the service, they will no longer appear in your Sourcegraph account after August 1.
Sourcegraph.com will continue to host an index of over 2M open source repositories so that you can freely search the open source universe. If you’re interested in Sourcegraph for your personal code or for your company’s code, you can also run a local installation of Sourcegraph for free, or get in touch with our team to learn more about single-tenant Sourcegraph Cloud.
Thank you for being a Sourcegraph.com user!
Ryan Phillips
Product Manager, Cloud
And, here’s an example of the follow up reminder that they used:
Hi [name],
This is a reminder that the personal code beta on Sourcegraph.com will end in 1 week, on Monday, August 1. All clones of personal repositories (public and private) will be removed from the service on that date. You can read more about the change on our blog.
Sourcegraph.com will continue to be a place to search open source code for free. You will still be able to access your Sourcegraph.com account to create Notebooks, code monitors, and search contexts based on open source code for free.
If you’d like to search your personal repositories, you can also run a local installation of Sourcegraph for free for up to 10 users.
Thank you for participating in the beta and being a Sourcegraph.com user!
Ryan Phillips
Product Manager, Cloud
Step 5: Execute the deprecation and track results
With the prep work done, it's time to implement the deprecation. There are typically two approaches: gradual sunsetting or complete removal.
With gradual sunsetting, you phase out the feature over the course of weeks or months. You might start by hiding the feature from new users, then disabling certain capabilities, and finally archiving it entirely. This allows you to monitor usage and feedback and adjust your course if needed.
With complete removal, you eliminate the feature in a single cutover. This is faster but riskier. It's best reserved for features with very low usage that have been extensively tested for dependencies.
Whichever approach you choose, instrument your analytics to track the results. Monitor key metrics like user engagement, sentiment, and churn in the days and weeks following the deprecation. Be prepared to make tweaks or even roll back the change if you see severe negative impacts.
After the deprecation is complete, share back the results with your users and team. Celebrate the ways the streamlined product experience is unlocking new value. And capture any lessons learned to optimize your deprecation process for the future.
Real-world examples of successful feature deprecation
Several well-known product organizations have effectively leveraged the feature deprecation framework. Let's explore a few examples.
Slack
Slack announced in 2018 that it would deprecate its standalone Screen Sharing feature in favor of integrating with interactive screen sharing tools like Zoom and Cisco WebEx.
Slack determined through research that the vast majority of users preferred the more advanced capabilities of dedicated screen sharing solutions. Maintaining feature parity would have required substantial engineering work that was better spent elsewhere.
Slack gave users 30 days notice of the deprecation and provided clear instructions for how to leverage Slack's integration partnerships for uninterrupted screen sharing. And removing the redundant feature helped Slack deliver on its core value prop of channeling communication and collaboration, not fragmenting it.
Intercom
Intercom decided in 2020 to sunset Articles, its knowledge base product, and focus squarely on its Messenger offering.
Though Articles was well-liked by many customers, Intercom realized that the content management system (CMS) space was highly competitive and not aligned with its strengths. The costs of evolving the feature were better invested in Intercom's core conversational capabilities.
Intercom gave customers a 6 month heads up on the deprecation and assisted them in migrating their knowledge bases to dedicated CMS solutions. This tough prioritization choice has enabled Intercom to cement its leadership in the customer messaging market.
HubSpot
HubSpot announced in 2021 that it would be archiving its standalone Sales Chrome extension and consolidating its functionality into the HubSpot Sales Hub.
The Chrome extension had accrued technical debt and couldn't support more advanced sales acceleration features on HubSpot's roadmap. Bringing the extension's capabilities native into the Sales Hub created a more integrated, delightful user experience.
HubSpot provided in-app guides and walkthroughs to help users transition seamlessly to the Sales Hub, and offered discounted upgrade pricing. Streamlining its feature set has empowered HubSpot to deliver a market-leading "connected CRM" vision.
Sourcegraph
Sourcegraph, a code intelligence platform, deprecated its Sourcegraph.com personal code beta in 2020 in favor of a single-tenant cloud offering for enterprise teams.
After experimentation and customer feedback, Sourcegraph determined that a dedicated, managed instance was the optimal solution for their customers' needs. Supporting personal repositories pulled focus from this strategic priority.
Sourcegraph notified affected users 30 days prior to shutting down personal code sync. They offered an open source version of Sourcegraph for individuals still wanting to search their own code. Sunsetting the beta enabled Sourcegraph to double down on enterprise product-market fit.
Exceptions to the deprecation framework
While the feature deprecation framework provides a strong foundation, there are some situations where you may need to bend the rules.
Exception #1: When regulations or contracts require the feature
Some features may be necessary to include due to industry regulations or contractual obligations, even if they drive low value. For example, a telehealth app may be required to maintain a cumbersome patient verification flow to comply with HIPAA laws.
When regulations or contracts are at play, work with your legal team to explore workarounds. Could you tweak the feature to be compliant while still minimizing maintenance costs? Is there a chance to amend contracts upon renewal? Deprecating these features may not be feasible, but optimizing them usually is.
Exception #2: When the feature is business-critical for select power users
Sometimes a feature will have very low adoption rates overall but be absolutely essential for your product's power users. Deprecating it could risk severe churn amongst your highest-value customers.
In these cases, rather than deprecating the feature for everyone, explore ways to hide it for the majority of users while keeping it accessible for power users. This could look like moving the feature to a beta or labs section, providing it via custom UI, or even productizing it as a paid add-on.
Exception #3: When the feature can be re-platformed at low cost
Occasionally the benefits of keeping a feature outweigh the costs, but the feature's current codebase is unsustainable. Maybe it's built on outdated architecture or is a constant source of bugs.
Here, consider re-platforming the feature on a more modern, maintainable stack rather than removing it altogether. You may even be able to outsource the re-platforming to a contractor or automate it with a low-code toolkit. Just be sure to rigorously scope and cost-justify the effort to avoid tech debt sprawl.
Closing thoughts
Feature deprecation can feel like a daunting, even painful, part of the product management process. No one wants to take away functionality that users have grown accustomed to, even if it's not providing sufficient value.
But approached strategically, deprecation is an invaluable tool for reducing product debt, enabling innovation, and delivering outsized value to your users. By following the feature deprecation framework - and thoughtfully assessing when exceptions need to be made - you can streamline your offering and focus your finite resources on the features that truly move the needle.
Remember, every feature you remove opens up space for your team to ship delightful new functionality your users will love. Deprecation is not a sign of failure, but a signal of a maturing, ever-evolving product.
The next time you find yourself staring down a feature that has overstayed its welcome, return to this guide and walk through the steps with confidence. Your users and your business will thank you.
Thank you to Pauli Bielewicz, Mary Paschentis, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
