The Problem Behind the Problem

Here’s something that happens in almost every product meeting at some point. Someone describes a problem: “Users are dropping off at checkout.” The room nods. Ideas start flowing. Redesign the checkout flow. Add a progress indicator. Simplify the form. An engineer suggests a technical fix. A designer pulls up a competitor’s checkout. Within fifteen minutes the room is deep in solutions. Someone asks who owns the task. It gets assigned.

Three weeks later: nothing moved. The drop-off rate is the same. The room reconvenes. This time someone asks: “What are users actually doing when they drop off?” It turns out 60% of drop-offs happen on mobile, at the payment step, between 11pm and 1am. The payment provider’s popup doesn’t render correctly on older Android devices. It was never a checkout design problem. Nobody had looked.

The failure wasn’t carelessness. It was a deeply ingrained habit of jumping to solutions before the problem is understood. This is the default mode of most teams. It feels productive. It moves fast. It produces nothing.

The first problem you name is almost never the problem worth solving. The first problem is what’s visible. It’s the symptom, the surface, the thing that got reported. The real problem is what’s underneath: the cause, the context, the reason it matters. Treating the visible problem as the real problem is how teams stay busy without making progress.

Staying sensitive

The first skill is noticing. Not every team has it. Friction normalizes over time. A loading screen that takes four seconds felt slow once. Now nobody mentions it. A process that requires three people to approve a two-line change used to create complaints. Now it’s just how things work. The longer a team lives with something, the less they register it as a problem.

The way to stay sensitive is to watch the moments you’ve stopped watching. New users notice everything. They haven’t adapted yet. Their confusion is signal. Watch where they slow down, where they abandon, where they invent workarounds. A workaround is a user telling you there’s a problem without using the word problem. Every workaround is a flag.

Intolerance is a choice. You decide that something that should bother you still does. The standard is: if a user encounters this, would it reduce their confidence, their willingness to return, their ability to do what they came to do? If yes, it’s a problem. The fact that it’s been there for six months doesn’t change that.

Knowing it’s worth solving

Not every problem deserves to be solved. Some are real but minor. Some are real but the cost of solving them exceeds the cost of living with them. Some are symptoms of a deeper problem, and solving the symptom without the root cause is waste.

The test has three parts.

First: can you quantify the impact of not solving it? This doesn’t require a precise number. A direction is enough. Is this affecting 5% of users or 50%? Is it causing one support ticket a week or twenty? Is it costing us a customer a month or one a day? If you can’t even estimate the magnitude, you don’t understand the problem well enough to decide whether to solve it.

Second: what are people doing instead? If users have a workaround that mostly works, the urgency is lower. If they’re abandoning entirely, it’s higher. Workarounds tell you both that the problem is real and how tolerable it is. A workaround that takes 30 seconds is different from one that requires a phone call.

Third: what happens at the root cause if you solve the symptom? If you fix the checkout drop-off by redesigning the flow but the underlying issue is a broken payment popup, you will have done real work and changed nothing. The problem will return in a different form. Solving symptoms is how teams generate churn without progress.

Digging to the root cause

The discipline is to ask why until the answer stops changing.

“Users are dropping off at checkout.” Why? “The checkout flow is confusing.” Why? “There are too many steps.” Why? “We added fields over time without removing any.” Why? “Nobody owns the checkout experience end to end.” That’s a different problem than the one you started with, and the solution is different too.

This is not a formal process. It is a posture. It means not accepting the first answer. It means treating every “why” response as a hypothesis that deserves at least one more push. The first answer is almost always a restatement of the symptom. The second starts to get at mechanism. The third or fourth starts to reach cause.

The mistake is stopping when you hit something that feels actionable. “There are too many steps” feels actionable. You can redesign it. But it isn’t the cause. It’s still a symptom. Push.

Two things signal that you’ve reached the root cause. One: the answer is no longer about the product. It’s about a decision, a process, an ownership gap, a habit. Root causes are almost always organizational or behavioral before they are technical. Two: the answer, if addressed, would prevent the whole family of symptoms from recurring, not just this instance. The pattern.

Thinking about it differently

Once you believe you understand the problem, try to break your own frame.

Deep thinking goes vertical: you push down, layer by layer, until you reach the foundation. Critical thinking goes sideways: you ask what assumptions you’re making and whether they hold. Lateral thinking goes outside: you ask whether the problem as framed is the right frame, or whether there is a frame where the problem doesn’t exist at all.

The lateral question is the hardest and the most valuable. “Users drop off at payment” assumes the goal is to get users through payment. What if the frame is wrong? What if the users who drop off are not the users you want completing payment? What if the drop-off is filtering out low-intent users and the conversion rate of completers is actually improving? You might fix a metric that didn’t need fixing.

Breaking the frame doesn’t mean abandoning the problem. It means making sure the problem you’re solving is the one that matters. Ask: what would have to be true for this not to be a problem? Sometimes the answer reveals a reframe that changes everything. Sometimes it confirms you’re in the right place. Either way, you’ve thought more carefully.

What a complete problem statement requires

A problem is well-formed when it can answer five questions without a follow-up conversation.

Who specifically has this problem, in what context and when. Not “users” but a segment: mobile users on Android during late-night checkout. What their underlying goal is when they encounter it: they want to complete a purchase quickly before they change their mind. What specific friction stops them: the payment popup fails to render and they can’t proceed. What they do instead: they abandon, or switch to desktop, or try again the next day and don’t come back. What the cost of inaction is in terms the business can measure: 60% of mobile drop-offs, translating to an estimated 15% of total lost revenue on mobile.

If you can’t answer all five, you don’t understand the problem yet. That discomfort is not a sign the problem is too complex to articulate. It is a sign you have more work to do before you are ready to define a solution.

The forcing function: after writing the problem statement, ask what success looks like if this problem no longer exists. Not what feature you would ship. What would a user do differently, feel differently, or stop needing to do? If the answer is vague, the problem statement is vague. They are mirrors.

There is a version of this discipline that collapses into bureaucracy. Teams fill out problem statement templates to satisfy a process gate, not because they’ve done the work. The five questions get answered with plausible-sounding assumptions. The “why” chain stops at the first comfortable answer. The reframe question never gets asked because the room is already committed to a solution.

The structure doesn’t protect against that. What protects against it is someone in the room willing to ask “how do you know that?” and hold the pause until the answer is honest. Not hostile. Not performatively skeptical. Just genuinely unwilling to proceed until the problem is understood.

Most rework doesn’t come from bad execution. It comes from building the right thing for the wrong problem. The investment in understanding the problem is not overhead. It is the work.

The problem behind the problem is almost always the one worth solving.