One of the most common pitfalls of product management is to never stop building and take a look back and see if what we’ve built makes sense.
I’ve seen way too many product teams get stuck with stakeholder requests, user requests, CEO requests, investor requests and all their roadmap looks like is building more and more features. What we often forget is that more features will not necessarily translate into more value delivered.
More features can sometimes actually cause the exact opposite.
Looking back to move forward
That’s why looking at what you’ve built - regardless if in the last sprint, last year or even 5 years - and deciding if you should keep it is an essential part of product management process.
A part that often, unfortunately, ends up forgotten.
Whether due to stakeholders that would get upset over its removal, forgetfulness and passivity, or due to the fact that as product managers we often get attached to our own solutions and have a hard time admitting to ourselves, or the world, that maybe it was a bad idea. Or a good idea at the time, but not anymore.
That’s why you should never fall in love with your solution, but with the problem you’re trying to solve.
That’s also why many single-use applications, like Instagram or Telegram, are super successful - they won against old school competition with their simplicity and limited features that solve a particular problem/pain point.
And to keep our products simple and understandable, sometimes we’ve gotta kill our darlings.
Why should we kill our products and features
There’s many reasons why, but the most important one is they don’t serve their purpose anymore.
There will always be a voice in your head wondering if it will cause damage to ‘take away’ a functionality from users, but if you’re making the right decision, most users just won’t care.
The first step to successfully killing a product feature is to actually accept it doesn't have a purpose.
Think about Blockbuster. They were renting out movies and video games to their consumers. It was a great and booming business, with a very clear problem that it was solving - enabling people to watch things outside of cinemas or scheduled TV, at their own time and pace.
But what they missed is a massive shift in the technology that can be used to solve this problem in a more modern, efficient and even more cost effective way. It ended up costing them the business and they went bankrupt.
With the revenue and market position they had, they could’ve been a massive video streaming service. But by insisting on keeping the same product offering in the 2000s as they did in the 80s, they failed.
Customer problems rarely change dramatically - it’s the way that they are solved that shifts and it’s what each company needs to keep an eye on.
It’s the same with your product - while it may fulfil a need and solve a problem now, some years down the line it might not be the greatest solution to the problem anymore. It might require a lot more than cosmetic changes and new UX, or a new feature added to it.
Besides the most obvious one, which is the lack of purpose and problem it solves, here’s a few more reasons why:
It doesn’t fit with the overall company vision or product stack anymore
If the direction your company has changed, or the target audience is now different, or your product stack has outgrown a particular functionality, just because it was always there doesn’t mean it should continue being there.
Every time you’re building something new, you are probably going through a process of defining how it fits with your companies vision and goals.
Whenever that vision changes, or at least shifts slightly, going through that same process for the features that already exist is a must.
It’s heavily underused by all user groups (like, Internet Explorer)
You’ve built it. Maybe some users even insisted on how much they need it. It’s out there in the world but nobody is using it. Across all different user groups, you’re noticing that it hasn’t really added any value.
Unless it is bringing in some PR, these type of functionalities are best removed, as well as to avoid cluttering your product and diluting the value proposition.
A few attempts at shaking things up and making it work have all fallen flat
You’ve blamed the positioning within the product. You thought it’s because of bad UX. You’ve changed copy. You’ve tried a different flow. You’ve sent messages telling users about it and explaining it. It still hasn’t moved the needle.
At some point it’s best to accept the fact that it’s not the execution that failed, but the functionality itself.
Check the stats - my rule of thumb is to judge if people even enter a funnel for a functionality and then get stuck within it, or if they don’t go to this functionality at all.
If it’s the latter, and even better positioning, naming and emailing users about it doesn’t help - then the root cause is far deeper.
Various data points, both from the usage and user interviews, show a lack of interest in it
This relates to the previous point - always check the stats to judge where exactly a feature is failing. Once you determine that, it’s easier to try and reposition it to see if that works out.
Running user interviews on it, especially with existing user base, will also help you understand if people are interested in it. If it’s a paid functionality, it might be valuable to test if the pricing is too high.
But if the answer just seems impossible to find, more often than not it’s because the value is lacking.
It is more difficult and costly to maintain than the value it brings
Extremely complex and maintenance-intense functionality, from both a support and tech standpoint, should always be looked at to conclude if their value is worth it. If you’re a bank providing a payment functionality which is robust, it probably is.
But if it’s a functionality that constantly causes maintenance issues, or makes it harder to build some other functionality due to limitations it brings it might best be left behind. Especially if it’s preventing you from building features with a higher anticipated value.
Keep in mind that when it is understanding that is failing, rather than interest in a functionality it might mean a different thing - that things were not explained and positioned properly and having another go at fixing it might just work out.
But if that’s not the case and users are genuinely disinterested - it’s time to move on and find a better solution.
FOMO is the main factor for doubt
I still remember a situation when a member of my team drastically changed a core feature. For weeks after it was released, we kept seeing the numbers in that funnel just dropping.
Then weeks went on and various excuses as to why this could be happening came up, none of them consisting of even the idea that what we implemented was just not superior to what we previously had.
And then when I mentioned it as an option that we could consider, that maybe the new solution is just worse than the old one I remember the look of fear that crossed their face.
And that’s the worst thing about the whole thing - being afraid that killing a feature means you’ve failed as a product manager.
There’s no failing if you learn from it. No product was ever built without implementing things that didn’t work, or didn’t scale. Or without experiments that just didn’t show good results.
Every failed and killed product is an opportunity to learn, to understand users and their needs better, and to grow as a product manager.
Most of the time, you’re not missing out on ways it could work, or a potential new target audience it could benefit, and just because it’s already there doesn’t mean that someday someone out there will use it.
So never be afraid of killing features or telling your team lead you want to kill features. Usually, it ends up adding value. As product managers we consider “building things” a part of the core of our work, but killing should equally be a part of that.
The main job of a product manager is not to build features. The main job of a product manager is to reach the goals that were set that are pushing the business forward - growth, revenue, stickiness or whatever other metric that brings value to the user and consequently, the business.
Just building and releasing features is not supposed to be a measure of success for us. And if we start changing that mindset, getting rid of features becomes easier.
