5个策略规划产品路线,避免被着牵鼻子走

+ 关注
如何规划产品路线
文章目录

WorldRemit CPO Alice Newton Rex以自己多年经历分享了几点技巧“如何规划产品线路图,避免被功能型产品路线图牵着鼻子走”。每一位产品经理都应该从最终期望结果倒推开发过程,而不是从听命于上司;大胆删除冗余功能,少即是多。但是这种行为可能产生几大问题:

  1. 公司没有明确的企业策略;
  2. 团队不知道如何验证思路可行性;
  3. 得不到高层允许;
  4. 团队工作重复。

不过别担心,Alice一一为你提供了解决办法。在职业生涯中,我设计过很多产品路线图。其中,光是在 WorldRemit 工作的头 3 年里,我就为公司做了 10 种以上不同类型的产品路线图。

之所以要不断变换设计思路,是因为我希望通过尝试,找到最有效的产品路线图,至少要具备这样几个优点:针对性强、能与股东更高效地交流、引领团队高效协作。

众多产品路线图中的一个
众多产品路线图中的一个

众多产品路线图中的一个

在我看来,现在大多数产品路线图都一个共通的大问题:产品路线图被做成了纯粹的“功能清单”,唯一的区别就是这些功能被放置在一个时间轴上(而且也不是那么明确)。产品路线图发明人告诉你如何使用产品线路图。

其实这样一个“功能清单”问题颇多 ,最直接的就是公司上下包括你的客户,都会觉得这样一个功能清单就是你的承诺书,而你将“矢志不移”地兑现承诺,这无形之中给开发团队施加了巨大的压力,必须原原本本地按照这份清单行事,就算撞了南墙也不回头。

因为一回头你就会发现,这些功能根本就没解决问题,即便解决了,也都是些无足轻重的小问题。这种团队的使命就是日复一日地完成清单上的任务,即便产品开发的环境(包括公司策略、用户需求、行业竞争格局)早已发生了改变。

一、功能导向性产品路线图几宗罪

作为一个产品经理,“功能清单”可能会让你陷入尴尬的境地。大公司里由上而下的公司治理文化,明确了高管和股东在产品开发上的绝对话语权,他们向产品团队下达功能开发指令,团队只能遵从指示办事。

类似的,如果你加入了一家创业公司,公司的创始人一般会决定产品要怎么做,只要你给他一个空白清单,立马就会给你填满。这时,你作为一个产品经理,几乎没有自主权,充其量是个指令接受者,你所需要做的就是想法设法,尽量以最好的效果呈现老板们想要的功能。

在功能路线图的框架下,即便你是一个优秀的产品经理,也只能保证做好个别功能,不能对产品的全局有效把控,这就好比你赢下了一场又一场的局部战役,最后却输掉了整场战争。

想象一下这样的场景:要到年底了,你结束了产品的开发工作,向管理团队汇报工作,你告诉他们,计划里的所有功能都开发出来了。不管你完成的是一项多么难以置信的任务,他们还是会向你咆哮,说你做砸了他们的创意,想要的效果根本没有达到。

如果你是按功能导向型的路线图来做的,那这种事情是很可能发生的,也许是因为你被迫开发的功能没有实现预期的效果,但你还是得原原本本地做出来。那么问题来了,你应该如何摆脱功能型路线图的束缚,转向更为科学的产品开发模式呢?

二、从期望的结果倒推过程

从现在开始,你应该放弃对功能的过分关注,而是关心我们最终想要的效果是什么,需要解决的具体问题又是什么。试着问问自己,如果我们的产品开发成功了,会给世界带来什么样的改变?我们的用户会有什么样的体验?他们能通过我们的产品做些什么?

在一个特定的时间段内,每个团队都应该围绕这个共同的、明确的目标或者说结果而奋斗,而不是被功能路线图牵着鼻子走任何好的目标,都应该是能够测度、衡量的,同样,你设定的结果也必须是能够加以验证的,最直观的反馈就是,你的产品能得到用户和业界的认可吗?

如果你实现的结果是:“用户能看到更多广告”,这对用户来说就毫无价值,也更不可能因为这个结果而取得业务上的成功。一个好的结果应当是像这样的:“用户注册时间缩短一半”。

