thinking-jobs-to-be-done

待完成的任务

核心原则：用户会在特定情境下选择解决方案，以推动进展。应优先关注任务、驱动力、结果和竞争性的替代做法，而非功能列表。

适用场景

• 用户需求不明确，需要决定构建、删减或优先处理哪些内容时
• 解释已发布功能的采用率为何偏低时
• 将竞争范围扩展到同类产品之外（电子邮件、电子表格、手动工作、不使用产品）
• 当用户寻求的进展存在争议时，进行定位或研究

至少需要一个证据来源：PRD/规格说明、工单、支持/销售记录、分析数据/日志，或当前产品行为。如果没有证据来源，应指出研究缺口；不要编造引言。

不适用场景

• 已知任务后的纯执行工作（修复 Bug、定义架构、CI、性能优化）——直接实施，不要重新探索任务
• 为已敲定的决策事后寻找理由——这是框架表演
• 不涉及终端用户进展决策的基础设施/内部工作
• 未决问题仅在于如何实现已确定的任务

流程

1. 明确执行者和情境。 谁会选择解决方案、在什么触发情境下、频率如何、利害关系是什么。优先关注每天都会执行高风险任务的主要执行者，而非偶尔出现的次要执行者。
2. 陈述任务，而非解决方案。 使用以下句式：当 [情境] 时，我想要 [进展]，以便 [结果]。拒绝以解决方案为中心的陈述（“使用 Slack”“添加仪表板”）。只有证据支持时，才记录功能、情感和社会层面的内容。
3. 梳理驱动力和转换过程。 根据现有材料，确定是什么推动旧方法失效、新进展带来什么吸引力、什么顾虑阻碍转换、什么习惯让现状得以维持。列出他们目前会选择的所有方式，包括非软件方式和不使用产品。
4. 定义完成标准和结果指标。 执行者如何判断任务已完成。列出需要降低和提高的结果指标（取得进展所需时间、返工、信心、意外情况）。优先考虑频繁但服务不佳的任务，而非罕见且已有足够替代方法的任务。
5. 根据任务为候选项打分。 对每项功能/优先事项，明确它服务于哪个任务步骤、涉及多少执行者、发生频率，以及替代方案的质量。提升高频且服务不足的维度的优先级；降低面向服务良好或风险较低任务的精致功能的优先级。
6. 提出最有力的反方论据。 指出任务陈述可能有误的最有力理由（执行者认错了、关注的是虚荣指标、流程本身就是任务、竞争实际上来自不使用产品）。如果反方论据更符合证据，应先修订任务，再建议构建方案。
7. 停止。 当证据已足以支持一个主要任务陈述、竞争方案集合和结果指标，并能据此改变构建/定位决策时，停止；若现有材料无法回答问题，且研究是唯一的下一步，也应停止。

输出

生成一份 JTBD 决策材料：

Job statement: When …, I want to …, so I can …
Performers: primary / secondary (frequency, stakes)
Forces: push / pull / anxiety / habit
Competition: direct | indirect | non-consumption
Outcomes: minimize […] ; maximize […]
Priority implication: build / cut / reposition — because job gap is …
Countercase checked: …
Evidence used / gaps: …

验证

• 证伪： 如果将任务陈述替换成功能名称后，建议不变，说明你仍停留在解决方案层面——根据情境和进展重新撰写任务。
• 停止： 排序决策稳定后，不要继续梳理任务步骤。
• 避免过度使用： 对纯实施任务和已知任务，跳过此流程。切勿编造用户引言或角色来填补证据缺口。