$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill problem-framingUse this skill when the user asks to "frame a problem", "define the problem", "write a problem statement", "articulate the user problem", "what problem are we solving", "help me think through the problem", "is this the right problem to solve", "clarify the problem", or when a use
| 1 | # Problem Framing |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | Frameworks: Teresa Torres (problem vs. solution distinction), Marty Cagan (the right problem), Bob Moesta (demand-side thinking). |
| 6 | |
| 7 | ## Step 1 — Load Context |
| 8 | |
| 9 | Read `memory/user-profile.md` and `context/product/personas.md` to ground the problem in the user's specific product and user segment. |
| 10 | |
| 11 | ## Step 2 — Separate Problem from Solution |
| 12 | |
| 13 | Before anything else, check: is what the user presented a problem or a solution? |
| 14 | |
| 15 | - **Solution in disguise:** "Users want dark mode" → Ask: what problem does dark mode solve? |
| 16 | - **Problem stated as a metric:** "Retention is dropping" → Ask: what user struggle causes this? |
| 17 | - **Problem stated as a feature request:** "Users asked for export" → Ask: what are they trying to do that export enables? |
| 18 | |
| 19 | Redirect solution-framing to the underlying struggle. |
| 20 | |
| 21 | ## Step 3 — Problem Statement Workshop |
| 22 | |
| 23 | Write three alternative problem statements and present them for the user to react to: |
| 24 | |
| 25 | **Format for each:** |
| 26 | "[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]." |
| 27 | |
| 28 | Make the three versions differ in: |
| 29 | 1. Scope (narrow vs. broad problem) |
| 30 | 2. User segment (different personas) |
| 31 | 3. Root cause (different underlying why) |
| 32 | |
| 33 | Ask: "Which of these best captures the problem you're trying to solve? Or is the real problem something different?" |
| 34 | |
| 35 | ## Step 4 — Problem Validation Questions |
| 36 | |
| 37 | For the chosen problem statement, stress-test it: |
| 38 | |
| 39 | 1. **Is it observable?** Can you point to a user behavior that proves this problem exists? |
| 40 | 2. **Is it frequent?** How often does this situation occur for affected users? |
| 41 | 3. **Is it severe?** What does the user do when this problem hits? (Workaround = severe; ignore = not severe) |
| 42 | 4. **Is it growing?** Is this problem getting worse, better, or staying flat? |
| 43 | 5. **Is it ours to solve?** Does solving this fit our product's positioning and capabilities? |
| 44 | |
| 45 | If any answer is "I don't know", flag it as an open question. |
| 46 | |
| 47 | ## Step 5 — Problem Brief Output |
| 48 | |
| 49 | Write a one-page problem brief: |
| 50 | |
| 51 | **Problem:** [Chosen problem statement from Step 3] |
| 52 | **Who:** [Primary user segment — specific, not generic] |
| 53 | **When:** [The triggering situation — context in which the problem occurs] |
| 54 | **Current behavior:** [What the user does today — the workaround or the abandonment] |
| 55 | **Cost of inaction:** [What happens if we don't solve this — to the user and to us] |
| 56 | **Evidence:** [What data, research, or observations support this problem existing] |
| 57 | **Open questions:** [What we still need to learn to be confident in this problem] |
| 58 | **Is this the right problem?** [Your recommendation — should we invest in solving this?] |