启动新项目或纠偏项目时，用问题陈述文档对齐用户痛点…

在启动新计划、重新对齐跑偏项目或向领导层沟通优先级时，快速产出一份聚焦「解决什么问题」而非「怎么解决」的问题陈述文档。

适用场景

解决思路

1. 识别用户群体：明确谁在经历这个问题，具体到用户画像、角色或细分群体，避免用「用户」这类模糊描述，而应写成「完成结账的移动端购物者」或「管理 50+ 用户的企业管理员」。
2. 理解痛点：探究用户遇到的摩擦、挫败或未被满足的需求，通过追问了解问题的严重程度和发生频率，并从用户研究、支持工单或行为数据中寻找证据。
3. 建立业务背景：把用户问题与业务影响挂钩，说明该问题如何影响收入、留存、增长或战略目标，以及为什么组织现在就该投入解决而不是往后拖。
4. 定义成功指标：确定如何衡量成功，明确问题解决后哪些指标会变化，建立当前基线和目标改进值，做到具体且有时间限制。
5. 梳理约束与考量：记录会限制解决方案空间的技术局限、资源约束、合规要求或依赖关系。
6. 记录开放问题：写下目前还不知道的内容，包括哪些假设需要验证、还需要补充哪些研究。
7. 按模板结构输出：使用 references/TEMPLATE.md 中的模板，完整填写每个部分——Problem Summary、User Impact、Business Context、Success Criteria、Constraints & Considerations、Open Questions。
8. 定稿前对照质量清单核查：问题是否针对明确定义的用户群体（而非「所有用户」）；影响是否用数据或合理估算量化；成功指标是否有基线和目标；问题是否只描述「是什么」而不规定「怎么做」；业务背景是否说明为何现在重要；开放问题是否已记录以便跟进。

适用边界 · 注意事项

• 问题已经达成共识、工程团队只需要规格说明时，应改用 deliver-prd。
• 想要提出并比较多种解决方案思路时，应改用 develop-solution-brief。
• 要捕捉的是客户动机而非业务问题时，应改用 define-jtbd-canvas；若「问题」其实只是未经验证的假设，应先用 define-hypothesis 框定并验证后再投入团队。