Killing features is hard. We put lots of time and effort—and a good dose of emotional energy—into creating and nurturing them. But even brief hesitation to excise an underperforming feature can be costly.

Think about it: If you ship four features a month and you have a hit rate of 25% (which is high; I’ll come back to this), waiting even two months to kill underperforming features means you’re supporting 75% × 4 × 2 = six dead-weight features at any given time.

Features kill if you don’t kill them first.

The costs of a feature that clings to life hit three constituencies. The first is developers, who suffer in two ways. The obvious one is that they spend time maintaining the feature.

Less obvious but more significant is the extra work developers do to ensure that new code plays nicely with existing. That’s part of the job when the existing code is delivering business value, but when a test covering a failing feature breaks or an extra else block gets added in new code to accommodate it, that’s time and energy gone to waste.

Users suffer too. At first blush, it seems like they’re the one constituency that should be ok with bloat. If a customer happens to use an unpopular feature, great; if not, they ignore it. It’s the part after the semicolon that doesn’t hold up.

Each button, link, call-to-action, etc. in a product has a little voice that says “I’m what this product is all about.” Despite how we patronize the “average user,” users do put real, focused mental effort into understanding your product. It’s the duration of the effort that’s limited, and even one or two bad signals of purpose in the form of misfiring features can prevent a user from getting to that “Aha!” moment.

The last person who suffers is you, the founder/product manager/UX lead. It’s easy to assume that, because you put so much more mental energy into your product than the user, you can filter out the noise of features you know aren’t long for the world. In a way, the opposite it true: In your own mind is the caucophony of those little voices you know too well, calling for your attention, clouding your own understanding of what your product is.

For the sake of your users and your team, and for your own sake, cull failing features early and often.

One final note, as promised, about hit and miss rates. As I said, 25% is high. Probably way high. If you look at what most mature products are compared to what they were years before, it’s usually only a kernel of meaning that remains. Any illusion that the evolution of a product like Facebook or Twitter followed a clear path is a revision. We just don’t remember all the things that came and went in between.

The takeaways: Fewer features than you think are going to be part of your and your users’ success. Kill them early and often. Shoot for zero bloat by minimizing the time between when you know in your heart (and on your Mixpanel) that a feature isn’t pulling its weight and the time when it’s gone.