You know those competitive analysis landing pages that every company now has – the ones with all the green check marks for all their features, and the glaring red X’s shaming their competitors for their lacking features? These charts say a lot about our relationship to features.
We idolize them. As product managers, building new features is core to our identity. Like engineers, we think of ourselves as builders: we add, we grow, we augment.
That’s why we rarely talk about removing features. No builder wants to tear down a wall in their house, and no deal was ever won for features you don’t have. But what if leveling that wall makes for a better layout, and what if that feature you’re “missing” is actually one that you removed to create a simpler and more usable product?
Each feature in product requires both maintenance and consideration: there is no free lunch. You should have confidence in every feature in your product, and if you find yourself second guessing that confidence, perhaps you’re staring at a candidate for removal.
How you know it’s time to go
- Obsolescence
This is the clearest and easiest reason to kill a feature. The most obvious indicator of obsolescence is, of course, lack of use. But some features are built for a particular specification or temporal event. As events and needs change, some features might become irrelevant. Legal developments are a good example; this is top of mind now with GDPR, which requires companies to prompt end users about cookies. Any product with an “optional checkbox” to enable this can now remove it — it’s no longer optional. You may find other parts of your product that codify law or policies that are outdated or no longer relevant, and it’s time to say goodbye.
- Architectural debt
Every once in a while, we have features whose very existence paralyzes our ability to advance our architecture. These features may use a code path relying on crappy infrastructure. If your engineers tell you that a single feature (or a small group of features) is holding your architecture hostage, it’s worth a look. Slowing down the pace of innovation or increasing the potential for instability in your product is FAR more important than any one feature.
- UX complexity
Apple is famous for removing things to drive simplicity (check out the book review of Jony Ive: The Genius Behind Apple’s Greatest Products). Most recently, the removals of the headphone jack and the ‘home’ button on the iPhone were an attempt to simplify the overall experience. Removing complexity also means changing our habits to adopt future-forward functionality, like when Apple did away with CD-ROM drives in our computers, pushing us towards using cloud storage. Ultimately you need to ask yourself whether any feature is actually needed to accomplish the user’s tasks. If not, explore removal.
How to kill features safely
Evaluating features from your perspective is only a first step in planning for removal. You’ll want to start going deeper on your analysis and communicating the intent to remove. This is work that could take days, weeks, or even months depending on usage. While Apple can simply remove a headphone jack on a new phone, you likely cannot take such drastic changes so abruptly. Here’s how you can kill features without feeling the hurt:
- Reach out to those using it
Go deep: get intelligence not just on which customers are using the feature but get names of actual users. It’s important to understand if people are just nibbling on the feature or really using it as part of their daily habits and jobs to be done. Look for in-depth interaction over a period of time (30-90 days). If it’s too sporadic or not recent, they likely aren’t using it.
Once you have a list of customers and users, reach out and interview them. Be direct. Tell them that you are planning on removing this feature. You need to understand how they are using it. More importantly, you need to understand the value they are getting from the feature. How would the removal impact their business, and in turn your own?
The goal here is to confirm your suspicion that you should indeed remove the feature and understand the impact, if any, to customers. Customers may provide important data that you hadn’t considered yet. In these interviews, it’s also nice to explore other solutions to their business problem that are alternatives to this feature. 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/roadmap for removal [OPTIONAL]
If your interviews went extremely well, you can simply remove the feature from the product. But, if you met some opposition, you’ll want to devise a roadmap based on the conversations, which will inform your communication.
- Communicate Internally
Once you have done your research and have a roadmap, it’s time to start communicating it internally that you’re planning on removing this feature. Invariably there will be a handful of individuals that are passionate about it. Be transparent with everyone. Share the data and solicit other customers that would be valuable to interview on this topic.
- Shut it down for new customers
Removal is real when you’ve turned off the feature for new customers. No new customers should even know it exists. Make this change as soon as you can in the process. It’s also good practice to remove the feature (even if still used by some) from all marketing collateral.
- Execute on roadmap and start migrating off existing customers
Based on your interviews, develop a plan for migrating customers off this feature. This may include building something new. Once the plan is developed, start communicating this plan to the remaining customers using this capability. Hopefully you interviewed enough of them to limit the blowback, but invariably there will be a few angry customers. Don’t fret; be confident in your plan and share the “why” behind your decision. Remember that you are ultimately removing this capability to make the product better–not worse.
Sometimes, less is more
Removing features is a powerful way to advance your product, but it requires fortitude and is rarely celebrated. The reality is that even if you start removing with confidence, you’ll likely add new features at a much faster rate. But removing helps you retain a clean experience: it’s products that boldly remove capabilities that are often the most loved over time.
Who’s to say that a feature added three or four years ago still delivers value to the user and customer. With the rate of change in business (and society), a couple of years can render a feature completely obsolete. What was once novel may now be a nuisance. I’d argue that removing features is equally, if not more important than, adding new ones. Anyone can add features, but only the truly great product managers can remove features with confidence.
