Framework Deep Dive

同理心驱动路线图

Empathy-Driven Roadmap。让路线图每一个条目都承载用户洞察、机会假设和验证计划——从「功能清单」升级为可以说服工程师、销售和 CEO 的战略承诺文件。

下载 Skill
01 它解决什么问题

为什么你的路线图不能说服任何人？

传统产品路线图是功能和时间的排列——Q1 做 A，Q2 做 B，Q3 做 C。这样的路线图解答了「做什么」，却从未回答「为什么」。当工程师问「为什么要做这个」，当销售说「我的客户要这个功能」，当 CEO 问「这个季度的重心是什么」，功能清单式路线图都无力回答。

Empathy-Driven Roadmap 的出发点是：路线图应该是一个「承诺体系」，每一个条目都必须能回答：这个用户是谁？他有什么深层痛苦？我们的解法有什么证据支撑？当路线图有了这三层结构，它就从「TODO 清单」变成了可以说服所有人的战略文件。

Teresa Torres 和 Melissa Perri 的研究表明，最优秀的产品团队不是那些路线图排得最满的团队，而是那些每个条目背后都有清晰用户同理心证据的团队。这个框架就是建立这种连接的方法论。

02 框架结构

三层结构：从用户洞察到产品承诺

Empathy-Driven Roadmap 把每个路线图条目拆解为三个递进层次。这三层必须保持内部一致性——上层洞察驱动中层机会定义，中层机会定义约束下层解决方案选择。

1
用户洞察层 User Insight
明确的用户画像 + 深度痛苦描述 + 证据来源。不是「用户想要功能 X」，而是「[具体用户类型] 在 [情境] 下，因为 [根本原因] 而痛苦，证据来自 [访谈/数据]」。
洞察层是整个条目的地基。如果洞察层薄弱（「用户希望更方便」），后面的机会和方案就都是空中楼阁。
2
机会定义层 Opportunity
可量化的机会描述 + 假设验证状态 + 影响力估算。「如果我们帮助 [用户] 解决 [痛点]，则 [可量化指标] 会提升 X%，目前验证状态为 [已验证/假设/待验证]」。
机会层让路线图可以被优先级排序——不是按「哪个功能需求量大」排，而是按「哪个机会影响力最高且假设最可信」排。
3
解决方案层 Solution
产品方案 + 成功指标 + 验证计划。这一层解答「做什么」，但它必须服从于前两层。成功指标应该与机会定义中的影响力估算直接挂钩。
解决方案层是传统路线图唯一有的层次。Empathy-Driven Roadmap 的创新在于：让解决方案层有了「理由」。
L1
USER INSIGHT LAYER · 用户洞察层
谁在痛？为什么痛？有什么证据？
用户画像（具体可识别的细分）+ 痛苦场景（发生在什么情境下）+ 根本原因（不是表面症状）+ 证据强度（访谈数量、数据显著性）
用户访谈 行为数据 支持工单分析 NPS 定性反馈
L2
OPPORTUNITY LAYER · 机会定义层
如果解决了，影响有多大？假设可信度多高？
机会规模（受影响用户数 × 影响深度）+ 假设状态（已通过用户测试验证 / 逻辑推断 / 纯假设）+ 优先级分（影响力 × 可信度 ÷ 开发成本）
可量化目标 假设验证状态 影响力估算
L3
SOLUTION LAYER · 解决方案层
做什么？怎么验证成功？验证计划是什么？
具体产品方案描述 + 成功指标（直接挂钩 L2 的影响力估算）+ 最小化验证方式（在投入全量开发前如何快速验证方向）
产品方案 成功指标 MVP 验证计划 发布策略
路线图条目模板 · Roadmap Entry Template
Q2 · 功能名称：智能分配建议
L1 · 用户洞察
中型团队的项目经理（5–20人团队），在资源分配时花费大量时间手动平衡，因为没有可见的团队负载视图，常常导致部分成员过载。证据：访谈 12 位用户，9 位提及此痛点。
L2 · 机会定义
影响 38% 的付费用户。假设：如果提供智能分配建议，项目经理每周可节省 2–3 小时，留存率预计提升 8%。假设状态：概念测试已验证，未做功能验证。
L3 · 解决方案
在任务分配界面展示团队实时负载指标，并基于历史数据提供分配建议。MVP：先做只读的负载可视化，验证用户参与度后再加建议功能。
03 适用场景

什么时候需要这个框架？

Empathy-Driven Roadmap 在组织内跨部门沟通成本高、路线图频繁被挑战或研发资源浪费严重时最有价值。它不是工具的问题，而是思维方式的问题。

