How to kill off a feature to improve your product
We all get caught up with the constant drive to deliver more new features to our product. Customers demand better ways of doing things. Salespeople want new toys to talk about. Customer success wants to reduce customer complaints or requests. Engineering managers want to increase team velocity.
What this gives us over time is a product that gets bloated with features and functions, as it has many things put into it, but very rarely are they taken out.
That's what we're going to cover today - how to kill some features and get them out of your product.
Why kill features?
I know that it is easy to think that you've all worked so hard to get a feature out into the wild and in front of customers, but let’s be honest: are our customers using everything we've thrown at them?
As our products have evolved we've made decisions with the information we had available at the time, on features we wanted to introduce, but the world has changed. What was important for customers a year ago, might not be important today. What we thought was a priority when a group of customers demanded a feature six months ago, turns out is was only important for that group of customers and not for our whole user base.
This is fine. We do our best as product people in trying to work out what people want and why they want it. Sometimes we get it wrong. Sometimes people change their minds. Sometimes things just move on.
There might be times when we have a feature that might still be being used by our customers, but it is hurting our business in some way. Maybe some users don't get on with it and they leave. Maybe it's costing you money to keep it running (in terms of database usage, third-party costs, or just plain support). Maybe it's contributing to you cannibalizing your premium subscriptions because this free feature is too good. In any case, if it's not delivering the right value to you as a business then it's ripe for killing off.
When should you kill features?
If we have features that are no longer contributing to the core value that our product should be delivering, or if they are constraining our product’s ability to develop in the way that it should, then we need to perform a bit of product euthanasia and put it out of its misery, so the rest of the product can get on with its life.
Ask yourself:
How is this feature contributing to the value that my product should be delivering?
Who is using this feature?
Does this feature deliver value to us as a business?
If the answers to these questions are like the responses below, then it's probably time to pull the plug.
this feature doesn't now fit with our core goal
only a handful of users are using the feature
this feature costs us money to maintain
this feature means we can't do X in the future
Dave McClure is an advocate of "kill a feature every week", as this allows you to see who screams, and if they do then you've got an opportunity to bring it back again, but better, but you’ve got to be in a specific kind of a business to be able to cope with this devil-may-care approach to your users.
How do you kill features?
Once you've made the decision to put a feature out of its misery, the important thing for you to do is make sure everyone knows what you're doing and why you're doing it.
It pays to over-communicate in these scenarios, as you really don't want some of your customers to get a nasty shock, and it gives them a chance to provide feedback and potentially even invalidate your decision.
All stakeholders need to be notified of the change, not just your users, as you don't want salespeople continuing to include the feature in sales pitches, support documentation to keep referring to it, and finance people expecting to receive revenue from it. Be clear with everyone on what's happening, when, and why.
What's happening is important to consider, as you might be removing something relied on by some people, so you need to make sure that if there's data that will disappear that users have a chance to get their hands on it, if there's an equivalent that they can transfer to then you make sure that the process for transition is as smooth as possible, or if you're switching an old version for a new version then make sure you have the right levels of parity.
There are ultimately a couple of ways to go when it comes to killing off a feature:
Short and swift - switch if off, never for it to be seen again
Gradual transition - allow for the new feature to be accessed and monitor people transitioning over on their own, before making more enforced changes
I've worked with clients to transition them to new interfaces and the process has taken a year, as people don't like change. The process required numerous email communications, multiple in-app messages, and the ability to switch between interfaces to allow them to gradually get used to the new way of working. Even then, it took firm notification of deadlines to force the last few users over to the new way of doing things.
You cannot underestimate how much some people don't like change, so work with them to get to the place you want to arrive at.
Conclusion
When it comes down to it, we all need to trim out the fat from our products, so it's important to:
Identify what isn't delivering what you need it to
How you can remove it without causing major customer distress
The best way to transition the feature out of your product
By doing this, you're setting your product up to succeed in the future by removing its chains.