待办任务

把问题框为用户"雇佣"产品去做的"任务"，揭示真实动机。

为什么

人们不买产品；他们雇佣产品在生活中取得进展。待办任务（JTBD）框架揭示人为何从一个产品换到另一个：新产品做了旧产品做不好的任务。"我雇佣 Slack 让团队同步而不用邮件线程"比"Slack 是消息应用"更可执行——它告诉你必须把什么任务做得更好才能赢他们生意。JTBD 对理解切换特别有力：人在当前产品在新变得重要的任务上失败时切换（如团队增长，Slack 频道混乱成问题）。这框架防止你在功能上竞争，而在用户试图取得的底层进展上竞争。

何时使用

在问题陈述之后，深化对动机的理解。半天。每次用户访谈都用。

如何做

1. 识别功能性任务
   - 他们想完成什么实际任务？
   - "从 git 历史编 changelog"（不是"用 changelog 工具"）

2. 识别情感性任务
   - 他们想感觉（或避免感觉）什么？
   - "对用户显得专业"/"避免发布日的恐惧"

3. 识别社会性任务
   - 他们想被他人怎么看？
   - "看起来像发干净版本的严肃维护者"

4. 写任务故事
   - "当 [情境]，我想 [动机]，以便 [期望结果]"
   - 例："当我每周发布，我想自动生成干净 changelog，以便显得专业且省 2 小时"

5. 识别当前雇佣及其挣扎
   - 他们今天雇佣什么产品/方法？
   - 它在哪任务上失败？（这是你的机会）

6. 找"推"和"拉"
   - 推：当前雇佣的什么挫败推他们切换？
   - 拉：新方案提供什么拉他们过来？
   - 焦虑：对新的什么恐惧拉住他们？
   - 习惯：什么惯性留他们在当前雇佣？
   - 切换发生在 推 + 拉 > 焦虑 + 习惯

示例

产品：AI 驱动的 changelog 生成器。
JTBD 分析：

功能性任务："从 git 提交和 PR 编准确面向用户的 changelog"
情感性任务："为发布自豪，不为乱 changelog 尴尬"
社会性任务："对开源用户和贡献者显得专业"

任务故事："当我每周发布，我想从提交自动生成干净分组的 changelog，以便显得专业、省 2 小时、不再怕发布日。"

当前雇佣：从 PR 标题手动复制进 markdown
  - 挣扎：漏修复、分组不一致、花 2 小时、感觉不专业

切换力：
  - 推："我的用户老问'v1.3 改了什么？'而我的 changelog 是空的"
  - 拉："这工具 10 秒从我的提交生成分组 changelog"
  - 焦虑："AI 会不会幻觉没发生的改动？"
  - 习惯："我已有 CHANGELOG.md 模板，挺好"

战略：最大化拉（展示 10 秒演示）+ 降焦虑（展示只用提交文本、不幻觉）→ 克服习惯。

常见问题

⚠把任务和产品混——"任务是使用 changelog 工具"是循环的；任务是他们想要的进展，产品是一种雇佣。
⚠忽略情感和社会任务——"省时间"只是功能；"显得专业"往往是更强动机和真正差异化。
⚠不识别四种切换力——没有推/拉/焦虑/习惯，你无法设计克服惯性的战略。
⚠任务故事太泛——"当我工作，我想高效"适用于一切也什么都不是；落到具体情境。

最佳实践

✓总写完整任务故事含情境 + 动机 + 结果——情境触发雇佣并使其具体。
✓识别全部四力（推、拉、焦虑、习惯）——你战略须增拉、降焦虑、克服习惯；推不在你控制内。
✓在用户访谈用 JTBD——问"你上次换工具是什么时候？什么推你？什么拉你到新的？"揭示真实切换动态。
✓在任务上竞争而非产品——"我们把 changelog 任务做快 10 倍"比"我们比竞品 X 的 AI 更好"更强。