从观察到需求机会：提炼并排序用户需求以支撑产品策略

当你需要把观察、痛点和欲望整理成可排序的用户需求/机会，并交给产品策略时使用。

适用场景

解决思路

1. 先确定要定义需求的用户是谁、处在什么情境：不要只写“用户”，要写清是哪一类用户、在何时；若存在多个不同需求类型的用户，分别处理。
2. 记录需求来源：调研、领域知识或假设；若是假设，标记并计划验证。
3. 明确用户想完成的工作：分别提取功能性、情感性、社会性三类任务。
4. 输出三类机会：需求（想达成什么）、痛点（造成摩擦的因素）、欲望（他们会重视的改进）；三者都有效，都要提取。
5. 判定每条需求基于证据还是假设：标记 observed / inferred / assumed。
6. 判断哪些需求最重要以及为什么，形成优先级。
7. 如果需求已经清晰且有依据，不要为了流程重复提取，直接把它们交给 /layers-product-strategy。
8. 坚持“需求，而非解决方案”：遇到“当我要报表时，我想导出 CSV”这类表述，继续追问底层需求。
9. 剥离机制：如果 When 子句提到你的具体方案（你的 dashboard、你的 CSM、你的每周邮件），说明你在描述当前系统而非需求；把它重述为不依赖由谁/什么来满足：在用户需要它的那一刻，什么对他而言是真的？需求来自状态，不来自机制。
10. 让 When 可被想象：足够具体到能看见事情发生的那一刻——由事件、感受、节奏或跨过阈值触发；一直追问直到达到这个程度。
11. 不只提取功能性工作，也要显式询问情感和社会性工作；功能性影响交互与模型；情感性影响表层语气/反馈；社会性影响表层，有时影响策略。
12. 为每条需求标记置信度：observed / inferred / assumed。
13. 把 workaround 当作信号：一个能促使人们做表格或发变通邮件的需求，是强需求。
14. 默认使用 job stories：When [situation], I want to [motivation], so I can [outcome]；它把解决方案排除在外，When 子句强制具体化。
15. 当团队偏好基于角色的框架或已有 Agile 工作流时，使用 user stories。
16. 当有大量既有用户群时，使用 top tasks analysis（Gerry McGovern）：通过频率识别哪些任务最重要；统计、基于问卷。
17. 当需要向习惯用原型思考的干系人沟通时，使用 persona + scenario；利于对齐，但对设计不够精确。
18. 当需要精确、可度量的陈述时，使用 ODI desired outcomes（Ulwick）：Minimize [metric] when [context]；可直接映射到机会评分。
19. 用 surface hidden needs 的提示词找出被忽略的需求：用户在你关注的那一刻之前/之后做什么；他们希望自己不必做什么；当前 workaround 在满足什么。
20. 做粗略优先级排序：按重要性 × 当前被满足得有多差排序；重要且被服务得很差的需求是高价值机会。保持粗略，精确评分属于策略工作。
21. 先和设计师确定用户是谁及在什么情境：不是“用户”，而是哪一类型、在何时；若有多类不同需求，分开做；记录来源；若为假设，标记并计划验证。
22. 然后把设计师提出的需求按上述 disciplines 过一遍，并探查隐藏需求。
23. 选择匹配的技术：默认 job stories；当可度量性重要时用 ODI；当用户群大时用 top tasks；不要跑固定流程。
24. 只记录残余信息：带置信度评级的优先需求、已浮现但未优先的需求（避免丢失）、缺口（可能是真需求但尚未被证据支撑）、不同用户类型之间的矛盾；只保留能影响决策的内容。
25. 把这些需求作为 /layers-product-strategy 的机会输入。
26. 如果这些需求大多是假设，考虑先用 /layers-observed-behaviour 收集证据，再构建策略。

适用边界 · 注意事项

• 需求已经清晰且有证据时，不要为了流程重新提取，直接进入产品策略。
• 如果大多数需求只是假设，不要直接用于构建策略；先用 /layers-observed-behaviour 收集证据。
• 不要在这一层做精确打分或完整策略；精确评分属于策略工作，这里只做粗略优先级。