Products don't usually die from missing features. They die from too many, and the death is slow, because each individual feature seemed reasonable when it was added. That's the trap: there's rarely a single bad decision you can point to. There's a long sequence of locally sensible additions that sum to a bloated, confusing whole, the way a desk accumulates clutter one reasonable object at a time until you can't find anything.
The feature you should not build is almost never obviously bad. If it were obviously bad, no one would argue for it. The dangerous ones are the plausible additions — the thing a real customer asked for, the capability a competitor has, the option that would make the product 'more complete.' Each has a real argument behind it. The problem is that the arguments are all local, and the cost is global, and the global cost never shows up in any single decision.
There's a particular version of this that catches good, generous teams. One loud customer wants a thing. They're a real customer, they're paying, they're asking sincerely, and saying yes feels like service. So you build it. And it turns out almost no one else wanted it, but now it's in the product forever, adding complexity to every screen it touches and confusion to every new user who has to wonder what it's for. The yes felt kind. The cost is permanent.
What makes subtraction so hard is that the costs of adding are invisible and diffuse while the benefits are visible and concrete. The benefit of a new feature is a thing you can point to and demo. The cost is spread across the whole product — a little more cognitive load here, a little more surface area to maintain there, a little more confusion for every future user — and no single piece of that cost is large enough to argue against the concrete, pointable benefit.
So the addition wins, every time, in any argument that only weighs one feature at a time. The only defense is to refuse to evaluate features one at a time, and instead hold a picture of the whole — what the product is for, who it's for, and what it would mean to keep that sharp. Against that picture, a lot of individually reasonable features reveal themselves as drift, things that serve someone but not the core user the product exists for.
The test that helps is asking who a feature actually serves. Does it serve the core user doing the core job, or does it just silence a complaint, satisfy an edge case, or match a competitor? Those are very different things wearing similar clothes. Serving the core user better is almost always worth it. Silencing a complaint by adding permanent complexity usually isn't, however much the complaint stings in the moment.
There's a deeper principle underneath, which is that every yes is a no to something else. The feature you build is time and attention and product surface you can't spend on the thing that would have served the core user more. The cost of the wrong addition isn't just its own complexity; it's the better thing you didn't build because you were building this. Roadmaps that say yes to everything are really saying no to focus, just invisibly.
So the underrated half of product work is the refusal — the feature you decline, the request you push back on, the clever option you leave out because it would quietly make the whole worse. It's harder than building, because it disappoints people and produces nothing you can demo. But it's where good products stay good, and the teams that master it tend to ship things that feel sharp and clear precisely because of everything they had the discipline not to add.