写在后面： 本文译自 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 个工单）。
设立后果时，倡议像示例二一样，阐明数据指标的起止变动范畴，即采纳形如「用户行为 在工夫范畴 <T> 内，从 <x> 变为 <y>」的格局。 这要求团队可能量化以后的产品状态，指标量化同样也是后果导向型治理的重要组成部分。
如果应用 OKR 工具管理工作，那么 Objectives 就是产品指标，Key Results 为后果。
第 4 步：确定扭转用户行为的机会点。 它能够是用户痛点 / 问题、能从产品取得的益处，以及想要实现的需要（Jobs To Be Done）。如果能抓住机会，提供良好的解决方案，就能达成预期的后果。
Marty Cagan 通过观察指出，团队须要对用户、数据和市场有深刻的理解，能力解决用户的问题，并发明出有价值的、可用的、可行的和有短暂生命力的产品。
SUMMARY | 未完待续
紧跟上述四个步骤，咱们便领有了
- 一个清晰且令人信服的产品愿景；
- 一组能够帮忙实现愿景的指标；
- 一些围绕用户开展的可量化的后果；
- 一系列可能产生用户价值的机会，比方用户痛点、获利或者待实现的需要等。
制订产品策略是一个一直求实、逐步具象的过程。产品研发不能脱离业务指标而存在，那么技术团队如何在产研实际中，交付正确的用户价值？
后果导向的产品路线图应该如何落实？又会以怎么的状态，与发版打算联合在一起？
下篇文章，LigaAI 持续揭秘。
理解更多研发治理、技术成长、麻利开发、行业动态等干货，请关注 LigaAI@SegmentFault 帐号~
也欢送点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品，与咱们开展交换~