jobs-to-be-done

通过待办任务（Jobs To Be Done）视角分析市场、产品和潜在客户——这套创新框架由 Clayton Christensen（《Competing Against Luck》）提出，并由 Tony Ulwick（Outcome-Driven Innovation）付诸实践。

核心洞见： 客户购买的不是产品，而是雇用产品，帮助自己在特定情境下取得进展。理解任务——而非客户人口统计特征或产品功能——才能预测成功。

双重用途技能：

• 销售/BDR 模式： 运用进步力量和转换访谈，了解潜在客户为何转换方案；围绕任务地图设计需求探索电话，并将价值主张表述为结果陈述
• 战略模式： 运用完整的 ODI 方法，评估结果的重要性与满意度，找出未充分满足的机会，并分析竞争中的雇用/解雇动态

适用情形：用户询问待办任务、JTBD 分析、客户任务、结果导向创新、进步力量、转换访谈，或客户为何更换解决方案。

<quick_start>

快速入门

触发方式： analyze [company/product/market] using JTBD

销售模式（需求探索电话、潜在客户研究）：

1. 明确潜在客户雇用解决方案来完成的核心功能性任务
2. 梳理进步力量（是什么推动他们转换方案？）
3. 生成用于需求探索电话的转换访谈问题
4. 将价值主张表述为结果陈述

战略模式（市场分析、产品创新）：

1. 撰写任务陈述
2. 构建任务地图（8 个步骤）
3. 生成 15-30 条结果陈述
4. 评估重要性与满意度（ODI 算法）
5. 找出最未充分满足的结果
6. 分析竞争中的雇用/解雇格局

示例： Analyze video conferencing for hybrid enterprise teams using JTBD </quick_start>

<core_concepts>

核心概念

什么是任务？

任务是一个人在特定情境下想要取得的进展。任务具有以下特点：

• 随时间保持稳定——“及时了解突发新闻”这项任务在过去 200 年里并未改变；改变的只是解决方案
• 与解决方案无关——任务陈述中不包含任何技术、产品或方法
• 兼具功能、情感和社会层面——每项任务都包含这三个维度

3 种任务类型

类型	定义	示例
功能性	要完成的实际任务	“减少现场直播期间的停机时间”
情感性	当事人希望拥有的感受	“确信直播不会在活动中途失败”
社会性	当事人希望他人如何看待自己	“被视为技术过硬的制作团队”

重要区别

概念	定义	示例	混淆时的问题
任务	在特定情境下取得进展	“监控远程课堂质量”	—
需求	结合情境的愿望	“我需要更快的编码器”	预设了解决方案
用户故事	开发需求	“作为用户，我想要提醒”	指定了实现方式
功能	产品能力	“以 60fps 进行 4K 编码”	描述的是你的产品，而不是他们要取得的进展

判断标准： 如果提到了你的产品、某项技术或某种具体方法，那就不是任务，而是解决方案。请反复改写，直到内容与解决方案无关。 </core_concepts>

<job_statement>

任务陈述

公式

[When ___], [I want to ___], [so I can ___]

• 当： 触发情境（不是用户画像）
• 我想要： 功能性任务（与解决方案无关的动词 + 宾语）
• 这样我就能： 更高层次的目的/期望结果

优质任务陈述的规则

1. 不包含技术、产品或品牌名称
2. 10 年以上保持稳定（如果这项任务在 2010 年就存在，表述也应相同）
3. 每条陈述只包含一项核心任务（将复杂任务拆解）
4. 使用主动动词：捕获、交付、确保、协调、监控

</job_statement>

示例

领域	工作陈述
视频制作	在制作有远程参与者的现场活动时，我希望确保所有来源的视频／音频质量一致，从而在没有技术中断的情况下呈现专业的直播
销售赋能	在为与新潜在客户进行探索性通话做准备时，我希望快速了解他们当前的情况和痛点，从而提出相关问题，发掘他们的真实需求
IT 运维	在关键系统性能下降时，我希望找出根本原因和受影响范围，从而在用户受到重大影响之前恢复服务
</job_statement>

<job_map>

工作地图 — 8 个通用步骤

每项工作都遵循这 8 个步骤。使用这些步骤来构建探索性通话，并在每个阶段识别成果机会。

步骤	定义	探索性问题
1. 定义	确定目标、规划方法、评估资源	“你如何判断 [工作] 的成功标准是什么？”
2. 查找	找到所需的输入和信息	“你会去哪里查找所需的 [信息／材料]？”
3. 准备	设置环境、整理输入	“在 [执行工作] 之前，你会做哪些设置或准备？”
4. 确认	在执行前确认已准备就绪	“开始之前，你如何确认一切都已就绪？”
5. 执行	执行核心工作活动	“请带我了解一下你今天实际如何完成 [这项工作]。”
6. 监控	跟踪工作进展是否顺利	“在 [这项工作] 期间，你如何判断进展顺利还是出了问题？”
7. 调整	情况变化时进行调整	“在 [工作] 过程中出现问题时，你会如何纠正？”
8. 结束	收尾、清理、评估结果	“你如何收尾？你如何判断 [这项工作] 是否完成得很好？”

