The Bias Toward More

The drift toward complexity is one of the most predictable patterns in product work, and it happens despite the fact that everyone involved will tell you they value simplicity.

The Paradox

Every product team I've worked with says they care about simplicity. It's in the company values. It's on the mood board. Designers reference it in critiques and PMs bring it up in planning. And yet almost everything I've seen gets more complex over time. Not because anyone wanted it to, but because the forces pushing toward complexity are constant, and the forces pushing back are rare.

That gap between what teams believe and what they actually build is what I keep coming back to.

Why It Keeps Happening

The most honest answer is that adding things feels like progress. Shipping a new feature is visible, celebratable, easy to put on a roadmap. Removing a feature, or deciding not to build one, doesn't show up in a sprint review. Nobody gets praised for the thing they prevented from existing. The incentive structure in most product teams is biased toward more.

Then there's the stakeholder pressure. Every person in the room has a feature that matters to them. Sales needs something for a deal. Support is getting tickets about a missing workflow. The CEO saw something a competitor launched. Each request, individually, is reasonable. Saying yes is easy and makes people feel heard. Saying no requires conviction, and it spends political capital that most people would rather save.

There's also a deeper assumption that I think goes mostly unexamined: the idea that more features means more value. That a product with 50 features is better than one with 10. I've seen teams treat their feature count almost like a scoreboard, as if breadth and quality are the same thing. They're not, but it's hard to feel that until a product is already drowning.

And then there's the thing that makes all of this worse: nobody's job is to simplify. There's almost always someone whose job involves adding. PMs add features. Sales adds requirements. Marketing adds messaging. But I've rarely seen a role whose explicit purpose is to subtract. Simplification happens in the margins, when someone cares enough to fight for it. It's never the default.

The Math Nobody Does

One of the biggest things I've learned building products is that every new feature isn't a +1. It's exponential.

A single new feature doesn't just mean one new screen. It means new states, new edge cases, new error handling. It means another thing for QA to test across every device. It means documentation. It means onboarding copy. It means support has to learn it, explain it, troubleshoot it.

But the real cost is how it interacts with everything else. Every feature exists in relationship to every other feature. A product with 10 features doesn't have 10 units of complexity. It has something closer to 10 × 10. Add an 11th feature and you're not adding 1 unit of work. You're adding another layer of interaction with all 10 that already exist.

This is the cost that's invisible at the point of decision. When someone proposes a new feature in a meeting, what the room sees is the upside: users get a new capability, a deal closes, a gap gets filled. What nobody calculates is the long tail of maintenance, the cognitive load on the team, the way it makes every future decision slightly harder.

I've started thinking of it like clutter in a room. One thing on the desk is fine. Ten things and you start losing track. Fifty things and you can't find anything, and every time you need to add something new, you have to first figure out where it goes relative to everything else. The desk doesn't get messy because of one bad decision. It gets messy because nobody made a decision to keep it clean.

When Complexity Is Earned

I'd be dishonest if I said simplicity is always the right answer. Some products need to be complex. Figma is complex. Blender is complex. Excel is wildly complex. And they're all great.

The difference is that their complexity is earned. It serves a specific audience of power users who have chosen to invest in learning the tool. The complexity is the product. It's not accidental bloat that accumulated because nobody pushed back.

The problem I see in most products isn't that they're complex. It's that their complexity is unintentional. Nobody chose it. It just happened, one reasonable decision at a time, until the product was doing 30 things adequately instead of 5 things well.

What I've Learned

I've started measuring my own contribution differently over the years. Early on, I measured it by what I shipped. Features designed, screens delivered, flows built. Somewhere along the way, I started noticing that the best work I did was often the opposite. The feature I talked a team out of building. The settings page I argued should be three options instead of twelve. The flow I simplified by cutting two steps.

None of that work was visible in a sprint review. But the products were better for it.

Simplicity isn't really a design principle. It's a discipline. It means having strong enough conviction about what a product should do that you can say no to everything else. And it means accepting that the forces working against you are constant, that complexity is the default, and that keeping things simple requires active, ongoing, sometimes unpopular effort.

The teams I've seen do this well aren't the ones with the best taste or the cleanest Figma files. They're the ones where someone in the room is always willing to ask: do we actually need this?

Most of the time, the answer is no. The hard part is being okay with that.