Why smart teams still build confusing products.
It’s almost never a competence problem. Every team I work with is sharp, fast, and technical, and the product still got away from them. I’ve watched it happen enough times that I stopped blaming anyone for it. Here’s how it actually goes.
Complexity compounds
It never happens in one decision. It happens in a hundred reasonable ones.
Every feature solved a real problem. Every setting came from a real customer who asked for it. Every exception made sense in the meeting where someone decided it. None of them were wrong on their own. But you add them up over two years and the product stops fitting in a single head.
Every “yes” was reasonable. The sum of them wasn’t.
The cruel part is that the people who built it notice last. You’ve been adding context for years, so you know why every corner exists. A new user shows up with none of that. The thing that feels obvious to you is a maze to them, and from the inside you genuinely can’t see it.
Then onboarding gets longer. The same support tickets keep coming back. The roadmap grows and never shrinks. And one day someone says “I don’t really get what this does,” and you realize you can’t explain it in one sentence either.
This isn’t failure. It’s physics.
Complexity compounds. Every good team building something powerful runs into it, because it’s the tax you pay for building something worth using. The only thing that changes is whether someone is watching for it and paying it down on purpose.
Complexity vs. features added
The good news is that it’s fixable. And the cheapest time to fix it is now, before the next big build bakes the confusion into code, and before your next hire learns the product the way it is instead of the way it should be.
Did you recognize your product?
Then it’s worth a conversation. A short, honest read on where the complexity is costing you, and what I’d fix first.