销售应用： 在探索过程中，带潜在客户逐步梳理步骤 1-8。每当他们描述阻碍、变通方法或痛点时，都是一个机会信号。

战略应用： 每个步骤生成 2-4 条成果陈述，构建全面的成果集合（总计 15-30 条）。 </job_map>

<outcome_statements>

成果陈述

公式

[Direction] + [metric] + [object of control]

方向： 最小化、减少、提高、最大化、降低、消除

规则

• 必须可衡量（包含指标：时间、可能性、数量、金额）
• 必须可控（用户能够影响的事项）
• 必须与解决方案无关（不提及产品）

示例

工作地图步骤	成果陈述	重要性	满意度
查找	最小化识别正确输入来源所需的时间	9	4
准备	降低遗漏必要设置步骤的可能性	8	5
执行	最小化执行过程中所需的手动调整次数	9	3
监控	提高在问题影响输出之前发现问题的能力	10	4
结束	最小化确认工作已正确完成所需的时间	7	6

Imp = 重要性（1-10），Sat = 对当前解决方案的满意度（1-10）

常见错误

错误	不佳示例	修改后
过于模糊	“让它更容易”	“最小化配置输入来源所需的步骤数”
嵌入解决方案	“减少在 Zoom 和 OBS 之间切换的时间”	“最小化在不同来源视图之间切换的时间”
不可衡量	“改善监控体验”	“提高在 5 秒内检测到质量下降的可能性”
</outcome_statements>

<forces_of_progress>

进步的力量

客户切换解决方案时，有四种力量在起作用。其中两种推动改变，另两种则阻碍改变。

  DRIVING CHANGE                    RESISTING CHANGE
  ─────────────                     ────────────────
  ┌─────────────────┐               ┌─────────────────┐
  │  PUSH            │               │  ANXIETY          │
  │  Current pain    │──────────────▶│  Fear of new      │
  │  "This is broken"│               │  "What if it's    │
  │                  │               │   worse?"         │
  └─────────────────┘               └─────────────────┘
  ┌─────────────────┐               ┌─────────────────┐
  │  PULL            │               │  HABIT            │
  │  New attraction  │──────────────▶│  Comfort of old   │
  │  "That looks     │               │  "I know how this │
  │   better"        │               │   works"          │
  └─────────────────┘               └─────────────────┘

切换发生的条件： 推力 + 拉力 > 焦虑 + 习惯

</forces_of_progress>

BDR 快速参考 — 发现问题

推动力（挖掘当前痛点）：

1. “你现在处理 [job] 时，最让你头疼的是什么？”
2. “上次 [current solution] 让你失望是什么时候？发生了什么？”
3. “如果你能挥动魔法棒，最先会解决什么问题？”

吸引力（新解决方案的吸引力）：

1. “是什么让你开始寻找替代方案？” 2.“理想的 [job] 解决方案应该是什么样的？”
2. “你还看过哪些方案？哪些地方吸引了你？”

焦虑（减少对改变的恐惧）：

1. “你对从 [current solution] 切换出来有什么顾虑？”
2. “要满足什么条件，你才会有信心做出改变？”
3. “你以前试过切换吗？结果如何？”

习惯（克服惯性）：

1. “你使用 [current solution] 多久了？”
2. “如果你改变团队完成 [job] 的方式，团队会怎么说？”
3. “团队接受过当前系统的培训吗？谁需要重新培训？”

**销售洞察：**如果推动力很弱，潜在客户还没准备好——应持续培育，而不是推销。如果焦虑感很强，你的演示必须直接回应他们的具体顾虑。 </forces_of_progress>

<hiring_firing>

招聘/解雇分析

客户会“雇用”解决方案来完成任务，在解决方案失效时“解雇”它。用这个视角梳理竞争格局。

模板

当前雇用的解决方案	雇用它来做什么（完成什么任务？）	解雇它的原因（为何失效）	使用的变通方法
手动电子表格流程	跟踪输入，灵活	规模扩大后难以为继，容易出错	复制粘贴，反复检查
老旧的本地部署软件	可靠性，IT 控制	更新缓慢，用户体验差	同时使用影子 IT 工具
竞争对手的 SaaS	快速设置，现代化界面	缺少企业级功能	额外添加自定义集成
什么也不做	零成本，没有变更风险	任务完成得不好	接受糟糕的结果

关键问题：

