用途
问题定义（Problem Statement）是一份简洁的文档，用于框定你正在解决的问题，阐明其对用户和业务的影响，并定义明确的成功标准。它作为后续所有产品工作的基础，确保团队在跳到“如何解决”之前，先就“要解决什么问题”达成一致。
何时使用
- 启动新计划或新项目，建立共同理解
- 将偏离方向的项目重新对齐到最初意图
- 向领导层或利益相关者沟通优先级
- 评估某个提议的解决方案是否真正解决了核心问题
- 帮助新团队成员了解背景
何时不使用
- 问题已经达成一致，工程团队需要规格说明 → 使用 deliver-prd
- 你想提出并比较多种解决方案 → 使用 develop-solution-brief
- 你是在捕捉客户动机而非业务问题 → 使用 define-jtbd-canvas
- 所谓的“问题”实际上是一个未经验证的假设 → 先用 define-hypothesis 框定并验证，再投入团队
使用方式
当被要求创建问题定义时，按以下步骤操作：
-
识别用户群体：询问谁在经历这个问题。具体到用户画像、角色或细分群体。避免“用户”这类模糊描述，而应定位到“完成结账的移动端购物者”或“管理 50+ 用户的企业管理员”。
-
理解痛点：探索用户经历的摩擦、挫败或未满足的需求。通过追问了解问题的严重程度和发生频率。寻找来自用户研究、支持工单或行为数据的证据。
-
建立业务背景：将用户问题与业务影响联系起来。这个问题如何影响收入、留存、增长或战略目标？为什么组织应该现在而不是以后投资解决它？
-
定义成功指标：确定如何衡量成功。如果问题被解决，哪些指标会变化？建立当前基线和目标改进值。要具体且有时间限制。
-
梳理约束与考量：记录任何技术限制、资源约束、监管要求或依赖关系，这些将影响解决方案空间。
-
记录待解决问题：记录你尚不知道的内容。哪些假设需要验证？需要哪些额外研究？
输出格式
使用 references/TEMPLATE.md 中的模板来组织输出。完整的问题定义应填写模板的每个部分：问题摘要、用户影响、业务背景、成功标准、约束与考量、待解决问题。
质量检查清单
在最终确定之前，验证：
- 问题针对明确定义的用户群体（而非“所有用户”）
- 影响用数据或合理估算量化
- 成功指标有基线和目标
- 问题描述“是什么”，而不规定“怎么做”
- 业务背景解释了为什么现在重要
- 待解决问题已记录以便后续跟进
示例
参见 references/EXAMPLE.md 获取完整示例。