define-problem-statement

问题陈述

问题陈述是一份简明的文档，用于界定你要解决的问题、阐明问题对用户和业务的影响，并明确成功标准。它是后续所有产品工作的基础，确保先就要解决的“是什么”达成一致，再着手讨论“怎么做”。

适用场景

• 启动新的计划或项目，以建立共同认识
• 让偏离方向的项目回归最初目标
• 向管理层或利益相关方说明优先事项
• 评估拟议的解决方案是否真正解决了核心问题
• 为新团队成员提供背景信息，帮助他们快速上手

不适用场景

• 问题已经达成一致，工程团队需要规格说明 → 使用 deliver-prd
• 你想提出并比较不同的解决方案 → 使用 develop-solution-brief
• 你要记录的是客户动机，而非业务问题 → 使用 define-jtbd-canvas
• 所谓的“问题”实际上是未经验证的假设 → 使用 define-hypothesis 来界定，并在让团队投入之前进行验证

说明

收到创建问题陈述的请求时，请按以下步骤操作：

1. 确定用户群体 询问谁正面临这个问题。明确具体的用户画像、角色或群体。避免使用“用户”之类的模糊描述，应聚焦于“完成结账的移动端购物者”或“管理 50 位以上用户的企业管理员”等具体群体。

2. 了解痛点 深入了解用户遇到的阻碍、挫折或未满足的需求。通过追问，了解问题的严重程度和发生频率。查找用户研究、支持工单或行为数据中的证据。

3. 明确业务背景 将用户问题与业务影响联系起来。这个问题会如何影响收入、留存、增长或战略目标？组织为什么要现在解决，而不是以后再解决？

4. 定义成功指标 确定如何衡量成功。如果问题得到解决，哪些指标会发生变化？记录当前基线和目标改进幅度。指标应具体，并设定时间范围。

5. 列出约束和注意事项 记录可能影响解决方案范围的技术限制、资源约束、监管要求或依赖项。

6. 记录待解决的问题 记录目前尚不清楚的事项。哪些假设需要验证？还需要开展哪些研究？

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的问题陈述应填写模板的每个部分：问题摘要；用户影响；业务背景；成功标准；约束和注意事项；待解决的问题。

质量检查清单

定稿前，请确认：

• 问题针对明确的用户群体（而非“所有用户”）
• 影响已通过数据或合理估算量化
• 成功指标包含基线和目标
• 问题描述了“是什么”，而没有规定“怎么做”
• 业务背景说明了为什么这件事现在很重要
• 已记录待后续跟进的未解问题

示例

完整示例请参见 references/EXAMPLE.md。