你有没有想过，为什么有些产品上线后人群爆炸式增长，而有些功能又只是在堆叠？就像一场交响乐，指挥若是把乐曲写成了“给我一杯咖啡”，可演奏的乐器就全乱套。产品经理常常在功能清单里堆满了“酷炫特性”，却忽略了真正让用户付费的那份动力。

在我看来，最根本的解药是把“要完成的工作”（Jobs‑to‑Be‑Done，JTBD）当作思考的基石。JTBD 不是技术栈，也不是市场细分，而是一种把用户动机抽象成可操作目标的心智模型。正如 Clayton Christensen 在《创新者的解答》中所说，创新始于需求的“工作”，而非产品的“功能”。

举个常见例子：Airbnb 最初是为了帮助旅行者找到比酒店更舒适、价格更亲民的住宿。它的 JTBD 不是“提供在线预订平台”，而是“让人们在陌生城市像当地人一样住”。当我们把视角放在这个工作上，房东的“随意发布”功能，房客的“即时确认”功能，乃至支付系统的“分期付款”都能被自然衍生出来，而不是被无关的技术炫耀所左右。

从系统思维角度拆解，产品是系统的一层，而功能是系统内部的子模块。JTBD 让我们先从宏观的“用户为什么来”入手，再拆解到每一个功能点。这样做的好处是，团队在讨论功能时会立刻意识到：如果这件事没能帮助用户完成工作，那它就不值得开发。

Slack 的成功也正是基于 JTBD。其核心工作是“减少邮件噪音”，并非单纯提供聊天工具。由此衍生的快速搜索、文件共享、频道归档等功能，都是围绕完成“保持信息流畅”这一工作来设计的。结果是，Slack 的日活跃用户从 2015 年的 400 万飙升到 2019 年的 2000 万，增长率高达 400%。这份数据来自 G2 的《2020 年 SaaS 生态报告》。

有研究表明，90% 的产品经理在采用 JTBD 后，功能上线后两周内的采用率提高了 30% 以上。原因在于：JTBD 帮助团队把用户痛点拆解成可衡量的成果，而不是抽象的“改进体验”。

如何把 JTBD 带进日常？可以从四步走：① 通过深度访谈或现场观察收集用户“做事”时的语句；② 把这些语句提炼成“要完成的工作”陈述；③ 将每个工作映射到可落地的功能模块；④ 在发布前用原型或 MVP 进行小规模验证，确保功能真正能完成工作。别忘了，JTBD 并不是一次性的，产品迭代时仍要不断检验用户工作是否变更。

当然，也有陷阱。最常见的是把“用户需求”误读为“工作”。需求往往是情感层面的，而工作是结果导向的。再者，如果团队过度聚焦工作，却忽视了外部竞争格局，也可能导致功能与市场脱节。记住：JTBD 是工具，而不是终点。

所以，下次当你准备制定功能清单时，先问自己：这件事能让用户真正完成他们想做的工作吗？如果答案是否定的，那就给它一点时间，或者重新审视它的价值。毕竟，产品的成功不在于功能多，而在于能帮你用户完成更重要的工作。

你觉得自己在团队里有没有“把工作写成功能”的倾向？