If you’re not making mistakes then you’re not making anything. Some features will be a win from day one, some need a few tweaks, some need a few weeks, but some just Don’t Work Out As Planned.
That’s okay. You’re guaranteed to make mistakes with the features you add, but you’re not guaranteed to recover from them. A common approach is to never mention them, pretend they don’t exist. Leave them sitting untouched and ignored by all but the most curious of users.
A different approach with the same outcome is to leave them anchored to the bottom of your prioritized roadmap. You talk about how there’s lots of “ways you need to finish it out” but there’s an unspoken agreement it’ll never happen. You’ll get to it on the 35th of Neveruary.
Unless you set out to build a bloated product the right thing to do is fess up and kill those features. Here’s how to do it with minimal customer impact.
1. Confirm the condition is terminal
If you know your product, and know your customers, you’ll quickly be able to evaluate this.
Here’s some questions you should be able to answer before committing to kill a feature:
What % of customers who can use this tool (i.e. it’s on their price plan, etc.) use it frequently?
What % of our revenue do those customers represent?
What attempts have we made to increase usage?
When we talk to non-adopters what reason do they give for not using it?
If we could go back in time, would we build or design the feature differently, or not do it at all?
If you can answer all those questions, and the answers don’t persuade you to give it another chance, then let’s proceed to killing it.
Now no matter how bizarre or misguided the feature, someone out there has built it into their workflow. XKCD has a great comic on this (above). The more people who depend on it, the harder it is to kill. Which brings us to step 2.
2. Stop offering it to new sign-ups
Stop adding to your problem. No one likes to have things taken off them, even when they had no plans for using it. So your first step to killing a feature is to add a feature flag (which if you progressively rolled it out you will have already).
From here onwards, new users do not see this feature. At the same time ensure it’s gone from your marketing site and not something your team still refer to, or use as a sales sweetener.
3. Divide users into two camps
If you launched this feature properly, you will have convinced a lot of people to try it out. The reason you’re killing it is because most people stopped there. And the reason you’re here reading this article is that it was only “most” people who stopped using it but definitely not “all”.
So your next step is split the usage into “real users” and “dabblers”. Let’s say it’s a calendar feature you’re removing. Dabblers might only have 1-5 events, and haven’t added/viewed them in months. Real Users will have lots of events and interact with the calendar on a weekly basis. Dabblers won’t even notice you removing the feature, real users will lose their shit if you break their workflow.
So let’s just hide it for Dabblers – worst case they notice a missing icon in the UI or navigation. You can be extra careful here and explain it, but it’s rarely worth the effort. You’ll end up writing a message akin to “Something that you never used is no longer there”.
Now we’re down to just the people who are likely to be upset: those who really depend on it, or really enjoy using it.
4. Announce end of life to remaining folks
To write a good explanation of what’s happening and why, you need the following ingredients:
An understanding of what they were using this feature for
A clear, consistent reason for why you’re removing it
A suggestion, or suggestions as to what else they can do/use that will solve their needs
Clarity about about how they can retrieve their data in a sane common format
It’s a nice touch if you have arranged easy transfers to other products which provide the same service, but such serendipity is rare (i.e. usually the users impacted are so few that it’s not worth another company spending time building importers for them).
Depending on the severity of impact you should decide how much advance notice you’ll give. Anywhere between a month and a year is typical, though longer will be necessary in some cases.
Your message to customers should have the following components:
Firm clarity of what is happening, don’t leave anything open to debate or speculation
A date on which the feature will be shut down
Sympathy for the interruption you’re causing them (they’ve come to rely on something you created, and you’re removing it)
Instructions on when and how to retrieve your data (if necessary)
Recommendations for how to achieve their goal elsewhere
Why bother?
It’s clearly more work to kill a feature than it is to leave it hanging around, but “What harm is it doing?” is not the mantra of a great product manager. Great products have a clear purpose. Features no one uses are the definition of use-less. So they must go.
Once you kill off older unloved ideas, fresh new ideas take their place. As Jason Fried notes, subtraction can lead to addition. Stagnant minds become open, bloated products become focused, confusing marketing sites become clearer.
As any sculptor knows, often art is defined by what you take away.
Comments