从 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@oschina](https://my.oschina.net/u/5057806) 。
点击 LigaAI - 新一代智能研发协作平台,在线申请体验我们的产品。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
手写模拟Spring底层原理-Bean的创建与获取
作者:京东物流 张鼎元 1 引言 大家好,相信大家对Spring的底层原理都有一定的了解,这里我们会针对Spring底层原理,在海量的Spring源代码中进行抽丝剥茧手动实现一个Spring简易版本,来促进我们对Spring架构有个更深的理解,对Spring的常用功能进行手写模拟实现。 2 启动Spring 针对Bean的创建和获取功能,我们来进行功能的实 首先我们创建JdApplicationContext类做为Spring启动类,实现bean的加载和获取功能。 UserService和OrderService类作为Bean的实现类,通过JdApplicationContext类中的getBean方法获取到前面两个类的实现。 App为启动测试类 AppConfig为启动配置类 注:下面的代码会顺着内容讲解逐步完成 首先创建App类做为入口,测试Spring功能。通过初始化JdApplicationContext类,动态加载bean实例。 通过getBean方法获取bean实例。 创建JdApplicationContext类,提供获取Bean实例方法,通过构造函数动态初始化bean实...
- 下一篇
备战一年半,我们让最火的开源网关上了云
这是最好的时代,我们满怀信心施展才华;这也是最坏的时代,我们遇到了前所未有的竞争。工程师们从不畏惧困难,因为热爱能化解一切困难。本文源于对张超(API7 Cloud 团队负责人,Apache APISIX PMC member)的采访,这是一个关于 API7 Cloud 诞生的故事,路转峰回,寻寻觅觅。一年半后,我们舒颜感叹:莫愁千里路,自有到来风! 一款优秀的产品只需要一个契机 云原生时代风云变幻,开源产品层出不穷。 2019 年 APISIX 在温铭和院生的代码下诞生,6 月当时仍处于 Demo 阶段的 APISIX 便在 GitHub 上开源。一经开源,APISIX 的独特性让它迅速席卷开源领域。2019 年 8 月,APISIX 成功进入了 Apache 孵化器,次年 7 月 APISIX 顺利毕业,并成为了 Apache 软件基金会的顶级开源项目。 Apache APISIX 的诞生打响了 API7.ai 商业化版图的“第一枪”。API7.ai 基于对市场发展的理解,定位 SaaS 未来能成为发展的方向,能够真正给公司带来增长,开始投入商业化。我们 API7 Cloud 团队...
相关文章
文章评论
共有0条评论来说两句吧...