用户注册时间图
用户注册时间图

这样一来,产品经理不再是管理层的传令官,产品怎么做、开发什么功能、达到什么效果,变成了整个团队的问题。这种方式最大的优点就在于:团队内部有了更大的自主性,每个成员都能够发挥自己的专业特长和创造性。同时,只要我们观察到,用户能够在原来一半的时间内完成注册,那么我们的目标就达到了,也不必再管哪项功能有没有实现。对希望实现的结果有了更清晰的认识之后,你会发现自己的思路更加开阔,解决问题的可能性也远比之前多。

爱德华·德博诺博士(Edward de Bono)在他的著作《水平思考法》中举了一个非常经典的例子:一家大公司的高管们遇到了一个难题,这家公司搬到了一栋新的办公楼后,大家才发现,大楼的设计者考虑不周,没有配备足够的电梯,公司员工经常因为长时间等电梯而心生抱怨。

许多高管提议,要想办法给电梯提速,或者在大楼里再开凿一个电梯井,增加运量。不过,他们最终另辟蹊径,采用了一个完全不同的方法,同样成功解决了问题。他们在电梯入口处安装了很多落地镜,大家早上来上班的时候,注意力都集中在镜子中的自己,不知不觉就忘了等电梯的辛苦。

在这个案例中,高管们真正需要解决的问题其实并不是电梯不够,而是员工因为等电梯而产生的烦躁情绪。可以看到:他们选了一个比加装电梯划算很多的方案,最后也取得了非常不错的效果。

三、删除冗余,少即是多

这个新的设计思路还会带来另一个好处,那就是避免开发团队向产品中加入过多的功能,尤其是那些用户根本不需要的功能。了解下为什么产品路线图上50%的功能都无法实现

结果驱动型的方法,能够引导团队将精力集中在改良现有功能上,最大限度激发这些功能的效果,而不是光想着增加新的功能。这种思维方式极大地提高了团队的创造性,甚至能让你关注到平时都没有留意的方面。

立即登录阅读全文
登录或注册即可解锁全站内容,即表示你理解并同意 服务协议 与 隐私政策

我曾经和一个朋友探讨过这方面的问题,他所在的电子商务行业最关注的一个指标就是转化率,他们每年年底都会进行一次年终统计,有充分结果表明:对提升转化率贡献最大的部分,并不是增添的新功能,而是他们对现有功能做出的技术改良,例如优化图片处理技术之后,他们的网页加载速度大幅提升。这种方法还能让团队不断优化产品,去掉影响用户体验的功能。不过,就像其他方法一样,合不合适还得试过再说。在这篇文章剩下的篇幅里,我想要重点谈谈,结果驱动型的方法可能会出现什么问题,以及如何避免。

四、可能产生的问题

1. 公司没有一个明确的企业策略

首先,最重要的一点,如果你的公司没有一个明确的企业策略,那么结果驱动型的产品路线图也必然会失败。在WorldRemit,我们首先从确定公司本年度目标起步,用这个目标来明确各团队的任务,接着又从任务入手,细分出我们的季度目标和要取得的关键成果。

公司目标分解
公司目标分解

我见过太多团队都是直接跳到了最后一步,还没有先确定一个共同的目标,就奔着结果去了。

2. 你的团队不知道如何验证思路的可行性

第二个导致结果驱动型方法失效的原因是,你的团队不知道如何验证思路是可行的。这个问题产生的原因,很可能是你的公司正在经历转型,从原来传统的由上而下的公司文化,转变为结果驱动型的产品开发框架,不再聚焦对特定功能的开发。

如何验证思路的可行性,这个主题本身就可以再另外写篇文章探讨,在这里我就用一张图来说明,我们是如何在开发过程中,利用用户的反馈来进行验证。

验证产品思路可行性迭代流程
验证产品思路可行性迭代流程

3. 你没有得到高层的许可

这通常来说是转型过程中最大的拦路虎,下面介绍几种不同的方法来解决这个问题:勇敢地向别人阐述你的想法我们似乎很少花时间和别人解释自己的方法论,似乎这是整个行业的通病。

