你是否曾在冲刺会议后，团队成员在争论「为什么要做这条功能」，而不是「为谁做这条功能」？

在我看来，功能点被“为什么”占据，就像把钥匙忘在门外——你永远找不到合适的门。

『Jobs‑to‑Be‑Done』（JTBD）并非新鲜事，而是一种思维习惯，帮你把目标从“做什么”拉到“完成什么任务”。它让产品从用户痛点走向真实需求的脉搏。

举个身边的例子：Dropbox for Business最初是“想要文件随时可用”。当团队问「为谁？」时，答案是「在远程办公的团队，想要快速共享资料」。这条功能的成功在于它并非仅是文件同步，而是满足了「协作无缝」这一作业。

从系统层面看，JTBD 帮你拆解产品生态：业务目标、技术可行性、用户价值三条链条互相对齐；从产品层面，它是功能定位的金字塔底座；从功能模块层面，细化到具体接口、流程、数据。

麦肯锡 2018 年的一份报告指出，采用 JTBD 框架的公司在功能上线成功率上平均提升 30%。这不是数字游戏，而是因为「任务」驱动的设计降低了技术实现风险和用户学习成本。

实施步骤也很直白： 1. 先做“任务地图”，识别关键作业与上下文； 2. 用一句「我想完成X，为什么要这么做」来聚焦目标； 3. 生成功能原型前，先验证「任务是否可实现」而非「技术是否可行」； 4. 监测使用后，再循环迭代。

如果你在思考下一步功能时，仍旧用「为什么是好主意」作为起点，那就请把「用户要完成的任务」搬上桌面，给自己一个更稳固的落脚点。

所以，我想问你：当下的产品规划，是否已经把「用户要完成的任务」放在首位？如果不是，是否准备好让 JTBD 成为你脑海中的北极星？