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

01 避免成为「功能工厂」

许多软件研发团队在交付用户价值时总觉得十分困难——这通常是因为产研团队没有与用户保持持续沟通，或者团队没有评估功能交付后是否如期发挥了作用。 团队陷入「功能工厂」困境，一味地开发和上线新功能，并期盼有人会使用它们。

用户是否喜欢刚上线的新功能？它们还有哪些可优化或待改进的空间？用户是否从功能中获得了真正的价值？如果产研团队不评估这些，也不与用户交流，那就几乎无法构建任何产品影响力。

要知道，「上线功能」不意味着「产品成功」；取得成功的关键在于，要以可量化的方式，为用户带去积极的行为改变。

02 路线图 VS 发版计划

众所周知，发版计划（Release Plan）是关于功能和日期的列表。

而路线图（Roadmap）是一份旨在传达公司战略方向的文件，它阐明了「目标是什么？」「预期结果是什么？」以及「产品将如何赢得市场？」

Netflix 的创业故事被大家奉为经典，我们来看看 2007 年（左右）的 Netflix 路线图。

事实上，很多公司可能只有发版计划。他们总是试图提前几个月，预测多个功能在规模和时间上的发展和可能的影响。

企业高管们很喜欢这种 「可控的确定性」，哪怕研发团队很少按路线图计划的那般交付，功能也很少能达到预期。写满功能和日期的列表被贴上「路线图」的标签，但你我都知道，这不过是弥天大谎。

大多数情况下，这类公司不评估战略目标的实现情况（尽管它们曾被正式地记录下来），也不考量某个功能是否对用户总量或 ARR 等业绩跟踪指标产生了直接影响。他们只是盲目地在发版当天，上线功能，然后期待会有效果。

03 关注产出，衡量结果

开发团队、产品负责人、UX 专家和运维人员等资源（Resource）通力合作，在软件开发这项活动（Activity）中，创造并交付市场和用户期待的功能（即产出，Output）。大多数团队做到这一步，便会高呼「成功」。

而今天，优秀的产研团队更加在意：刚交付的功能是否取得了预期的结果（Outcome）。

An Outcome is a measurable change in customer behavior.

结果是可量化的客户行为的变化。

所有向用户交付的功能都应该为用户行为带来可量化的、积极的改变。通常情况下，我们不认为发布一个毫无效用的功能，能够代表成功。

功能无法实现预期效果的原因有很多，例如：

• 最初的方向可能有问题。
• 首发版本需要迭代优化，才能达到预期。
• 功能没有解决用户的问题，不能给用户带来好处，或者不能完成用户想实现的需求。

04 在迭代中评估结果，才能取得成功

想了解一个功能是否真的奏效，就必须：

• 知道每个功能真正奏效是什么样？
• 了解如何判断和评估功能的效用？
• 并在每次发布后评估每个功能的结果。

结果（即用户行为的变化）是产品功能所产生的影响。它应该是可测量的、与公司目标保持一致的，并以用户为中心的。

想要实现产品愿景并在市场上产生影响，就必须知道目标（Goal）是什么。而作为组织顾问和产品负责人，我发现大多数团队在工作时，没有明确的产品愿景或目标。

05 产品策略从产品愿景和目标开始

产品策略与计划不同，它是一个决策框架。产研团队依据框架指导做出决策，以实现产品愿景。

第 1 步：确定一个清晰且令人信服的产品愿景。 明确产品存在的意义，以及 5 年后产品的形态。产品愿景是不受时间影响、能持续为研发团队提供北极星般引路之光的存在。

产品愿景示例： 成为欧美地区酒店维护行业的第一大移动人力管理软件。

第 2 步：设立 2 - 3 个公司未来 1 - 2 年（内）要实现的目标。 目标是具体的、可衡量的、与产品愿景相关的；如果目标全部达成，就能实现一部分的产品愿景。

目标要足够具体，例如：

到 2021 年 7 月 30 日，要让欧洲目标市场上 4% 的酒店维修人员每天使用。

第 3 步：考虑要改变哪些用户行为（即结果）以实现目标。 它可能是注册率、转化率、用户满意度、创建的项目数量等等。

同时，结果的设定应遵循 SMART 原则，即具体的（Specific）、可衡量的（Measurable）、可实现的（Achievable）、切合实际的（Realistic）和有时限性的（Time-bound）。

结果示例一： 到 2019 年 12 月 31 日，用户在下载应用后 5 分钟内能以其母语创建工作订单。

结果示例二： 至少 80% 的用户每周至少管理 5 个工单（现在他们每周管理 2 个工单）。

设立结果时，建议像示例二一样，说明数据指标的起止变化范围，即采用形如「用户行为 <A> 在时间范围 <T> 内，从 <x> 变为 <y>」的格式。 这要求团队能够量化当前的产品状态，指标量化同样也是结果导向型管理的重要组成部分。

如果使用 OKR 工具管理工作，那么 Objectives 就是产品目标，Key Results 为结果。

第 4 步：确定改变用户行为的机会点。 它可以是用户痛点/问题、能从产品获得的好处，以及想要完成的需求（Jobs To Be Done）。如果能抓住机会，提供良好的解决方案，就能达成预期的结果。

Marty Cagan 通过观察指出，团队需要对用户、数据和市场有深入的了解，才能解决用户的问题，并创造出有价值的、可用的、可行的和有长久生命力的产品。

SUMMARY | 未完待续

紧跟上述四个步骤，我们便拥有了

• 一个清晰且令人信服的产品愿景；
• 一组可以帮助实现愿景的目标；
• 一些围绕用户展开的可量化的结果；
• 一系列可能产生用户价值的机会，比如用户痛点、获利或者待完成的需求等。

制定产品策略是一个不断务实、逐渐具象的过程。产品研发不能脱离业务目标而存在，那么技术团队如何在产研实践中，交付正确的用户价值？

结果导向的产品路线图应该如何落实？又会以怎样的形态，与发版计划结合在一起？

下篇文章，LigaAI 继续揭秘。

了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 。

欢迎点击 LigaAI - 新一代智能研发协作平台，在线申请体验我们的产品，开启智能提效！