defining the right problem

I have seen a lot of product failures across training cohorts at Pragmatic Leaders. Bad prioritization, bad execution, bad communication — all of these happen. But the most expensive failure, the one that wastes the most engineering hours and the most runway, is almost never about execution.

It is about definition. The team built something well. They just built the wrong thing.

This is the skill nobody teaches explicitly: how to define a problem with enough clarity and precision that the solution becomes obvious — and the wrong solutions become easy to rule out.

Why PMs reach for solutions first

There is a monument in Washington that was deteriorating faster than any other structure around it. The Park Service brought in a team to investigate. Their first instinct was maintenance methods — the cleaning chemicals, the frequency, the techniques.

They kept asking why. Why was this monument deteriorating faster? Because it was cleaned more often. Why was it cleaned more often? Because more bird droppings. Why more birds? Because there were more insects. Why more insects? Because the monument’s floodlights were turned on before sunset, attracting insects earlier than elsewhere.

The solution was not a new cleaning chemical or technique. It was delaying when the lights turned on by two hours. A completely different class of solution — one that never appears if you start with “how do we clean this better.”

That is the monument example from the Five Whys tradition. I have used it in every cohort for six years. The reason it resonates is not because of the monument. It is because every PM in the room immediately thinks of a project where they did the cleaning-technique equivalent — optimized the surface when the real problem was two levels deeper.

We reach for solutions first because solutions feel productive. Writing a PRD feels like progress. Running sprints feels like execution. Sitting with a half-formed problem statement feels like wasted time. It is not. It is the highest-impact work a PM can do.

The anatomy of a bad problem statement

A bad problem statement has four failure modes. You will recognize them all.

Failure 1: The problem statement is actually a solution in disguise.

“We need to build a notification system for overdue tasks.” That is not a problem. That is a pre-decided solution. The actual problem might be that users forget to complete tasks, or that task assignment lacks accountability, or that the workflow is poorly designed and tasks accumulate. The notification system might solve none of these — or it might solve all of them less efficiently than something else.

Failure 2: The problem statement is too broad to prioritize against.

“Our onboarding experience is bad.” Bad for whom? Which part? How bad? This is not a problem statement — it is an area of concern. You cannot build a solution to it because you do not know what you are solving. You cannot prioritize it against other work because “bad” has no unit of measurement.

Failure 3: The problem statement skips the user.

“Revenue is declining in the mid-market segment.” That is a business observation, not a product problem. Who is the user experiencing something? What are they experiencing? Why does that cause the revenue decline? Without a user at the center, you cannot identify what to build.

Failure 4: The problem statement assumes a cause without evidence.

“Users are not converting because the checkout flow has too many steps.” You have a hypothesis embedded as a fact. Maybe checkout steps are the cause. Maybe they are not. If your problem statement contains a causal claim, that claim needs to be verified, not assumed.

The Five Whys: how to use it without making it annoying

The Five Whys is a root cause technique from the Toyota Production System. The idea is simple: for any problem, keep asking “why” until you hit the root cause. Usually five iterations gets you there.

It is also one of the most misused tools in product management. PMs either skip it entirely or turn it into an interrogation that irritates stakeholders. Here is how to use it well.

The mechanic:

Start with the observed symptom — the thing you can measure or verify. Then ask why it is happening. Take the answer and ask why again. Repeat until you reach a cause that is actionable and fundamental.

The key word is actionable. You stop when the answer reveals something you can change. If the next “why” leads to “because that’s human nature” or “because the market is like this,” you have gone too far.

A real example from a fintech product:

The fix is not a new UPI flow. It is a deprecated API parameter, plus a CI test, plus ownership clarity. All of that is invisible if you stop at “the UPI app does not open” and immediately start redesigning the payment screen.

When Five Whys breaks:

The technique assumes the problem has a single root cause. Complex systems often have multiple contributing causes. If you find yourself with branching “why” chains — where each level has two or three valid answers — you are not in Five Whys territory. You are in a causal analysis problem that needs a different tool (fishbone diagrams, fault trees, or simply structured research).

Do not force a single chain when the reality is more tangled. Acknowledge the multiple causes and prioritize among them.