• 潜在客户目前在为这项任务“雇用”什么？
• 为什么他们可能会“解雇”当前的解决方案？（= 你的切入点）
• 哪些变通方法揭示了尚未满足的成果？（= 你的差异化优势）
• “什么也不做”是否是竞争对手？（通常是最难击败的）

**不显而易见的洞察：**你最大的竞争对手往往不是另一款产品，而是潜在客户组合使用的变通方法、习惯和“够用就好”。在推介之前，先了解完整的“雇用组合”。 </hiring_firing>

<switch_interview>

切换访谈时间线

梳理潜在客户从最初念头到最终决策的决策历程。基于 Bob Moesta 的需求侧访谈方法。

时间线

First       Passive      Active       Deciding     Consuming    Satisfaction
Thought     Looking      Looking
  │            │            │            │            │            │
  ▼            ▼            ▼            ▼            ▼            ▼
"Something  "I notice    "I'm         "Comparing   "Using the   "Was it
 isn't       alternatives  actively     options,     new          worth
 working"    in passing"   searching"   getting      solution"    switching?"
                                        buy-in"

各阶段问题

初次萌生念头：“你第一次意识到目前完成 [job] 的方式行不通，是什么时候？是什么触发了那个时刻？”

被动关注：“在开始主动寻找之前，你注意到过哪些替代方案吗？在哪里看到的？哪些地方引起了你的注意？”

主动寻找：“是什么让你从‘只是留意一下’转为主动寻找？你搜索了什么？和谁聊过？”

做决定：“你如何缩小选择范围？哪些标准最重要？还有谁参与了决策？”

使用：“入门/设置体验如何？实际情况符合预期吗？”

满意度：“回顾来看，这次切换解决了最初的问题吗？有什么让你意外——好的或坏的？”

销售应用

• **赢单复盘：**带买家梳理全部 6 个阶段——你会发现真正促使他们购买的因素（很少是你以为的那些）
• **丢单复盘：**找出你在时间线的哪个阶段失去了机会——初次萌生念头（没有痛点）、做决定（标准方面落败）还是使用（入门体验糟糕）
• **发现沟通：**使用初次萌生念头和主动寻找阶段的问题，了解潜在客户当前处于决策时间线的哪个位置 </switch_interview>

<opportunity_algorithm>

机会算法（ODI 评分）

Tony Ulwick 的结果驱动型创新评分法可识别哪些结果服务不足（机会高），哪些结果服务过度（已商品化）。

公式

Opportunity Score = Importance + max(Importance - Satisfaction, 0)

• **重要性（Imp）：**1–10，该结果对完成任务有多关键？
• **满意度（Sat）：**1–10，当前解决方案对此的满足程度如何？
• **分数范围：**1–20

解读

分数	分类	行动
>15	服务不足——重要性高，满意度低	首要创新目标。在销售宣传中重点强调
12-15	服务适当——较为均衡	基本门槛。必须达到竞争对手的水平，此处无法实现差异化
<12	服务过度——重要性低或满意度高	简化／降低成本。对于“够用就好”的方案，客户可能愿意少付一些

评分示例

#	结果陈述	Imp	Sat	Score	Class
1	缩短直播期间检测到质量下降所需的时间	10	3	17	服务不足
2	降低不同信号源之间出现音频同步问题的可能性	9	4	14	服务适当
3	减少直播活动期间所需的手动调整	9	3	15	服务不足
4	提升切换信号源时避免出现明显故障的能力	8	6	10	服务过度
5	缩短设置多信号源录制所需的时间	7	5	9	服务过度

JTBD 机会指数（0-100 综合评分）

为与 Blue Ocean 和 Business Model Canvas 评分保持一致：

def jtbd_opportunity_index(outcomes):
    """Normalize ODI scores to 0-100 composite index."""
    scores = [imp + max(imp - sat, 0) for imp, sat in outcomes]
    max_possible = 20  # imp=10, sat=0
    avg_normalized = sum(s / max_possible for s in scores) / len(scores)

    # Weight by number of underserved outcomes
    underserved_ratio = sum(1 for s in scores if s > 15) / len(scores)

    index = (avg_normalized * 70) + (underserved_ratio * 30)
    return round(index * 100) / 100

# Interpretation:
# 75-100: Massive opportunity — many critical underserved outcomes
# 50-74:  Solid opportunity — clear gaps to exploit
# 25-49:  Moderate — some gaps, market partially served
# 0-24:   Low opportunity — market well-served, compete on cost/convenience

</opportunity_algorithm>

<consumption_chain>

消费链

分析客户在使用解决方案的整个生命周期中与之互动时遇到的阻力。

阶段	关键问题
认知	客户最初如何得知存在满足此任务需求的解决方案？
获取	他们如何评估并购买？购买流程中有哪些阻力？
设置	从购买到首次使用需要多久？哪些因素阻碍他们快速获得价值？
日常使用	核心使用模式是什么？痛点在哪里？
补充	他们会将哪些其他工具／变通方法与此解决方案结合使用？
维护	该解决方案需要哪些维护、更新或故障排除工作？
弃用	他们如何停止使用？转换成本／数据锁定情况如何？

