pm-problem-statement
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseProblem Statement Skill
问题陈述 Skill
How this skill behaves (read first)
此 Skill 的行为方式（请先阅读）
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:
- Establish what you actually have — a validated problem, or a prompt / signal / request / metric that only looks like one.
- 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.
- 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 (the measurable element) and (the assumed root cause) for validation.
pm-okr-metric-validity-auditpm-assumption-rigor-auditScope: this skill owns the problem-statement artifact. It defers the broader problem-finding process to , hypothesis/experiment design to , turning the statement into a full spec to (audited by ), ranking which problem to tackle to / , personas depth to , and user stories to .
pm-discoverypm-assumption-testingpm-product-specpm-spec-quality-auditpm-prioritization-rigor-auditpm-prioritizationpm-personas-jtbdpm-user-story这是一个生成型 Skill，而问题陈述正是大多数产品工作悄然出错的地方。Claude 的默认做法是把请求换个说法，当成问题，然后继续推进——这会导致四类经典失败：伪装成问题的解决方案（“用户需要更好的搜索”）、含糊其辞（“UX 很糟糕”“流程效率低下”）、伪装成问题的业务结果（“我们需要提高收入”），或把症状误当成原因（流失率上升 →“修复流失”）。每一种都会让团队偏离正确方向，并且“解决”得非常彻底。好的问题陈述应当描述一个真实用户在特定情境中经历的差距，它有证据支撑、可衡量，而且不包含任何指定的解决方案。因此，本 Skill 会把关：
- 确认你手上实际拥有的东西——一个已验证的问题，还是仅仅看起来像问题的提示 / 信号 / 请求 / 指标。
- 应用始终成立的核心原则——区分问题与解决方案 / 症状 / 目标，找出真正原因，使其具体且可衡量，以证据为依据，并连接用户与业务。
- 呈现依赖上下文的决策（使用哪种定义工具、当前需要多大程度的可衡量性、根因是推理所得还是经过验证、范围），并说明各自的权衡。
随后，它会将内容移交给 （可衡量要素）和 （假定的根因）进行验证。
pm-okr-metric-validity-auditpm-assumption-rigor-audit范围：本 Skill 负责问题陈述这一交付物。更广泛的问题发现流程交由 ；假设 / 实验设计交由 ；将陈述转化为完整 spec 交由 （由 审计）；问题优先级排序交由 / ；personas 深度交由 ；用户故事交由 。
pm-discoverypm-assumption-testingpm-product-specpm-spec-quality-auditpm-prioritization-rigor-auditpm-prioritizationpm-personas-jtbdpm-user-storyStep 0 — Establish context before writing the statement
第 0 步——撰写陈述前建立上下文
Ask if not known; state the assumption if proceeding without an answer:
- What do you actually have in hand? A moving metric, a feature request ("add X"), or a vague directive ("improve onboarding") is a signal or a solution, not a problem. Restate it without metrics, tools, or desired outcomes first. The test: could the sentence plausibly be said by the person experiencing the issue?
- Whose problem, and in what context? A problem needs a specific group, moment, and difficulty. "Improve engagement" becomes workable only as "new users abandon setup because the required steps are unclear."
- What evidence backs it — and is the cause known or assumed? Distinguish what you've verified from what you're inferring. The root cause at this stage is usually a reasoned claim, not a proven one.
- What is the statement feeding? A spec, a discovery effort, an OKR, or an interview/case answer — this sets how measurable and formal it needs to be.
如尚不清楚，先询问；如果没有回答也要继续，则说明假设：
- 你手上实际有什么？ 一个变化中的指标、一项功能请求（“添加 X”），或一项模糊的指令（“改进 onboarding”），都只是信号或解决方案，不是问题。先去掉指标、工具和期望结果，重新表述。检验方法：这句话是否可能由正经历该问题的人说出？
- 这是谁的问题，发生在什么情境？ 问题需要明确的对象、时机和困难。“提高参与度”只有改写为“新用户因必需步骤不清楚而放弃设置”才可处理。
- 有什么证据支持它——原因已知还是仅为假设？ 区分已经验证的内容与推断的内容。此阶段的根因通常只是一个基于推理的主张，而非已经证实。
- 这份陈述将用于什么？ spec、问题发现工作、OKR，或访谈 / 案例答案——这决定了它需要达到何种可衡量程度和正式程度。
The always-apply core (true for any problem statement)
始终适用的核心原则（适用于所有问题陈述）
- A problem is a gap, never a feature. It describes the distance between the current and desired state from the user's point of view, with no solution named. Translate "we need to add / we should build / the product lacks…" into a neutral description of what is difficult, slow, confusing, or risky. Test: if only one solution could address it, it's a solution in disguise — a real problem leaves room for several.
- Separate the problem from symptoms, goals, and constraints. A moving metric (churn, low adoption) is a symptom; "increase retention/revenue" is a goal or business outcome; budget and timeline are constraints. The problem sits underneath them — the user difficulty that causes the symptom. "We need to increase revenue" is never the problem.
- Find the true cause, not the surface. Use 5 Whys / reasoning to get from symptom to root. The cause must logically explain the symptom and survive being challenged ("the feature is already shown in onboarding, so 'users don't know it exists' doesn't hold — more likely it appears at the wrong moment"). Treat the cause as an explanation that has to stay consistent under questioning.
- Be specific and fact-based. "Users are unhappy" hides the cause and the impact. Name who is affected, when/where it happens, the concrete obstacle, and the measurable consequence. ❌ "We need to redesign the app." ✅ "Users fail to complete purchases because navigation between product and checkout pages is unclear."
- Make it measurable. Include a metric so success is checkable and scope is bounded ("decrease cart abandonment 15% within a month"). The measurable element doubles as a future key result. Without it, you can't know if you succeeded — but keep it a real outcome, not a vanity count.
- Ground it in evidence, not internal assumption. Verify the problem against user signals — interviews, support tickets, analytics, session replays — and synthesize patterns. Coding qualitative feedback into quantitative findings ("45% of reports mention a checkout error") turns opinion into evidence. A statement built only on what the team believes is the failure mode.
- Bridge user and business. Connect the user difficulty to its business impact (lost conversions, churn, cost, risk) so it earns attention — without treating user needs and business goals as competing. Translate a business problem into the user problem beneath it: "not enough signups" → why aren't users signing up (unclear value? complex flow? trust?).
- Test the statement before using it. Can design, engineering, and leadership each understand who is affected, why it matters, and what's wrong — without extra explanation, and without a solution baked in? If it keeps needing reinterpretation, it isn't done.
A workable structure: problem + consequence/impact + intended goal, carrying who / when-context / measurable element — or the 4 Ws (Who, What, Where, Why) for the user-centric framing.
- 问题是差距，绝不是功能。 它从用户视角描述当前状态与期望状态之间的距离，且不指名任何解决方案。将“我们需要添加 / 我们应当构建 / 产品缺少……”转译为中性的描述：什么难以完成、缓慢、令人困惑或有风险。*检验：*如果只有一种解决方案能够处理它，那么它就是伪装的解决方案——真正的问题应为多种方案留出空间。
- 将问题与症状、目标和约束区分开。 变化中的指标（流失率低、采用率低）是症状；“提高留存率 / 收入”是目标或业务结果；预算和时间表是约束。问题位于它们之下——正是导致症状的用户困难。“我们需要提高收入”永远不是问题。
- 找到真正原因，而非表面现象。 使用 5 Whys / 推理，从症状追溯到根因。原因必须能够合理解释症状，并经得起质疑（“该功能已经在 onboarding 中展示，所以‘用户不知道它存在’并不成立——更可能是它在错误的时机出现”）。将原因视为一种必须在质疑下保持一致的解释。
- 具体且基于事实。 “用户不满意”掩盖了原因和影响。说明谁受到影响、何时 / 在哪里发生、具体障碍是什么，以及可衡量的后果。❌ “我们需要重新设计这款 App。” ✅ “用户无法完成购买，因为产品页与结账页之间的导航不清楚。”
- 使其可衡量。 纳入一个指标，以便检查成功情况并界定范围（“一个月内将购物车放弃率降低 15%”）。可衡量要素同时可作为未来的关键结果。没有它，你就无法知道是否成功——但要确保它是真实结果，而不是虚荣性计数。
- 以证据为依据，而非内部假设。 通过用户信号验证问题——访谈、支持工单、分析数据、会话回放——并归纳模式。将定性反馈编码为定量发现（“45% 的反馈提到结账错误”），可以把意见转化为证据。仅以团队对失败模式的判断为基础的问题陈述。
- 连接用户与业务。 将用户困难与其业务影响联系起来（转化损失、流失、成本、风险），从而让问题值得关注——同时不要把用户需求与业务目标视为相互竞争。将业务问题转译为其下方的用户问题：“注册量不足”→为什么用户没有注册（价值不清楚？流程复杂？缺乏信任？）。
- 使用前检验陈述。 设计、工程和团队负责人是否都能在无需额外解释、且未夹带解决方案的情况下，理解谁受到影响、为什么重要以及出了什么问题？如果每次都需要重新解释，它就没有完成。
一种可行的结构：问题 + 后果 / 影响 + 预期目标，并包含谁 / 何时的情境 / 可衡量要素——或者采用以用户为中心的 4 Ws 框架（Who、What、Where、Why）。
The context-dependent decisions (surface, don't auto-apply)
依赖上下文的决策（呈现出来，不要自动套用）
Present each with its trade-off and a recommendation tied to Step 0; let the user choose. Running every framework on every prompt is the failure mode — reach for the tool that closes the specific gap.
| Decision | Apply when | Avoid / adapt when | Default recommendation |
|---|---|---|---|
| Which definition tool | Match to the gap: personas / empathy map (who & feelings unclear), journey map (where in the flow), 5 Whys / affinity (cause unclear), assumption mapping (team beliefs unchecked) | Running every framework as ritual, which buries the problem in artifacts | A 5 Whys pass + a Who/What/Where/Why framing; add others only if a specific gap remains |
| How much measurability now | Feeding a spec or committing resources — include a metric and tie it to an OKR | Earliest framing where any number would be a guess | Add the measurable element once the problem is validated; keep it falsifiable, not vanity |
| Reasoned vs. evidence-validated cause | A reasoned cause is fine for interviews, case work, or early low-stakes framing | Committing real build resources on a cause that's never been checked against users | Reason first, then validate with user evidence before the spec; scale rigor to the stakes |
| Ambiguity: assume vs. ask | Ask only the 1–2 questions that would change the framing; otherwise state a grounded assumption | Asking about every unknown (stalls) or silently guessing (hidden risk) | State explicit assumptions; ask only what moves the framing |
| Scope / granularity | Narrow to a specific segment + moment so analysis can proceed | Too broad ("improve UX") or arbitrarily narrow | One clear group, situation, and difficulty — broad enough for multiple solutions, narrow enough to act |
逐一呈现每项决策及其权衡，并给出与第 0 步相关的建议；让用户选择。对每个提示都运行所有框架正是失败模式——应选择能弥补特定差距的工具。
| 决策 | 何时采用 | 何时避免 / 调整 | 默认建议 |
|---|---|---|---|
| 使用哪种定义工具 | 与差距匹配：personas / empathy map（对象和感受不清楚）、journey map（流程中的位置不清楚）、5 Whys / affinity diagram（原因不清楚）、assumption mapping（团队主张尚未核查） | 把每个框架都当成仪式来运行，从而让问题淹没在文档产物中 | 先进行一次 5 Whys，并采用 Who / What / Where / Why 框架；仅在仍有特定差距时补充其他工具 |
| 当前需要多大程度的可衡量性 | 陈述将用于 spec 或资源承诺时——纳入指标并与 OKR 关联 | 在最早期的问题构建中，任何数字都只是猜测时 | 问题验证后再加入可衡量要素；确保它可证伪，而不是虚荣指标 |
| 推理所得的原因 vs. 经证据验证的原因 | 对访谈、案例工作或早期低风险的问题构建而言，基于推理的原因已足够 | 因从未与用户核查过的原因而投入真实开发资源时 | 先进行推理，再在编写 spec 前用用户证据验证；严格程度应与风险高低匹配 |
| 歧义：假设 vs. 询问 | 只询问那 1–2 个会改变问题构建方式的问题；其他情况则陈述有依据的假设 | 询问每一个未知项（造成停滞），或默默猜测（隐藏风险） | 明确陈述假设；只询问会改变问题框架的事项 |
| 范围 / 粒度 | 缩小到一个具体群体、时刻和困难，使分析能够继续 | 过于宽泛（“改善 UX”）或随意地过窄 | 一个明确的群体、情境和困难——要足够宽泛以容纳多种解决方案，也要足够聚焦以便采取行动 |
Validate the result (orchestration)
验证结果（编排）
Hand-offs name each lens by its installable skill. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.name
After producing or revising, hand it to the audit lenses rather than declaring it done. These are candidate lenses — posture per , or route the whole artifact through . Here is the always-relevant lens (auto-runs); the others are offered, tied to what the artifact actually contains. If the user invoked this skill for one specific thing, respect that scope.
docs/orchestration-policy.mdpm-product-reviewassumption-rigor- (auto-runs) — the root cause is an assumption until validated. Is the riskiest cause-claim named honestly, and is the evidence behind it real (a pattern across sources) rather than a single anecdote or an internal belief?
pm-assumption-rigor-audit - (offer — if it names a measurable element) — the measurable element: is it a real outcome that reflects the user's success, falsifiable, and not a vanity or gameable number? (This is also the metric that will likely become a key result.)
pm-okr-metric-validity-audit
Composition (per §9): if discovery hasn't yet surfaced the underlying problems, that work () is an upstream input; the test designed for the statement () and the spec it becomes () are downstream (offer to produce next, don't auto-generate). If the audits surface a conflict (e.g., the only available metric is a vanity number, or the cause can't be evidenced), resolve toward the purpose: a problem statement exists to point the whole team at the right problem — keep it true, specific, and provable, not convenient. For a full idea-to-plan build, is the compositional front door that sequences this step with the rest of the ladder and enforces evidence before the spec.
docs/orchestration-policy.mdpm-discoverypm-assumption-testingpm-product-specpm-idea-to-plan交接时应使用每个视角对应的可安装 Skill来标识它。仅在相应 Skill 已安装时调用；如果未安装，本 Skill 的核心原则已涵盖这些规则——继续执行，不要因此阻塞。name
完成或修订后，应将其交给审计视角，而不是直接宣告完成。这些是候选视角——根据 确定处理方式，或将整个交付物交给 。在这里， 是始终相关的视角（自动运行）；其他视角则属于可选提供项，应根据交付物实际包含的内容来确定。如果用户调用本 Skill 是为了处理某个特定事项，应尊重该范围。
docs/orchestration-policy.mdpm-product-reviewassumption-rigor- (自动运行) —— 根因在被验证之前只是一个假设。是否如实指出了风险最高的因果断言，其背后证据是否真实（跨来源呈现出的模式），而不是单一轶事或内部主观判断？
pm-assumption-rigor-audit - (可选——如果陈述中包含可衡量要素) —— 可衡量要素是否是反映用户成功的真实结果，能否被证伪，而不是虚荣指标或容易被人为操纵的数字？（这也很可能成为一项关键结果。）
pm-okr-metric-validity-audit
组合方式（依据 §9）： 如果问题发现尚未揭示底层问题，那么相关工作（）是上游输入；为陈述设计的测试（）以及由其转化而成的 spec（）位于下游（可作为下一步提供，但不要自动生成）。如果审计发现冲突（例如，唯一可用的指标是虚荣指标，或原因无法获得证据支持），应围绕目的来解决：问题陈述的存在是为了让整个团队指向正确的问题——应保持真实、具体且可证实，而不是为了省事而妥协。 若要完成从创意到计划的完整构建， 是组合式入口，用于安排此步骤与后续各层级，并在编写 spec 前强制要求证据。
docs/orchestration-policy.mdpm-discoverypm-assumption-testingpm-product-specpm-idea-to-planCommon do/don't patterns
常见应做 / 不应做模式
| ❌ Don't | ✅ Do |
|---|---|
| "Users need a better search function" | "New users can't find relevant products because categories don't match how they think, so 40% leave without buying" |
| "The UX is bad" / "the process is inefficient" | Name who, when, the concrete obstacle, and the measurable impact |
| "We need to increase revenue" (business outcome) | Translate to the user problem beneath it ("users abandon checkout before paying") |
| Treat the symptom (churn) as the problem | Trace to the cause via 5 Whys; the symptom is a signal, not the problem |
| Bake the solution into the problem | Describe the gap so multiple solutions could address it |
| Leave it unmeasurable | Include a falsifiable metric; it becomes a key result |
| Build it on team assumptions | Ground it in user evidence; code qual feedback into quantitative findings |
| Accept a reasoned cause as proven | Reason first, then validate before committing real resources |
| Too-broad ("improve onboarding") | Narrow to a specific group, moment, and difficulty |
| Ship the statement unchecked | Hand off to okr-metric-validity + assumption-rigor |
| ❌ 不应做 | ✅ 应做 |
|---|---|
| “用户需要更好的搜索功能” | “新用户找不到相关产品，因为分类方式不符合他们的思考方式，因此 40% 的人未购买就离开” |
| “UX 很糟糕” / “流程效率低下” | 指出谁、何时、具体障碍和可衡量影响 |
| “我们需要提高收入”（业务结果） | 转译为其下方的用户问题（“用户在付款前放弃结账”） |
| 把症状（流失率）当作问题 | 通过 5 Whys 追溯原因；症状只是信号，不是问题 |
| 将解决方案夹带进问题 | 描述差距，使多种解决方案都能处理它 |
| 让问题无法衡量 | 纳入可证伪的指标；它将成为关键结果 |
| 建立在团队假设之上 | 以用户证据为依据；将定性反馈编码为定量发现 |
| 将基于推理的原因视为已经证实 | 先进行推理，再在投入真实资源前进行验证 |
| 范围过于宽泛（“改进 onboarding”） | 缩小到一个具体群体、时刻和困难 |
| 未经检验就发布陈述 | 移交给 okr-metric-validity + assumption-rigor |