Kill a feature every week. When you kill the wrong one, people will make noise and you’ll be clued in to what actually adds value. — Dave McClure, FOWA 2009
How do you know which features need to be killed?
Every product that’s been around for some time will inevitably have some leftover feature ‘residue’: things that were built because they were easy to slip in, were built in reaction to a competitive move, were specific customer or user requests, or in general, just seemed like a good idea at the time.
There’s a whole pile of reasons to kill off a feature. Here’s just a few:
- No one (or barely anyone) uses it
If you were to remove this feature tomorrow, would anyone notice? If not, there’s a good chance it doesn’t need to be there. - It’s costing you users
Your users probably have very little time to sift through piles of options or user guides to figure out how to accomplish what they signed up for in the first place. If they can’t figure this out quickly and easily, they’ll walk away. - It’s diluting your value proposition
Your product should solve problems, probably a quite specific problem. It doesn’t need to do everything else at the same time. - It’s blocking the effectiveness of another feature
You might be unable to sell a premium package because something you’re offering in the free package is perfectly suitable. Or it might be as simple as having two features competing for attention at the same time. - It’s costly to keep up
You need to be able to focus on maintaining the features that make your product really shine. Having to support a feature that just doesn’t add to the big picture can add up to a lot of lost time.
How do you kill a feature?
Case Study: BraveNewTalent Relaunch
At BraveNewTalent, we recently had the opportunity to really dive into what was providing value and what wasn’t, and as a result, underwent a major feature cull. Having proven our market positioning and product as a prototype under the label of Beta, we rebuilt the majority of the platform, this time with a larger and cumulatively more experienced team.
The first thing we did was take a look at the usage data on some of our features. As it turned out, a few of these had barely more clicks than we had developers. It seemed the only time anyone accessed these features was us, to test them.
A couple of these made for great sales points (“Look at all of the cool stuff you can do!”), but weren’t really part of the core product at all. Knowing that we needed to up the ante on our entire code-base, but acknowledging that we weren’t prepared to rewrite and maintain every existing feature on the new architecture, we created a list of features to cull or to look at addressing later if the need arose.
The end result was a full relaunch, instantly removing a variety of ‘legacy’ features. Since that time, a number of these have been built back, but in better shape, while others were buried permanently.
Some of these features are missed, however, as we discovered afterwards – not necessarily from a usage point of view, but from the sales pitch. It was initially harder to sell the same product but with a fraction of the features.
With the major cull behind us, we now experience smoother development processes, a cleaner UI, and significantly less maintenance effort. It’s helped us focus on our core value proposition, both on our development side and our sales side, delivering and talking about what we do best.
Before you go slashing apart your product, create a ‘kill list’ of items you’re thinking you’d be better off without.
Get a second or third set of eyes on the paper, and discuss why you’d like to sunset each item. Most will likely be obvious, but be ready to talk about the cost of upkeep vs. the benefit of keeping a small fraction of your users happy, or whatever else you’ve got to qualify your call.
I hate to state the obvious, but try not to break anything else while in there. All to often, you’ll find that if you rip out one seemingly siloed feature, you’ll be left with residuals everywhere: Are there any broken links in a notifications boxes? Maybe some links to the page from external sites and internal user guides? Check that you’ve not left any tracking codes that were dependent on now missing pages busted, and that you’ve updated your documentation and homepage to reflect the change.
Talk to your developers, and have them help in determining what the fallout would be if you switched the lights off on a feature. Before making any moves, communicate the changes to the people who’ll need to be there on the front line, and arm your community manager with a list of defenses that will help protect them from the masses.
a) Cold turkey
If the feature isn’t really being used, you might consider just turning it off altogether. Going cold turkey on a feature that’s getting a fraction of your overall activity, let’s say a handful of clicks per thousand, might just do the trick. With this kind of usage, the vast majority of your users won’t notice, and the rest probably won’t care.
If you’re thinking that you will get called out for it, be prepared to acknowledge the change and justify it in ‘user-friendly’ terms. People can be pretty forgiving if you’re ready and willing to discuss why you’re shaping the product as you are…. and this generally acts as a great opener to tell the world about what you will be focussing on and launching in place of the killed features.
b) Wean them off
If you’ve got a more sensitive userbase, you might consider testing the waters with some of the features stripped, before removing them altogether.
Have a frank chat with your development team or tech lead about how you can go about removing something temporarily, if at all possible. If you haven’t already, consider getting your product set up with a Beta switch, allowing only certain users to see certain features.
Once you’ve removed the feature for a select few, judge the reaction, and if it’s safe to proceed, add more users to this pool, or kill the feature completely at this time.
c) Full disclosure
If you’ve made major interface changes to a well used product, seriously consider the type of backlash you will get, even if the changes truly are better. Every site gets
In all cases, be ready with a feedback mechanism of sorts, allowing people to report what they like (or more likely) what they don’t like about the change. Also stand guard over all of the social media streams you think are relevant. A lot of your feedback will come in the form of a tweet between peers, comments on a blog post somewhere, or, if you’ve really made a splash, in the form of a Facebook group gathering sign-ups in hopes you’ll change once they hit 1M members.
How well your major feature cull goes down will depend on how you communicate the changes.
What if it was the wrong choice?
Before acting rashly and rolling back that release, figure out what exactly is making you so sure that your initial decision to kill that feature so wrong.
Is it customer backlash? Was it the ‘pet’ feature of someone influencial in your company or userbase? Be prepared to chime in as the voice of reason. Assure the person why this was the right choice, and be ready to back it up.
Equally, be ready to admit you’re wrong. Perhaps you underestimated how useful something really was, or mismeasured its usage across your userbase. Perhaps usage was low because it just wasn’t being given the chance to shine – instead, it needs a facelift and will eventually make it as a core item to tout on your homepage.
Dieter Rams nailed this point with his 10th principle of design:
Good design is as little design as possible
This last principle focusses on creating less, but better – a take on the better known ‘less is more’ adage.
Comments 1