PM-Copilot-by-Product-Faculty problem-framing

Use 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 user presents an idea and needs help distinguishing the problem from the solution. Do NOT use this skill if the user is ready to write a full PRD — use the execution/prd-authoring skill or /write-prd command instead.

install

source · Clone the upstream repo

git clone https://github.com/Productfculty-aipm/PM-Copilot-by-Product-Faculty

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/Productfculty-aipm/PM-Copilot-by-Product-Faculty "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/problem-framing" ~/.claude/skills/productfculty-aipm-pm-copilot-by-product-faculty-problem-framing && rm -rf "$T"

manifest: skills/problem-framing/SKILL.md

source content

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?]