Problem Statement Skill

How this skill behaves (read first)

This is a generative skill, and a problem statement is where most product work quietly goes wrong. Claude's default is to restate a request as a problem and move on — producing the four classic failures: a solution in disguise ("users need a better search"), a vagueness ("the UX is bad," "the process is inefficient"), a business outcome posing as a problem ("we need to increase revenue"), or a symptom mistaken for the cause (churn is up → "fix churn"). Each one locks the team into solving the wrong thing, well. A good problem statement is a gap a real user experiences, in context, grounded in evidence, measurable, and free of any named solution. So this skill gates:

1. Establish what you actually have — a validated problem, or a prompt / signal / request / metric that only looks like one.
2. Apply the always-true core — separate problem from solution/symptom/goal, find the true cause, make it specific and measurable, ground it in evidence, bridge user and business.
3. Surface the context-dependent decisions (which definition tool, how much measurability now, reasoned vs. evidence-validated cause, scope) with trade-offs.

Then it hands off to pm-okr-metric-validity-audit (the measurable element) and pm-assumption-rigor-audit (the assumed root cause) for validation.

Scope: this skill owns the problem-statement artifact. It defers the broader problem-finding process to pm-discovery, hypothesis/experiment design to pm-assumption-testing, turning the statement into a full spec to pm-product-spec (audited by pm-spec-quality-audit), ranking which problem to tackle to pm-prioritization-rigor-audit / pm-prioritization, personas depth to pm-personas-jtbd, and user stories to pm-user-story.

Step 0 — Establish context before writing the statement

Ask if not known; state the assumption if proceeding without an answer: