problem-statement

目的

从用户视角阐述问题，运用以共情为驱动的框架，描述用户是谁、想做什么、遇到了什么阻碍、阻碍的原因，以及这些情况带给用户的感受。先借此让利益相关方就问题达成共识，再着手寻找解决方案；并围绕用户成果而非功能请求来规划产品工作。

这不是一份需求文档，而是一段以人为本的问题叙述，确保你解决的是一个值得解决的问题。

输入

最适用的内容： 用户是谁，以及他们想做的事情遇到了什么困难。 也有帮助的内容： 阻碍是什么、问题为何重要、用户有何感受，以及相关佐证。

随调用一同提供的任何内容——技能名称后面的文本、粘贴的上下文资料，或追加的 ARGUMENTS: 行——都视为已提供的答案。使用这些内容，并跳过其中已涵盖的问题；不要重复询问。

没有准备任何内容？也没关系。 该技能会先询问用户是谁、目标是什么——没有具体“谁”的问题陈述，只是在为解决方案寻找借口。

调用示例： Problem statement: clinic schedulers double-book exam rooms because the calendar doesn't show equipment availability.

核心概念

问题框定框架

该框架基于 Jobs-to-be-Done 和共情地图，将问题组织为：

问题框定叙述：

• 我是： [描述遇到问题的角色]
• 我想要： [角色关注的目标成果]
• 但是： [阻碍实现这些成果的因素]
• 因为： [问题的根本原因]
• 这让我感到： [带来的情绪影响]

背景与限制条件：

• [地理、技术、时间、人口统计等因素]

最终问题陈述：

• [简洁且富有共情的一句话总结]

为什么这种结构有效

• 以角色为中心： 促使你从用户的视角看待问题
• 以成果为导向： “我想要”强调期望的结果，而非任务
• 根因分析： “因为”促使你超越表面症状，探究深层问题
• 情绪认同： “这让我感到”使问题更具人情味，并增进共情
• 考虑背景： 限制条件承认现实世界的种种约束

反面模式（这不是什么）

• 不是伪装成问题的解决方案： “问题是我们缺少 AI 驱动的分析功能”＝暗中塞入解决方案
• 不是业务问题： “我们的收入下降了”不是用户问题（而是一种症状）
• 不是功能请求： “用户需要一个仪表板”不是问题（他们想做什么？）
• 不能过于笼统： “用户想要更好的用户体验”过于模糊，无法据此采取行动

适用场景

• 启动探索或问题验证工作
• 在寻找解决方案前协调利益相关方
• 向工程、设计或高管团队阐明问题
• 有功能请求，但尚不清楚背后的问题时
• 说明为什么某个问题值得解决

不适用场景

• 尚未开展任何用户研究时（不要猜测——先进行访谈）
• 内部运营问题（本框架用于面向用户的问题）
• 代替 PRD（本框架用于界定问题；PRD 用于定义解决方案）

---

应用

使用 template.md 获取完整的填写模板。

步骤 1：收集用户背景

起草前，请确保掌握以下信息：

• 用户访谈或研究： 直接引述、观察到的行为、痛点
• Jobs-to-be-Done 洞察： 用户“雇用”你的产品来完成什么（参见 skills/jobs-to-be-done/SKILL.md）
• 角色清晰度： 哪些具体人群会遇到这个问题（参见 skills/proto-persona/SKILL.md）
• 限制条件数据： 地理、技术、时间及人口统计方面的限制

缺少背景信息时： 开展探索性访谈、情境访谈或用户跟访。不要捏造问题。

---

Step 2：起草问题界定叙述

从角色的视角填写模板：

## Problem Framing Narrative

**I am:** [Describe the key persona, highlighting 3-4 key characteristics]
- [Key pain point or characteristic 1]
- [Key pain point or characteristic 2]
- [Key pain point or characteristic 3]

**Trying to:**
- [Single sentence listing the desired outcomes the persona cares most about]

**But:**
- [Describe the barriers preventing the persona from achieving outcomes]
- [Job-to-be-done or outcome obstruction 1]
- [Job-to-be-done or outcome obstruction 2]
- [Job-to-be-done or outcome obstruction 3]

**Because:**
- [Describe the root cause empathetically]

