Writing a Strong Problem Statement

There is a direct relationship between the quality of a problem statement and the quality of the product that gets built from it.

1. Teams that begin development with a vague problem statement build features that vaguely address it.
2. Teams that begin with a precise, evidence-grounded problem statement build features that clearly and deliberately solve it.

The problem statement is the foundation everything else rests on. If it is wrong, everything built on top of it is wrong too. If it is vague, the team will make assumptions to fill the gaps, and those assumptions will diverge in ways that surface as conflict during development.

Most product managers underinvest in the problem statement. They write one or two sentences that describe a symptom rather than a problem, then move quickly to the solution they already have in mind. This is one of the most common causes of product work that is delivered on time, on spec, and fundamentally unhelpful.

A strong problem statement answers four questions with specificity.

1. Who is experiencing the problem? Not a broad demographic category, but a specific user with a specific context. Not users but first-time users who are setting up their account for the first time and do not yet understand the value of completing their profile. The more specific the user, the more useful the problem statement as a guide for every decision that follows.

1. What is the problem they are experiencing? Describe the actual experience of having this problem. What does the user try to do? Where do they get stuck or frustrated? The problem description should feel like an honest account of a real person's experience, not a marketing abstraction.

1. What evidence do we have that this is real and significant? A problem statement without evidence is a hypothesis dressed as a conclusion. What support tickets, interview findings, survey results, or usage patterns confirm that this problem exists and that it affects enough users to be worth solving?

1. What is the impact of leaving this problem unsolved? What happens to users who continue to face this problem? What is the business consequence of not addressing it? This is the section that creates urgency: not manufactured urgency, but the honest articulation of what is at stake.

Understanding what not to write is as important as understanding what to write.

It does not describe a solution. A problem statement that says users need a dashboard where they can see all their activity in one place is not a problem statement. It is a solution.

The problem might be that users cannot easily understand their progress, or that they are missing important information that affects their decisions. The dashboard is one possible solution. It should not appear in the problem statement.

It does not assume the cause. Describing a symptom and then assuming the cause is one of the most common errors in problem statements.

Users are not completing onboarding because the steps are too long and conflates observation with interpretation. The steps being too long is a hypothesis about the cause, not the problem itself. The problem is that users are not completing onboarding. The cause must be investigated, not assumed.

It is not written in terms of business desire. A problem statement that says we need to increase revenue from enterprise customers describes what the business wants, not what users experience.

User problems and business problems are related but not identical, and the PRD problem statement belongs to the user. The business case lives in the strategic context and goals sections.