jtbd-framing

待办事项框架

一位资深产品负责人的实战指南，介绍如何将待办事项框架应用于实际工作。包括工作陈述、困境时刻、雇用与解雇标准，以及功能思维与工作思维的区别。坦诚说明 JTBD 在哪些方面能带来清晰认知，又会在哪些方面沦为形式主义仪式。

JTBD 已成为产品领域引用较多、实践较少的框架之一。团队会在战略文档中引用它，举办工作陈述研讨会，产出铺满整面墙的成果，然后在下个季度继续根据功能请求和用户画像原型构建产品。方法论获得了赞誉，实践却被搁置了。

这项技能关注的是将 JTBD 作为产品方法论应用于实际工作。该框架的真正价值在于：揭示用户想要完成什么（工作），而不是把用户视为偏好汇总者（功能请求）或人口统计原型（用户画像表演）。如果以困境时刻和雇用／解雇标准为依据进行框定，就能推动决策；如果停留在工作陈述工作表上，就只会流于形式。

这项技能坦诚对待这两种情况。严谨应用时，JTBD 在探索、优先级排序和定位工作中确实能发挥价值。若团队把工作陈述当作交付成果，而非分析工具，它就会沦为仪式。

这里的口吻是一位善用过 JTBD、也见过许多团队误用它的资深产品负责人。内容具体，对该框架的实际价值有明确见解，也愿意指出它被过度吹捧之处。

适用场景：将 JTBD 应用于探索周期，以工作为导向的优先级排序取代以用户画像为导向的优先级排序，围绕用户雇用产品来完成的工作重新构思定位，或审查组织中现有的 JTBD 工作是否正在推动决策。

---

这项技能的用途

这项技能涵盖 JTBD 作为产品工作中的一种框定技巧。与 PM 技能的区别如下：

• discovery-research-synthesis 是更广泛的综合分析方法；JTBD 是其中一种框定技巧。
• **jtbd-framing（这项技能）**聚焦于具体的 JTBD 方法论、其优势与失效模式。
• pm-spec-writing 属于后续环节：规范会将工作作为输入来引用。
• creative-direction 涉及定位；JTBD 能为定位提供参考，但不能取代创意方向。
• roadmap-planning 属于后续环节：路线图可以围绕工作而非功能来组织。

目标受众：资深 PM、产品总监、产品策略师、负责探索和定位工作的代理机构，以及正在考虑采用或已经在使用 JTBD 的内部团队。

不在范围内的内容：其他产品战略框架（Wardley mapping、North Star、OKR）；更广泛的综合分析方法（由 discovery-research-synthesis 负责）；有时会与 JTBD 混淆的人口统计用户画像工作。

---

功能请求清单 vs 人设戏码 vs 工作定义

核心框架。

功能请求清单。“用户想要 X、Y、Z。”这种框架把用户视为偏好集合体。产品团队会开发呼声最高的功能。结果：产品满足了用户明确表达的偏好，却没有解决用户真正想完成的事。用户不一定知道什么能解决自己的问题；他们描述的是症状，而不是解决方案。以功能清单为导向的产品往往只能逐步改进，却无法实现实质性的提升。

**人设戏码。**取些可爱的名字，再构建人口统计学画像。“市场经理 Maria，35 岁，住在城市，是 Pinterest 用户，喝燕麦奶拿铁。”这类画像只是装饰，无法指导决策。人设特征很少与用户对产品的需求相关；人口统计细节取代了对用户行为的洞察。现实中的人设往往只是贴在墙上的海报，在实际的优先级讨论中无人提及。

**工作定义。**用户雇用产品来完成工作。工作指用户想要完成的事，而不是用户是谁，也不是他们要求哪些功能。这种框架能揭示挣扎时刻（用户何时会想转而采用其他方案）；选择标准（什么促使他们采用某个产品）；弃用标准（什么促使他们转而选择其他产品）。结果：产品决策以用户动机为依据，而非用户描述。

检验标准。拿团队正在争论的一项产品决策来试试。JTBD 能为这项决策提供依据吗？“我们应该开发功能 X 吗？”换个角度问：“功能 X 能帮助用户完成什么工作？目前有什么工作完成得不好，而这个功能可以解决？”如果 JTBD 框架能让双方的论据都更清晰，说明这个框架发挥了作用。如果它只是增加了一套术语，却没能解决争论，那它就沦为了形式。

---

工作陈述的结构

标准结构：“当 [情境] 时，我想要 [动机]，这样我就能 [结果]。”

**情境。**工作开始变得重要的背景、触发因素或时刻。不是人口统计特征，而是一个时刻。

• “当我的团队正在推出一项新功能，而我需要向客户说明这项功能时……”
• “当我准备季度董事会演示文稿时……”
• “当我在工作时间之外收到客户升级反馈时……”

