需求不清或功能低采纳时，用 JTBD…

当用户需求不清、功能采纳率低或需要定位和映射竞争时，用 JTBD 从证据中恢复用户在特定情境下要实现的进步，并据此决定构建/砍掉/重排优先级。

适用场景

解决思路

1. 命名执行者和情境。确定谁雇佣解决方案、在什么触发情境下、频率如何、涉及什么利害关系。优先选择每天都有高利害任务的主动执行者，而非罕见的次要执行者。
2. 陈述任务，而非解决方案。使用框架：`When [circumstance], I want to [progress], so I can [outcome]`。拒绝解决方案形态的陈述（如“使用 Slack”“加一个仪表盘”）。仅在证据支持时，捕获功能性、情感性和社会性维度。
3. 映射驱动力和切换。从工件中分析：什么推力让旧方式失败、什么拉力提供新的进步、什么焦虑阻碍切换、什么习惯维持现状。列出他们今天雇佣什么——包括非软件和非消费。
4. 定义完成和产出指标。确定执行者如何知道任务已完成。列出要最小化和最大化的产出（到达进步的时间、返工、信心、意外）。优先选择频繁但服务不佳的任务，而非罕见但已充分变通解决的任务。
5. 针对任务给候选方案打分。对每个功能/优先级：它服务于哪个任务步骤、执行者占比、频率、替代方案质量。提升高频且服务不足的维度；降级那些为已服务好或低利害任务所做的精细工作。
6. 写出最强反例。陈述所陈述任务错误的最佳情况（错误执行者、虚荣指标、流程即任务、竞争实际上是非消费）。如果反例更符合证据，在建议构建之前修正任务。
7. 停止。当一条主要任务陈述、竞争集合和产出指标已有足够证据支持，足以改变构建/定位决策时停止——或者当工件无法回答且研究是唯一下一步时停止。
8. 产出一个 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: …
9. 证伪：如果把任务陈述替换成功能名称后推荐没有变化，说明你从未离开解决方案空间——从情境和进步重新编写任务。
10. 停止：一旦排序决策稳定，不要继续映射任务步骤。
11. 过度应用防护：在纯实现任务和已知任务上跳过。绝不编造用户引语或人物角色来填补缺失证据。

适用边界 · 注意事项

• 已知任务后的纯执行（bug 修复、schema、CI、性能）：直接实现，不要重新发现任务。
• 为已锁定的决策做事后合理化，或开放问题只是如何实现已确定的任务。
• 没有最终用户进步决策的基础设施/内部工作。