Can You Create Value by Not Building Features?
Most product teams measure progress in features shipped. I spent a year proving the opposite: we cut the product's scope by about 25% and grew Day 1 retention by over 20%. Removing underperforming features, not adding new ones, is what moved the metrics.
At the beginning of 2021 I took ownership of a legacy mobile app that shows personalized news on the lockscreen. Over the years it had built a strong presence, mainly in Latin America, with over 8M daily active users getting news from leading publishers straight to their lockscreen. The team had been consistently launching new features, and none of them moved our KPIs. "The product's potential is capped" had become common wisdom in the organization. That is the ultimate frustration for a product team.
Then QA found a bug that only appeared when users switched their device language to Hungarian. I was surprised the app supported Hungarian at all. I was more surprised to learn we supported over 36 languages used by a combined 0.9% of our users. Rather than fix the bug, I suggested we remove the redundant languages and see what happened. Nobody complained. What we did not expect was that the app got smaller and performance improved. Which raised the obvious question: what happens if we remove more?
Why is it bad to keep an underperforming feature?
Because the small group still using it costs you the attention of everyone who is not. The 1% who use a weak feature will suffer from neglect, and by definition they should be the least of your worries. Your problem is the 99% who never understood the feature in the first place, and who now navigate a product built around exceptions.
The excuses for keeping it are always available: the team worked hard on it, a specific customer asked for it, analytics show a handful of users are finally adopting it after five years. Deep down you know it is not strategic, and you know you cannot justify investing in it further because it will not move the needle. That is exactly the moment where keeping it starts damaging the product.
What do underperforming features actually cost?
There is a direct cost and a much larger indirect one. The direct cost is usually visible but rarely measured: a minor bug here, a small fix there, and the hours pile into days and weeks that could have gone to work that matters.
The indirect cost is the one that hurts. The biggest is the loss of strategic focus, which makes the product harder to sell, longer to implement, and slower to adopt. On top of that sits maintenance: every improvement, refactor, or external change you make has to stay compatible with the features nobody uses, so each one quietly taxes everything you build afterwards.
How do you find the underperforming features in your product?
Use the same prioritization framework you use for new work, and run it in reverse. The decision is hard because it is emotionally tied to how much the team already invested, which is textbook sunk cost. A scoring framework is what gets you past that.
At Taboola we used ICE, scoring initiatives 1 to 10 on Impact, Confidence, and Ease, and comparing scores across the backlog to set priorities. The same frame reverses cleanly. These features are already live, so you have far more confidence about the impact they are not making, and R&D can estimate how complex each one is to remove. Gather your stakeholders and let them argue with the ranking. What you end up with is a prioritized list you can work through from the bottom up.
Where are underperforming features usually hiding?
Outside the golden flow, the path along which users actually get value. Three places are worth checking first:
- Settings. This is where things built "just in case," or for one very specific request, tend to collect. The question is whether those use cases are frequent enough to justify their existence. Your analytics, support tickets, and feature requests in that area will tell you.
- Legacy customers. Look for custom-built features made for old accounts. Are those customers still active? Do they still represent your core segment?
- Analytics events. Pull the events with the least usage over the last three to six months. If they cluster in one area of the product, that area is worth a hard look.
When we applied this, we found plenty of features that were simply sitting there, waiting for someone to decide.
When should you iterate on a feature, and when should you kill it?
Compare the result against the best case you imagined before you built it. Every PM meets the "maybe one more iteration will turn this around" voice at least once. The way past it is to make the comparison explicit, using the same colour bands as an OKR.
Before building, ask what the feature would deliver if it worked exactly as planned. Would it lift the metric 5%? 10%? More? Then measure what the release actually did against that number.
- Red zone, 0% to 40% of the goal. Further incremental iteration will not work. Try a different concept.
- Yellow zone, 40% to 70%. You are close enough that iteration has a real chance.
Say you build a new sign-up form expecting conversion to grow 10%. If it grows 3.5%, that is 35% of target and you are in the red: try a new concept rather than polish this one. If it grows 6.5%, that is 65% of target, and iterating on what you have is the better bet.
The same test applies to a feature you suspect is underperforming. Estimate the best case for its adoption, measure what actually happened, and if it does not move the needle for the people it was built for, it is not worth another iteration.
Key takeaways
- Removing features is a way to create value. Cutting scope by around 25% grew Day 1 retention by over 20% on a product people had written off as capped.
- The 1% is not the problem; the 99% is. An underperforming feature costs you the focus and clarity of everyone who never used it.
- The indirect costs dominate. Lost strategic focus, harder selling, slower adoption, and permanent maintenance drag outweigh the visible bug-fix time.
- Reverse your prioritization framework. Score live features on impact, confidence, and ease of removal, then work the list bottom-up.
- Check settings, legacy-customer builds, and low-usage events. That is where deadweight collects, outside the golden flow.
- Set the best case before you build. Under 40% of target means a new concept, not another iteration.
If your roadmap keeps growing while your metrics stay flat, the fix may be subtraction rather than addition, and the hard part is choosing what goes. That is the kind of call I work through with product leaders in product advisory. Bring your feature list and your usage data, or start with the prioritization tools in resources.