Feature deprecation doesn’t get a lot of attention.

Makes sense.

Most of us get excited about adding new functionality, not killing old features.

But there’s a small number of product managers out there arguing that feature deprecation is just as important as feature development.

And they’ve got a point.

Features that aren’t used cost money to support.

They complicate user workflows and risk distracting them from core tasks. And they can slow you down in taking your product in the direction you want it to go – where it’s solving the problems your users come on board to solve.

Vazgen Babayan is one of that crowd. He’s a senior product manager at Adobe and at ProductDrive 2021 virtual summit, he’ll be giving a presentation on “Less Is More – Why Killing a Feature Is a Good Thing!”

Treat Killing A Feature Like Adding A Feature

At Adobe (and previously Workfront) Vazgen has proven to be something of a serial killer of features.

He’s removed three whole areas of functionality from the products he works on and is currently working on a fourth.

His secret?

Treat deprecating features in the same way you treat adding features

Far from being apples and oranges, these processes are two different varieties of orange.

• When product managers consider a new feature to add, they think about how it will align with the overall vision for their product. They should do the same thing when thinking about what to remove.

• New feature development needs to be informed by comprehensive user research – interviews, feedback, close and careful analysis of behavioral data. So does feature deprecation.

• Both processes need careful planning, roadmapping and communication to users.

• There are direct costs involved in adding and removing features, as well as indirect costs associated with change management, user onboarding and training, etc.

• And both can have a big impact on profitability – by affecting revenue and costs.

Successful feature deprecation – that doesn’t end up costing you customers – depends on the same prioritization, collaboration and roadmapping efforts as new feature development.

And it needs the same product management tools – airfocus for example.

When Should You Kill A Feature?

One thing that’s important to stress again and again is that you should always do an in-depth analysis of your customers before deciding to kill any feature.

It’s vital to know exactly what problems they are using your tool to solve. 

So, examine in-app analytics, user feedback, exit surveys, etc thoroughly.

But also talk to users, particularly (as we’ll discuss later) two-way communication is a critical part of successful feature deprecation.

Once you have this understanding of customers’ Jobs To Be Done, you should begin to see the three kinds of justification for removing features (or “buckets”, as Vazgen calls them):

Download Now Our Ultimate Guide to Mastering Prioritization

The feature has missed the market

This means it’s not central to users’ JTBD and as a result, it is rarely used. Infrequent use is not in itself necessarily a reason to kill a feature – the reasons behind it are important.

Consider the following scenario: in your user feedback surveys you uncover a particular segment of users are not using a feature, but are asking for it to be added. Now, if you would have looked at usage only before deciding to kill that feature, you would’ve removed something that would have helped your users get their job done, when in fact, you had a feature discovery problem.

Analysis of the data plus user intentions will help you establish where the problem really is.

Similarly, it’s important to be sure about who the people who do actually use an underperforming feature are. If they make up your highest-value customers, killing the feature could be a very bad idea.

The feature solves the right problem for users, but it’s unsustainable

Although the feature deserves to be part of the product, it’s too expensive to deliver, the code base is unstable and causes bugs, it’s overcomplicated, etc.

For example Adobe’s suite of Flash-based tools, which were suffering growing compatibility and security problems, driving the company towards a new platform.

The problems were deemed unfixable, and the solution Adobe adopted is the usual one businesses opt for here: build and launch a replacement service in parallel with deprecating the unsustainable one.

“Unsustainable” here, of course, is relative.

If there is an amazing tool out there with similar features to yours that you can’t compete with, then those features are a candidate for deprecation. Think Spotify’s native messaging capabilities, which were eventually ditched in favor of integrations with more popular standalone apps.

The feature solves the right problem for users, but it’s not a problem you want to be solving

That is, the feature is useful but it’s not aligned with the product vision.

Take Workfront for example, a time management tool.

Its detailed time-tracking tools were deemed to be out of sync with their general approach to time management so they decided to kill the feature while suggesting third-party alternatives to users.

How To Communicate The Deprecation Roadmap To Users

Transparency is key here.

Indeed product managers should make the case for deprecation with as much thoroughness to users as they do to their executives.

And the product roadmap is an essential part of that communication strategy.

Two concepts are important to understand here:

• End of Service Life (EOSL): the date from which a feature stops being updated and supported, despite still being available.

• End of Life (EOL): the date upon which the feature is removed entirely – usually following a planned EOSL period, which may cover several release cycles.

Both need to be communicated to users (and fully understood internally, so that teams can support users) early and often.

Experts recommend over-communication around the removal of features, even if the feedback or questions you get back slow the process down. 

And communication should be multi-channel: in-app and contextual (slideouts, modals, etc), pop-up messages on login, email, via social media etc. This minimizes the risk of users being unaware when things change.

How To Wean Users Off Features You Are Killing

So you’ve analyzed data and decided it’s time to kill a feature. What now?

Here are a few things you should consider before switching the off button completely.

Remove the feature for new users

Even before a planned EOSL. New users won’t miss what they never had!

Always segment out and deal with different use case patterns separately, as they require different approaches.

De-emphasize the feature in the UI

This can not only provide valuable data about how important a feature planned for retirement is to users, but it can help reduce any sense of loss for those who don’t use it via the “out of sight, out of mind” principle.

Provide something better in its place

Perhaps this isn’t viable in every case, but it’s the best way to minimize disruption. A good example of this tactic was how Microsoft’s communications around the retirement of Internet Explorer were heavily focused on the advantages of its replacement, Edge.

Suggest alternatives and help users migrate

If you don’t plan on providing a feature in the future, your users who depend on it will appreciate recommendations on what to use instead. Indeed, it shows you care about their success even when it doesn’t benefit you directly (although, of course, winning trust in this way does benefit you).

Treat onboarding as an integral part of the process

As Vazgen says, “user training is part of the product”.

Will current users need to be retrained? Studying current user journeys will give you significant insight here.

In fact, it can be valuable to treat the deprecation as yet another user journey.

Map out every step a user would have to go through to get value from product v2 from their v1 state of use – and build your communications, cues and roadmap stages around driving affected users along that route.

And finally, keep analyzing your data and keep communication channels open.

Remember, just because you’re not receiving negative feedback about a change overtly doesn’t mean UX hasn’t been negatively affected.

If nothing else, a poorly communicated feature deprecation can be very damaging to users’ trust in you.

Download Now Our Ultimate Guide to Mastering Prioritization

Less Is More – Why Killing a Feature Is a Good Thing!

In his Product Drive talk, Vazgen is going to dig into these themes and more in order to show why killing features can be a good thing for your product.

At the very least, we’ve shown here how product managers need to stop treating it as something separate from and lesser than product development.