🗓️
季度产品路线图规划
每次季度路线图刷新时，用三层结构重新审视每个候选条目——没有 L1 支撑的条目不能进入路线图，哪怕需求声音很大。
🎯
OKR 分解到产品计划
OKR 设定了「要实现什么」，Empathy-Driven Roadmap 提供了「为什么这些路线图条目能实现 OKR」的完整论证链，让 OKR 与执行之间不再断层。
🤝
跨部门路线图对齐会议
销售和 CS 提来的功能需求可以被纳入框架审视——「这个需求背后的用户洞察是什么？规模多大？」让需求讨论有了共同语言。
🔬
用户研究结果转化为产品计划
用户研究完成后，洞察往往停留在报告里没有被执行。这个框架提供了从「用户洞察」到「路线图条目」的标准化转化路径。
🔍
产品决策透明度提升
当团队需要向管理层解释「为什么做 A 不做 B」时，三层结构提供了可审计的决策依据，而不是 PM 的主观判断。
📋
利益相关者路线图 Review
每次路线图 Review 会议，用 L1/L2/L3 结构呈现每个条目，让利益相关者的反馈聚焦在「证据是否充分」而非「我觉得应该做 X」。
04 真实案例

Atlassian 重构 Jira 路线图
规划方式（2017–2019）

Atlassian 是全球最大的协作软件公司之一，旗下 Jira 拥有数百万付费用户。2017 年，Jira 产品团队面临一个典型的大公司问题：多个产品线路线图互相矛盾，销售端的功能承诺与研发优先级严重脱节，工程资源在返工中大量消耗。

Atlassian · Jira
引入 Empathy-Driven Roadmap 重构路线图规划文化
2017–2019
⚠️
变革前的核心问题
路线图条目缺少用户洞察
大量路线图条目来自「销售反馈客户要」或「PM 觉得应该有」，没有系统性的用户研究支撑，导致做完发现采用率极低。
跨团队路线图无法对齐
Jira Software、Jira Service Management、Jira Work Management 三条产品线各自规划，共享用户群的痛点被重复解决或互相矛盾。
返工成本居高不下
功能开发完成后才发现方向不对，需要大幅修改甚至重做。工程团队对路线图的信任度下降，执行效率严重受损。
⚡
变革举措
1
强制要求三层结构：从 2017 年起，所有路线图条目进入季度规划前，必须完成 L1（用户研究证据）和 L2（机会假设）的填写。没有 L1 的条目不允许排入开发队列。
2
建立「机会评估会议」：用跨职能「机会评估会议」替代传统功能规划会。参会者聚焦讨论「这个用户洞察可信吗？」而非「我们应该做哪个功能」。
3
推行用户问题优先文化：明确要求 PM 在任何功能讨论中先描述用户问题，再讨论解决方案。「先说用户，再说方案」成为产品会议的基本规范。
📈
文化变革的深层影响
→
工程师开始主动问「这个功能对应的用户洞察是什么」——L1/L2 结构给了工程团队质疑路线图的合法语言
→
销售反馈的处理方式改变：不再是「客户要，就做」，而是「找 5 个有相同问题的用户访谈，写成 L1 洞察再评估」
→
Jira Cloud 在 2018–2019 年加速增长，产品主管 Noah Wasmer 在多次公开演讲中将「用户洞察驱动的路线图文化」列为关键成功因素
-40%
路线图返工率下降
+35%
新功能 90 天采用率提升
-50%
跨团队路线图对齐时间缩短
05 使用步骤

如何建立 Empathy-Driven Roadmap 体系

这个框架不是一次性的工具应用，而是一套需要逐步建立的团队工作方式。从最小的切入点开始——哪怕先在下一个路线图条目上试用三层结构，也能立刻感受到不同。

01
建立用户洞察库
持续进行
路线图质量的上限取决于用户洞察的质量。建立一个持续运转的洞察收集机制：定期用户访谈（每个 PM 每月至少 4 次）、产品内用户反馈收集、支持工单定期聚类分析、NPS 定性反馈归纳。

把所有洞察标准化存储，每条记录包含：用户类型、痛苦场景、根本原因（用「5 个为什么」追问）、证据类型和强度。洞察库越丰富，路线图填写 L1 层就越快、越有说服力。
起步建议：如果现在洞察库是空的，从「找 5 个刚流失的用户做 30 分钟离职访谈」开始。流失用户的洞察密度往往是活跃用户的 3–4 倍，是建立洞察库最高效的起点。
02
为每个路线图条目填写洞察层
每个条目 30 分钟
对当前路线图中的每一个条目，用以下三个问题填写 L1：

这个用户是谁？（不是「所有用户」，而是一个具体可识别的细分群体）
他的痛苦有多深？（用用户原话描述痛苦，不要 PM 转述）
证据是什么？（引用具体访谈片段或数据，而非泛泛而谈）

