Back to Details

problem-definition

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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
涵盖内容
  • 将模糊想法转化为清晰、可测试的问题定义
  • 撰写可共享的问题陈述（一句话概述+详细展开）
  • 记录**Jobs To Be Done (JTBD)**和目标用户群体
  • 梳理现有替代方案（包括非数字化/传统方案）以及“为何现在做/为何选择数字化”
  • 建立证据与假设日志以指导学习
  • 定义成功指标+约束条件和清晰的范围边界
适用场景
  • “为……撰写问题陈述”
  • “我们需要明确问题空间 / JTBD。”
  • “我们总是直接跳到解决方案，帮我们理清真正的问题。”
  • “有‘做AI’的压力——先确认是否存在真实的痛点。”
  • “在撰写PRD之前，先对齐我们要解决的问题。”
不适用场景
  • 你已经有获批的问题定义，需要可交付的PRD（使用
    writing-prds
    ）
  • 你需要在多个竞争项目中进行路线图优先级排序（使用
    prioritizing-roadmap
    ）
  • 你需要制定公司层面的战略/愿景（使用
    defining-product-vision
    ）
  • 你正在执行深度研究（招募用户、访谈、分析）；用此方法来规划要学习的内容，而非替代研究

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.
最低要求
  • 产品/背景信息 + 目标用户（或用户群体假设）
  • 触发信号（客户反馈、数据趋势、利益相关方需求、竞品动作）
  • 待做决策（例如：现在投入还是稍后投入；探索还是终止）+ 时间线
  • 已知约束条件（技术/法律/隐私/合规/资源容量）
缺失信息处理策略
  • 从references/INTAKE.md中提出最多5个问题。
  • 如果仍有缺失，基于明确标记的假设继续推进，并列出会改变决策的未解决问题。

Outputs (deliverables)

输出成果（交付物）

Produce a Problem Definition Pack in Markdown (in-chat; or as files if the user requests):
  1. Context snapshot (product, user, trigger, decision, constraints)
  2. Problem statement (1-liner + expanded) + why now
  3. JTBD (primary job + key sub-jobs) + target segment notes
  4. Current alternatives (including analog/non-digital) + gaps + switching costs
  5. Evidence & assumptions log (what we know vs what we’re guessing)
  6. Success criteria (outcome metric(s), leading indicators) + guardrails
  7. Scope boundaries (in/out, non-goals, dependencies)
  8. Prototype / learning plan (fast prototype + tests to de-risk)
  9. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
Expanded heuristics: references/WORKFLOW.md
生成Markdown格式的问题定义包（在对话中展示；或根据用户需求以文件形式输出）：
  1. 背景快照（产品、用户、触发信号、待做决策、约束条件）
  2. 问题陈述（一句话概述+详细展开）+ 为何现在推进
  3. JTBD（核心任务+关键子任务）+ 目标用户群体说明
  4. 现有替代方案（包括传统/非数字化方案）+ 差距+转换成本
  5. 证据与假设日志（已知内容 vs 猜测内容）
  6. 成功标准（结果指标、领先指标）+ 约束条件
  7. 范围边界（包含/排除内容、非目标、依赖项）
  8. 原型/学习计划（快速原型+测试以降低风险）
  9. 风险/未解决问题/后续步骤（必须包含）
模板：references/TEMPLATES.md
扩展启发：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8个步骤）

1) Intake + decision framing

1) 信息收集 + 决策框架搭建

  • 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 <date>”).
  • 输入： 用户提供的背景信息；references/INTAKE.md。
  • 行动： 明确待做决策、时间范围、利益相关方和约束条件。记录触发信号（数据/反馈/事件）。
  • 输出： 背景快照。
  • 检查项： 可以用一句话表述决策内容（“我们将在<日期>前决定是否……”）。

2) Define the target user + situation (segment + context)

2) 定义目标用户+场景（用户群体+背景）

  • 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)

3) 撰写问题陈述（一句话概述+详细展开）

  • 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.
  • 输入： 目标用户+触发信号。
  • 行动： 草拟清晰的一句话概述，然后展开描述症状、根本原因（假设）和影响。包含为何现在推进的原因。
  • 输出： 问题陈述部分（使用references/TEMPLATES.md模板）。
  • 检查项： 陈述内容仅描述问题，不涉及具体解决方案或技术。

4) Map current alternatives (including non-digital) + “why use this”

4) 梳理现有替代方案（包括非数字化方案）+ “为何选择此方案”

  • 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)

5) 区分问题与解决方案（避免盲目跟风）

  • 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.
  • 输入： 替代方案+早期解决方案想法（如有）。
  • 行动： 将解决方案想法记录为假设，而非承诺。如果提出“AI”（或任何技术），先陈述用户痛点，将技术选择视为实现细节。
  • 输出： 证据与假设日志（包含测试想法）。
  • 检查项： 每个假设都有对应的测试方案和置信度。

6) Define success criteria + guardrails

6) 定义成功标准+约束条件

  • 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

7) 可视化最终状态+规划清晰的原型路径

  • 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.
  • 输入： 成功标准+范围约束。
  • 行动： 描述“完成”的状态（用户可见的最终状态）。制定快速原型/实验计划，在开发前验证最不确定的假设。
  • 输出： 最终状态描述+原型/学习计划。
  • 检查项： 团队能够“看到最终目标”，并明确要测试的1-3个最大未知项。

8) Quality gate + finalize the pack

8) 质量检查+最终确定问题定义包

  • 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.
  • 输入： 完整的草稿包。
  • 行动： 对照references/CHECKLISTS.md检查，并使用references/RUBRIC.md评分。添加风险/未解决问题/后续步骤。
  • 输出： 最终的问题定义包。
  • 检查项： 利益相关方无需开会，异步审阅后即可决定“推进/暂停/终止”。

Quality gate (required)

质量检查（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、未解决问题、后续步骤。

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
.
示例1（B2B SaaS）： “为改进我们分析产品的新用户激活流程定义问题。”
预期输出：包含明确用户群体、现有新用户激活替代方案/变通方法、可衡量的激活成果、以及验证最不确定假设的原型计划的问题定义包。
示例2（消费类产品）： “移动端结账时用户流失率高；在提出修复方案前先明确问题空间和JTBD。”
预期输出：基于证据的问题陈述、替代方案梳理（包括“不采取任何行动”）、以及约束条件（欺诈/拒付/支持负载）。
边界案例： “为构建AI助手撰写PRD；我们不知道它要解决什么问题。”
回应：建议先推后PRD撰写；先使用此方法定义用户痛点和成功指标，再转交至
writing-prds
流程。