A problem statement that engineers respect has five properties: it names a specific person, describes what they currently do, identifies where that breaks, quantifies the cost, and states what success looks like. Most problem statements have none of these properties.
"Users have trouble with the onboarding flow" is not a problem statement. It is a vague complaint. It tells an engineer nothing about what to build, who it is for, or whether the solution is working.
The five-part framework
1. Name the persona. Not "users" — a specific role, context, and level of sophistication. "Senior product managers at B2B SaaS companies managing 3+ features simultaneously" is a persona. "Users" is a placeholder.
The reason specificity matters: a problem that applies to everyone applies to no one. When you name the persona, you make implicit constraints explicit. A senior PM's problem statement will look completely different from a junior PM's problem statement, even if the surface complaint is identical.
2. Describe the current state. What does this person currently do to accomplish the goal? Walk through the exact steps, including the workarounds they have constructed. The workarounds are often the most important part — they tell you where the biggest friction is and what the user actually values.
"Currently, the PM writes the PRD in Notion, manually creates tickets in Linear, copies acceptance criteria from Notion into each ticket, and cross-references both documents to verify nothing was missed. This takes 40 minutes per feature and introduces errors when sections are updated in Notion but not propagated to Linear."
That is a current state. It is specific, it is verifiable, and it tells an engineer exactly what they are replacing.
3. Identify the friction point. The moment where the current process fails. What breaks, takes too long, requires too much skill, or produces an incorrect result? Be precise about the failure mode.
"The friction is the copy-paste step between Notion and Linear. It is manual, error-prone, and repeated every time either document is updated."
4. Quantify the impact. Attach a number. Time lost per occurrence. Error rate. Cost per failure. Frequency. Unquantified pain is easy to deprioritize because there is nothing to compare it against.
"40 minutes per feature × 4 features per week × 20 PMs = 3,200 PM-hours per year spent on manual copy-paste."
5. State the desired outcome. What does success look like for the persona after the problem is solved? Not for the company — for the person. Be specific about what changes in their day.
"The PM generates engineering tickets directly from the PRD and exports them to Linear in one click. Updates to the PRD propagate to Linear automatically. The copy-paste step is eliminated."
What this looks like assembled
Senior product managers at B2B SaaS companies currently spend 40 minutes per feature manually transferring content from their PRD tool to their engineering ticket system. This step is error-prone — acceptance criteria frequently drift between the two documents — and must be repeated every time either document is updated. This costs 3,200 PM-hours per year across a 20-person product org. We will solve this by generating engineering tickets directly from the PRD and providing one-click export to Linear, Jira, and GitHub Issues, with bidirectional sync to keep documents in alignment.
That is a problem statement engineers respect. It is specific, quantified, and tells them exactly what success looks like. It takes about 5 minutes to write when you have the right framework. It saves hours of clarification meetings and rework.