**动机。**用户在这种情境下想要做的事。

• “……我想写一则清晰的公告，说明有哪些变化以及为何重要……”
• “……我想把收入和用户参与度数据整理成连贯的叙述……”
• “……我想分诊并作出回应，同时尽量不影响晚上的安排……”

**结果。**成功的样子；用户通过完成这项工作想要实现的目标。

• “……这样我就能顺利推出更新，避免支持团队被困惑的询问淹没。”
• “……这样我就能在董事会提出可能的问题之前准备好答案。”
• “……这样我就能回应客户的顾虑，同时仍能陪伴家人。”

这种结构会迫使你在三个层面上都明确具体。情境、动机或结果模糊不清，都会导致工作陈述无法指导任何行动。

详见 references/job-statement-structure-patterns.md。

---

识别受挫时刻

当用户当前的解决方案无法满足需求、他们觉得现有替代工具不够用，并且主动希望换一种方式完成工作时，待完成的工作就会显现出来。

信号。 用户会描述当前做法带来的阻碍、他们采用的变通办法，以及他们希望有更好的工具。他们还会描述当前做法失效的具体时刻。

方法。 通过具体的提问，探索性访谈可以发现受挫时刻：“带我回顾一下你上次做 X 的情况。”“当时最难的是什么？”“如果可以，你会怎么做得不一样？”具体、近期的时刻比对“我通常怎么做这件事”的抽象描述能提供更丰富的信息。

模式识别。 从许多用户的反馈中，受挫时刻会形成聚类。相同类型的阻碍会反复出现。这些聚类揭示了市场上目前尚未得到妥善解决的待完成工作。

陷阱。 访谈时不以具体时刻为依据的团队，得出的待完成工作描述会过于抽象，无法指导决策。“用户想提高效率”并不是一个受挫时刻；“周二我花了一个小时，从三个不同的仪表板整理董事会指标，因为没有一个仪表板能提供我需要的数据切片”才是。

详情见 references/identifying-struggling-moments.md。

---

选择与放弃标准

用户为什么采用某款产品（选择），又为什么转而使用其他产品（放弃）。这两个问题让该框架立足于用户的真实决策。

选择标准。

• 用户想要解决的受挫时刻。
• 用户考虑过或首先尝试过的替代方案。
• 选定的产品为何能解决问题（相较于替代方案）。
• 预期的工作成果：用户期望借助该产品完成什么。

放弃标准。

• 即使使用了选定的产品，仍会再次出现的受挫时刻。
• 开始显得更好的替代方案。
• 什么因素让用户从“考虑换用其他产品”转为“实际换用其他产品”。
• 选定的产品未能持续交付的工作成果。

选择与放弃标准的重要性。

• 选择标准揭示了产品必须在哪些方面表现出色，才能赢得用户采用。
• 放弃标准揭示了产品必须维持哪些表现，才能留住用户。
• 两者往往不同：促使用户采用产品的功能，不一定也是防止用户流失的功能。

方法。 通过具体的提问，客户访谈可以了解用户选择或放弃产品的原因：“采用 X 之前，你在做什么？”“是什么让你换用其他产品？”“如果你明天不再使用 X，什么因素会促使你这么做？”近期做出的换用决定尤其能提供丰富的信息；用户会记得具体时刻。

详情见 references/hire-and-fire-criteria.md。

---

工作的功能、情感和社会维度

工作有三个维度。扎实的 JTBD 分析会呈现这三个维度；薄弱的分析则只关注功能。

功能维度。 用户在实际操作层面试图完成什么。

• “制作季度董事会汇报材料。”
• “跟踪团队 OKR 的进展。”
• “帮助新工程师熟悉代码库。”

情感维度。 用户在完成工作时的感受（或希望获得的感受）。

• “确信汇报材料反映了团队的实际进展，而不是粉饰后的版本。”
• “能够掌控 OKR 检查的节奏，而不是落在进度之后。”
• “能帮助新工程师，同时不必成为他们的全职向导。”

社会维度。 用户希望在完成工作时被他人如何看待。

• “让董事会认为自己是一位能力出众、熟悉各项数据的领导者。”
• “让直接下属认为自己会兑现承诺。”
• “让新工程师认为自己是一位投入精力帮助他们完成入职的资深同事。”

三个维度为何重要。

• 只在功能上取胜的产品，往往会输给那些同时满足情感和社会需求的替代方案。
• 有些产品决策取决于情感维度（“用户想要获得掌控感”）；仅靠功能分析无法发现这一点。
• 与功能描述相比，社会维度更能为产品定位提供依据。

