Problem statement for PMs
A problem statement gives me a concise, shared description of the product problem I am trying to understand. I use one before discovery, prioritization, design, or delivery when a request is moving faster than the evidence. A good statement helps the team investigate the same problem without quietly committing to a solution.
I do not expect a problem statement to be perfect on the first attempt. It is a working hypothesis that should become clearer as I learn. The discipline is in separating the customer’s situation from my proposed response and making the uncertainty visible.
Start with the person and the context
I name who is affected, what they are trying to accomplish, and when the problem occurs. I avoid labels that are too broad to guide research. “Users are confused” is a symptom without context. “New administrators are unsure whether their first configuration is complete before inviting teammates” gives me a situation I can observe and discuss.
I include the environment when it changes the problem: device, workflow, team, timing, permissions, stakes, or a handoff. Context often explains why a behavior that looks irrational is reasonable. A customer may choose a slower path because it provides review, control, or a way to recover from mistakes.
Describe the gap without prescribing the fix
I write the difference between the current experience and the desired progress. I use language such as “people struggle to…” or “the team cannot reliably…” and then explain the consequence. I avoid starting with “we need a dashboard,” “add a button,” or “build an AI feature.” Those may be possible responses, but they are not the problem statement.
A useful statement can coexist with several solution options. If I can only imagine one feature after writing it, I ask whether I have included a hidden solution assumption. I want the statement to create room for product, design, engineering, operations, and research to contribute.
Ground the statement in evidence
I record what I have observed and what I am inferring. Evidence may include interviews about recent behavior, usability observation, support conversations, product data, research, operational incidents, or a credible technical constraint. I do not treat a stakeholder request as proof of the underlying problem, though it can be an important signal about urgency or perceived value.
I also record the boundaries. A small number of conversations may reveal a failure mode without showing how common it is. A metric may show where people stop without explaining why. A support theme may represent a vocal segment. I use those limits to decide what to learn next rather than decorate the statement with unsupported certainty.
Explain why the problem matters
I describe the effect on the customer and, where relevant, the product or business. The impact might be lost progress, rework, delayed decisions, preventable support effort, lack of trust, or a missed outcome. I avoid jumping straight to a business metric unless I can explain the connection to customer value.
I distinguish severity, frequency, reach, and urgency. A problem can be rare but consequential, common but minor, or important for a narrow audience. I do not force those differences into one number before the team understands them. The point is to make the tradeoff explicit.
I use assumption mapping for product managers when the statement depends on beliefs about behavior, value, feasibility, or viability. That helps me identify which part of the problem framing could most change the next decision.
Keep scope and non-goals clear
I write what is included in the current investigation and what is not. A problem statement about first-time setup may not cover every issue in the customer lifecycle. A statement about one workflow may intentionally exclude a broader platform redesign. Boundaries keep the team from expanding the problem every time someone adds a related request.
I also state important constraints without turning them into a predetermined solution. Legal, privacy, accessibility, reliability, staffing, timing, and integration constraints can shape the problem. I want the team to see them early and explore options responsibly.
Invite different perspectives
I review the statement with people who see the problem from different angles. Customers can challenge our understanding of the job. Design can expose a usability or content issue. Engineering can explain system behavior and feasibility boundaries. Support and operations can show where the cost appears after launch. Leadership may clarify the strategic context.
I am not seeking unanimous wording for its own sake. I am looking for disagreements that reveal an unstated segment, outcome, constraint, or assumption. If two groups describe different problems, I may split the statement rather than negotiate a vague compromise.
Turn the statement into discovery and measurement
I use the statement to shape research questions and possible outcomes. I ask what I need to learn about the current behavior, what evidence would confirm or challenge the framing, and what progress would look like for the customer. I define guardrails when a change could improve one outcome while harming another.
I avoid choosing a metric merely because it is easy to count. A useful measure should connect to the problem and the customer’s progress. Depending on the context, that could be successful task completion, reduced rework, time to a meaningful outcome, recovery from an error, or a qualitative signal of confidence that I can investigate further.
I revisit the statement when new evidence changes the situation. Sometimes the problem becomes narrower. Sometimes the affected audience is different. Sometimes the real issue is a policy, workflow, or expectation rather than the interface I first suspected. Updating the statement is progress, not failure.
Example structure I use
My working format is simple: “For [specific customer] in [context], [problem or unmet need] makes it difficult to [desired progress], leading to [customer consequence]. We believe this matters because [evidence and impact]. We will learn more by [next investigation], while treating [key assumption or constraint] as unresolved.”
I keep the format flexible. The goal is not to make every problem sound the same; it is to make the customer, situation, evidence, consequence, and uncertainty visible. I connect the statement to a product discovery for product managers plan and only then compare solution options.
My bottom line is that a problem statement protects product teams from solving a request before understanding the need. I use it to create a shared starting point, invite better questions, and keep the decision open long enough for evidence to improve it.
Next step
Build stronger product discovery, communication, and outcome-focused decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
