人们买电钻，不是为了拥有一台机器，而是为了在墙上打一个洞。人们在上班路上买奶昔，常常不是为了“喝一杯饮料”，而是为了让通勤的无聊路上有个东西能单手拿着、慢慢吸、还能稍微垫垫肚子。这就是 Jobs-to-be-Done（待办任务，简称 JTBD）最核心的一句话：

用户并不是在为“产品功能”付费，而是在“雇用”你的产品，去完成自己生活或工作里的一项任务。

任务（job）才是稳定的市场边界，而产品形态、人群标签、渠道都会变。谁先看清用户真正要“完成什么事”，谁就握住了创新的入口。

本文分两部分：第一部分完整拆解 JTBD 与 结果驱动创新（Outcome-Driven Innovation，ODI） 方法论（主要参考 Strategyn 官方流程页 strategyn.com/outcome-driven-innovation-process）；第二部分用它来解释——为什么 Livo 要从录音和内容里自动提取待办，又为什么把这些待办交给 Pi.Agent 去执行，本质是把“整理待办、执行待办”这两件最耗人的事，从人身上彻底卸下来。

一、Jobs-to-be-Done 到底是什么

JTBD 由克莱顿·克里斯滕森（Clayton Christensen）推向主流，并由 Tony Ulwick 在 Strategyn 把它工程化成一整套创新流程。它的基本立场是：

用户雇用产品，是为了在某种情境下，把某项任务“更好地完成”。

“更好地完成”由一连串可度量的标准决定——更快、更省、更少出错、更不费心。这些标准，才是需求本身。

一个“任务”通常有三维：

  • 功能维度：把事做成（打个洞、写封邮件、做完会议纪要）。
  • 情感维度：过程中是否安心、是否有掌控感、是否不焦虑。
  • 社会维度：在别人眼里显得专业、靠谱、省事。

传统产品管理常把市场定义成“25–40 岁白领”或“某个行业”。JTBD 说，这错了——市场应当围绕“任务”定义。一个任务可以被完全不同的人、在不同场景里“雇用”不同产品来完成。看清楚任务，你才不会在错误的抽象层级上做产品。

JTBD 句式

当 （情境） 出现时，我雇用 （产品/服务），是为了 （把某项任务更好地完成）。

例：当一场会议结束时，我雇用 Livo + Pi，是为了把会上说定的事真正做完，而不是只记下来。

二、为什么“按人口统计分”会害死创新

企业最常见的失误，是用年龄、行业、收入、地区去切分用户，再据此拍脑袋想功能。问题有两个：

  • 同一类人，任务可能完全不同。两个都是“35 岁产品经理”，一个要写 PRD，一个要盯上线——你给他们同一个功能，只对了一半。
  • 不同类人，可能雇你做同一件事。老板、工程师、学生都会“把会议说定的事做完”，只是场景不同。

按任务切分，才能找到真正的增长点。这正是 ODI 要解决的：它不靠创意脑暴，而是靠一套“定性 + 定量 + 细分”的方法，把隐藏的、未被满足的需求挖出来。

三、Outcome-Driven Innovation（ODI）：把 JTBD 变成可执行的流程

ODI 是 Strategyn 发明、被克里斯滕森称为“为创新带来可预测性”的战略与创新流程。它的行业地位相当突出：官方称成功率约 86%，而行业平均成功率仅约 17%（约 83% 以失败告终）。差距来自一个核心反转——

Needs-First（需求优先），而不是 Ideas-First（创意优先）。

创意是创新流程的输出，不是起点。先精确识别哪些需求没被满足，再去想方案；而不是先攒一堆点子再筛。ODI 主张在写第一行产品概念之前，就先把产品—市场契合（product-market fit）定义清楚，避免事后反复 pivot。

ODI 的五步流程

Strategyn 官网把 ODI 拆成五个步骤（FAQ 里也给出一个更细的“六步版”，后文会提）。我们按主流程讲：

