>科技>>正文

最科学的产品开发模式是怎样的?WorldRemit产品经理告诉你!

原标题:最科学的产品开发模式是怎样的?WorldRemit产品经理告诉你!

产品路线图并不是纯粹的“功能清单”,你应该放弃对功能的过分关注,而是关心我们最终想要的效果是什么,需要解决的具体问题又是什么;这样才能摆脱功能型路线图的束缚,转向更为科学的产品开发模式。

在职业生涯中,我设计过很多产品路线图。

其中,光是在 WorldRemit 工作的头 3 年里,我就为公司做了 10 种以上不同类型的产品路线图。

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

众多产品路线图中的一个

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

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

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

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

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

类似的,如果你加入了一家创业公司,公司的创始人一般会决定产品要怎么做,只要你给他一个空白清单,立马就会给你填满。

这时,你作为一个产品经理,几乎没有自主权,充其量是个指令接受者,你所需要做的就是想法设法,尽量以最好的效果呈现老板们想要的功能。

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

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

如果你是按功能导向型的路线图来做的,那这种事情是很可能发生的,也许是因为你被迫开发的功能没有实现预期的效果,但你还是得原原本本地做出来。

那么问题来了,你应该如何摆脱功能型路线图的束缚,转向更为科学的产品开发模式呢?

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

从现在开始,你应该放弃对功能的过分关注,而是关心我们最终想要的效果是什么,需要解决的具体问题又是什么。

试着问问自己,如果我们的产品开发成功了,会给世界带来什么样的改变?我们的用户会有什么样的体验?他们能通过我们的产品做些什么?

在一个特定的时间段内,每个团队都应该围绕这个共同的、明确的目标或者说结果而奋斗,而不是被功能路线图牵着鼻子走。

任何好的目标,都应该是能够测度、衡量的,同样,你设定的结果也必须是能够加以验证的,最直观的反馈就是,你的产品能得到用户和业界的认可吗?

如果你实现的结果是:“用户能看到更多广告”,这对用户来说就毫无价值,也更不可能因为这个结果而取得业务上的成功。

一个好的结果应当是像这样的:“用户注册时间缩短一半”。

这样一来,产品经理不再是管理层的传令官,产品怎么做、开发什么功能、达到什么效果,变成了整个团队的问题。

这种方式最大的优点就在于:团队内部有了更大的自主性,每个成员都能够发挥自己的专业特长和创造性。同时,只要我们观察到,用户能够在原来一半的时间内完成注册,那么我们的目标就达到了,也不必再管哪项功能有没有实现。

对希望实现的结果有了更清晰的认识之后,你会发现自己的思路更加开阔,解决问题的可能性也远比之前多。

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

许多高管提议,要想办法给电梯提速,或者在大楼里再开凿一个电梯井,增加运量。不过,他们最终另辟蹊径,采用了一个完全不同的方法,同样成功解决了问题。

他们在电梯入口处安装了很多落地镜,大家早上来上班的时候,注意力都集中在镜子中的自己,不知不觉就忘了等电梯的辛苦。

在这个案例中,高管们真正需要解决的问题其实并不是电梯不够,而是员工因为等电梯而产生的烦躁情绪。

可以看到:他们选了一个比加装电梯划算很多的方案,最后也取得了非常不错的效果。

三、删除冗余,少即是多

这个新的设计思路还会带来另一个好处,那就是避免开发团队向产品中加入过多的功能,尤其是那些用户根本不需要的功能。

结果驱动型的方法,能够引导团队将精力集中在改良现有功能上,最大限度激发这些功能的效果,而不是光想着增加新的功能。

这种思维方式极大地提高了团队的创造性,甚至能让你关注到平时都没有留意的方面。

我曾经和一个朋友探讨过这方面的问题,他所在的电子商务行业最关注的一个指标就是转化率,他们每年年底都会进行一次年终统计,有充分结果表明:对提升转化率贡献最大的部分,并不是增添的新功能,而是他们对现有功能做出的技术改良,例如优化图片处理技术之后,他们的网页加载速度大幅提升。

这种方法还能让团队不断优化产品,去掉影响用户体验的功能。

不过,就像其他方法一样,合不合适还得试过再说。在这篇文章剩下的篇幅里,我想要重点谈谈,结果驱动型的方法可能会出现什么问题,以及如何避免。

四、可能产生的问题 1. 公司没有一个明确的企业策略

首先,最重要的一点,如果你的公司没有一个明确的企业策略,那么结果驱动型的产品路线图也必然会失败。

在WorldRemit,我们首先从确定公司本年度目标起步,用这个目标来明确各团队的任务,接着又从任务入手,细分出我们的季度目标和要取得的关键成果。

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

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

第二个导致结果驱动型方法失效的原因是,你的团队不知道如何验证思路是可行的。

这个问题产生的原因,很可能是你的公司正在经历转型,从原来传统的由上而下的公司文化,转变为结果驱动型的产品开发框架,不再聚焦对特定功能的开发。

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

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

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

大多数人会有这样的想法:如果说一家比我们还好的公司,他们都还在循规蹈矩,为什么我们就要调整呢?不过,只要你能解释到位,科学的方法仍然是容易被别人接受的。建议你用一些比喻,让自己的表述更加生动。

比如你可以这样讲:如果我是一支探险队的领队,我下达命令说要建一座桥,那队员们很可能花大量的时间去找造桥的材料,最后造出来的桥也许还不够结实,不能满足全队安全渡河的要求。

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

向领导询问导致问题的原因,而非解决方案。

如果你这样问领导:“我们在做明年的产品路线图,您认为有什么功能需要加进来吗?”你不可避免地会得到这样的答复:“我们要在登陆页面加一个蓝色的窗口小部件,放一个视频告诉用户,我们能提供什么样的服务。”

实际上,我们更推荐你围绕现有的问题提问,比如:“我们明年的目标是提升登陆页面的转化率,您觉得有什么原因在导致用户数量下降呢?”

那么,你很可能得到更具建设性的答复,像是:“我们觉得用户转化率低,很可能是因为他们不太清楚我们能提供什么服务。”

向大家证明,少即是多。

有时候你会发现,不断地添加新功能,可能只是你的一厢情愿,说不定功能越少反倒越好。微软曾经通过一次试验,发现有将近 1/3 的功能给产品带来的是负面影响,还有 1/3 压根没有产生影响。

当他们不同意你的解决方案时,试着提议先做一个测试。

如果领导不同意你的方案,可以试图找到一个成本较低的测试方法,并在合适的机会下向他们提议,说不妨先测试一下看看效果。

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

如果你像以前一样,按照不同的功能为团队分工,的确很容易确保大家各司其职,但改为结果驱动型的方法时,你就很可能会遇到这个问题。

比方说,在共同目标的引导下,不同的小组有不同的开发任务,那么当这些小组任务之间产生矛盾时,应该如何确定它们的优先级呢?

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

五、回到产品路线图来

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

退一步说,即便是一个只有象征意义的产品路线图,也能在一定程度上消除他人的顾虑和疑惑。但是你需要调整心态,不要再将产品路线图视为一个“义务清单”,实现结果比推出功能更重要。

事实上,你要构造产品路线图,必须要有清楚的路线和地点,但无论是从产品设计还是工程学的角度来看,现实中的企业很难做到这点。

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

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

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

原作者:Alice Newton Rex

原文链接:https://www.mindtheproduct.com/2018/10/escape-from-the-feature-roadmap-to-outcome-driven-development/

翻译:即能,公众号:「即能学习」

本文由 @ 即能 翻译发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
阅读 ()
投诉
免费获取
今日推荐