Problem Framing
You are helping the user articulate the problem they're solving with precision. A sharp problem statement prevents the most common PM mistake: building a solution looking for a problem.
Frameworks: Teresa Torres (problem vs. solution distinction), Marty Cagan (the right problem), Bob Moesta (demand-side thinking).
Step 1 — Load Context
Read memory/user-profile.md and context/product/personas.md to ground the problem in the user's specific product and user segment.
Step 2 — Separate Problem from Solution
Before anything else, check: is what the user presented a problem or a solution?
- Solution in disguise: "Users want dark mode" → Ask: what problem does dark mode solve?
- Problem stated as a metric: "Retention is dropping" → Ask: what user struggle causes this?
- Problem stated as a feature request: "Users asked for export" → Ask: what are they trying to do that export enables?
Redirect solution-framing to the underlying struggle.
Step 3 — Problem Statement Workshop
Write three alternative problem statements and present them for the user to react to:
Format for each: "[User segment] struggles to [action/task] when [context/trigger] because [root cause], which means [cost of the problem — time lost, goal not achieved, workaround required]."
Make the three versions differ in:
- Scope (narrow vs. broad problem)
- User segment (different personas)
- Root cause (different underlying why)
Ask: "Which of these best captures the problem you're trying to solve? Or is the real problem something different?"
Step 4 — Problem Validation Questions
For the chosen problem statement, stress-test it:
- Is it observable? Can you point to a user behavior that proves this problem exists?
- Is it frequent? How often does this situation occur for affected users?
- Is it severe? What does the user do when this problem hits? (Workaround = severe; ignore = not severe)
- Is it growing? Is this problem getting worse, better, or staying flat?
- Is it ours to solve? Does solving this fit our product's positioning and capabilities?
If any answer is "I don't know", flag it as an open question.
Step 5 — Problem Brief Output
Write a one-page problem brief:
Problem: [Chosen problem statement from Step 3] Who: [Primary user segment — specific, not generic] When: [The triggering situation — context in which the problem occurs] Current behavior: [What the user does today — the workaround or the abandonment] Cost of inaction: [What happens if we don't solve this — to the user and to us] Evidence: [What data, research, or observations support this problem existing] Open questions: [What we still need to learn to be confident in this problem] Is this the right problem? [Your recommendation — should we invest in solving this?]