① 围绕任务定义市场
把市场定义为“谁，在雇用产品完成哪项核心任务”。市场应长期稳定，不被产品形态牵着走。这一步只有约 14% 的领导者做得好。
② 挖掘期望结果（Desired Outcomes）
用户会用上百条指标来定义什么叫“完美完成任务”。把需求表达成“期望结果”，而非功能清单。这一步被 71% 的人认为关键，但只有 15% 做得好。
③ 量化哪些结果未被满足
用统计样本测“重要性 × 满意度”，算出哪些结果代表最大机会。以数据确定性，替代主观猜测。
④ 发现隐藏的机会细分
用户对“哪些结果没被满足”意见常常不一致。按结果（而非人口统计）细分，能找到对手看不见的细分人群。
⑤ 制定并落地制胜策略
基于未满足需求的共识，重新定位/改进产品、填补组合空白、指导研发投资。

FAQ 的“六步版”在 ③④ 之间补了一步 对齐现有产品（先更新话术、找竞品弱点，不急着新开发），在 ⑤ 之前补了一步 构思新产品（针对特定细分的未满足结果，数小时到数天就能出赢家概念）。本质一样：先把需求说清，再动手。

关键概念：期望结果（Desired Outcomes）

ODI 把“客户需求”重新定义为“期望结果”。它不是“我想要一个导出按钮”，而是“当我导出时，希望不出错、格式干净、一次成功”。一条好的期望结果有三个属性：

  • 与方案无关（solution-free）：描述成功标准，不预设怎么实现。
  • 可度量：能用“更快 / 更准 / 更少步骤”衡量。
  • 随时间稳定：今天和三年后，用户对“完美”的定义基本不变。

单个市场通常会产出 50–150 条 期望结果陈述。正是这一长串指标，构成了后面量化和细分的地基。

关键概念：机会算法（Opportunity Algorithm）

怎么判断哪条结果“最值得做”？ODI 用一个简单公式把“重要性”和“满意度”合成一个机会分：

机会分 = 重要性 + max(重要性 − 满意度, 0)

重要性越高、当前满意度越低 → 机会分越大 → 越该投入。

逻辑很直观：用户极其在乎、但现有方案又没做好的事，就是蓝海。满意度已经很高的，再做是浪费；重要性很低的，做了也没人在乎。

关键概念：基于结果的细分 & 通用任务地图

  • Outcome-Based Segmentation（基于结果的细分）：把市场按“拥有相似未满足结果集合”的人分组，而非按年龄/地区。这样能发现传统细分看不到的隐藏人群。
  • Universal Job Map（通用任务地图）：一套定性研究工具，用来系统性捕获一项任务从“触发”到“收益”全链路上的所有期望结果，确保不漏需求。
  • Market Sizing：容量按“任务执行者数量 × 执行频率 × 支付意愿”估算，而不是按产品销售额——因为市场是围绕任务定义的。

Universal Job Map：把一项任务拆成 8 个阶段

多数团队一谈“需求”，眼里只有“执行”那一步。Ulwick 的 Universal Job Map（通用任务地图）指出：任何一项任务，都由 8 个普适阶段构成——define / locate / prepare / confirm / execute / monitor / modify / conclude。它画的是“任务本身”的流程，不是某个产品的用法，所以同样稳定、与方案无关。

真正不漏需求的办法，是在每个阶段下都挖期望结果：用户在“定位资源”时希望更快找到？在“监控”时希望少盯一点？在“收尾”时希望自动归档？把这些都列出来，才不会只优化“执行”而漏掉前后两端。下表把这 8 个阶段，套到 Livo + Pi 那条“把说过的话变成做完的事”的任务上：

阶段任务上在做什么Livo / Pi 的落点
Define 定义说定什么了、什么算做完Livo 摘要 + 待办提取
Locate 定位找上下文、找原始对话Livo 转写 + 知识库检索
Prepare 准备把输入整理成可用材料Livo 写入 meeting-brief.md / transcript.txt
Confirm 确认判断哪些待办该做、由谁做Livo 待办分流（答案 / 交付 / 只能人做）
Execute 执行真正产出成品Pi 草稿优先、自主执行
Monitor 监控盯每条待办的状态summary.md 回流 + Livo 轮询
Modify 调整按反馈迭代Pi refine 循环（V3）
Conclude 收尾接受结果、在待办告知用户、留指针给后续任务完成状态与结果在待办任务中告知用户；产物留在 Pi outputs/，供后续任务复用（不写回 Livo 知识库）

