Killing a product by a thousand paper cuts

Your reaction slows down, your senses dampen, and it requires more effort to move things around... but it's not you; it's your product in danger.

👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!

Product managers often launch new features, but sometimes, they get it wrong. Occasionally, they launch a functionality that is not validated enough, does not solve a real challenge, or simply will get ignored by customers. And it won’t be an imminent issue, but it can be one of many paper cuts.

It’s okay if an uncooked feature slips through the cracks a single time and gets into the real product. Maybe even a few times is okay. But if this happens repeatedly, it will eventually bloat the product and make it very hard for that company to innovate.

Why?

First, these tiny features will hurt the discoverability of real value-adds, the things that are making the difference in your solution. The information architecture will suffer, and users will drown in the sea of features.

Second, in a sizable company, every single feature will get some adoption. Maybe it’s an accidental click now and then, but it’ll show up on the metrics dashboard as utilization. And after that, it’s a lot more effort to sunset the functionality than it was to build it.

Third, the total cost of ownership is always more expensive than the feature development itself. Fixing bugs, writing documentation, and educating new joiners about some functionality that almost no one uses. Unless the startup goes bankrupt in a year.

What to consider when launching new features

You can build new features in many ways. Doing months of research, building based on a hunch, seeing an opportunity on the market, copying the competition, or even just providing what those loud customers have been asking for.

If it doesn’t solve a real pain point, enable new opportunities for a good chunk of your customers, or progress the product vision, it’s just a nice to have. And too many nice-to-haves will eventually kill your product by a thousand paper cuts.

Know when you’re working on incremental improvements for too long.

Maybe that colorful loading animation is making a lot of users happy. Maybe it’s making just the product team happy? There is nothing wrong with some confetti in your product, but if that’s what is being built most of the time, ring the alarm!

Consider that product managers, especially the empowered types, have a lot of control over how they spend the company’s resources. If they work with a team of 6 developers, with an average yearly salary of €80.000 (US figures can be much higher), that is already close to half a million in a year. A house with 3 bedrooms and a garden can be bought for less in many countries. Is your investment also that long-lasting?

Deprecating features is difficult

Let’s imagine that you’ve fallen into this trap and launched a couple of functionalities that are just bloating the product. Or maybe it was your predecessor.

Now, how do you get rid of those?

At the very least, you need a good product vision and product leadership who is committed to building something good. If you don’t have the vision, you will lack the compass that guides you in the right direction. You’re trying to go north, but you might be heading south. If your leadership doesn’t care about keeping the product complexity in check, you’ll be building new features instead of being allowed time and resources to mow the grass.

In the short term, removing useless features will hurt a bit. It’ll affect your team as they must do all the work and communication. It’ll be painful for selected customers who really love those functionalities.

But if you’ve picked the right things to eliminate, most will never notice what’s gone. In return, your product will get focused. Instead of 12 mediocre things to do on the page, you’ll have a great 5. Instead of 15 clicks to get to the results, your users will only need 9.

And after all this, you can go back to building what moves the needle again!