9 Scary Signs You Should Kill a Feature

When a feature first enters the product backlog or is penciled in on a roadmap, it is full of nothing but promise. Perhaps you put it on the map because a customer requested it, a clever team member suggested it, or maybe someone noticed that it was being offered by a competitor. It was researched, specified, scoped, coded, tested, deployed and promoted. Press releases were issued, sales teams were trained, demos were created. Happy customers, increased sales, market parity, and “stickiness” were all part of the hopeful plan.Unfortunately, the best laid plans don’t always work out. That feature that everyone was initially so excited about doesn’t move the needle, it doesn’t get used, or it doesn’t really work all that well. And then you have to make the decision to throw it all away—which can be an incredibly hard move, despite all you’ve learned about “sunk costs” and rational thinking.But when it comes to the sellability, usability, and viability of your products, it’s essential to remember that quality trumps quantity every time. In order to be successful, you must maintain focus on doing the most important things right, and not just doing a lot of things OK. In other words, you’ve got to trim the fat.As product manager Liraz Axelrad says:

“Dead spaces in our apps are harmful. We should not let our apps become graveyards for failed ideas...apps get inflated over time because we keep adding stuff to them, so it’s doubly important to trim them down whenever we can. And it’s also important not to be afraid to make the call.”

With this in mind, there are plenty of occasions when a feature is ripe for culling during the product lifecycle. Here are nine signs it might be time to pull the plug:

1. Backlog Backburner

As a product manager, you’re doing your job when you take every random half-baked idea that might be interesting and toss it into your backlog. It’s not taking up anyone’s time and hey, you never know, right?You start reviewing your backlog and prioritizing things, that wacky idea gets pushed aside, life goes on. Rinse, repeat, rinse, repeat. Now every time you are reviewing possible features, this one has to be considered. It takes up space—whether it’s a sticky note on the wall, a chunk of whiteboard, or just your mental bandwidth. At a certain point, everyone knows this feature will never make it to the head of the class, yet it continues to linger.But while a feature may not have any feelings, the person who suggested it does — whether that be an overly enthusiastic salesperson or a well-meaning executive. But giving this feature a stay of execution just to avoid an awkward conversation isn’t helping anyone.Whoever requested the feature might actually think it will someday make the big time and be built, and it will continue to come up in conversations and meetings when there’s no chance of it ever happening. So make like Elsa and “Let It Go.”

2. Roadmap Roadkill

A roadmap gets a lot of use in technology companies, giving direction to customers, sales teams, engineers and project managers. It is one of the most important documents a product manager creates and serves as the PowerPoint version of their vision for the future.Many people see the roadmap not as a rough idea of what’s going to happen, but rather as a definitive path to the future with all of the accompanying expectations. These people may be disappointed or even angry when a roadmap item not only slips, but never sees the light of day.On the flip side, when an item is only at the roadmap level, it’s still a relatively cheap time to kill it off. Technical teams have spent little, if any, time on it, customers aren’t already using it, and salespeople can still tap dance their way around its absence.If it’s clear that the feature in question will be too tough of a technical challenge, chew up too many resources, or simply isn’t worthy of the investment, there’s no better time to say goodbye. Likewise, as market demands shift, there may simply not be the demand that was anticipated when you first gave it that Q2 slot.But now is also the time when you need to communicate that a feature is going on the scrap heap. Roadmaps (which should always be dated) should be updated, with the new version being circulated to all relevant parties as soon as possible. They should include a note that you’ve removed the feature, a brief explanation of why and, hopefully, let people know what you’ve slotted in its place...if anything.

3. Scope Shock

When you finally roll up your sleeves and get ready to spec your feature—creating use cases and workflows and sorting through the “What Ifs?” and “If/Thats?”— you sometimes discover that what seemed like a minor enhancement has turned into a major undertaking.There are plenty of times when it’s worth this level of effort to keep up with the competition or create a significant amount of new value for customers. But plenty of features only add incremental value while turning out to be way more complicated than anyone initially imagined.So before you open up this can of worms and spring it on your team, make sure it’s really going to be worth the effort. If not, it’s time to cut and run.

4. An Implementation Nightmare

“Yeah, this is going to require a database change.”“Turns out we’re going to have to re-architect the entire shopping cart for this to work.”“This is going to exceed our current license, so we’ll need to upgrade to the enterprise edition.”

These are just some of the nuggets that your technical team may bring to you during a feature’s development. In an ideal world, you would have been aware of these things before you started building the new feature, but things don’t always work out as we’ve planned. Sometime it’s not until tech gets under the hood and start tinkering that these conclusions are reached. At this happy juncture, you’re in the position of having to weigh the ROI of these added undertakings.