这张表也解释了为什么 Livo 和 Pi 要拆成两层、而不是塞进一个工具：8 个阶段里，“理解类”（Define / Locate / Prepare / Confirm）靠 Livo 的真相层，“执行类”（Execute / Monitor / Modify）靠 Pi 的执行台；而 Conclude 收尾则由 Livo 在待办中告知用户结果、产物留在 Pi 环境供后续任务复用（不写回知识库）——它把两层连成闭环。各管自己机会分最高、也最该自动化的那几段。

ODI vs. 传统新产品流程

维度传统（Ideas-First）ODI（Needs-First）
起点脑暴创意 → 筛选识别未满足的期望结果
需求表达功能清单 / 用户故事50–150 条可度量期望结果
决策依据主观判断、老板偏好重要性 × 满意度，机会算法
细分方式人口统计 / 行业基于结果的细分
PMF 时机事后 pivot 才找开发前就定义清楚
典型成功率约 17%（行业平均）约 86%

四、用 ODI 的镜头看 Livo：用户到底雇它做什么

把上面这套方法论套到 Livo 上，结论会非常清晰。

Livo 表面是个“AI 智能录音助手”：浏览器插件或本地上传录音，自动转写、摘要、思维导图、提取待办、可分享。但如果按 JTBD 定义市场，用户雇用的不是“录音”，而是——

Livo 的任务

当 一场会议 / 一次访谈 / 一段现场对话 结束后，我雇用 Livo + Pi，是为了 把“说过的话”变成“做完的事”。

顺着这个任务往下拆，会发现一条清晰的需求链，而链上各环节的“满意度”天差地别：

  • “把对话录下来” —— 早已被广泛满足（各类录音、会议软件都在做）。
  • “把录音转成文字” —— 基本被满足（转写工具很多）。
  • “从内容里找准该做的事（待办）” —— 服务不足。人还是得自己听、自己记、自己理，容易漏、容易散。
  • “把该做的事真正执行完” —— 严重服务不足。纪要写完，待办躺在列表里，最后还是人一封封写、一项项做。

这正是 ODI 眼里的金矿：用户极其在乎、现有方案却没做好的“期望结果”，恰恰落在“提取待办”和“执行待办”这两步。 Livo 的产品设计，等于主动去啃这两条未被满足的结果。

五、为什么 Livo 要从内容里提取待办

在 Livo 的架构里，Livo 是“真相层”（truth layer）：录音、转写、摘要、思维导图、待办提取、知识库，都归它。它的强项是“理解一段对话，并在一回合内给出答案”。

“从内容里提取待办”，本质是把一团杂乱的对话，翻译成用户的期望结果——也就是“接下来该把哪些事更好地完成”。这一步为什么必须由 Livo 做、而且价值巨大？

它把人从“整理待办”里解放出来。

过去一场会结束，最累的往往是“会后整理”：谁说了什么、决定了什么、谁该干什么。人要在记忆、录音、聊天记录之间反复横跳，还经常漏掉关键行动项。Livo 把这件事自动化：转写 → 摘要 → 待办，一次成型。

而且 Livo 不会把所有待办一股脑丢给 Pi。它先做待办分流（triage）：

  • 答案型（answer-type）：Livo 当场就能答（比如“上次会议定了啥”）——原地回答，不进 Pi。
  • 交付型（deliverable）：要产出文件/方案/研究——派发给 Pi。
  • 只能人做（human-only）：打电话、签字、当面谈——留在 Livo 当提醒，不派发。

这个分流本身就是 ODI 思想的体现：先判断“这条期望结果该由谁来完成”，再决定执行路径，避免把人无意义地推给另一个系统。

六、为什么把待办交给 Pi 去执行

Pi.Agent 是 Livo 的“执行工作台”（execution workbench）：多步、读写文件、产出交付物、能跨多个待办、能迭代。它的强项是“把一个意图，变成一件成品”。