分析方法。 针对每条工作描述，明确询问这三个维度。大多数早期工作描述都只关注功能；补充情感和社会维度，往往能揭示产品真正需要解决的问题。

详见 references/functional-emotional-social-dimensions.md。

---

JTBD 在哪些方面能带来清晰认知，在哪些方面会沦为形式

坦诚地说。

JTBD 确实能发挥作用的领域。

• 发现。 如果研究立足于用户遇到困难的时刻，以及他们选择雇用或解雇某种解决方案的决策，JTBD 就能揭示用户动机，而这些动机往往会在以功能列表为核心的发现工作中被忽略。围绕工作设计的发现访谈，比围绕功能偏好设计的访谈能获得更丰富的数据。
• 优先级排序。 团队讨论优先推进哪些工作时，工作能让讨论聚焦于用户试图完成的事情。“这项工作能帮助用户更好地完成重要任务吗？”这一问题可以化解功能请求排序中的各方博弈。
• 定位。 营销或销售团队阐述产品用途时，工作能将产品定位为帮助客户完成他们在意之事的途径，而不是一份功能列表。

JTBD 沦为形式的领域。

• 把工作描述研讨会当作交付成果。 团队举办研讨会，产出满墙的工作描述，却从未在后续决策中参考这些材料。研讨会成了交付成果，分析工作却并未真正开展。
• 缺乏严谨分析，用工作描述取代用户画像。 团队声称“我们现在采用 JTBD 了”，却把工作描述当作有名字的角色（工作鲍勃、工作爱丽丝），而不是分析工具。
• 要求每个产品问题都采用 JTBD。 每场会议都以“用户的工作是什么？”开场，即使这个问题并不适用。方法论变成了负担，而不是工具。
• 把 JTBD 当作合规要求。 组织因为领导力书籍或会议演讲的推荐而采用 JTBD；团队制作 JTBD 材料，以证明自己在使用这个框架；但实际上没有人用这个框架来做决策。

坦诚的判断依据。 如果团队能说明近期某项产品决策如何因 JTBD 分析而改变，就说明这个框架发挥了作用。如果团队会使用 JTBD 术语，却无法追溯决策与 JTBD 分析之间的联系，这个框架就沦为了形式。

---

将 JTBD 应用于发现、优先级排序和定位

JTBD 真正能发挥作用的三种模式。

发现。 围绕近期遇到困难的时刻、选择某个产品的决定以及弃用某个产品的决定来设计访谈。访谈结束后再从数据中提炼工作陈述，而不是事先设定。跨用户聚类工作。根据聚类结果为工作命名。搭配 discovery-research-synthesis，践行更全面的综合分析方法。

详见 references/applying-jtbd-to-discovery.md。

优先级排序。 评估路线图候选项时，按每个候选项要解决的工作来描述。问问：产品目前有哪些工作做得不好？哪些候选项能解决这些工作，哪些涉及相邻领域或无关工作？搭配 roadmap-planning，践行更全面的优先级排序方法。

详见 references/applying-jtbd-to-prioritization.md。

定位。 阐述产品的用途时，应先说明要完成的工作，而不是介绍功能。“帮助产品团队将探索性研究综合为决策”是对工作的描述；“具备协作工具的 AI 驱动研究综合”则是对功能的描述。搭配 creative-direction 和 brand-discovery，开展更全面的定位工作。

详见 references/applying-jtbd-to-positioning.md。

---

常见失败模式

快速诊断见 references/common-jtbd-failures.md。

• “我们办了 JTBD 工作坊，但路线图没有任何变化。”把工作陈述工作坊当成交付成果；工作坊之后没有开展分析工作。
• “我们的工作陈述听起来都一样。”工作陈述过于笼统，未以具体的困难时刻为依据。回到访谈数据中寻找依据。
• “我们的工作读起来像功能请求。”“当我使用产品 X 时，我想要功能 Y”并不是一项工作；工作是用户试图完成的事情，与产品无关。
• “我们既有用户画像，也有工作，两者还互相矛盾。”用户画像描述人口统计特征；工作描述具体情境。两者不必一致；如果发生冲突，工作通常在决策中权重更高。
• “JTBD 说我们应该什么都做。”如果不对各项工作进行优先级排序，JTBD 只会识别出许多机会，却不会帮你做出选择。搭配优先级排序方法。
• “我们放弃了 JTBD，因为它变成了形式主义。”这种情况很常见；解决之道是把 JTBD 当作分析工具，而不是仪式。在 JTBD 能发挥作用的地方使用这一框架；不要强行到处套用。
• “我们的工作陈述只有功能层面。”加入情感和社会层面；许多产品决策都取决于后两者。
• “我们无法就工作达成一致。”这通常意味着不同细分群体有不同的工作。明确呈现各细分群体之间的差异。
• “我们的营销文案用了 JTBD 术语，但产品没有。”这是定位与产品之间的脱节；营销主张并未在产品决策中发挥关键作用。

