观察 | 产品迭代需要多久?谷歌说,5天

很多互联网公司中经常看到这样一种景象:产品经理、技术、运营、设计围在一张桌子前,闹哄哄地进行关于产品迭代的头脑风暴讨论会。一脑暴就是一整天,重点偶尔跑偏,沟通不时急赤白脸,最终决策者拍板决定一个方案,大家分头去执行,over。

 

这样的方法效率高吗?是我们能达到的最优结果吗?在这个决策的制定过程中,每一个人都尽了全力吗?

 


脑暴暴不好的下场

读过《乌合之众》的人知道,人一进入群体中,会表现得无异议、情绪化和低智商,可是做出一个决策往往需要不同领域的人共同探讨。如果有一种流程,既能保留个人的聪明才智,又能发动群体的力量;既能缩短会议的时间,又能做出正确的决策,那就了不起了。

 

谷歌作为一个了不起的公司,创造出了这个了不起的流程,它几乎被用于谷歌的任何项目,从搜索引擎、电子邮箱,再到无人驾驶汽车。传入谷歌风投之后,又帮助了100余家初创公司成功起步,它们中的许多如今已是人尽皆知的业界标杆。
用这个流程做产品迭代只需要5天,它的名字就叫做《设计冲刺》

书名:设计冲刺

作者: [美] 杰克·纳普 / [美] 约翰·泽拉茨基 / [美] 布拉登·科维茨

译者: 魏瑞莉 / 涂岩珺

出版社: 浙江大学出版社

出版年: 2016-8

 

其实五天完成产品迭代介绍起来十分简单:

周一 拆包,把一切已知摆上桌面

周二 写写画画,每个人都贡献点子

周三 决策日

周四 完成原型产品

周五 交卷,检测

 

当然,这本书不会像“要把大象装冰箱,拢共分几步”这样草草带过,而是每一步都详尽地介绍了具体操作过程,以及容易被忽略的细节,还有许多颠覆我们惯常操作流程的地方,比如:

 

 为什么需要五天

更短的时间将使得团队成员筋疲力竭,没有时间制作原型、进行测试。更长的时间会出现干扰和拖延,并让团队成员更坚持自己的意见。五天时间带来的紧迫感让人更容易集中注意力、打断不必要的争论,同时又有时间制作原型、进行测试。

 

 为什么不进行脑暴

接下来我审查了我组织过的每一场头脑风暴的成果,然后我注意到了一个问题。真正付诸实践并且获得成功的想法并不是来自大喊大叫的头脑风暴,那些更棒的点子来自于个体依然用过去习惯的方式思考创意时——坐在办公桌前时,在咖啡店等咖啡时,洗澡时。这些有嗯们独自想出的点子更胜一筹。当讨论会的狂热劲头散去,头脑风暴产生的点子其实并没有那么特别。

 

 为什么不解释方案

解释方案有各种弊端。如果一个人为自己的方案提出了强有力的理由,或是他天生就富有个人魅力,他就很容易左右你的评价。

 

提出方案的人很容易为自己平淡无奇的想法找到华丽的说辞,或者是给说不通的方案做牵强附会的解释。但在现实生活中,这些人无法到现场自卖自夸,他们的方案必须要自己站得住脚。如果团队里的专家都不能理解这个方案,那么用户为之困惑的几率就更大。

 

设计冲刺这个流程,算是精益创业在产品验证方法论上的一个可操作的具体形式。读完这本书你会发现,从优化产品到制定营销策略,从为公司命名到评估新商机的可行性,这些棘手难题解决起来,只要5天,这在瞬息万变的互联网界,足够让你占尽先机了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注