Via Negativa: The Case for Subtracting Your Way to a Better Product

I’ve been working on brownfield products long enough to develop a gut feeling about complexity. When a product has been around for years, every conversation about improvement eventually turns to edge cases. You walk into a meeting with a Post-it-sized idea and walk out two hours later having mapped a decision tree with dozens of branches. The idea was fine. The product had just accumulated so much stuff that nothing was simple anymore.

Nassim Nicholas Taleb has a name for the opposite approach: Via Negativa. I picked up the term from Antifragile. Subtract first, then see where you are.

How Products Get Heavy

The reflex I see everywhere is the same. Churn creeps up. A conversion rate flatlines. Users drop off at a step. The response is to build something. A new onboarding flow. A tooltip. A modal. A toggle. A smart default. A new pricing tier. Each one addresses a real problem, and each one makes sense in isolation.

But the number of possible states a user can encounter doesn’t grow linearly. It explodes. That pricing page tweak you wanted to make? It depends on which plan the user is on, which depends on whether they signed up before or after the last pricing change, which depends on whether they have a promotional discount, and which behaves differently on annual vs. monthly billing. Five independent variables, each with a handful of values, and suddenly the state space is in the hundreds.

Every time we add something to address a problem, we’re also increasing the surface area for the next 10 problems. And the next team that comes along will add something to deal with those. And nobody stops to ask where the product is actually heading. Everyone’s too busy optimizing their own corner of the funnel.

Why does this keep happening? Maybe because addition is more fun. Building something new is what most product managers were taught the job is about. Ship features! Grow the product, dream BIG! And stakeholders want to see progress. A new feature looks like progress. Removing something looks like retreat. On top of that, most decision-makers sit far enough from the codebase and the support queue that they underestimate the cost of adding something. A feature looks simple from the roadmap level. Second-order effects show up later, after the commitment is already made.

The Leverage Problem

There’s a practical math issue with addition. You spot a drop-off in the funnel, so you design something to catch those users. But that drop-off might be a small slice of overall traffic, and your intervention converts some fraction of them. The net move on the metric is small. Meanwhile, you’ve created a new code path that will need to be tested, documented, and supported indefinitely.

Removing an unnecessary step or collapsing two flows into one touches every user who passes through. The leverage tends to be higher, and the ongoing cost is negative. You’ve reduced what needs to be maintained.

So when the urge is to add, I’ve started asking a different question: what can I remove instead?

The Noise Problem

There’s another reason small additions are unreliable: noise. Say you run an A/B test, measure a few percent improvement, and roll out the winning variant. Sounds solid. But then market conditions shift, your user mix changes, seasonality kicks in, or any number of things happen that have nothing to do with your change. That few percent gain can be lost amid background fluctuations. You’ve added permanent complexity to the product for a signal that might not have been real in the first place.

Subtraction is different. When you remove a confusing step, the flow gets simpler, and that holds regardless of what the market does next quarter. You measure it the same way you measure anything: before and after. Support volume, time-to-value, retention. But the signal tends to be clearer, because you’ve reduced the number of variables instead of increasing them.

What Leaning Out Gets You

A product with less internal complexity can be configured and integrated more easily because there are fewer hidden interactions between features. When a product handles the common cases well and stays out of the way for the rest, teams and customers can build on top of it. When it tries to handle every edge case internally, it turns brittle.

There’s a business case too. A simpler product means lower operating costs. Less code to maintain, fewer support edge cases, less QA overhead. Revenue might dip if you cut a feature some segment relied on. But if operating costs decline faster, profit rises. And a leaner operation adapts faster when market conditions change, because there’s less to retool.

This applies to the customer base, too. I’ve seen it repeatedly: the customers who generate the most support tickets, advocate the loudest for new features, and take up the most product bandwidth are not the ones with the best ROI. It’s often the quiet ones who drive the most revenue per effort spent. When you stop bending the product to serve the high-maintenance segment, you free up time to care for the customers who actually matter and to figure out how to attract more like them.

Filters That Weren’t Filters

I was working on a recommendation system. Customers kept asking for more filters to narrow down the recommended list. Too much irrelevant stuff is showing up. The obvious move would have been to build those filters, and every individual request made sense. But stacking filters on top of a recommendation engine would have added complexity to every layer of the implementation.

So I dug into why they wanted each filter. It turned out the interesting part wasn’t what they wanted to see. It was what they didn’t want to see. And those items shouldn’t have been recommended in the first place. The model was surfacing things it shouldn’t have.

Instead of adding filters to work around the problem, we’re rebuilding the recommendation models from the ground up. It’s more work than slapping on a few filter dropdowns. But the feature request was “give us more filters,” and the real answer turned out to be: stop recommending things that don’t belong there. Fix the root cause, not the symptoms.

Scalpel, Not Axe

Subtraction done badly is just as destructive as addition done badly. You don’t walk into a product and start ripping things out. You plan it. You map the dependencies, understand the second-order effects, and figure out what breaks and what gets freed up.

This is not a junior PM move. Knowing what to remove requires deep familiarity with the product, the customer base, and the business model. There’s no checklist for it. It requires the kind of judgment that comes from having seen what happens when things go wrong. Both from adding too much and from cutting the wrong thing.

Pitching Subtraction

A stakeholder comes to you with a feature request. They’ve thought about it, maybe even sketched it out. Telling them “actually, I’d rather remove something” is not an easy conversation.

I often go back to first principles. The stakeholder doesn’t want the feature. They want the outcome. So I dig until we get to that. What’s the actual problem? What does success look like? Sometimes this takes multiple conversations, because the first answer is usually the surface-level one. The real need is often buried under assumptions about how it should be solved. Once there’s common ground on the outcome, it’s easier to jointly explore how to get there. “Remove complexity” becomes a viable path, not a threat.

Sometimes they push back hard. They want the feature, and they don’t want to hear about alternatives. When that happens, I don’t force it. I lay out the implementation cost honestly, including the planning overhead, the edge cases, the regression testing, and let them weigh it against the expected benefit. If all of that still doesn’t shift the conversation, there’s always escalation. Not as a confrontation, but as a way to get a broader perspective on whether the product should be getting heavier or lighter. That’s a strategic question, and sometimes it needs to be answered at a level above a single feature request.

The Bigger Question

This approach isn’t intuitive, especially in product work where the expectation is always to ship more. But I’ve found that the most useful thing I can do with a complex product, whether I’m part of a team or running the whole thing myself, is to step back from individual feature requests and look at the big picture. What are we actually trying to achieve? What’s the real north star?

And then ask whether we even need to build anything new, or whether we need a better foundation to get there, and whether removing what’s in the way is the right move. Sometimes the answer is to simplify everything, accept a short-term revenue hit, and end up with a product that’s cheaper to run, easier to adapt, and ready for whatever the market does next.

Dare to question what’s already there. Remove what isn’t necessary. Make room for what is. Via Negativa.