March 21, 2026·
post

Most people think a Product Manager’s job is to build features.

Original post
Most people think a Product Manager’s job is to build features. It’s equally about killing them. Every feature you ship takes rent: maintenance, support, cognitive load, edge cases, team bandwidth, leadership attention. Some of them justify it. Many don’t. The tricky ones are the “almost working” features. They generate "some" revenue, look decent on dashboards, and survive because they’re not obviously broken. But under the hood, they’re leaking resources, focus, and opportunity cost. Good product thinking isn’t just about identifying what to build. It’s about continuously asking: should this exist at all? Because building is easy to justify. Deleting requires clarity. And a modicum of courage. Why courage? - It looks like failure Killing a feature is often read as “this didn’t work.” Which means someone’s vision, strategy, or execution was wrong. Resources were “wasted.” What gets missed is this: you can make the right decisions and still get negative outcomes. That’s not failure. That’s reality. - The ripple effect is real Features don’t exist in isolation. They come with processes, people, dependencies. Over time, they become part of the baseline. Removing them means change management, reassignments, sometimes reorgs, sometimes shutting entire units. It’s not just a product decision. It’s an organizational one. - The leadership scorecard problem Sometimes everyone knows something is bleeding. But it stays alive because it still looks good on someone’s scorecard or serves a "larger purpose" like valuation/fundraising or market/people perception. Revenue shows up. Costs are distributed hazily. The narrative holds. When success is measured in visible gains, removing something invisibly leaking doesn’t always get rewarded. So it stays. - It feels like extra work (and attracts heat) Removing something rarely feels like progress. It creates more work before things get better. Stakeholders ask questions. Teams feel disrupted. Short-term pain is visible, long-term gains are not. So inertia wins. Not because it’s right, but because it’s easier to continue. Think of it like infrastructure: - You don’t build a cantilever bridge if a suspension bridge is feasible. - You don’t build a bridge *at all* if a ferry solves the problem. Same outcome. Very different cost structures. The same applies across systems. Products are no different. In some systems inefficiencies can hide longer, but they still compound. The highest leverage often comes not from adding more, but from removing what shouldn’t be there in the first place. It isn't “this is failing, shut it down" But, “this is okay-ish… and that’s exactly the problem”. P.S. To paraphrase the popular quote, often nothing is better than something.
Have a thought or correction? Reach out on LinkedIn.

Get new notes by email

No noise — just new notes as they land.