**Which makes me feel:**
- [Describe the emotions from the persona's perspective]

质量检查：

• “我是一名……”的具体程度： 能想象出这个人吗？还是说法太笼统（例如“忙碌的职场人士”）？
• “试图……”的清晰度： 这是一个结果（可衡量）还是一项任务（活动）？
• “但是……”的深度： 这些是真正的障碍，还是只是小小的不便？
• “因为……”的真实性： 这是根本原因，还是只是表象？
• “这让我感到……”的真实性： 这些情绪来自研究，还是主观臆测？

---

Step 3：记录背景与约束

## Context & Constraints

- [Enumerate geographic, technological, time-based, or demographic factors]
- [e.g., "Must work offline in rural areas with limited connectivity"]
- [e.g., "Used by non-technical users unfamiliar with complex software"]
- [e.g., "Time-sensitive: decisions must be made within 24 hours"]

质量检查：

• 相关性： 这些约束是否会直接影响问题？
• 具体性： 这些约束是否足够具体，能为设计决策提供依据？

---

Step 4：撰写最终问题陈述

将叙述提炼成一句有力的话：

## Final Problem Statement

[Single, concise statement that provides a powerful and empathetic summary]

公式： [角色] 需要一种方法来 [期望结果]，因为 [根本原因]，这目前导致了 [情绪／实际影响]。

示例： “企业 IT 管理员需要一种能在 5 分钟内配置用户账号的方法，因为当前流程需要 2 个多小时，还要经过人工审批，导致项目延误并让最终用户感到沮丧。”

质量检查：

• 一句话： 如果需要多句话，说明问题还不够精炼。
• 可衡量： 能判断问题是否已解决吗？
• 有共鸣： 情感上是否能引起共鸣？
• 便于分享： 在会议上说出这句话，利益相关者会认同吗？

---

Step 5：验证并推动各方认同

• 与用户测试： 向经历过该问题的人大声读出这段话。他们会说“没错，就是这样！”吗？
• 与利益相关者分享： 包括产品、工程、设计和高管。它能让所有人达成共识吗？
• 根据反馈迭代： 如果有人说“我觉得这不是真正的问题”，就继续深入探究。

---

示例

完整示例（好的和不好的问题陈述）请参阅 examples/sample.md。

迷你示例摘录：

**I am:** A software developer on a distributed team
**Trying to:** Communicate in real-time with my team without losing context
**But:** Email is too slow and IM is ephemeral
**Because:** No tool combines real-time chat with searchable history
**Which makes me feel:** Frustrated and disconnected

---

常见误区

误区 1：暗中塞入解决方案

表现： “问题是我们没有 [某项具体功能]”

后果： 你还没验证问题，就已经预先决定了解决方案。

改进方法： 围绕用户期望的结果重新表述，而不是围绕功能。问问“他们想要实现什么？”

---

误区 2：把业务问题伪装成用户问题

表现： “用户想提高我们的收入”或“问题是我们的流失率”

后果： 这些是公司的问题，不是用户的问题。用户并不关心你的指标。

改进方法： 深入探究用户流失的原因，或是什么会让他们愿意花更多钱。从用户的角度来描述问题。

---

误区 3：角色过于笼统

表现： “我是一名忙碌的职场人士，想提高工作效率”

后果： 范围太宽，无法据此采取行动。每个产品都声称能帮助“忙碌的职场人士”。

改进方法： 描述得更具体。“我是一名销售代表，用电子表格手动管理 50 多个潜在客户，想要安排后续跟进的优先顺序，同时不错过高价值机会。”

---

误区 4：描述表象而非根本原因

表现： “因为界面令人困惑”

后果： 你描述的是表象，而不是潜在问题。

改进方法： 问“为什么界面令人困惑？”不断追问“为什么”，直到找到根本原因（例如“因为用户对系统的工作方式没有清晰的心智模型”）。

---

误区 5：捏造情绪

表现： “这让我感到得心应手、喜悦不已”

后果： 这听起来像营销文案，不像用户的真实情绪。

改进方法： 使用用户访谈中的真实引述。真实情绪包括：“沮丧”“不知所措”“焦虑”“受阻”。

---

参考资料

相关技能

• skills/jobs-to-be-done/SKILL.md — 为“试图……”和“但是……”部分提供参考
• skills/proto-persona/SKILL.md — 定义“我是一名……”中的角色
• skills/positioning-statement/SKILL.md — 问题陈述为定位提供依据
• skills/user-story/SKILL.md — 问题陈述指导用户故事的优先级排序

外部框架

• Clayton Christensen，《Jobs to Be Done》——以结果为中心的问题界定方法的起源
• Osterwalder 和 Pigneur，《Value Proposition Canvas》——客户的痛点、收益和任务
• Dave Gray，《Empathy Mapping》——情感界定技巧

Dean 的作品

• [如适用，请链接到 Dean Peters 相关的 Substack 文章]

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/framing-the-problem-statement.md。

---

技能类型： 组件 建议文件名： problem-statement.md 建议放置位置： /skills/components/ 依赖项： 引用了 skills/jobs-to-be-done/SKILL.md、skills/proto-persona/SKILL.md