Will the additional costs/time spent/downstream impact of a far more involved implementation be worth the benefits this feature will bring? You’re still making an educated guess here, but everything in product management decision-making involves a trade-off.If you don’t think the long-term win is worth the battle, it might be better to nip this one in the bud before your developers are recoding half your product just to add one new capability.

5. A Testing Trainwreck

Not everything works. Or works the way you intended. Such is life.While it’s nice to figure this out during the design or prototyping phase of feature development, sometimes things don’t become apparent until your QA team has it running in a simulated production environment.Again, you’re faced with making the ROI-driven decision. How much work is it going to take to fix this so you can actually ship it? Is it worth it?

6. A Beta Blowout

Whether you run a formal beta testing program, give a few customers early access, or run some A/B testing, it’s ideal to get real-world feedback on your feature before it’s unleashed to the entire world. In a perfect world, when the reviews and inputs start coming in, you’re faced with lot of positives and only some minor tweaks and bug reports that can be easily addressed.Unfortunately, this isn’t always the case. It may turn out that you’ve really botched things up. The feature may not work. It may not make sense. Your users may not understand why they should be using it. They may not even realize it’s there.This creates another decision point. You can forge ahead, hold off until you make some improvements, or put it on ice altogether. But remember, this is the last time you can kill a feature before everyone gets a chance to use it. From here on out, your failure gets an audience.

7. #MarketFail

Your feature has been released. The marketing buzz and customer announcements have been initiated. Then, one of two unfortunate things have happened:

1. No one used/downloaded/installed/opened/clicked on your new feature. While this could be compensated for with some additional tactics to increase awareness and usage, sometimes it’s just a sign that people aren’t interested. At this point you need to consider a) doing a cost-benefit analysis and seeing if there’s a long-tail uptick in usage b) taking it off the market before it causes any more problems.
2. People used it and hated it. Whether it was a poor user experience, technical snafus, or it just held little customer value, the returns are in and they don’t look good. You’ve now got the opportunity to quickly yank the underperforming feature to minimize the negative feelings and limit its exposure to additional users. If people weren’t clamoring for this feature and it’s not generating the usage of revenue you anticipated, it might be the right call.

8. Dwindling Usage = No Seat at the Popular Table

Once upon a time, your new feature was one of the cool kids. It was popular, got invited to parties, and was used frequently by lots of customers. Over time, it found itself at home on Saturday nights and fewer people stopped by and said hello anymore. Now it’s ignored by almost everybody.That “almost” is the important variable in the equation. Even if a feature isn’t used by most of your users, are the feature’s faithful fans valuable customers? If so, you want to be careful not to upset or alienate them by nixing the feature altogether. In this case, consider minimizing the feature’s prominence while still making it findable.A potential exception to the above? When your unpopular feature is expensive to keep around, either because of actual costs, because it’s difficult to maintain, or because it can’t be supported on new platforms or coexist with a new framework and so makes future developments problematic. If this is the case and you need to say goodbye, try to figure out how to soften the blow to those loyal users, even if it means sending them to a competitor that is keeping that functionality around (yes, seriously).

9. Pivot Victim

Your app’s GPS-driven restaurant finder made sense when your company’s primary driver was curating the best chefs in the city. But now that you’ve pivoted your business model and are now delivering food from the top chefs to your users’ doorsteps, that mapping feature doesn’t really fit with your business model anymore.Those pesky map companies keep changing their APIs and the “Find a Restaurant” button is taking up some valuable screen real estate. But, you still see in the analytics reports that people are using the feature anyway. What’s a product manager to do?Look, your business has changed. The way you now make money is by delivering chow to hungry users. People who want to go out to five-star restaurants can find another way. It’s important to not let anxiety about change prevent you from focusing on those tasks that bring in revenue. We encourage you to wave goodbye to the old, hold a little parting ceremony if you must, and move on to better things.

The TL;DR: Tips for a Smooth Transition

• Before putting the kibosh on a feature, check with customer support, sales, and account management to make sure no one’s going to be surprised by the cut and that there won’t be any unforeseen complications. “How well your major feature cull goes down will depend on how you communicate the changes,” says ProductCamp London founder Janna Bastow.
• Inform customers (either key customers or the entire userbase) that a feature’s time has come. Give them ample time to prepare for the transition.
• Hold a retrospective to see what you’ve learned and how you can do it better next time around (RIP, old features.)