Your product is too complex when users can't complete its core job without help. The clearest signs are people dropping off in the same place, support tickets clustering on one flow, and a team that keeps saying "we'll explain it in the demo." Complexity isn't a UX problem. It's a growth problem, because every point of friction is a point where someone leaves.
"Is our product too complicated?" is a hard question to answer from the inside, because complexity arrives gradually and every piece of it felt justified at the time. No single feature broke the product. They accumulated. And the people best placed to notice are the people who can no longer see it, because they built it and they use it every day without friction.
So instead of asking whether it feels complex, look for the symptoms. Complexity leaves fingerprints. Here are the ones I look for first, and what each is usually telling you.
Six signs your product is too complex
1. People drop off in the same place, every time. Look at where users abandon. If there's one step that consistently loses people - a setup screen, a particular form, the moment right before the core action - that's not a coincidence and it's rarely a copy problem. It's a point where the product asks for more than the user can give: more context, more patience, more trust than they have at that moment. One reliable drop-off point is the single loudest signal you have.
2. Support tickets cluster on one flow. Scan your support queue and group the tickets by where in the product they came from. If a disproportionate share point at the same flow, that flow is too hard. Support tickets are users paying you the compliment of asking for help instead of leaving. Most people don't ask. They just go. So a cluster of tickets on one flow means a much larger silent group hit the same wall and didn't write in.
3. You explain the product the same way every time, and it always takes a while. Listen to how your team demos the product. If everyone reaches for the same workaround sentence - "you just have to know that this bit does X" - that sentence is marking a piece of complexity the product is offloading onto a human. A product that needs a person to narrate it isn't finished being designed. The narration is the missing design, performed live.
4. "We'll explain it in the demo." This is the one that should worry you most, because it's usually said with relief. If the product only makes sense once someone walks a prospect through it, then every user who doesn't get that walkthrough - which is most of them - is meeting a different, harder product. The demo is hiding the problem from the only people who could fix it: you.
5. Your team argues about the roadmap more than usual. Internal disagreement about what to build next is often a downstream symptom of complexity. When the core job the product does is clear, priorities mostly sort themselves: you build what serves that job. When the product is doing several half-jobs, every feature has a defensible case and there's no shared yardstick to rank them, so the debate never resolves. Roadmap arguments that go in circles are frequently a clarity problem wearing a prioritisation costume.
6. New users need to be "good at" your product. If using the product well is a skill people develop over weeks, you've shipped complexity as a feature. Some products earn that - professional tools with real depth. But most of the time, "power users love it, everyone else bounces" means the product is obvious to the people who pushed through the learning curve and opaque to everyone who didn't have a reason to. And the people who bounced are the growth you're not getting.
If you recognised two or more of these, your product is probably more complex than it needs to be. That doesn't mean it's broken. It means there's growth sitting behind the friction, and right now you're paying for it.
What complexity actually costs
It's tempting to file complexity under "UX" - a polish problem, a someday problem, a thing to clean up when there's time. That framing is why it never gets fixed. Complexity isn't a polish problem. It's a growth problem, and it's costing you in three currencies at once.
Acquisition you've already paid for. Every drop-off point is a place where someone you spent money to attract leaves before they get value. You paid the acquisition cost and got none of the return. Complexity doesn't reduce signups. It reduces the fraction of signups that turn into anything, which is the more expensive failure because it's invisible in the top-line number.
Compounding support load. A product that needs explaining generates work forever: tickets, onboarding calls, documentation, the demo that can't be skipped. That cost scales with every new user instead of shrinking, which means complexity quietly caps how big you can get before support becomes the business.
Team velocity. Complexity in the product becomes complexity in the codebase, the roadmap, and every conversation about what to build next. Teams slow down not because they're working less but because every decision now has more dependencies to reason about. The product's complexity becomes the team's tax.
The throughline: every point of friction is a point where someone leaves, or asks for help, or slows down. Complexity isn't an aesthetic concern. It's a leak in the part of the funnel you've already paid to fill. (For why these symptoms so rarely point at their own cause, see why most product problems aren't what they look like on the surface.)
What to do about it
The instinct, once you see the symptoms, is to start cutting features. Resist it for a moment. Cutting at random trades one kind of complexity for another and risks removing something that was quietly load-bearing. The right first move isn't subtraction. It's diagnosis.
The question that organises everything is: what is the one core job this product exists to do, and what's the most direct path to it? Once that's clear, the symptoms above become a map. Every drop-off, every ticket cluster, every "you just have to know" is a place where the product wanders off that path. You're not deciding what to cut. You're deciding what's in the way of the one thing that matters, and removing that.
That's the work I do in the first phase of every engagement, and it's exactly what the Clarity Audit is built to deliver on its own: two weeks to map where your product is losing people and tie each friction point to what it's costing you, so you know what to simplify first and why.
If two or more of those signs sounded like your product, the good news is that complexity is diagnosable. It leaves a trail, and the trail leads to a cause you can actually do something about.
If you want an outside read on where yours is losing growth, the Clarity Audit is two weeks to find out. Book a conversation.
