On Killing It by Killing Features

There’s a lot less written about killing features than about building them. That’s because building features is fun. It’s easy. It’s exciting. You get to go out into the world and say, “Behold! Here’s the feature that will solve all your problems, forever.” And if there’s one thing customers love, it’s having all their problems solved, forever.

But killing features is seldom exciting, easy, or fun. It’s something, like exercise, that we know we need to do to prevent feature bloat - but often, it's easier to put it off. Maybe it’s because it doesn’t seem like a priority compared to all the new things that need to be built. Or maybe it’s because there’s a risk that removing the feature could backfire and frustrate customers. Often it’s both. And that means that deprecating features is not something many of us have a lot of practice with. 

At HubSpot, we’re no experts at this - it’s a muscle that we, too, have been learning to exercise. But even if saying goodbye to features will never be exciting or fun, here are some tips to at least make the process a little bit easier.

1. Make the decision

These are four helpful questions to ask when thinking about whether a feature should be deprecated. The easier it is to answer these questions, the easier it will be to decide on a course of action.

How many people are using the product? 

It’s easy to make the decision to deprecate a feature that no one uses. For example, in the case of Spotify’s in-app messaging feature, the low usage coupled with the multitude of popular messaging apps that integrated with Spotify made retiring the feature an easy choice. But what if the feature is used by lots of people, but shallowly? Or by only a few people, but it’s a major part of their workflow? Both of these situations pose their own challenges, and merit their own plans of attack.

Who are these users?

If the feature's users are in a company's target market, or if they’re paying a lot of money, deprecating it might not always be the best decision. But if the functionality in question doesn’t serve the people you’re building for, it’s probably a good candidate for the guillotine. 

What does it cost to support it?

If costs of keeping a feature afloat are minimal, there might not be a pressing reason to remove it. But the costs of keeping seldom-used software running, like server costs and the salaries of the folks who need to occasionally help customers use it or fix bugs, quickly add up. Those costs should be kept in mind when balancing the trade-offs.

Can we fix it or make it better?

Sometimes, giving a feature the axe isn’t always the right move, especially if there are ways to increase usage and adoption, or if it's worth fixing the underlying tech. Look at the data and do some research. If those indicate that taking the time to make the feature a bit more useful, usable, or desirable will pay off (and there are resources to do so), investing in the feature might be better than removing it. 

It's often difficult to figure out the right time to remove a piece of functionality from your product. Keep in mind, however, that there’s usually opportunity cost for not killing a feature that's dragging a product down, because product debt can quickly turn into a quagmire that slows down the team and increases the complexity of the codebase. HubSpot's VP of Marketing Products, Nicholas Holland, has a useful framework for identifying and prioritizing product debt below:

2. Get comfortable with the decision

Okay, so the team has decided that killing a feature is the right thing to do. To keep the negative effects to a minimum, most solutions will fall into one of these two buckets:

1. Give customers something better instead
2. Help customers gradually wean themselves off

The first option is the best (but of course, not always possible). When Microsoft launched Windows 10, it announced that its long-running and much-maligned web browser, Internet Explorer, would be discontinued. But this was actually good news for Windows users, who would be getting Microsoft’s new, much more modern web browser, Edge, as part of the update. And while there was certainly some resistance to change on the part of longtime Internet Explorers, there’s no arguing that getting a new tool for your trouble is a pretty sweet deal.

Alternately, if a feature’s being deprecated because of tech debt or product bloat and there’s nothing better to offer, it’s sometimes easier to de-emphasize the feature before sending it to the gallows. One of the easiest ways to do this is to remove it altogether for new users, since they won’t know the difference. Similarly, it can be de-emphasized in the UI or the team can slowly remove little-used functionality over time. Weaning users off the tool will make the transition much easier.

3. Measure key metrics

When we overhauled our social media tools, we had the old version and the new one running in parallel for several weeks. This let customers check out the new tools and start getting used to using them, but also allowed them to switch back to the old UI if, for example, they needed to send out a tweet immediately and were more comfortable doing it in a familiar interface. 

Of course, we didn’t want to keep the product in that state forever. So we measured our user opt-out rate, or the rate our users switched from the new interface back to the old one, week by week:

We really wanted to get to a single digit opt-out rate before removing the option to switch back to the old version. Why single digits? Because it made sure that we’d addressed most of the concerns our users had with the new interface. It also meant that most users were comfortable using the new tools before we took the option to use the old ones away.

There might be a different key metric that helps determine when the right time is to pull the plug. Maybe it’s page views or the number of clicks on a certain button - only your team will know the right number to track. But exploring data will provide a huge amount of insight into the right time to take action.

4. Over-communicate the change

One of my biggest learning moments as a PM was when the cross-functional team I was leading at a previous company decided to deprecate a piece of functionality that was old, hardly used, and had a similar purpose as another part of the product. It seemed like a slam dunk. As it turned out, there was a company that relied on this data and they had no idea that this feature would be going away until it was too late. They were unhappy and ended up taking us to the court of public opinion. We just weren’t as well prepared to communicate the change as we should have been and three days after we took the feature away we had to press the big “undo” button. Lesson (painfully) learned.

Of course, a good communication strategy will be based on the size of the change being made. It’s not necessary to tell everyone in the world about the deprecation, but all of the key constituents need to know. This can include internal employees, like other development teams, support and account management teams, sales, marketing, PR, and finance. It can also include external stakeholders like agencies, integration partners, and of course, users.

Keeping the lines of communication open can increase how long it takes to get to the finish line, but it’s truly critical. Front line support and services have to bear the brunt of angry customers. Internal development teams and external integration partners might need to change their APIs to keep things running smoothly. Sales and marketing might need to know that this feature no longer exists in case they have to change their positioning. The product manager needs to make sure that everyone is armed with the facts. Knowing the timing and the reasoning behind the change will go a long way towards building trust with those stakeholders and helping the change run more smoothly.

And it goes without saying that it’s absolutely crucial to communicate changes to the users who will be affected by it. Rdio, a music streaming service that shut down in 2015, did a good job of this, letting users export their library and playlists so they could later import them into other music services:

Killing features will almost never be easy. Users will almost always feel some pain when the product they've gotten used to changes under their feet - but if a feature needs to go, it needs to go. With data, some considered thought about the user experience, and a solid communication plan, it’s entirely possible to minimize that pain.

So be brave. Cut away the cruft. You’ll be killing it in no time.