Customer Problem Statement for Product Managers: template, structure and example
A Product Manager's Customer Problem Statement clarifies the problem before anyone commits to a solution: the affected users, the current-state process, the impact, the evidence and the constraints. It becomes a shared reference point that stops the team jumping to a solution before the problem itself is agreed, in the Discover phase.
Reviewed by Gensudo Team · Last reviewed 24 July 2026
When to use it
Write it early in Discover, when you need to fix a shared understanding of a customer problem before ideation or investment. Use it when you must explain not just what is happening but why acting on it is right, and when senior stakeholders should be able to challenge the thinking before cost and effort increase. It should precede an Opportunity Assessment.
When not to use it
Do not use it to specify a solution or its requirements; a PRD in Define is the place for scope, behaviour and acceptance conditions. If the problem is already well evidenced and agreed and you are weighing options and value, an Opportunity Assessment is the better next document.
What you need before you start
- Customer evidence and research method notes
- A clear view of who is affected: the personas and segments, and the triggers that bring the problem on
- The current-state process and the workarounds users accept today
- Evidence of impact on users and the business, with any thin spots noted
- The underlying root causes and known workflow, technical, data and organisational constraints
- A sense of strategic fit and why the problem matters now
Recommended structure, section by section
- Problem Statement — The customer problem stated plainly, covering the affected user, the context, the pain, how often it occurs, the outcome they want, and what is explicitly out of scope. One tight paragraph.
- Affected Users and Context — Who experiences the problem, the personas and segments affected, and the situations and triggers that bring it on. A few tight sentences.
- Impact and Evidence — What the problem costs users and the business, the workarounds they accept today, and the evidence that it is real and material, noting where the evidence is thin. A short paragraph plus a few evidence points.
- Root Causes and Constraints — The underlying causes and the workflow, technical, data and organisational constraints behind the problem. Two or three points.
- Strategic Fit and Timing — Why this problem matters now, across its fit with strategy, the customer urgency, and the commercial or market timing. A few sentences.
- Success Indicators — The measurable signals that would show the problem has been reduced or solved. Three to five indicators.
What good looks like
It is strong when another product lead can understand the issue without a long verbal explanation from you. Quality means the problem is supported by evidence, not personal preference, with assumptions stated and evidence kept separate from opinion so the reader can see how conclusions were reached. A new reader can describe its purpose, see the recommended next step, identify who approved it, and know what would trigger an update.
Quality checklist
- The problem is stated plainly in one tight paragraph, with what is out of scope made explicit
- Evidence is separated from opinion, and thin evidence is flagged honestly
- Customer evidence and research method notes are attached
- Root causes and constraints are identified, not just symptoms
- Success indicators are measurable, with three to five signals defined
- The recommendation, accountable owner, risks, dependencies and date of next review are confirmed
- Final sign-off sits with the Product Manager, with accountable product, design and delivery leads in agreement
Who creates it, and when
In Gensudo this document is a governed template for:
- Product Manager in the Discover phase (as “Customer Problem Statement”)
Where it sits in the flow
Before this document: Jobs to Be Done Analysis for Product Managers · Product Discovery Brief for Product Managers
This unblocks: Opportunity Assessment for Product Managers · Product Requirements Document (PRD) for Product Managers
Frequently asked questions
How is this different from an Opportunity Assessment?
The Customer Problem Statement agrees the problem: who is affected, the impact, the evidence and the constraints. The Opportunity Assessment comes next and weighs whether and how to act on it. Agreeing the problem first stops the team solving the wrong thing.
How long should it be?
Concise. The problem itself belongs in one tight paragraph, affected users in a few tight sentences, and impact in a short paragraph plus a few evidence points. The aim is a position teams can repeat, not a long report.
What if the evidence is thin?
Say so. Note where the evidence is weak rather than overstating it. Being honest about uncertainty is what lets senior stakeholders challenge the thinking early, before cost and effort increase.
Why separate evidence from opinion?
So the reader can see how conclusions were reached and judge them independently. A problem supported by evidence rather than personal preference is far harder to dismiss and far easier to build shared commitment around.
Create this document in Gensudo
The governed template, role-specific guidance and AI drafting grounded in cited evidence.
Get started