I killed product features to improve the product!

Before I dive into my murdering instincts 😆, let me cover the back story that led me to do a full feature audit to evaluate the product.

I’ve always paid a lot of attention to the initial product discovery phase, defining an MVP, and the whole build-measure-learn analogy. As product geeks, we are intrigued and satisfied by building new features. We think of ourselves as creators: we create, we add, we scale. That’s why we rarely talk about removing features.

But sometimes, it gets hard to keep up with changes in product strategy, dynamic external factors, shifting internal priorities, customer demand, and whatnot. You try adjusting to these factors and keep adding new features to stay relevant, competitive, and current in the market.

But it’s important to take stock, revisit old features and perform a feature audit- are all users using all features in the product? Of course not! I’ve learned it the hard way.

What’s my story?

In my case, the product had been in the market for approximately 10 years, is B2B, was underinvested, and was only in maintenance mode. During ‘maintenance’ many customer requests made it to the product and the user experience got cluttered over time. To make the product ‘usable’ and ‘simple’ again, I performed a feature audit and started with writing the vision and mission in BIG BOLD LETTERS. Here’s how it went —

The ‘Feature Audit’

I used a popular method to visualize feature usage by plotting all product features on two axes: how many people use a feature, and how often. The X-axis indicates the adoption of a feature and the Y-axis shows the engagement of the adopted audience.

I saw a trend like this one (thanks to Intercom) —

The legend I used:
Few of the people < 2%
Some of the people 2% to 30%
Most of the people 30% to 70%
All of the people >70%

The top corner was already the star, I needed an action plan for the rest.

After feature audit?

For any given feature with limited adoption, there are usually three main choices:

• Kill it: admit defeat, and start to remove it from your product.
• Increase the adoption rate: get more people to use it.
• Increase the frequency: get people to use it more often.

This story is about how I killed some features, so I’ll stick to it.

Why kill a feature?

Let’s talk about why should we ever kill a feature? There are many reasons that could act as a trigger to end supporting a feature. Here’s just a few:

• No usage (or barely any usage) over significant time
  This is an obvious one. If no one has used it over the last year (let’s say), it’s highly likely that it doesn’t add any value and your users are better off without it.
• It overshadows the core value proposition
  The best products are those which solve ONE specific problem and do it better than any other alternative. If your product’s core value prop is getting overshadowed by numerous other features, users won’t accomplish what they signed up for and they’ll walk away.
• It’s costly to keep up
  It’s important to factor in the cost of maintaining numerous features. Maintain the ones that make your product really shine. Having to support a feature that just doesn’t add to the big picture is a lot of time wasted.

How to kill features safely?

Evaluating features from my perspective was only a first step towards planning for removing them. And of course, I was very nervous about removing features as there could be one customer who is using it, but they may be the loudest! I wanted to go deeper, confirm my analysis and communicate my intent.

Talk to those who are using it

I tried to get an understanding of why some customers are using it. I could only speak to a handful of customers but I also reached out to external-facing teams (commercial, consulting, support) and tried to get their perspective. For the handful of customers, I managed to speak, I was direct and communicated my intent.

Some tips: If your customers are not accessible directly, you can try to launch a quick survey to get to the bottom of it. Be direct. Tell them that you are planning on removing this feature. You need to understand how and why they are using it. More importantly, you need to understand the value they are getting from the feature. It's important to understand how the removal will impact their business? Through the conversation, you may realize that they are trying to achieve some goals and your product may already have some alternatives to doing it. It may be the case that they are trying to accomplish a goal that the product wasn’t designed to do, hence the low usage. It’s possible you could replace the feature in a completely different way, and you’ll need to create a backlog to do this.

Create backlog for removal (if the opposition is strong)

If all interviews were the same, and you were not convinced with the value, simply remove the feature from the product. But, if you met some opposition, you’ll want to find an alternative of doing the job, or simply communicate that you already have an alternative way of doing it. In my case, no one cared about two of the features. However, I got some opposition for one feature. To be specific the feature allowed administrators to moderate a step. I didn’t see the value, nor were the end-users able to justify it. It was simply the case of — we have been using it for last 2–3 years and our processes are created accordingly. I went over and above to explain why moderation is not needed and it should be a self-serve step to increase the agility of your team. I pointed out some roll-back/version control features which can be used instead. It went well, at least I think it went well 😁

Communicate Internally

Once I was satisfied with my research and had a plan, I started communicating internally that I am planning on removing these features. Few things I kept in mind — the removal may impact internal teams. The support team may get many inquiries or commercial teams may get some heat. Make sure internal teams are aware and have a way to respond to the customers. Objection handlers or FAQ documents may come in handy here. Include details as to why was it removed, what’s the alternative, what to expect in the future.

Shut it down for new customers

It’s official when the feature is removed for new customers, and it is a safe step, to begin with. Plan in a way that no new customers should even know it exists. Make this change as soon as you can in the process.

Follow a phased approach, create a plan

For the customers who are using it, develop a phased plan for migrating customers off this feature. Phase 1 should be migrating the customers who did not create any objection in phase 1. Phase 2 should be targeted at migrating customers who showed some objection. Execute phase 2 when the backlog for providing an alternative is executed.

Execute the plan and start migrating off existing customers

Once the plan is developed, start over-communicating. Customers who are using it, internal teams who are responsible for selling, onboarding, training, or supporting should know about the plan.

Hopefully, enough to limit the blowback, but invariably there will be a few angry customers. Don’t worry; be confident in your plan and share the “why” behind your decision.

Lastly…

You know your product best. Remember that you are ultimately removing this capability to make the product better–not worse!

If you’ve found this helpful, share it with peers, and share your thoughts with me through comments.