name: problem-statement description: 从用户的角度阐述问题，使用基于同理心的框架，捕捉他们是谁、他们试图做什么、是什么阻碍了他们、为什么，以及这让他们感觉如何。使用这个框架在与利益相关者开始解决方案之前对齐问题，并将产品工作围绕用户结果而不是功能请求来构建。
这不是需求文档——它是一个以人为中心的问题叙事，确保你正在解决一个值得解决的问题。 type: component
目的
从用户的角度阐述问题，使用基于同理心的框架，捕捉他们是谁、他们试图做什么、是什么阻碍了他们、为什么，以及这让他们感觉如何。使用这个框架在与利益相关者开始解决方案之前对齐问题，并将产品工作围绕用户结果而不是功能请求来构建。
这不是需求文档——它是一个以人为中心的问题叙事，确保你正在解决一个值得解决的问题。
关键概念
问题框架框架
基于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） - 约束数据： 地理、技术、时间、人口限制
如果缺少上下文： 进行发现访谈、上下文查询或用户观察。不要编造问题。
步骤 2：起草问题框架叙事
从人物角色的角度填充模板：
## 问题框架叙事
**我是：** [描述关键人物角色，突出3-4个关键特征]
- [关键痛点或特征1]
- [关键痛点或特征2]
- [关键痛点或特征3]
**试图：**
- [单句列出人物角色最关心的期望结果]
**但是：**
- [描述阻碍人物角色实现结果的障碍]
- [Job-to-be-done或结果阻碍1]
- [Job-to-be-done或结果阻碍2]
- [Job-to-be-done或结果阻碍3]
**因为：**
- [以同理心描述根本原因]
**这让我感觉：**
- [从人物角色角度描述情感]
质量检查：
- “我是”具体性： 你能想象这个人吗？还是它是泛泛的（“忙碌的专业人士”）？
- “试图”清晰度： 这是结果（可测量）还是任务（活动）？
- “但是”深度： 这些是真正的障碍还是只是不便？
- “因为”诚实度： 这是根本原因还是只是症状？
- “让我感觉”真实性： 这些情感来自研究还是假设？
步骤 3：记录上下文与约束
## 上下文与约束
- [列举地理、技术、时间或人口因素]
- [例如，“必须在连接有限的农村地区离线工作”]
- [例如，“被不熟悉复杂软件的非技术用户使用”]
- [例如，“时间敏感：必须在24小时内做出决策”]
质量检查：
- 相关性： 这些约束是否直接影响问题？
- 具体性： 它们是否具体到足以指导设计决策？
步骤 4：构建最终问题陈述
将叙事综合为一个有力的句子：
## 最终问题陈述
[单一、简洁的陈述，提供有力且富有同理心的总结]
公式： [人物角色] 需要一种方式来 [期望结果]，因为 [根本原因]，目前 [情感/实际影响]。
示例： “企业IT管理员需要一种方式在5分钟内配置用户账户，因为当前流程需要2小时以上并涉及手动审批，这导致项目延迟和最终用户沮丧。”
质量检查：
- 一句话： 如果需要多句话，问题还不够清晰
- 可测量： 你能判断是否解决了它吗？
- 富有同理心： 它是否在情感上产生共鸣？
- 可分享： 你能在会议中说这个并让利益相关者点头吗？
步骤 5：验证与传达
- 与用户测试： 向经历问题的人大声读出。他们是否说“是的，没错！”？
- 与利益相关者分享： 产品、工程、设计、执行。它是否对齐所有人？
- 基于反馈迭代： 如果有人说出“我不认为那是真正的问题”，深入挖掘。
示例
参见 examples/sample.md 获取完整示例（好和坏的问题陈述）。
迷你示例摘录：
**我是：** 分布式团队中的一名软件开发者
**试图：** 与我的团队实时沟通而不失去上下文
**但是：** 电子邮件太慢，IM是临时的
**因为：** 没有工具将实时聊天与可搜索历史结合
**这让我感觉：** 沮丧和脱节
常见陷阱
陷阱 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 文章]
来源
- 改编自
prompts/framing-the-problem-statement.md在https://github.com/deanpeters/product-manager-prompts仓库中。
技能类型： 组件
建议文件名： problem-statement.md
建议放置位置： /skills/components/
依赖： 参考 skills/jobs-to-be-done/SKILL.md, skills/proto-persona/SKILL.md