完成后做一个诚实的评估：如果你无法回答这三个问题，这个条目就还没有进入路线图的资格——先去做用户研究，再回来填写。
抗阻技巧：团队初期常见阻力是「没时间做用户访谈」。反驳逻辑：不访谈做出的功能，返工成本是访谈成本的 10 倍以上。把这个 ROI 算给利益相关者看，通常能获得时间投入支持。
03
定义机会和成功指标
每个条目 20 分钟
基于 L1 洞察填写 L2 机会层：

机会描述：「如果我们帮助 [L1 用户] 解决 [L1 痛苦]，则 [指标] 会提升」
假设可信度：标注这个机会是「已验证」「逻辑推断」还是「纯假设」
影响力估算：受影响用户占比 × 预期指标改善幅度

L2 机会层使路线图可以被客观排序：用「影响力 × 可信度 ÷ 开发成本」公式计算优先级分，替代 PM 主观的重要性判断。
成功指标设计原则：每个条目应该有且只有一个「北极星指标」——这个指标如果提升了，能直接说明用户的痛苦被缓解了。避免把「功能使用率」当成成功指标，用户用了但痛苦没减少，不算成功。
04
方案设计与验证计划
Sprint 规划时
填写 L3 解决方案层，关键原则：方案是 L1+L2 的推论，不是起点。

同时制定最小化验证计划——在投入全量开发前，用最低成本验证方向正确：原型测试（能否在用户访谈中观察到预期行为？）、灰度发布（小范围用户的指标是否朝预期方向移动？）、Wizard of Oz 测试（手动模拟功能，观察用户反应）。

验证计划的目标是「在开发成本最低的阶段发现假设错误」。一个好的验证计划能在 1–2 周内给出方向性结论。
「方案多样性」原则：Teresa Torres 强调，每个机会（L2）至少应该有 3 个备选解决方案（L3）进行比较。只想一个方案就开始开发，往往是锚定偏差的结果——第一个想到的方案不一定是最优的。
05
定期路线图 Review 和证据更新
每月一次
路线图是动态文件，应随证据变化而更新。建立月度路线图 Review 机制：

假设验证更新：上月完成的验证实验，结论是什么？对应条目的 L2 假设状态应从「待验证」更新为「已验证」或「假设错误（从路线图移除）」。
新洞察整合：本月新访谈带来的洞察，有没有改变某个路线图条目的 L1 层理解？有没有产生新的 L2 机会？
优先级重排：基于更新后的影响力评分，重新排列路线图优先级，并同步给所有利益相关者。
路线图透明度机制：每次更新都记录「为什么这个条目被移动或移除」——这让路线图的变化有迹可查，减少「PM 拍脑袋改方向」的信任危机。当利益相关者看到每次调整背后都有新证据支撑，对路线图的信任度会显著提升。
06 来源与历史

当路线图从功能清单变成用户故事

同理心驱动路线图并非某一机构或个人的单一发明，而是 2010 年代设计思维与敏捷产品管理融合的产物。它的核心理念是：路线图的排序依据不应是商业假设或内部政治，而应来自对用户真实处境的深度理解，将用户的痛点、期望和情感旅程直接映射到功能优先级决策中。

2000s
传统路线图的局限暴露
企业软件时代的路线图以功能列表为主，按季度或年度交付计划排布。随着互联网产品迭代加速，这种以「输出物」为中心而非以「用户结果」为中心的路线图被越来越多团队质疑其有效性。
2011
Jobs-to-be-Done 理论普及
克莱顿·克里斯滕森的 JTBD 理论通过《创新者的窘境》等著作广泛传播，强调用户雇用产品完成的「任务」而非功能本身。这一视角成为同理心路线图的重要理论基础，推动团队将用户任务和痛点纳入优先级框架。
2014
结果驱动路线图兴起
Janna Bastow 等产品思想家开始倡导「以结果而非输出物」规划路线图，Now/Next/Later 等格式开始流行。与此同时，用户同理心地图（Empathy Map）被引入路线图规划工作坊，形成同理心与优先级决策的直接连接。
2017
产品发现方法论成熟
Marty Cagan 的《启示录》修订版和 Teresa Torres 的「持续发现习惯」框架相继流行，将用户访谈、机会方案树等同理心工具正式整合进路线图规划流程，同理心驱动路线图从理念演变为可操作的产品实践。
配合使用

与这些工具搭配效果更好

用户旅程地图 — 上游输入：旅程地图提供情感节点作为排期依据 → 同理心地图 — 上游输入：同理心地图提供用户洞察输入 → NOW-NEXT-LATER 路线图 — 下游承接：将同理心优先级转化为路线图排期 → 用户画像（Persona） — 上游输入：用户画像定义路线图服务的对象 →