从 Netflix 传奇看，结果导向的产品路线图如何制定？（下篇）

写在前面：本文译自 Jason Doherty、Kelsey Stevenson 和 Thomas Vela 于「2019 年丹佛创业周」发表的「Outcome Based Roadmaps」主题演讲实录；原作者为 Jason Doherty。

👉如何制定产品路线图（上篇）👈中提到，今天优秀的产研团队不只关注功能的上线交付，还更加在意功能交付后是否达成了预期的结果，而结果（Outcome）是功能所产生的、可测量的、与企业目标一致的用户行为的变化。

跟随路线图制定的前四部曲，我们设立了一个产品愿景，多个目标、结果和机会。在敲下第一行代码或键入第一个词语之前，我们先明确了「什么是产品成功」，并清楚地指出实现目标所需关注的一系列事情。

你可能不信，大多数团队并不这么工作。他们实施的功能通常来自 CEO 或 SVP 在晨间沐浴时蹦出的想法——典型的 HiPPOs（Highest Paid Person's Opinion，最高薪人士意见）现象。Jez Humble 在 2012 年的一项研究中指出，超过 60% 的产品团队会通过 HiPPOs 决定待构建的事项。

产品成功被定义为「功能上线」，而只有七分之一的功能实现了「创造可量化的影响」的目标。

得到一个想法，非常容易。

解决用户问题并实现目标，却很困难。

一个可以衡量成功与否的战略框架，能够让拥有授权的跨职能组织不断迭代功能并解决问题，直到预期目标达成。

01 结果导向的路线图

路线图是一个与领导层和产研团队沟通的战略工具。它阐明了

• 愿景和目标是什么？

• 想要达成什么结果？

• 如何衡量「成功」？

• 当前的重点是什么？

• 有哪些重要的时间节点？

路线图侧重于产品愿景、目标、成果和机会，而发版计划则描述了故事、功能、解决方案和想法。

路线图的终点就是发版计划的起点

02 最容易实现目标的是跨职能团队

就像前面说的那样，过去大多数功能都是由高高在上的企业领导者所指定，与产品战略毫无关联。产研团队像外包供应商一样，不断实现功能；无论功能是否达到预期，我们只衡量工程师团队的开发速度和已交付的功能，接着便能宣布成功。

更快地交付错误的功能，依然没有交付价值。

现在，高效能的产研团队使用数据和用户反馈，衡量功能是否达成预期目标。每个功能在发布时都是可量化的，并且都有一个预期的结果。团队会不断迭代功能（使用精益创业技巧，如「构建-评估-学习」循环）直到成功为止——大家都知道什么是成功，也清楚目标应该长什么样子。

企业中最有能力达成结果和目标的人，是那些实现功能和离用户最近的人；他们通常是产品团队、产品经理、工程师和运维团队。理想情况下，他们应该处在一个跨职能团队中，而不是孤立地分布在各个部门里——如果这正是你所在团队的组织形式，那么结果导向型管理恐怕不太适用。

03 机会 > 想法 > 解决方案 > 功能

跨职能的研发团队如何以结果为导向，确保发版计划与路线图的目标一致，并将价值交付落实到研发全流程中？

制定产品策略图的第 5 步：将「结果」同步给跨职能团队，让他们：

🔸 结合共同商讨出的机会，提出想法（Idea）；

🔸 使用数据和用户反馈，验证哪些想法真正解决了用户问题；

🔸 根据已完成验证的用户问题的解决方案（Solution），创建功能（Feature）；

🔸 迭代功能，直到真正获得成功。

强烈推荐使用 Theresa Torres 的「机会解决方案树」工具，它可以清楚地展现结果和解决方案之间的联系。

机会解决方案树要弄清楚三个问题：

1. 有哪些想法可以解决这个机会？

2. 曾经尝试过哪些实验、假设或可能的解决方案？

3. 实验的结果如何？是否要推进该功能/放弃这个想法，或者展开新的实验以改进该想法？

实践中，应该明确地向管理者表达自己看法，承担起自己的责任；在大公司里，随着时间推移，也可以在团队间交流彼此的学习经验。

通过实验验证想法后，再推进下一步工作，创建功能和用户故事，并构建生产就绪的代码。优秀的产研团队总是避免构建没有价值的功能。

机会解决方案树有助于让高层领导们更具体地理解实验和学习成果。Dave Chalmers 在《一个前「功能工厂」的 PM 自白》中，也提供了一些能让机会解决方案树在组织内具象化的实用建议。

04 Current, Next and Future 模型

尽管我很反感在路线图上设置时间点，但现实情况是我们需要为企业高管们提供一些时序计划的指导；可以使用「Current, Next and Future」模型，列出时间线。

别忘了要在路线图上列出产品愿景和目标，以确保结果与目标紧密相关。如果需要，也可以将结果按主题（Theme）分组，这有助于战略的具象化。

将所有内容放在一起，就会得到一张结果导向的产品路线图：

一个非常有用的小技巧：只罗列出「Current」列中正在开发的功能，让企业高层们了解「目前正在进行的工作」和「下一季度或以后的战略」。

由 Todd Lombardo、Bruce McCarthy、Evan Ryan 和 Michael Conners 合著的 Product Roadmaps Relaunched 一书中也有许多很棒的案例，推荐大家阅读。

总结一下

以结果为导向，管理产品是一个难题。我们必须建立一个清晰的产品愿景和战略；必须拥抱变化，接受不确定性；必须放弃传统的项目制管理，转向结果导向的怀抱。

我们要组建和培养一支能够掌控结果的团队，授权他们解决问题，并不断迭代直到产品成功；还要构建 DevOps 文化，以便在生产中安全地与真实用户一起测试想法，获得反馈和数据。

别担心组织规模太大或限制太多而无法开展以结果为导向的管理工作，因为亚马逊、谷歌、Netflix 和 Facebook，甚至英国政府，都是这么工作的。

在工作实践中逐渐向结果导向转变，尤其是销售主导或工程主导的团队。可以慢慢地从小规模改变开始，关键在于要结合产品路线图，围绕产品的共同愿景，建立起一致性。

了解更多研发管理、效能提升、敏捷开发、前沿技术等消息，欢迎关注 LigaAI@InfoQ 获取更多咨讯。

期待您点击 LigaAI-智能研发协作平台 ，在线申请体验我们的产品，期待与您展开交流~

LigaAI，以 AI 赋能，助力开发者扬帆远航！