Writing a problem statement that actually works

A useful problem statement has four elements. Not a template — a checklist. The format can vary. The elements cannot.

Element 1: The user and their context.

Who is experiencing this problem, and in what situation? Not the persona card — the actual context in which the problem appears. “Mid-market HR managers at companies with 100–500 employees who are running monthly payroll for the first time” is useful. “HR professionals” is not.

Element 2: The observable symptom.

What can you see, measure, or verify that tells you this problem exists? If you cannot point to something observable, you are working from an assumption. The symptom might be a metric (34% drop-off), a behavioral pattern (users calling support instead of using self-serve), or a qualitative signal (consistent “this doesn’t work for me” feedback from a specific user segment).

Element 3: The impact.

Why does this matter — for the user and for the business? A problem statement without an impact statement cannot be prioritized. “Users struggle with bulk data import” — so what? If bulk import is used by 3% of users and takes them 20 minutes longer than it should, that is a different priority than if it blocks 60% of enterprise customers from completing their first week.

Element 4: What you do not know yet.

An honest problem statement includes the gaps. “We believe the root cause is X, but we have not yet verified whether Y is also contributing.” This matters because it tells the team what needs to be researched before the solution can be designed.

A fully formed statement might look like this:

Our enterprise customers (100+ seat accounts) are taking an average of 12 days to complete onboarding, compared to our target of 5 days. This is primarily affecting customers in the BFSI sector who have data compliance requirements. As a result, we are seeing delayed revenue recognition and elevated churn risk in the first 90 days. We believe the bottleneck is in the data migration step, but we have not yet confirmed whether this is a tooling gap or a process gap on the customer’s end.

Notice: a user segment, an observable metric, a business impact, and an explicit statement of uncertainty. No solution. No prescription.

Reframing: when the first definition is wrong

Some problems are correctly identified but poorly framed. Reframing is not about finding a completely different problem — it is about rotating your perspective on the same situation until you see the solution space clearly.

Three reframes that matter for PMs:

From symptom to behavior. Instead of “users are not using the dashboard,” reframe to “users are not completing the task that the dashboard was designed to support.” Now you ask: what is that task, and where are they going instead? This usually reveals that they have found a workaround — which tells you exactly what to build.

From product problem to workflow problem. “The approval flow is too slow” might not be a product problem at all. The product might be working fine; the bottleneck might be that approvers have a policy to wait for end-of-month review. Shipping a faster UI does nothing. The problem is a process problem disguised as a product problem.

From individual complaint to pattern. A single customer saying “this does not work for me” is not a problem statement. Ten customers in the same segment, with the same role, describing the same friction — that is a pattern. Before you define a problem, you need to know whether you have a pattern or an outlier.

The discipline: problem definition as a forcing function

Problem definition is not a one-time exercise at the start of a project. It is a forcing function you use at every decision point.

Before a sprint begins: “Is the problem we are solving in this sprint the same problem we identified at the start of the quarter, or has new information changed it?”

Before a design review: “Does this design solve the problem we defined, or a slightly different problem that the design team found more interesting?”

Before a stakeholder presentation: “Are we reporting on how well we solved the problem, or on how much we shipped?”

These are uncomfortable questions. They slow things down. They surface disagreements that feel easier to avoid. That is exactly why most teams skip them — and why the best PMs are disciplined about them.

In India’s startup ecosystem specifically, the pressure to ship fast is intense. Founders want velocity. Investors want feature counts. The team wants to build. Problem definition feels like friction in that environment. It is not. It is the thing that makes your velocity mean something. Shipping fast in the wrong direction just gets you to the wrong place faster.

Test yourself

Where to go next

• The research that feeds problem definition: User Research Methods — how to run interviews and observe behavior instead of collecting opinions.
• Understanding what users are actually trying to accomplish: Jobs to Be Done — the job framework as a lens for problem definition.
• Translating a well-defined problem into a spec: Writing PRDs — how to move from problem statement to requirements without losing the thread.
• The mental habits that make problem definition easier: Product Thinking — first principles, hypothesis formation, and the discipline of asking why before what.