---

JTBD 框架：JTBD 定义的 12 项考量

应用 JTBD 或审查 JTBD 工作时，请逐一检查以下 12 项。

1. 围绕工作定义，而非罗列功能或扮演用户画像。 用户雇用产品来完成工作。
2. 工作陈述的结构：情境、动机、结果。 三个层面都要具体。
3. 挣扎时刻为工作提供依据。 要关注具体的近期时刻，而非抽象概念。
4. 明确雇用标准。 用户为何选择产品而非替代方案。
5. 明确解雇标准。 用户为何（或会）转而使用其他产品。
6. 呈现功能、情感和社会层面。 三者都要涵盖，不能只有功能层面。
7. 工作应从数据中得出，而非来自研讨会产出。 工作陈述应从访谈数据中提炼，而不是在白板会议中产出。若没有访谈数据，请按照数据可用性规则说明这一缺口。
8. 只在 JTBD 能发挥作用的地方应用它。 用于发现、优先级排序和定位，而非当作仪式。
9. 呈现不同细分群体的工作差异。 当不同细分群体因不同工作而雇用同一产品时，须呈现这些差异。
10. 决策应能追溯至 JTBD 分析。 每项重大决策都应能通过工作定义加以解释。
11. 不能用 JTBD 术语替代分析工作。 只有术语而没有分析，就是仪式。
12. 诚实评估 JTBD 无法提供帮助的地方。 有些问题无法从这种定义方式中获益；强行套用只会沦为仪式。

该框架的产出是以用户动机而非用户描述为依据的产品决策，并且只在能增加清晰度时应用这种定义方式，避免将其变成仪式。

---

如果所需数据不可用

此技能的输出依赖它无法自行生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证，经认可的输出方式是提供交付内容并说明缺口：需要什么、实际获取或验证了什么，以及输出中的哪些部分受到了影响。绝不允许为了完成交付内容而捏造、估算或插值推算所需数值。说明缺口本身就是完整的回答。

---

参考文件

• references/job-statement-structure-patterns.md - 情境／动机／结果结构及其完整示例。常见的结构性问题（情境模糊、将功能请求当作动机、将功能输出当作结果）。
• references/identifying-struggling-moments.md - 用于发现挣扎时刻的探索提示。识别不同用户之间的模式。区分具体时刻与抽象概念。
• references/hire-and-fire-criteria.md - 发掘雇用标准和解雇标准的方法。阐明两者为何往往不同。近期转换行为的访谈准则。
• references/functional-emotional-social-dimensions.md - 每项工作涉及的三个层面。说明为何只关注功能层面会失效。各层面的完整示例。社会层面对定位的影响。
• references/applying-jtbd-to-discovery.md - 围绕工作开展发现访谈的结构。工作聚类。从数据中为工作命名。与 discovery-research-synthesis 配合使用。
• references/applying-jtbd-to-prioritization.md - 根据工作为路线图候选项排定优先级。识别哪些工作完成得不好。与 roadmap-planning 配合使用。
• references/applying-jtbd-to-positioning.md - 以工作为导向的定位与以功能为导向的定位。突出产品如何帮助用户完成工作。与 creative-direction 配合使用。
• references/common-jtbd-failures.md - 9 种以上失败模式及其诊断和解决方法。贯穿始终的模式：将 JTBD 当作仪式，还是分析工具。

---

结语：关注工作，而非功能

严谨应用时，“待完成工作”（Jobs-to-be-Done）框架是最实用的产品方法论之一；但若将其当作仪式来应用，它也最容易流于形式。两者的区别在于：框架究竟推动了决策，还是仅仅装点了文档。

关注工作而非功能，是产品思维的一次真正转变。通过功能列表来发现需求，会把用户视为偏好汇总者；人物角色原型会把用户视为人口统计类别；而以工作为出发点，则会把用户视为努力完成某件事的人，产品只是他们为完成这项工作而雇用（或解雇）的工具之一。

从 JTBD 中受益的团队，会认真对待分析工作：以挣扎时刻为依据界定工作，识别雇用和解雇标准，挖掘功能、情感和社会层面的需求，根据数据推导工作，并在真正有用之处运用这一框架。采用 JTBD 术语却不做分析工作的团队，只会制造形式主义。

如果不确定某项 JTBD 应用是真正落地还是流于形式，可以问：最近的某项产品决策能否追溯到 JTBD 分析？还是说，JTBD 工作与基于其他依据做出的决策并行开展？如果是前者，JTBD 就发挥了作用；如果是后者，这个框架就只是装饰。