去死吧,精益创业

没人带,自学慢,不在BAT怎么学产品?人人都是产品经理联合200+BAT资深产品经理带你学 点此查看详情

1418179516390

最近有创业者问我在中国还能不能搞精益创业。一两句话说不清楚,但非要我给个答案的话就一个字:不。

在中国,精益创业更像是一种世界观而不是一种方法论。所谓世界观,就是当你拿出一个简陋原型的时候对投资人和市场用户的说法,但是如果连你自己都相信这个说法那你就没救了。

具体来说,精益创业在国内有以下四个障碍。

原因 1:比竞争对手更敏捷开发的唯一方法是放弃精益创业

在精益创业中一个重要的方法论是做任何事情都要有认知。从开发的领域来说,就是你添加一个按钮并不是工程师或产品经理说了算的,而是要做出两个版本一个版本有安妮和一个版本没按钮让两个版本都接触到用户。根据用户行为数据的变化,最终决定采用某一个版本作为正式版本。这听起来是一个十分美妙的事情,工程师再也不是想当然的开发出用户根本不需要的蹩脚的产品,产品终于脚踏实地的每一步都踩在用户的痛点上。

但是,现实是什么样的呢?

现实是,在中国,几乎每一个产品类目下都会有至少两个竞品(如果没有,你要考虑是不是你们的产品形态根本是作死)。而每个竞品的工程师都是在全速开发的,根本没有时间在同一个功能上并行开发出两个版本来进行这样的测试。

因此,在中国的创业环境下,产品经理或者说创业团队的顶头上司的判断其实往往决定着一个公司的生死。从全局来看,基于用户需求反馈的开发循环和 ABTest 也在进行,只不过是在不同的创业团队之间进行。在做同一个产品形态的时候,A 团队选择了 A 增长引擎,B 团队选择了 B 增长引擎。等到的 B 团队发现 A 增长引擎是正确的时候几乎是无法追上 A 团队的。而 C 团队如果选择在自己的产品线上验证 AB 两种增长引擎是否能够成功,那么几乎可以肯定的是他必将败给 A 和 B 团队中的某一个。

原因 2:开会并不比开发更重要

精益创业可以说是一本产品经理的红宝书,它的发源地是工程师资源过剩、全栈工程师遍地跑的硅谷。

在精益创业中曾经很明确的描述过这一点:媒体总是将那些大公司的创始人描述成一个天才,他们总是一拍脑子想出一个点子然后在经历一段蒙太奇的开发镜头之后就迈向了人生的成功。硅谷的许多创业者因为自身是工程师,他们认为那段被蒙太奇的内容自己一个人就能干的过来。而确实,全栈工程师也有着这样的优势,他们能够凭借自己的力量将想法变为现实。

精益创业就是这样一本告诉工程师们:好了,我知道你们开发能力很强,但是你们开发出来的东西都是屎,在没有数据驱动,用户需求拉动的情况下,无论走多远你们都只是在错误的路线上挣扎。

因此,在精益创业的方法论中,会议和沟通成为了一项比开发更为重要的事情。

理由很简单:找到方向比迈腿更重要。

所有的创业者和投资人不用我列举数字你也会对国内的技术人员公司占比有一个直观的印象——我见到的大多数创业团队中三个创始人里有一个技术创始人就不错了。有的创业者甚至从一开始就没打算找技术创始人,而是雇佣了一名员工来解决所有的开发问题。

国内创业项目中,负责迈腿的人本来比例就要低上不少。那些非研发岗的联合创始人他们在跑展、站台、融资之外的基础性工作就应当是掌握公司的方向。

在这种情况下,如果仍然要求迈腿的人每天拿出大量的时间来开会讨论该往哪边迈腿,这个企业基本也就不用迈腿了。

原因 3:并不是创业团队中的所有人都需要知道什么是精益创业

作为一个工程师、程序猿或者随便你怎么叫的研发岗位人员,不论他在大公司还是在创业公司,无论是在五道口还是在硅谷。他们都讨厌一件事:编程的时候被打断。

研发人员的普遍认识是:打断我们编码(拉我们去开会讨论需求)是大幅度降低效率的一件事。

而精益创业方法论从硅谷的实际情况告诉硅谷的工程师:不,你们离开了有数据驱动的专业产品经理,效率再高开发的还是一坨屎。你们停下 Coding 的手开始开会的话,可以挽救这个致命的现象。

然而这显然并不符合中国的实际情况,中国的实际情况是即使产品经理、你的部门上司、你团队的正牌创始人找你去开会,他们也不会给你的研发带来任何帮助。你们会在吵架中度过一个下午,他会没有任何数据支撑的告诉你「这是用户需求」,你会异常抵触的告诉他「这技术上实现不了」。最后浪费了一下午的时间,由于你的创始人根本不懂技术,最后你还是按照原先的计划开发但是你的进度晚了一整天,并且你的创始人已经开始准备在下一轮融资中把你的股权稀释了。

在一个优秀的创业团队中,创始人(如果不是技术创始人)和开发岗位之间应该是彼此相信并了解对方的水平的。优秀的创始人(在中国的产品经理人创业和媒体人创业的氛围下,我们假定他不是一个开发)应该阅读精益创业并深知自己要做的不是拍脑袋而是去做需求调研和数据反馈,并在了解创业团队(自身)所使用的核心技术和信任研发岗(不论他是你的联合创始人还是员工)的基础上提出「技术上可行的需求方案」,成为市场与研发之间的缓冲。

如果能够达到这种平衡,创业公司就完全不需要将技术研发岗卷入到精益创业无比复杂不断打断程序猿入定 Coding 模式的会议流程中来。

精益创业对中国创业者的启发应该是告诫那些在创业团队中拿着大头充当产品经理的创世人们:多了解技术,少拍脑瓜,给你的联合创始人提需求之前问问自己想没想好怎么验证假设,如何进行创新测量。而不是把这些事情统统丢给你那个身兼研发、测试、产品经理的技术创始人,然后当他的开发循环刚跑起来就踢开他的办公室神采奕奕的喊一声:「嘿!我又想到了个新点子。」

原因 4:在超过 50 人的创业团队精益创业?疯了么?

精益创业的一个原则是充分的沟通,在创业公司中每一个人都可以贡献自己的知识与力量。这是一句非常漂亮的话,而作者则用「创业企业家」这一虚职企图告诉大家在一家不论多大的企业里精益创业的理论体系都是适用的。但是实际情况是,在大公司中必须实现信息的隔离才能保证组织正常的运转,否则的话设想一下如果公司的每一个动作,公司中每一个人的想法都要让公司里所有的人知道的话,那么这个公司要么有 100 间会议室,要么每个人每天都能收到 100 封以上的邮件。

忙于处理沟通,就会挤掉所有的工作时间。

搞出精益创业的硅谷在传统组织构架和精益创业之间妥协出了一种叫合弄制的东西,但是其实合弄制并不是什么新鲜玩意儿,在经典公司管理里这叫项目组制。

合弄制创造性的认为,在新组成的小项目组里重新选择领导构成一个完整的团体会让事情变得好起来,但最终的结果是事与愿违——「合弄制仍然在非常大的程度体现的是传统的上下级制度,而且出现了一个非常奇怪而有趣现象:一个人可以成为另一个人的上级,同时也是这个人的下级」。

我并不认为如此复杂的关系网络在中国国情下会形成良好的办公室政治环境。

 

作者:@评论尸          来源:创之网