Problem Definition
Scope
Covers
- Turning a vague idea into a crisp, testable problem definition
- Writing a shareable problem statement (1-liner + expanded)
- Capturing Jobs To Be Done (JTBD) and target segments
- Mapping current alternatives (including non-digital/analog) and “why now / why digital”
- Building an evidence + assumptions log to drive learning
- Defining success metrics + guardrails and clear scope boundaries
When to use
- “Write a problem statement for…”
- “We need to define the problem space / JTBD.”
- “We keep jumping to solutions; help us get clear on the real problem.”
- “Pressure to ‘do AI’ — verify there’s a real pain point first.”
- “Before we write a PRD, align on what problem we’re solving.”
When NOT to use
- You already have an approved problem definition and need a delivery-ready PRD (use
writing-prds) - You need roadmap prioritization across many competing initiatives (use
prioritizing-roadmap) - You need to set company-level strategy/vision (use
defining-product-vision) - You’re doing deep research execution (recruiting, interviews, analysis); use this to frame *what to learn*, not as a substitute for research
Inputs
Minimum required
- Product/context + target user (or segment hypotheses)
- The triggering signal (customer quotes, data trend, stakeholder request, competitor move)
- The decision to make (e.g., invest now vs later; explore vs stop) + timeline
- Known constraints (tech/legal/privacy/compliance/capacity)
Missing-info strategy
- Ask up to 5 questions from references/INTAKE.md.
- If still missing, proceed with clearly labeled assumptions and list Open questions that would change the decision.
Outputs (deliverables)
Produce a Problem Definition Pack in Markdown (in-chat; or as files if the user requests):
- Context snapshot (product, user, trigger, decision, constraints)
- Problem statement (1-liner + expanded) + why now
- JTBD (primary job + key sub-jobs) + target segment notes
- Current alternatives (including analog/non-digital) + gaps + switching costs
- Evidence & assumptions log (what we know vs what we’re guessing)
- Success criteria (outcome metric(s), leading indicators) + guardrails
- Scope boundaries (in/out, non-goals, dependencies)
- Prototype / learning plan (fast prototype + tests to de-risk)
- Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md Expanded heuristics: references/WORKFLOW.md
Workflow (8 steps)
1) Intake + decision framing
- Inputs: User context; references/INTAKE.md.
- Actions: Clarify the decision, time horizon, stakeholders, and constraints. Capture the trigger signal (data/quotes/event).
- Outputs: Context snapshot.
- Checks: You can state the decision in one sentence (“We are deciding whether to… by ”).
2) Define the target user + situation (segment + context)
- Inputs: Context snapshot.
- Actions: Specify who experiences the problem, when it happens, frequency, and what’s at stake. If multiple segments, pick a primary and list others as secondary.
- Outputs: Target user + context bullets.
- Checks: The segment is specific enough that a researcher could recruit for it.
3) Write the problem statement (1-liner + expanded)
- Inputs: Target user + trigger signal.
- Actions: Draft a crisp 1-liner, then expand with symptoms, root causes (hypotheses), and impact. Include why now.
- Outputs: Problem statement section (using references/TEMPLATES.md).
- Checks: Statement describes the problem without implying a specific solution or technology.
4) Map current alternatives (including non-digital) + “why use this”
- Inputs: Problem statement.
- Actions: List how users solve this today (manual workarounds, spreadsheets, incumbents, doing nothing). Include at least one analog/non-digital alternative when relevant.
- Outputs: Alternatives table + gaps + switching costs.
- Checks: You can answer: “Why would a user give this the time of day vs their current way?”
5) Separate problem from solution (avoid the shiny object trap)
- Inputs: Alternatives + early solution ideas (if any).
- Actions: Capture solution ideas as hypotheses, not commitments. If “AI” (or any tech) is proposed, state the user pain point first and treat tech choice as an implementation detail.
- Outputs: Evidence & assumptions log (with test ideas).
- Checks: Each assumption has a proposed test and a confidence level.
6) Define success criteria + guardrails
- Inputs: Problem statement + evidence.
- Actions: Define measurable outcomes, leading indicators, and guardrails (quality, trust, cost, latency, support load, etc.).
- Outputs: Success metrics + guardrails section.
- Checks: Metrics are unambiguous and tied to the user’s desired outcome.
7) Visualize the end state + prototype a path to clarity
- Inputs: Success criteria + scope constraints.
- Actions: Describe what “done” looks like (user-visible end state). Create a fast prototype/experiment plan to validate the hardest assumptions before building.
- Outputs: End-state description + prototype/learning plan.
- Checks: The team can “see the end” and name the 1–3 biggest unknowns being tested.
8) Quality gate + finalize the pack
- Inputs: Full draft pack.
- Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks/Open questions/Next steps.
- Outputs: Final Problem Definition Pack.
- Checks: A stakeholder can review async and decide “proceed / pause / stop” without a meeting.
Quality gate (required)
- Use references/CHECKLISTS.md and references/RUBRIC.md.
- Always include: Risks, Open questions, Next steps.
Examples
Example 1 (B2B SaaS): “Define the problem for improving onboarding activation in our analytics product.” Expected: a pack with a tight segment, current onboarding alternatives/workarounds, measurable activation outcomes, and a prototype plan to test the most uncertain hypothesis.
Example 2 (Consumer): “Users abandon checkout on mobile; define the problem space and JTBD before proposing fixes.” Expected: a problem statement grounded in evidence, an alternatives map (including ‘do nothing’), and guardrails (fraud/chargebacks/support load).
Boundary example: “Write a PRD for building an AI assistant; we don’t know what problem it solves.” Response: push back; run this skill to define the user pain point and success metrics first, then hand off to writing-prds.