Product Problem Statement Template: Turn Requests into Evidence
Use this product problem statement template to move from a feature request to user evidence, capture what is still unknown, and give product and engineering a clear next step.
Share
A product problem statement is a short, evidence-linked description of who is struggling, in what situation, what they do today, the consequence, and what is still unknown. It helps founders, product managers, product engineers, and product builders agree on the problem before choosing a feature or writing a build brief.
The short answer
Use this structure: When [specific person and situation], they are trying to [goal], but [observable friction]. Today they [workaround], which leads to [consequence]. We saw this in [evidence]. We still need to learn [unknown]. We will know we are helping when [observable change].
A problem statement is useful when it gives a team enough evidence to decide what to learn or do next, while leaving room for more than one solution.
Copyable product problem statement template
Paste this into a brief or issue, then fill only what you can support. Write “unknown” where the evidence is missing.
Decision we need to make:
[What will the team decide after learning more?]
User and situation:
[Who experiences this, and when does it happen?]
Goal:
[What are they trying to accomplish?]
Observed behavior:
[What did they say or do in a recent, specific instance? Link the source.]
Current workaround:
[What do they do now? What tools, people, or steps are involved?]
Consequence:
[What becomes slower, riskier, confusing, or impossible? Use evidence; do not invent a number.]
Problem statement:
[When / user / goal / friction / workaround / consequence.]
What we know:
[Observations and evidence, with source links.]
What we are assuming:
[Interpretations or explanations that still need checking.]
What is still unknown:
[Questions that could change the decision.]
Desired outcome:
[What should the user be able to do or experience?]
Next step:
[The smallest interview, prototype, data check, or experiment that can reduce uncertainty.]
This template makes evidence, interpretation, and action visible as separate things. The GOV.UK research-analysis guide recommends recording what researchers saw or heard before writing what they think it means. That separation makes it easier for another teammate to check the source and challenge an assumption.
Example: turn a feature request into a problem to investigate
S
Specky Team
Writing about AI-native product development at Specky.
Request: “Add a notification whenever a project status changes.”
Fictional example: A product engineer says they sometimes miss an important blocker because project updates are spread across chat and an issue tracker. They open both tools and ask a teammate for a summary before deciding what to do. This points to a possible problem with finding current status; it does not prove that more notifications are the right solution. The team still needs to learn how often this happens, which updates matter, and whether a clearer status view would solve it.
A useful next step could be to review a few recent examples with engineers, note what information they were looking for, then test a status summary with one real workflow. The example is illustrative; it is not a Specky customer result or benchmark.
Scrum.org’s business problem statement examples also connect the problem to customer success and observable behavior. Keep any target measure specific to your own product and baseline; a template cannot supply a valid success number for you.
How to write a product problem statement
1. Start with a decision, not a feature
Write the decision the team is trying to make: build a capability, change an existing workflow, run a test, gather more evidence, or stop. This prevents the problem statement from becoming a justification for a solution chosen in advance.
A feature request is still useful. Treat it as a clue about a user’s situation, not proof that the requested feature is the best response. The feature-request prioritization workflow can help you compare requests after you understand the underlying needs.
2. Describe a person in a real context
“Users need better visibility” is too broad to investigate. Name the kind of person and the moment: “A solo founder checking whether a customer issue is ready for engineering before the weekly planning call.”
Keep the segment as narrow as the evidence allows. If you have only spoken with one person, say that. Do not turn one example into a claim about every customer.
3. Capture what happened before explaining it
Record a recent action, short quote, or observed workflow, plus a link or reference to its source. Then add your interpretation in a separate field. For interview notes and cross-interview patterns, use this customer-interview synthesis template.
For example:
Observation: The engineer searched chat for the original request, then opened the ticket to find its status.
Interpretation: The team may not have one reliable place to see the current decision.
Idea: Add a status digest.
Only the first line is direct evidence. The other two are hypotheses until checked.
4. Name the workaround and its consequence
A workaround shows how the person manages today. Ask what they did the last time, who helped, what they tried, and what happened next. Consequences can include delay, repeated work, risk, confusion, or a missed opportunity. Use the consequence you can support; leave its size unknown when you have not measured it.
5. Keep open questions visible
A useful problem statement does not hide uncertainty. Note the alternative explanations that would change your response. Perhaps people need fewer notifications, clearer ownership, or a better way to find decisions. A short problem statement can still hold several plausible solutions.
6. Define an outcome before writing acceptance checks
Describe what should become easier or more reliable for the user. When you can, choose an observable behavior rather than a vague goal such as “improve experience.” After the team selects an approach, turn the problem into scoped requirements and acceptance checks with the product requirements guide or the free AI PRD generator.
Using the template with product engineers and AI builders
A product engineer or AI builder can use the same statement before opening a coding agent. Add the relevant product context, constraints, non-goals, source links, and unresolved decisions. Ask the agent to point out missing information and draft possible approaches; do not ask it to invent customer evidence or decide that a request deserves priority.
The need for this handoff is showing up in current practitioner discussions: one recent r/ProductManagement thread asks how teams should use engineering capacity when AI has made delivery faster than discovery. That conversation is qualitative and self-selected, not a measure of how common the problem is. It is a useful reminder to keep the customer situation attached when work moves from product into code.
For the implementation handoff, pair the statement with a clear scope and reviewable checks. The AI-agent acceptance checklist helps teams review what an agent produced without treating a plausible-looking result as proof that the user problem was solved.
Product problem statement checklist
Before sharing the brief, check that:
A teammate can identify who has the problem and when it occurs.
The statement describes a user goal and an observed obstacle.
The current workaround and consequence are concrete.
Evidence links are close to the observations they support.
Assumptions and unknowns are labeled.
The statement leaves room for multiple solutions.
The next step can change the team’s understanding or decision.
Frequently asked questions
What is a product problem statement?
It is a concise description of a user’s situation, goal, obstacle, current workaround, and consequence, supported by evidence. It helps a team agree on what needs to be understood before deciding which solution to build.
How is a problem statement different from a feature request?
A feature request proposes a solution, such as adding a notification. A problem statement describes the user and the situation that led to the request, including what they do today and what remains uncertain. A request can help you find a problem; it does not settle the solution.
Can AI write a product problem statement?
AI can organize notes, identify missing fields, and draft a statement for a person to review. The researcher or product owner still needs to check every claim against its source, label assumptions, and decide what evidence is sufficient for the next step.
Who should write it?
The person closest to the decision can start it, but product, design, and engineering should be able to inspect and correct the evidence. Product engineers and AI builders can add technical constraints and implementation questions without replacing the user problem with a solution.
The goal is a small, checkable brief that keeps the user’s situation attached to the next product decision.