消费链中的每个阻力点都可能成为创新机会或竞争优势。

</consumption_chain>

<example_session>

示例：混合办公企业团队的视频会议

任务陈述

在协调包含现场和远程参会者的会议时，我希望确保每个人都能平等地看见、听见并参与，这样无论人们身处何处，我都能主持高效的会议。

任务地图（关键步骤）

步骤	当前情况	阻力
准备	IT 部门提前 30 分钟检查会议室音视频设备	耗时，仍会失败
确认	“大家都能听见我吗？”的例行确认	每次会议都浪费前 5 分钟
执行	远程参会者互相抢话	缺少空间音频，摄像头取景不佳
监控	无法判断远程音频是否正在恶化	直到有人说“你声音断断续续”才发现
调整	手动切换摄像头、调整音量	演讲者无法专注于内容

## 得分最高的 5 项预期结果

#	预期结果	重要性	满意度	得分
1	尽可能缩短发现远程参会者音频／视频问题所需的时间	10	3	17
2	降低远程参会者听不清会议室内音频的可能性	9	4	14
3	尽可能减少会议期间所需的手动摄像头调整	9	2	16
4	提高远程参会者平等参与的能力	10	4	16
5	尽可能缩短混合会议前所需的准备时间	8	5	11

JTBD 机会指数：72/100 —— 机会良好，5 项预期结果中有 3 项未得到充分满足。

进步驱动力（客户从旧会议室系统转向其他方案）

驱动力	证据
推动力	“我们每年在会议室系统上花 5 万美元，远程员工却说体验糟糕。CEO 在董事会会议上注意到了。”
拉动力	“我看过一个演示，AI 可以自动取景发言者并混合音频。这正是我们需要的。”
焦虑	“我们有 40 间会议室。拆除现有 AV 设备是个需要 6 个月的项目。”
习惯	“我们的 AV 团队对当前系统了如指掌。他们不愿意改变。”

结论： 推动力 + 拉动力强。分阶段部署可以缓解焦虑。需要 AV 团队中的拥护者来应对习惯因素。

选择／弃用

方案	选择原因	弃用原因
旧会议室 AV 系统	可靠，IT 团队熟悉	远程体验差
Zoom Rooms	设置简单，界面熟悉	AV 质量控制有限
OBS + 自定义设备	灵活性最高	过于复杂、脆弱
无（笔记本电脑摄像头）	零成本	会议室体验糟糕
</example_session>

<success_criteria>

成功标准

• Job Statement 遵循 [When], [I want to], [so I can] 格式——不提及产品、技术或方法
• Job Map 涵盖全部 8 个步骤，并包含探索性问题
• Outcome Statements 使用 Direction + Metric + Object 公式，且可衡量
• 使用具体证据／引述（而非泛泛而谈）梳理进步驱动力
• 计算 ODI 机会得分：Importance + max(Importance - Satisfaction, 0)
• 找出得分最高的 3 项未充分满足的预期结果（得分 > 15）
• Hiring/Firing 表格从待完成任务的角度梳理竞争格局
• 计算 JTBD 机会指数（0-100 综合得分） </success_criteria>

<integration_points>

战略技能集群

JTBD 与其他 4 项战略技能相结合，支持第一性原理思考：

技能	关联
Blue Ocean	未充分满足的预期结果（ODI >15）是 Blue Ocean 中“创建”和“提升”因素的候选项
BMC	工作陈述定义客户细分；预期结果陈述定义价值主张
Challenger Sale	Reframe 步骤就是潜在客户尚未意识到的未充分满足的预期结果。使用 ODI 评分找出洞见。
NSTTD	校准问题（“成功是什么样的？”）是工作探索问题。进步驱动力对应 NSTTD 所应对的情感动态。

流程： JTBD（要完成什么任务？） → Blue Ocean（机会在哪里？）→ BMC（如何交付？）→ Challenger（洞见是什么？）→ NSTTD（如何沟通？） </integration_points>

输出 Outcome Sidecar

最后一步，将内容写入 ~/.claude/skill-analytics/last-outcome-jobs-to-be-done.json：

{"ts":"[UTC ISO8601]","skill":"jobs-to-be-done","version":"1.0.0","variant":"default",
 "status":"[success|partial|error]","runtime_ms":[estimated ms from start],
 "metrics":{"job_statements_created":[n],"outcome_statements":[n],"odi_scores_calculated":[n],"underserved_outcomes":[n]},
 "error":null,"session_id":"[YYYY-MM-DD]"}

如果某些阶段失败但仍生成了结果，请使用状态 "partial"。只有在未生成任何输出时才使用 "error"。