The visible product problem - churn, low activation, a confusing screen - is almost never the real one. The real cause usually sits one layer up: in positioning, in the core flow, or in a decision made before design ever started. Fix the symptom and it comes back wearing a different face. Find the layer above it and the symptom often dissolves on its own.
Most teams I meet have already diagnosed their problem. That's the issue.
They've looked at the numbers, formed a theory, and started building against it. Churn is up, so they're reworking pricing. Activation is flat, so they're adding an onboarding tour. The dashboard tests badly, so they're redesigning the dashboard. Every one of these is a reasonable response to what the data appears to say. And a surprising number of them are aimed at the wrong target.
Here is the pattern I see again and again: the thing you can measure is rarely the thing that's broken. It's the place where something broken upstream finally becomes visible. The churn isn't the problem. The churn is where an earlier problem surfaces, after it's already done its damage.
That gap between the visible symptom and the actual cause is where most product effort gets spent, and wasted.
The symptom is downstream of the cause
A symptom is honest but not informative. It tells you something is wrong. It doesn't tell you what, and it usually points in a confident, plausible, wrong direction.
Take churn. Churn is a lagging signal. By the time a user cancels, the decision was made weeks earlier, in a moment you never saw. They hit a wall in the core flow, decided the product wasn't going to get easier, and quietly stopped opening it. The cancellation is just the paperwork. If you treat the cancellation as the problem and build retention offers and win-back emails against it, you're negotiating with people at the one moment they've already decided. You're working downstream of the actual failure, which happened in week one, in a flow you assumed was fine.
This is why "we fixed it and the metric didn't move" is such a common story. The fix landed on the symptom. The cause was somewhere else.
Three places the real problem usually hides
After enough of these, you start to see where the real cause tends to live. In my experience it's almost always one layer up from where the team is looking, in one of three places.
1. Positioning. Sometimes the product works exactly as designed and people still leave, because they arrived expecting something else. The marketing promised one job; the product does a slightly different one. Users aren't confused by the interface. They're confused about what the thing is for. No amount of UI polish solves a positioning problem, because the friction is in the gap between expectation and reality, not in any single screen. You can redesign every button and the misunderstanding survives intact.
2. The core flow. The single path that delivers the product's main value: get set up, do the central thing, see the result. When that path has friction, it doesn't announce itself as "core flow friction." It shows up as low activation, as support tickets clustering on one step, as a sales team that says "it demos great but people don't stick." Teams react to each of those symptoms separately - a tooltip here, a help article there - while the actual path stays just hard enough that most people give up. The fix is upstream of all the symptoms: make the one path that matters obvious. The rest stops bleeding.
3. A decision made before design started. This is the one teams resist most, because the decision usually felt right and was made by people who are good at their jobs. A data model that made sense to engineers but forces users to think like the database. A feature scoped to satisfy a big customer that quietly reshaped the whole experience for everyone else. A roadmap priority set in a quarter nobody remembers. By the time it surfaces as a UX problem, it's load-bearing, and the team treats it as a fixed constraint to design around rather than the cause to remove. The hardest problems to find are the ones that have been there so long they look like the floor.
Why good teams miss it
None of this is a competence problem. The teams getting this wrong are usually sharp, and that's part of why they miss it.
The reason is structural, not personal. Most products are built by specialists who each see one slice. Strategy goes one way. Design goes another. Development does what it can with what it's handed. Everyone is good at their job, but nobody is solving the same problem, and the gap between those perspectives is exactly where products get complicated and where growth quietly disappears. A problem that lives in the seam between positioning and design belongs to no one. Each specialist looks at it, sees that it isn't in their lane, and reasonably concludes it's someone else's. So it sits in the seam, unowned, generating symptoms in every direction.
There's a second reason, and it's harder to fix from the inside: proximity. A team that built the product is standing inside the assumptions that created the problem. The decision that's now causing churn felt obviously correct at the time, was agreed by smart people, and has been true for so long it's invisible. You can't easily diagnose an assumption you're standing on. Not because you're not good enough - because you're too close to see it as a choice rather than a fact. The advantage of an outside diagnostician isn't intelligence. It's distance.
What to do instead: diagnose before you build
The practical shift is small and it changes everything: before you build the fix, find the cause. Spend the time to separate the symptom from the thing underneath it.
That means resisting the most expensive instinct in product work, which is to act on the first plausible explanation. The first explanation is almost always the symptom restated as a solution. "Churn is up, so let's improve retention" is the symptom wearing a roadmap. The discipline is to keep asking why one more time than feels necessary:
- Churn is up. Why? Users aren't seeing enough value. Why? They don't reach the core action. Why? Onboarding drops them three steps short of it. Why? The setup assumes context they don't have, because of a decision about the data model made eighteen months ago.
Now you have something worth fixing. The version four questions back - "improve retention" - would have cost you a quarter and moved nothing.
This is the entire premise of how I work. Founders come to me when something isn't working and nobody can name it, and the first job is never to build. It's to find the layer the team is standing on. The diagnosis is the product. Once the real cause is named and tied to what it's costing in growth, the fix is usually smaller, cheaper, and more obvious than the one they were about to build against the symptom.
The takeaway
If you take one thing from this: distrust the obvious diagnosis, especially when it's yours and especially when it's convenient. The visible problem is real, but it's a witness, not the culprit. The cause is usually one layer up, in positioning, in the core flow, or in a decision made before anyone opened a design tool. Find that layer and the symptoms tend to resolve together. Fix the symptom and you'll meet it again next quarter, in a new disguise, having spent a quarter learning nothing.
Most product problems aren't what they look like on the surface. If yours has been resisting fixes that should have worked, the cause is probably somewhere you haven't looked yet, and it's findable.
If you want an outside read on where your product is actually losing growth, that's what the Clarity Audit is: two weeks to diagnose the real problem and tie it to what it's costing you. Book a conversation.
