如何从客户反馈出发制定产品路线图：六个步骤
阅读约 1 分钟
如何制定产品路线图，说到底就是这样：收集客户已经提过的要求，按每条请求背后的问题分组，用一条你能解释清楚的规则给各组排序，判断你对每一项有多大把握，再用适合读者的格式把结果发布出来。顺序很重要。先选版式、再往里填想法的团队，得到的是一份看起来完工了、却没有任何证据的文档。从请求出发的团队，得到的是一份更短、但每一行都有依据的路线图。
| 步骤 | 做什么 | 得到什么 |
|---|---|---|
| 1. 收集 | 把请求、支持工单里的主题和使用数据汇总到一张清单 | 一份每行都标有来源的原始清单 |
| 2. 分组 | 合并重复项，为每组命名背后的问题 | 十到二十个带计数的问题 |
| 3. 排序 | 用一条评分规则，并把它写下来 | 一份你能为之辩护的有序清单 |
| 4. 承诺 | 把每项标为已承诺、预测或探索中 | 每一行都有如实的把握程度 |
| 5. 版式 | 按读者选择版式 | 采用 Now/Next/Later、主题或时间线的路线图 |
| 6. 复查 | 为每一行定下再看一遍的日期 | 一份始终保持最新的路线图 |
制定产品路线图，应该从哪里开始？
从你已经掌握的证据开始，而不是从一张白纸开始。未处理的功能请求、带有同一类抱怨标签的支持对话、销售电话的记录，以及你自己产品里的使用数据，都是输入。把它们放进同一张清单，并写下每一项来自哪里。
请求很少以可直接使用的形态到来。“加一个 Slack 集成”和”任务有变化时通知我的团队”，可能是同一个需求。这正是下一步要分组的原因，也是值得用一个能合并重复项的追踪系统的原因；重复的功能请求讲了怎么做。还要记住，支持工单和功能请求带来的是不同种类的信号，只用其中一种来做路线图，就会往错误的方向倾斜。
如何把请求变成路线图上的条目？
按问题给请求分组，把每一组命名为一个预期成果，并保留计数。十四条都在描述”刷新后筛选条件丢失”的请求，就变成一个条目：“记住上次用过的筛选条件”。计数填进来源列，这样读路线图的人就能看出它背后有多大分量。
用客户的话来写预期成果。“实现已保存视图的持久化”能告诉工程师要做什么，却什么也没告诉客户。用预期成果的写法还会逼出一个有用的问题：如果你说不出客户那边会发生什么变化，你面对的可能是一个应该放到另一张清单上的内部任务。
如何决定先做什么？
选一条评分规则，把它写下来，并套用到每一个条目上。最常见的是 RICE，它对覆盖面、影响力、把握度和投入成本打分；Intercom 对 RICE 的介绍是它的原始出处。一条更简单的规则只要你能解释清楚，效果一样好：请求的数量，按提出者是否为活跃的付费账户加权，再除以大致的工作量。
关键在于规则要说得出来，因为第一个问你”我的请求为什么不在清单上”的客户，会想要一个答案。当规则和你的判断不一致时，就在那一行里写明。功能请求优先级排序讲了各种评分方法、按收入加权的问题，以及投票数能说明什么、不能说明什么。
你对每个条目有多大把握？
在发布任何东西之前，先给每个条目标上把握程度。一个简单的三值量表就够了：已承诺，意思是如果这个时间窗口内没上线，团队会感到意外；预测，意思是除非有变化，否则这就是计划；探索中，意思是没有任何承诺。
这一列单靠自己就能避免大部分路线图造成的伤害。没有它，客户会把探索中的条目当成承诺来读，销售拿它去对外说，一个季度之后它就变成了一条投诉。Marty Cagan 那篇谈路线图的替代方案的文章阐述了背后的论点：带日期的功能清单，是被当成计划呈现出来的一堆猜测，解决的办法是明确说出你知道什么。
路线图应该采用哪种版式？
最后再按读者来选版式。想知道你有没有听到他们的客户，需要一个简短的公开视图。问”为什么要做这项工作”的管理层，需要主题或预期成果。每个月都调整方向的团队，用没有日期的”现在、接下来、以后”（Now/Next/Later）效果很好。产品路线图示例展示了六种版式、配有贴近实际的条目，并说明了各自怎么失灵；选定之后，产品路线图模板给出了可以复制的字段。
大多数团队最后会有两份文档：一份给内部读者的战略路线图，以及一份只展示你愿意被追责的内容的精简公开版。如果你要发布一份，公开路线图介绍了怎样用你已经在追踪的 issue 上的标签来驱动它。
如何防止路线图变陈旧？
给每一行定下复查日期，并把路线图放在工作本来就在的地方。在单独的工具里手动更新的路线图之所以会陈旧，是因为没有人的日常工作包含它。如果每一列都对应 issue 上的一个标签，标签一变，路线图就跟着变。
条目上线时，要把循环闭合。提出过请求的人应该收到消息，通常的做法是通过体验日志条目；客户反馈循环描述了整条路径。如果你决定不做某件事，也要说出来。明确的”不做”对提出请求的人是有用的，拒绝功能请求里介绍了怎样措辞。
FAQ
制定产品路线图有哪些步骤? 收集请求和数据，按每条背后的问题分组，用写下来的规则排序，给每项标上你有多大把握，为读者选一种版式，再定好复查日期。从证据出发，才能让路线图既简短又经得起追问。
产品路线图应该以什么为依据? 依据客户请求、支持工单中的主题、使用数据和你的战略，这个顺序也正是它们被忽略的频率高低。一份各行背后没有来源的路线图，只是一张愿望清单。
产品路线图应该覆盖多长时间? 长到有用，又短到可信。对许多小团队来说，就是详细写出当前这个季度，再把之后的一两个季度写成主题。更远的内容放进”以后”，不写日期。
制定产品路线图应该有哪些人参与? 产品负责人做决定，工程团队评估可行性和工作量，支持和销售提供他们听到的请求和主题。客户看到的是公开版本的结果，但他们不参与编辑。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。