大多数人会有这样的想法:如果说一家比我们还好的公司,他们都还在循规蹈矩,为什么我们就要调整呢?不过,只要你能解释到位,科学的方法仍然是容易被别人接受的。建议你用一些比喻,让自己的表述更加生动。比如你可以这样讲:如果我是一支探险队的领队,我下达命令说要建一座桥,那队员们很可能花大量的时间去找造桥的材料,最后造出来的桥也许还不够结实,不能满足全队安全渡河的要求。

但是,如果我告诉他们,我想让全队安全过河,那么队员们很可能会拿出各种不同的办法:造木筏、寻找河流的浅滩等,而且大家都非常清楚,什么时候算是完成了任务呢——那就是大家都能安全过河了。向领导询问导致问题的原因,而非解决方案。

如果你这样问领导:“我们在做明年的产品路线图,您认为有什么功能需要加进来吗?”你不可避免地会得到这样的答复:“我们要在登陆页面加一个蓝色的窗口小部件,放一个视频告诉用户,我们能提供什么样的服务。”实际上,我们更推荐你围绕现有的问题提问,比如:“我们明年的目标是提升登陆页面的转化率,您觉得有什么原因在导致用户数量下降呢?”那么,你很可能得到更具建设性的答复,像是:“我们觉得用户转化率低,很可能是因为他们不太清楚我们能提供什么服务。”

向大家证明,少即是多。

有时候你会发现,不断地添加新功能,可能只是你的一厢情愿,说不定功能越少反倒越好。微软曾经通过一次试验,发现有将近 1/3 的功能给产品带来的是负面影响,还有 1/3 压根没有产生影响。当他们不同意你的解决方案时,试着提议先做一个测试如果领导不同意你的方案,可以试图找到一个成本较低的测试方法,并在合适的机会下向他们提议,说不妨先测试一下看看效果。

4. 团队工作重叠了,你该怎么办?

如果你像以前一样,按照不同的功能为团队分工,的确很容易确保大家各司其职,但改为结果驱动型的方法时,你就很可能会遇到这个问题。比方说,在共同目标的引导下,不同的小组有不同的开发任务,那么当这些小组任务之间产生矛盾时,应该如何确定它们的优先级呢?

例如,一个小组的任务是减少产品内的诱导性宣传,而另一个小组的任务是提高用户的转化率,显然两者之间存在一定的冲突,这时候,就需要组织你的产品开发团队共同协商了,大家必须要有清晰的大局观。

五、回到产品路线图来

我已经介绍了结果驱动型方法的好处,以及如何应对一些常见的问题,但不得不承认,有些时候你还是需要有个产品路线图,尤其是有外部团队参与的时候,因为他们需要知道,你大致会在何时推出什么功能。

退一步说,即便是一个只有象征意义的产品路线图,也能在一定程度上消除他人的顾虑和疑惑。但是你需要调整心态,不要再将产品路线图视为一个“义务清单”,实现结果比推出功能更重要。事实上,你要构造产品路线图,必须要有清楚的路线和地点,但无论是从产品设计还是工程学的角度来看,现实中的企业很难做到这点。

产品路线图
产品路线图

生活不像谷歌地图那样路线清晰。

每一次产品开发都像是一次对新大陆的探索,你知道想去哪里——也就是你希望达到的结果——但却没有明确的路线。因此,你只能踏上征程,每走出一步,都准确地定位自己,并不断获得反馈,那么你就能沿着正确的道路,走向你所期望的结果。

其实,直到整个旅程结束,你才能回过头来,画出完整的产品路线图。思路一变天地宽,不妨暂时忘掉功能,关注结果吧。

原作者:Alice Newton Rex
原文链接:escape from the feature roadmap to outcome driven development

继续阅读本文相关话题
创作者推荐
Runwise创研院

前沿创新智库

Jackie Pan

创新咨询专家

Jack Ge

高级创新顾问

Elysha

创新研究者

Mia Wang

新消费研究者

热门圈子
相关文章推荐

One thought on “5个策略规划产品路线,避免被着牵鼻子走

发表回复

关注
1
打开微信"扫一扫" 点击右上角"分享"