两者的分工被一句话概括：

分工

Livo 回答“说了什么 / 该做什么”；Pi 产出“该做的事做完了的成品”。

当用户在 Livo 的待办页点下“交给 Pi 执行”（或“打开 Pi 工作区”），Livo 把待办列表 + 会议上下文（以文件形式写入 inputs/meeting-brief.md 与 inputs/transcript.txt，而非塞进 prompt）一次性移交给 Pi。之后 Pi 在 workspace 里自主跑：

任务分类
Pi 在会话开始时给每个待办定性：直接产出（agent_deliverable）、可准备大部分（agent_assist）、只能人做（human_only）。
草稿优先（draft-first）
绝不中途停下来问。信息不全就产出带 [待确认: …] 占位符的草稿，把问题集中到最后。
风险分级
低风险歧义（语气、格式）Pi 自己定并注明假设；高风险歧义（收件人是谁、外部承诺、价格、日期）保留占位符 + 结尾提问。
独立执行、遇阻继续
待办默认相互独立；某个 blocked/failed，记录原因后继续下一个，整批不中断。
回写结果
最后写 outputs/summary.md，逐条列出状态、产出路径、待确认事项，回流到 Livo 待办页。

用户的“家”始终是 Livo：派发 → 等待 → 在 Livo 里查看 summary.md、接受或细化，默认零切换。进入 Pi 是可选的深入入口，不是必经之路。

它把人从“执行待办”里解放出来。

起草邮件、做调研、写方案、出开发任务书、整理资料——这些原来要人亲自动手、反复迭代的活，现在由 Pi 在 workspace 里跑完，人只需要在终点审核和确认。中间过程（working/ 草稿、执行日志）留在 Pi，不污染 Livo 的“真相层”。

七、前后对比：人到底少做了多少

把“整理待办 + 执行待办”两段人力成本摊开看，差距非常具体：

以前（人全程亲力亲为）

  • 会后听回放、翻聊天，手动记笔记
  • 自己归纳“谁该干什么”，写进待办软件
  • 逐条起草邮件 / 方案 / 调研提纲
  • 上网查资料、整理、反复改稿
  • 盯进度、催节点、回邮件
  • 待办常常烂尾，因为“做”太费劲

现在（Livo + Pi 接管两段）

  • Livo 自动转写 → 摘要 → 待办，一气呵成
  • 待办自动分流：能答的当场答，该做的派 Pi
  • 一键“交给 Pi”，Pi 产出成品草稿
  • Pi 自主调研、写稿、迭代，留痕在 workspace
  • 状态与结果回流 Livo，人只审核确认
  • 待办真正“做完”，而不只是“记下”

减少的不是一两步操作，而是“整理”和“执行”这两个最烧脑、最容易被拖延的环节。人从流程的“操作员”退回到“审核员与决策者”——这正好对应 ODI 里“让系统接管重复、确定、可审计的部分，人负责授权、审核、处理异常”的方向。

八、回到 ODI：Livo + Pi 是“需求优先”的范本

最后，用 ODI 的术语收束：

  • 市场围绕任务定义：不是“录音工具市场”，而是“把说过的话变成做完的事”的任务市场。
  • 需求优先于创意：先锁定“提取待办”“执行待办”这两个未被满足的期望结果，再决定 Livo、Pi 各自怎么实现。
  • 期望结果可度量：更少遗漏的待办、更快的初稿、更少人工切换——都是可验证的指标。
  • 分工即细分：Livo 管“理解”，Pi 管“执行”，各做自己机会分最高的那段。
最好的产品创新，不是多一个功能，而是把用户一项“没被好好完成”的任务，默默接过去做完。Livo 提取待办、Pi 执行待办，就是在做这件事。

JTBD 给我们的启发其实很朴素：别问“我的产品有什么功能”，要问“用户雇我，到底想完成什么”。当你看清那个任务，并把它链路里最未被满足的环节啃下来——就像 Livo 啃“提取待办”、Pi 啃“执行待办”——产品自然就立住了。