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