去死吧,精益创业.pdf

去死吧，精益创业 最近有创业者问我在中国还能不能搞精益创业。一两句话说不清楚，但非要我给个答案的话就一 个字：不。 在中国，精益创业更像是一种世界观而不是一种方法论。所谓世界观，就是当你拿出一个简陋原型 的时候对投资人和市场用户的说法，但是如果连你自己都相信这个说法那你就没救了。 具体来说，精益创业在国内有以下四个障碍。 在精益创业中一个重要的方法论是做任何事情都要有认知。从开发的领域来说，就是你添加一个按 钮并不是工程师或产品经理说了算的，而是要做出两个版本一个版本有安妮和一个版本没按钮让两 个版本都接触到用户。根据用户行为数据的变化，最终决定采用某一个版本作为正式版本。这听起 来是一个十分美妙的事情，工程师再也不是想当然的开发出用户根本不需要的蹩脚的产品，产品终 于脚踏实地的每一步都踩在用户的痛点上。 但是，现实是什么样的呢？ 现实是，在中国，几乎每一个产品类目下都会有至少两个竞品（如果没有，你要考虑是不是你们的 产品形态根本是作死）。而每个竞品的工程师都是在全速开发的，根本没有时间在同一个功能上并 行开发出两个版本来进行这样的测试。 因此，在中国的创业环境下，产品经理或者说创业团队的顶头上司的判断其实往往决定着一个公司 的生死。从全局来看，基于用户需求反馈的开发循环和 ABTest 也在进行，只不过是在不同的创业 团队之间进行。在做同一个产品形态的时候， A 团队选择了 A 增长引擎， B 团队选择了 B 增长引擎 。等到的 B 团队发现 A 增长引擎是正确的时候几乎是无法追上 A 团队的。而 C 团队如果选择在自 己的产品线上验证 AB 两种增长引擎是否能够成功，那么几乎可以肯定的是他必将败给 A 和 B 团队 中的某一个。 精益创业可以说是一本产品经理的红宝书，它的发源地是工程师资源过剩、全栈工程师遍地跑的 硅谷。 在精益创业中曾经很明确的描述过这一点：媒体总是将那些大公司的创始人描述成一个天才，他们 总是一拍脑子想出一个点子然后在经历一段蒙太奇的开发镜头之后就迈向了人生的成功。硅谷的许 多创业者因为自身是工程师，他们认为那段被蒙太奇的内容自己一个人就能干的过来。而确实，全 栈工程师也有着这样的优势，他们能够凭借自己的力量将想法变为现实。 精益创业就是这样一本告诉工程师们：好了，我知道你们开发能力很强，但是你们开发出来的东西 都是屎，在没有数据驱动，用户需求拉动的情况下，无论走多远你们都只是在错误的路线上挣扎。 因此，在精益创业的方法论中，会议和沟通成为了一项比开发更为重要的事情。 理由很简单：找到方向比迈腿更重要。 所有的创业者和投资人不用我列举数字你也会对国内的技术人员公司占比有一个直观的印象 —— 我 见到的大多数创业团队中三个创始人里有一个技术创始人就不错了。有的创业者甚至从一开始就没 打算找技术创始人，而是雇佣了一名员工来解决所有的开发问题。 国内创业项目中，负责迈腿的人本来比例就要低上不少。那些非研发岗的联合创始人他们在跑展、 站台、融资之外的基础性工作就应当是掌握公司的方向。 在这种情况下，如果仍然要求迈腿的人每天拿出大量的时间来开会讨论该往哪边迈腿，这个企业基 本也就不用迈腿了。 作为一个工程师、程序猿或者随便你怎么叫的研发岗位人员，不论他在大公司还是在创业公司，无 论是在五道口还是在硅谷。他们都讨厌一件事：编程的时候被打断。 研发人员的普遍认识是：打断我们编码（拉我们去开会讨论需求）是大幅度降低效率的一件事。 而精益创业方法论从硅谷的实际情况告诉硅谷的工程师：不，你们离开了有数据驱动的专业产品 经理，效率再高开发的还是一坨屎。你们停下 Coding 的手开始开会的话，可以挽救这个致命的 现象。 然而这显然并不符合中国的实际情况，中国的实际情况是即使产品经理、你的部门上司、你团队的 正牌创始人找你去开会，他们也不会给你的研发带来任何帮助。你们会在吵架中度过一个下午，他 会没有任何数据支撑的告诉你「这是用户需求」，你会异常抵触的告诉他「这技术上实现不了」。 最后浪费了一下午的时间，由于你的创始人根本不懂技术，最后你还是按照原先的计划开发但是你 的进度晚了一整天，并且你的创始人已经开始准备在下一轮融资中把你的股权稀释了。 在一个优秀的创业团队中，创始人（如果不是技术创始人）和开发岗位之间应该是彼此相信并了解 对方的水平的。优秀的创始人（在