编者注：本文来自被誉为当代创新大师的Steve Blank的博客。 中文版由天地会珠海分舵编译。
全文从当今非常多人对精益创业的误解作为一个切入点，深入的分析了为什么人们这么easy就对精益创业产生误读。然后提出了自己独到的解决方式…
迷失精益创业
业界的所谓砖家们对精益创业所提倡的”Build(打造) - Measure(衡量) - Learn(学习)”模式的诟病和抱怨已经不是一天两天的事情了。但每次当我听到他们说这无知的话的时候我依旧会感到无比的惊讶:
“这模式无非就是将一个半成品高速的投入市场进行试水而已。“
何以至此呢？非常不幸，之所以让人困惑的原因恰恰正是由于精益创业中的这个“打造-衡量-学习”模型图而引起的，由于咋一看这模型图的顺序。这全然是一个本末倒置的东西嘛。这就好比你作为射击教练去教学生射击的时候却喊着口号：“射击 - 准备 - 瞄准“ 一样。
时至今日，精益创业已经大行其道非常长一段时间了，我们也已经摸索出当中怎样才干真正的去“精益”的进行创业的秘诀。所以。为了以正视听，我觉得如今是时候对这个“打造-衡量-学习”模型进行对应的更新了。
那么我们以下就看看应该怎样进行更新吧，请看官们耐心往下看。
“打造-衡量-学习”，这听上去事实上是一件异常简单的事情。无非就是先打造出一个产品，然后把它丢到市场上面去，然后去收集并衡量客户的反映以及反馈，然后从中进行学习，最后依据学习的结果进一步打造出更好的产品。这是一个不断循环的过程，过程中你须要依据上一轮学习的结果去决定在本轮中。你是须要在已有产品的基础上进行进一步的迭代呢，还是须要挖掘出一个新的方向，然后重整旗鼓换条道路前进。又或者是须要全盘推翻从头再来。终于能跳出这个循环的出口仅仅有一个。就是当你能打造出客户真正喜欢的产品的时候。
闭门造车的困局 - 瀑布模型
尽管这听上去非常easy。但相对于贯穿整个20世纪所使用的瀑布式开发来说，“打造-衡量-学习”模型能够算得上是一项彻底的变革了。那时候，企业家们是在差点儿没有获得不论什么用户反馈的情况下。运用一系列的产品研发流程来进行产品打造的。
这些公司创始人会在假设自己已经非常清楚客户碰到的问题或者客户的需求的前提下。開始进行需求文档(ERD)的编写，进行产品的设计，进行硬件/软件的实现/构建，然后对硬件/软件进行測试以验证其和需求文档的描写叙述是吻合的，最后就会以首批出货(FCS)的形式向潜在客户揭开产品的神奇面纱 。
瀑布模型所做的事情事实上就是去将需求文档进行编码实现。尽管产品的Alpha版本号和Beta版本号终于还是会邀请客户一起进行測试和验收。可是，这时客户介入的目的事实上已经不是为了对你的产品的功能或者易用性提供反馈，而仅仅是去看下你的产品是否全然依照需求文档去进行实现，是否存在缺陷而已了。
在这样的情况下。仅仅有在产品真正的卖给客户之后。我们的初创公司才干获得客户来的有实际意义的反馈。
而事实往往更悲催的是，在你的产品经历了几个月甚至几年的闭门造车的开发过程之后，你终于却发现客户根本就不会付钱买你的产品，由于他们可能压根就不须要你的产品所提供的大部分功能！
瀑布开发模式下，一个产品往往须要经历三个版本号才干真正走向正轨满足客户的需求。第一个版本号毫无疑问是个闭门造车的产物了，根本没实用户反馈可言，所以就更谈不上满足客户需求了。而第二个版本号的开发往往又是在第一个版本号还没有全然获得用户大量反馈之前，就已经密锣紧鼓的開始的了。所以，我们往往仅仅能在第三个版本号中才干真正基于用户的反馈进行产品的打造(当中微软的Windows 3.0 这个产品的开发过程就是一个非常典型的样例)。
到了2000年初，敏捷开发逐渐成为软件开发的最佳实践方式。这样的方法通过引入迭代和邀请用户參与的方式来对陈旧的瀑布开发模式进行大幅的改进。这事实上已经是一个非常大的进步，但问题是它没有一个行之有效的框架来指导我们怎样在市场上验证那些商品化方面的猜想。所以在这样的情况下在你的产品开发过程中盲目的运用敏捷开发的话，就算你将一个客户所要求的全部功能都实现了，你的产品也难免会碰上滑铁卢而终于铩羽而归。
这时，精益创业所提倡的“打造-衡量-学习”这个框架模型就应运而生了！
一波未平一波又起
“打造-衡量-学习”关于这个“打造-衡量-学习”的循环。首先我们必须明确这个循环的目的并非要去让我们打造出一件终于的产品或者产品原型。而是为了让我们在不停的迭代和增量开发的project中最大化我们对要打造的产品的学习。（这里的学习包含产品功能，客户需求，产品定价以及销售渠道等等…）而“打造”指的当然就是就是去打造出一个MVP(最小可行化产品)了。这里并非说你仅仅去实现你的产品的一小部分功能就叫做MVP了，明确这一点是非常重要的。事实上。MVP指的应该是一个能够让你高速给客户演示并高速获得用户的反馈以进行学习的那么一个最简单可行的东东。
在创业早期，MVP能够仅仅是几张PPT幻灯片，也能够是一幅线框图，更能够是一个模型。甚至能够仅仅是一些採样数据而已。在你每次进行一个MVP的打造之前，你都须要先去定义好在该MVP中你所须要測试/衡量的到底是什么东西，然后你才干有针对性的对你的产品、市场和客户等进行学习和认知。随着这方面知识的积累，你的MVP慢慢自然而然的就会往用户真正须要的产品这个目标靠拢。
但此时可别得意忘形了。在往下的迭代周期中，你的目标依旧是为了继续最大化你的学习，而不是去给你的终于产品打造个产品原型或者Beta版本号。相对瀑布模型来说，“打造-衡量-学习”模型令创业变得更为简单，灵活并且有效率。
精益创业中经常使用上图对“打造－衡量－学习”这个模型对其进行阐述。可是把“打造”这个词放在整个流程的首位往往会让人困惑。
如前文所述。这让人咋一看是有种本末倒置的感觉。因此，为了帮助我们能更好的了解精益创业的这个模型，我们还须要增加另外三个元素。所以终于更细化的一个版本号就出来了：“创意－打造－编码－衡量－数据－学习”。
“打造－衡量－学习”的这个细化版能够让我们对easy让人困惑的”打造“这个词的本意有更好的认知。让人们清楚的知道”打造”的目的是要去測试验证你对产品的”创意“。而非”无的放矢“的盲目地去进行产品开发。
而当中的“编码（Code）”非常好理解。指的就是怎样的对产品进行编码实现，当然，假设不是软件行业的话，你也能够简单的将其替换成“硬件开发”或“人造基因研发”。
而“数据（Data）”意思是当我们的MVP公布给用户使用后，我们将会获得用户的反馈，然后我们会对获取回来的反馈进行衡量。如找出哪些是有效的或者无效的、实用或者没用的数据，以便我们在下一步能够更深入的对这些数据进行学习。而这些学习回来的新认知又将会反过来影响我们下一轮循环迭代的”创意“。
所以在此我们能够非常清楚的认识到，“打造－衡量－学习”的目标并不仅仅是为了打造MVP而打造MVP，而更应该是有针对性的去为了验证你的创意而进行MVP的打造。
一旦你认识到这一点，那么你就会清楚“打造－衡量－学习”这个模型的并非如上文中砖家们所质疑的”这模式无非就是将一个半成品高速的投入市场进行试水而已。“，相反，该模型的关注点应该是在怎样測试验证你的产品的”创意“。
那么这是否就足够了呢？答案是否定的，我们事实上能够做的更好！
精益创业的改进该从猜想開始
“打造－衡量－学习”这个模型事实上还是缺了那么点东西。它忘了一个新产品产生之前事实上都不是由创意(不管是初创企业的创意还是一个成熟企业开发新产品的创意)開始的。而是从一些还不明朗的对产品的一些猜想(事实上就是”推測“更冠冕堂皇的说法而已)開始的。
创意和猜想是两个截然不同的东西，这一点非常的重要。对于大部份创新者来说，创意就是对产品的洞悉。一旦有了创意，就须要立马制定具体计划来将之付诸实现以产生成果的。相对来说，”猜想“指的是。我们如今已经有一个依据经验而来的猜想，但还须要一些实验/试验以及对应的数据来证明其到底是可行还是不可行的。
这些猜想覆盖面非常之广。我们的目的就是要验证这些猜想以确定我们的产品应该怎样进行打造。从找出谁是目标客户。到怎样确立产品的价值主张，到怎样给产品定价。到怎样找到并打通销售渠道，再到怎样创建需求(获取用户，激活用户，黏住用户。等等等等…)。这些都须要进行验证才干确定的。
事实上。假设你真要进行精益创业的话。承认自己的创意事实上仅仅是一系列未经证实的猜想是一个非常重要的開始。
之所以说它重要。是由于你所打造的东西应该是为去验证你的猜想而服务的。
你要知道。为了验证谁是真正潜在的客户所打造的MVP和为了验证产品定价所打造的MVP的要求是不一样的，而用于測试新功能所须要打造的MVP又是另外一回事。另外。这些猜想（及MVP）会随着你不停的学习积累而不停的产生变化。
综上所述。我们去打造我们的MVP的时候所运用的精益创业的框架更应该是”猜想 - 实验设计 - 验证 - 洞悉”。而非原来的“打造 - 衡量 - 学习”。
怎样构建猜想
假设运用“猜想 - 实验设计 - 验证 - 洞悉”这个新的框架，那么问题将会变成：有哪些猜想我们是应该去验证的？关于这个问题， Alexander Osterwalde在它的商业模式画布中早就将商业上须要验证的九个模块压缩成一张可视化的图来让你一目了然了。请看下图(假设看不清楚的话能够直接点击这里进行查看)：
价值主张：公司通过其产品和服务所能向消费者提供怎么样的价值？
客户细分：比如是普通用户还是付费用户。是家庭主妇还是年轻人？
销售渠道：怎样找到目标客户。并向其提供你的产品的价值主张？
客户关系：怎样创造很多其它的需求？
收益流：怎样通过价值主张而获得收入来源？
活动: 怎样运行必须的活动来实现你的商业模式？
资源: 怎样获得活动所须要的资源？
第三方合作伙伴: 怎样获得别人的支持以令你的活动能够推进？
成本结构: 怎样确立你的商业模式下所产生的成本结构？
通过以上几点，对初创企业的又一次定义就浮出水面了：初创企业指的就是一个对可复用和可扩展的商业模式进行探索的暂时性组织。
怎样验证猜想
当建立好满足以上商业模式画布的猜想之后。我们又将须要怎样对这些猜想进验证呢？假设你是一个科学家，那么答案非常easy，去做实验就完了。事实上这对作为企业家的我们相同适用。事实上美国国家科学基金会(NSF)对Steve Blank(作者本人)的课程”精益产品打造(Lean LaunchPad)”的描写叙述，就是将这样的验证的方式归类成一个科学方法来看待的。
书籍《初创企业家手冊》所描写叙述的”客户关系拓展流程“就是一个将你的猜想交到客户手上进行验证的简单且行之有效的方法。里面章节所提及的”客户挖掘“的方法就是用来捕获创始人的愿景，并把它们一项项的细化成商业模式的猜想。同一时候它还给出了一系列的验证方法来指导我们该怎样验证我们的客户对这些猜想的反馈，并将它们付之实现。验证猜想的实验能够是一系列你想要问用户的问题，但通常情况下，提供一个帮助用户更好的理解你是怎样解决他们的痛点的一个MVP将会是一个更好的选择。
所以这就是为什么说我们打造MVP的目标并非为了去打造一个产品原型。而是为了最大化进行对产品相关猜想的学习。
最后，获取数据也不是设计这些实验和打造MVP的终于目标。不论什么人都能够获得数据，想要数据的话，把潜在用户聚集起来开个座谈会做个问卷调查之类的就好了。但这并非我们终于想要的，我们如是做的终于目标事实上是为了更深入的洞悉我们的产品的方方面面。
走出闭门造车的困局，重点就是要去让客户了解产品的愿景并有效的对之进行验证。那么怎样才干真正的洞悉产品呢？当然。你能够从慢慢分析用户反馈入手。但也有可能你根本不须要分析不论什么的数据。由于你可能非常快就意识到你正在打造的产品事实上是一个破坏性创新，这时候该产品的市场还没有真正形成(编者注：我就没有听过当年乔布斯开发iphone的时候有跟用户一起迭代过多少个版本号)，这个时候你就须要将你的实验和MVP从验证特定功能这个目标，转变到打造未来这个方向上来了。
小结
“打造－衡量－学习”模型是对瀑布模型的一个伟大改进，它提供了一套框架来让我们真正的让用户參与到我们的敏捷开发流程上面来。
然而，假设在第一步就把注意力集中在”打造”和”创意”上面的话，你就会丢失掉精益创业所带给我们的洞悉力 - 你应该从对产品的猜想開始。然后对这些猜想进行验证。然后在此过程中找寻出一个属于你的可反复且可扩展的商业模式。
”猜想 - 实验设计 - 验证 - 洞悉“的更好的阐述了精益创业的流程:
利用商业模式画布来框定你的猜想，利用上面提到的”客户挖掘”的方式走出闭门造车的困局以验证你的假想。最后利用敏捷开发project思想来增量迭代的打造你的产品。
—
提醒:很多其它文章请关注公众号:techgogogo或官网www.techgogogo.com。当然。也非常欢迎您直接微信(zhubaitian1)勾搭。
本作品採用[创作共用署名3.0中国大陆版许可证], 欢迎转载，转发时切勿删除联系信息。