From pm-copilot
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.
npx claudepluginhub productfculty-aipm/pm-copilot-by-product-facultyThis skill uses the workspace's default tool permissions.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
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).
Read memory/user-profile.md and context/product/personas.md to ground the problem in the user's specific product and user segment.
Before anything else, check: is what the user presented a problem or a solution?
Redirect solution-framing to the underlying struggle.
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:
Ask: "Which of these best captures the problem you're trying to solve? Or is the real problem something different?"
For the chosen problem statement, stress-test it:
If any answer is "I don't know", flag it as an open question.
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?]