Write a customer problem statement without guessing
Describe the person, situation, current workaround, and consequence using evidence from actual conversations or observation.

A customer problem statement should describe a specific person in a specific situation, the work they are trying to do, and the friction they experience. Use evidence from conversations or observation. Do not turn a founder’s preferred feature into a problem customers supposedly have.
Separate the problem from the solution
“People need an AI scope generator” names your proposed solution. “Freelancers receive vague requests and spend time clarifying what the client expects” describes a possible problem. It still needs evidence about which freelancers, which requests, and how often or consequentially this occurs.
Build an evidence-backed sentence
For [specific person], when [situation], doing [task] is difficult because
[observed friction]. They currently [workaround], which leads to
[supported consequence]. We still need to learn [important unknown].In a fictional example: “For solo web designers, when a client sends a loose redesign request, defining the deliverables is difficult because pages and revision limits are unspecified. They currently clarify by email. We still need to learn whether a structured brief reduces that back-and-forth.” The last sentence prevents a proposed benefit from sounding measured.
Inspect each part
| Claim | Evidence to look for |
|---|---|
| Specific audience | Relevant participant or observation |
| Recurring situation | Actual recent example |
| Workaround | Steps or tools used |
| Consequence | Reported or observed effect |
| Proposed improvement | Test still needed |
Use AI as an editor
Edit this problem statement using only the supplied evidence.
Separate customer statements, observations, and our assumptions.
Remove solution language from the problem description.
Flag claims about frequency, cost, or impact that lack evidence.
Notes and draft: [paste]Keep the statement short enough to guide a decision, but preserve the uncertainty that matters. Update it when new evidence changes the audience or problem. The goal is a useful boundary for what to build and whom to help, not a dramatic claim about a universal pain point.



