We all have regrets.
When I was a teenager, I had a friend who was a genius with all things technology. He gave me recommendations for my computer setup, developed websites as a side hustle, and was just an inspiring individual overall. Yet one day, I decided to not take him up on his offer to buy hundreds of Bitcoins for virtually pennies on the dollar. Instead, I wanted to spend my small paychecks on video games, dates, and the random pizza night rather than on what I considered “make-believe currency.” One invested paycheck would have resulted in a very different future. Thanks, past Josh.
The truth is that everyone makes mistakes and has regrets, and PMs are no exception. I’ve never met a product person who hasn’t kicked themselves over something they’ve managed and released. Some features can be underwhelming, overshadowed, or occasionally just bad. It’s a tough feeling, and if you’re the reason for it, it’s even worse. Imagine you have a baby who you decide would look great with a face tattoo. You’re about to make a big mistake and feel like a failure. PSA: don’t tattoo babies.
The important takeaway here isn’t to dwell on your feature failures, but own the honest criticism and make the hard decision: should I kill this feature? Rather than consider every aspect of killing features, let’s focus on three major themes: Assessment, Reflection, and Decision. By following this basic framework, you’ll be properly equipped to proactively make key decisions on whether a feature should be killed or bolstered. So grab a mirror and a pint of ice cream – it’s time to make some tough calls.
Assessment
First and foremost, why are we even talking about this? Why am I telling you to potentially kill features in your product? What if we’re doing just fine? Let me answer those questions with a simple one: Do you use every single feature on your phone? And I mean it. Every. Single. Feature?
Simply put, many features just don’t perform well. Products have a continuous growth cycle, and over time it’s realistic that some features may not be used as much as others. And you may already be fully aware of features that you don’t like. Passion and features go hand-in-hand. If you’re not excited about what you’re building, you’re more likely to ship something with problems. Or worse yet, you may become so excited about new ideas that you overlook older features, leading to gaps that reduce adoption and usage.
My most important piece of advice to you on assessment is this: let data be your guide. Tools like Pendo and Fullstory are incredible storytellers and will serve up red flags without much effort. How much time are people spending on certain pages? How often are users clicking this button? If you see these metrics start to deteriorate, find out why. Take product personas into account and learn why the value is faltering for those who should be using these features. Usage and behavioral dashboards are fantastic options in your toolkit. If you’re not taking advantage of them, you’ll likely find yourself blindsided.
Once you are starting to see trends of lower feature usage, try to dig in a bit. Talk to your colleagues and your customers to find out what’s going wrong and why. Review your wishlist and identify key themes related to asks around the feature in question. What’s missing that could make the feature more valuable? How many people want improvements in this area? How long has it been since we’ve iterated on this? Are we avoiding this feature in demos and onboarding? It’s quite the revelatory moment when you hear that your own company is purposefully avoiding talking about a feature, and even more so when you realize why that is.
In short, don’t be caught by surprise when someone starts yelling that a feature is worthless. Know it ahead of time and be prepared for some frustration.
Reflection
When it comes to reflecting on why a feature isn’t doing well, let’s start with a little tough love: get the excuses out of the way. Speaking from personal experience, I’ve both heard and used these same excuses early in my career:
- My leadership team rushed me to ship this feature.
- My developers were fighting over solutions and wouldn’t work well together.
- Other priorities constantly interrupted our progress.
- The prototype and beta feedback sessions were really positive.
- I was told to prioritize it, so I did.
These excuses and many more like them can generally be tied back to the product manager not setting proper expectations and possibly not pushing for the best outcome possible. It’s easy to get tunnel vision with the hard dates and positive words that imply that you’re building the right thing. Other times, you may feel like you don’t have a choice in the matter. The goal of this step is to stay unbiased, confident, and consistent (check out my other article on how to handle these issues within your day-to-day).
Outside of some of the more extreme examples above, you should also spend time reviewing your previous releases. Did you continue to iterate on the feature after its release? Did another feature end up solving the problem better than the original one? Why did your team prioritize this feature in the first place? Did we solve the right problem with the right solution? Take a look back at the value you’ve added since the original launch. Then use your assessment analytics to see where things started to fall off.
With all of that said, reflection is still an incredibly important part of this process. In order to make the best decision regarding the next steps, you need to consider your past mistakes. Understanding why something you own has failed is one of the hardest aspects of being a product manager, mostly because the result is almost always some form of blame. Instead of wallowing in self-defeat, I encourage you to embrace this problem like any other and learn from it. Your product’s success is tied directly to your own growth.
Decision
Now that you’ve found some problems and realized what you could have done better, it’s time to decide what to do next. You have three choices with regard to the feature(s) in question:
- Bolster the feature with requested improvements
- Utilize adoption tools such as in-app guides and monitor the impact
- Kill the feature
I know that this article is about killing features, but this doesn’t necessarily mean that you remove it entirely and wipe your hands clean of the situation. Small improvements and general guidance can do wonders here, as can general education and simple reminders. I’ve personally had a handful of moments where a conversation ended with me waving my arms and excitedly saying, “We can already do that!”
Yet there are rare moments when you’ll need to retire a feature, and these need to be treated as carefully and thoughtfully as possible. Here’s a basic checklist to walk through when considering truly removing a feature from the application:
- Has anyone used this feature in the last 90 days?
- Are prospects and customers still asking for this feature?
- Can I just hide this feature for now in case something comes up?
- Does this feature cause problems for my users?
- Should I replace this feature with another feature?
Removing a feature from your product is still a sign of growth. By killing unnecessary features, you can avoid feature bloat and user experience concerns while simultaneously removing the need to support seldom-used parts of your product. It can be scary, but it can also be a win-win situation.
Sometimes, you must kill your darlings
Like a rosebush, your product will occasionally need pruning in order to be its best. No one ever enjoys the conversation around killing features. However, it’s your job to be mindful of what’s working and what isn’t so that you can make the best decision for your product. As long as you are routinely informed and proactive, you’ll be able to stay ahead of what could be a ticking time bomb and ensure your baby doesn’t get that sweet face tattoo. If you’re following all the warning signs and the day still comes when a tattoo suddenly appears, be ready to remove it. And again, please don’t tattoo babies.
