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 .