非常高兴来到这里。首先感谢大家提前扮演”测试用户”角色。这是我第一次使用这套关于”最小可行性产品“（Minimum Viable Product，简称 MVP）的演示文稿。我一直在寻找一个合适的场合，来对”最小可行性产品”这个概念本身进行一次 MVP 式的测试，今天的非正式沙龙正合适。非常欢迎大家在过程中随时打断我，提问并展开讨论。我希望能听到大家的反馈，了解哪些逻辑清晰、哪些依然晦涩、哪些内容不可或缺。
按照惯例，今晚的演讲只有一条基本规则：请大家拿出手机，在听讲过程中随时发推文（Twitter），并请务必加上 #leanstartup（精益创业）的标签。这对我至关重要，因为这能让我实时捕捉到大家的反馈。即使你只是觉得某个概念有启发并随手分享，也能帮助我评估大家究竟听懂了什么，判断我的表达到底提供了实质价值，还是仅仅沦为一场娱乐表演。
我是埃里克（Eric Ries）。感谢 SlideShare、Rich 以及 KISSmetrics 促成这场活动。曾几何时，我在硅谷四处阐述这些后来演变为”精益创业”的理念时，收获的往往只有疑惑和看怪人一样的眼神。虽然现在偶尔依然如此，但至少今晚这间屋子里坐满了认为这套方法论大有可观的人。相比过去，这确实是一个令人愉悦的变化。
KISSmetrics：一家专注于用户行为分析的数据分析公司
大家应该都了解我的博客《创业汲取教训》（Startup Lessons Learned），我的 Twitter 账号是 @ericries，再次欢迎大家随时分享思考。
我们究竟为什么要做产品
在深入细节前，我想从一个极其基础的问题切入：我们究竟为什么要做产品？
我们大多数人都具备产品开发背景，往往理所当然地将”做产品”视为天经地义的职责。正如史蒂夫·布兰克（Steve Blank）经常强调的那样：”当人们陷入迷茫时，他们往往会掏出名片，然后名片上写着什么职务，他就去干什么。”创业过程充满混乱与迷茫，因而引发了大量”看名片行事”的行为。
过去当我的名片上写着”工程副总裁”或”首席技术官”时，一旦我感到困惑，我就会告诉自己：”今天我最好多写点代码、搞点技术，因为这就是我的本职工作。”
然而，创业公司若想取得成功，核心前提是打造出能让用户产生喜悦的产品，吸引规模化人群，并在此基础上建立起可持续的商业模式。
精益创业（The Lean Startup）的终极目标，是服务于那些具备宏大远景、渴望改变世界的创业者。如果你仅仅想快速开发一款低质廉价的应用并借此套现，这套方法论并不适用。我默认今天在场的所有人，都在追求通过产品带来深远改变。
接下来，我将把 MVP 放置于精益创业的整体框架中，解析它与各个核心概念的关系。
产品的两种构建路径
【产品的两种构建路径】
[路径 A：最大化成功率] [路径 B：早发布，常发布]
· 堆叠所有可能的功能 · 极速上线，持续听取反馈
· 假设：功能越多，受众越广 · 风险：缺乏主线，原地打转
· 风险：批次过大，延迟反馈
\ /
\ /
【MVP 模式：混合创新】
以最低限度的功能组合，
向早期预言家用户验证宏大愿景。
在我的创业生涯中，我一直在两种产品开发策略之间摇摆：
策略一：最大化成功率
第一种策略：最大化成功率（Maximizing Chance of Success）。如果你怀揣宏大愿景，希望打造伟大产品，传统的逻辑推演会告诉你可以通过尽可能堆叠更多功能来提升成功概率。这种理论认为：每新增一个功能，就可能多打动一位原本不打算使用产品的边缘客户。
如果你认为创业机会只有一次，选择把产品”做完全、做正确”再推向市场，看起来是一个极具理性色彩的工程学决定。这种策略的致命缺陷在于，它将工作批次（Batch Size）扩大到了极其庞大的程度，演变成一种非赢即输的零和博弈。更糟的是，它把市场反馈的获取节点推迟到了几乎无法挽回的后期。
策略二：早发布，常发布
第二种策略：早发布，常发布（Release Early, Release Often）。作为对前者的反思，许多开源社区的从业者秉持这一信条。其逻辑在于：既然做全量功能是错误的，那就走另一个极端——以最快速度把产品砸向市场，收集尽可能多的反馈，然后根据用户的要求进行高频迭代。
这种方式容易引发混淆。精益创业倡导宏大愿景，有些人以为我们在主张第一种策略；精益创业又强调持续部署与快速迭代，有些人便以为我们只是在重复”早发布，常发布”。
MVP 既不是单纯的功能堆砌，也不是无方向的快速瞎折腾，而是两者的有机融合。
MVP 的本质是：用满足早期核心用户（Early Evangelists）所需的最低限度功能组合，来验证我们关于未来的长远愿景是否成立。
在”早发布，常发布”的模式下，创业团队极易陷入”原地打转”的困境。当你向三位用户征求意见时，可能会收获五个互相矛盾的反馈。团队在频繁响应这些杂音的过程中，会逐渐丧失方向感。
因此，我们的目标绝非获取”尽可能多”的反馈，而是只获取”足以验证方向正确与否”的关键认知。
MVP的最小化本质
实施 MVP 的难点在于：它所需要的”最小”程度，往往远超创业者的心理底线。
在实践中，创业者极易说服自己”必须先做完这几十个功能，用户才可能理会我们”。以我早年创办 IMVU 的经历为例：当时我们开发了一款可下载的客户端软件，团队耗费了大量精力讨论软件需要包含哪些功能、画质需要多高、系统稳定性要达到什么指标。
然而我们忽略了一个最基础的逻辑前提：在用户体验产品之前，我们必须先说服他们点击”下载”按钮。
当产品终于发布时，真实的状况是——根本没有任何人去点击下载。
这意味着，我们在后面 6 个月中耗费无数心血研发的 3D 虚拟形象渲染系统、物理碰撞引擎与音效，对我们验证”用户是否需要这个产品”没有任何帮助。所有价值巨大的经证实的认知，全部来自于最后那 3% 的工作——也就是那页极其粗糙的下载引导落地页（Landing Page）。那个落地页，才是真正意义上的 MVP。
核心反馈回路：构建-衡量-学习
【精益创业核心反馈回路】
[ 想法 Ideas ]
/ \
/ \
(构建 Build) (学习 Learn)
/ \
v \
[ 代码/产品 ] ------> [ 数据 Data ]
(衡量 Measure)
要在早期成功推行 MVP，必须建立以下基本认知：
-
早期只有”早期预言家”会理会你：在产品极早期，只有史蒂夫·布兰克所定义的”早期预言家（Early Evangelists）”愿意给你的产品投来关注。普通主流量产用户在现阶段对你毫无意义。
-
“最小”代表着与这群早期用户建立互动所需的最低工作量：这群用户本身就具备极强的愿景感知能力，他们甚至能主动帮你补全产品目前的缺陷。产品性能差、有漏洞、功能缺失，他们都能容忍，因为他们自身正遭受着该痛点的剧烈折磨，他们渴望解决方案。
-
不要直接询问用户”想要什么”：绝大多数用户无法准确预判未出现的产品。MVP 的做法是向他们展示一个具体的响应实体（原型、早期版本、落地页、甚至是纸质模型），观察他们面对具体事物时的真实行为与反应。
-
尽早尝试向用户收费：如果能让用户为这个不完善的产品付费，你就能获得关于”该问题是否足够真实”的极高置信度信号。
此外，MVP 必须配合对”迭代”与”转型（Pivot）”的坚定承诺。
我不希望任何人误以为：一旦把 MVP 推向市场并收到负面反馈，就意味着必须立刻放弃愿景。在创业过程中，你可能需要围绕同一个核心愿景，连续进行十几次 MVP 实验，每次仅对愿景中的某一个变量进行调整（即转型）。在数据面前保持理性，在愿景面前保持韧性，这才是创业者的核心素质。
上图展示的是精益创业最为核心的反馈回路：构建 – 衡量 – 学习（Build – Measure – Learn）。
创业团队的终极目标，是最小化穿过这个闭环的总循环时间。我们将想法转化为产品（或代码），通过市场暴露进行衡量并获取数据，最终提炼出认知以指导下一轮想法。MVP 是极少数能同时在这一回路的所有三个阶段发挥作用的战略工具。
如果你当前没有任何产品处于市场中，不妨问自己一个问题：为了完整跑完一次这个反馈闭环，我需要完成的绝对最小值工作是什么？
接下来，我想分享两个真实的切身案例。
案例分享
案例一：IMVU 总统竞选虚拟形象事件（反面教材）
2004 年恰逢美国大选（小布什对阵克里）。当时 IMVU 创立约 6 个月，团队只有 5 个人，资金极其匮乏。
某天早晨，有人提出了一个在我们看来堪称”绝妙”的商业点子：为了让 IMVU 切入主流大众话题，我们可以推出一套布什与克里的虚拟形象（Avatars）。这样用户就能在互联网上与朋友进行一场属于自己的”总统大选辩论”。
这个想法在当时令我们极度兴奋。我们幻想着媒体会争相报道，甚至幻想着用户录下辩论视频发布到网上形成现象级传播。
我们盘算了一下，开发这套竞选人形象以及配套的交互逻辑，大约需要耗费团队 2 周 的全职开发时间。对于一个成立半年的团队而言，我们当时真诚地认为”2周时间”就是一个标准的 MVP。
于是，5 个人停下手头的所有工作，全力以赴封闭开发了 2 周。
产品上线后，我们向既有用户发送了邮件，购买了 Google AdWords 广告进行推广。为了避免价格成为阻碍，我们将该功能定价为非常低廉的 1.99 美元。
最终的市场转化率是：绝对的零（Exactly Zero）。
不是 0.5%，也不是 0.1%，而是彻底的零。没有一个人愿意为这个产品支付哪怕一分钱。因为从本质上看，这是一个完全脱离真实需求的糟糕构想。
随后我们以为是价格问题，决定将其改为免费赠送。然而即便免费，依然没有任何用户愿意使用它。
事后反思：在付出整整两周的团队开发成本之前，我们该如何提前验证这是一个坏主意？
答案非常简单：我们完全可以在产品开工前，先搭建一个简单的宣传落地页，上面放上购买按钮，并投入同样的广告预算吸引流量。我们只需要统计点击”购买”按钮的人数占比即可。
当时我们之所以没有选择这种方式，是因为陷入了所谓的”第二步焦虑”——我们过度担心”如果用户点击了按钮，发现后面没有真实产品，我们该怎么向他们解释？是不是要道歉？还是让他们留邮箱？”
事实证明，这种担心是极其荒谬的。因为在第一步（需求本身）成立之前，根本没有任何用户能走入第二步。
在创业过程中，偶尔做出一款”只有少数人喜欢”的产品并不致命；真正对创业公司构成毁灭性打击的，是那些”根本没有任何人需要”的产品。
案例二：O’Reilly 精益创业研讨会（正面示例）
另一个例子发生在我和 O’Reilly 合作举办精益创业研讨会期间。
当时我在旧金山的 Web 2.0 展会上有一场演讲。在演讲前夕，我告诉自己：作为演讲者，我必须在现场向听众交付或销售一些具体的东西。但我当时没有任何现成产品。
于是我决定在演讲中公开宣布：我将在近期举办一场关于”精益创业”的线下研讨会。
在演讲前 6 个小时，我花了 19.95 美元在 SurveyMonkey 上创建了一份问卷，用于调研大家希望在研讨会上听到什么内容。问卷的最后一页需要配置一个跳转链接，我直接附上了一个 PayPal 的付款链接。
在写下研讨会大纲和定价时，我设定的价格远远高于我预期中任何人愿意支付的金额。
即使我天天向别人宣讲 MVP，当需要在我自己的业务上践行时，我同样感受到了巨大的心理恐惧。作为顾问去指点别人的项目很容易，因为那不是自己的”孩子”；但面对自己的项目时，我也害怕被别人嘲笑：”你凭什么开研讨会？还敢收这么贵的费用？”
但我最终克服了这种恐惧，将这个极简的页面推了出去。
由于 PayPal 当时的系统通知延迟，我一开始只收到了前三笔付款通知，随后便再无音讯。我当时沮丧极了，以为这个实验彻底失败了。直到几天后我登录 PayPal 后台时才震惊地发现：研讨会的全部门票早已售罄。
整个 MVP 的构建过程只消耗了我 2 个小时 的实际工作时间，以及 50 个小时 的自我心理斗争。
在大多数时候，执行一个 MVP 的技术难度，远低于团队内部为了要不要做 MVP 而产生的无休止争论。
组织的双核架构：解决团队与问题团队
【精益创业下的组织双核架构】
+---------------------------------------+
| 创业公司整体 |
+-------------------++------------------+
||
+--------------++--------------+
| |
v v
【解决团队 Solution】 【问题团队 Problem】
· 职责：工程、运营、质量保证 · 职责：验证客户与需求假设
· 目标：证明"当前假设正确" · 核心工具：MVP 实验
· 视角：把既有版本做得更好 · 目标：寻找更有效的替代假设
在精益创业的组织架构中，我建议将团队划分为两个互补的单元：
解决团队（Solution Team）：由工程、运营与 QA 组成。他们的日常职责是确保既有产品假设能够被高效执行，把当前版本的体验不断提升。
问题团队（Problem Team）：他们的日常职责是尝试证明公司当前的商业假设是错误的，并不断探索更高效的新假设。MVP 正是”问题团队”手中最为核心的兵器。
许多创业团队之所以陷入长达数月的盲目迭代，正是因为整个公司只有”解决团队”，所有人都在凭借惯性去堆砌功能，试图用”更多功能”来掩盖”需求未被验证”的底层危机。
常用MVP工具与技术盘点
除了上述案例，以下方法同样是构建 MVP 的有效手段：
-
冒烟测试（Smoke Testing / 间接营销）：为尚未存在的产品提前配置营销推广方案，测试潜在市场反应。
-
每日 5 美元的搜索引擎营销（SEM）：以极低成本每日吸引约 100 名目标受众访问落地页，精准监控转化率变动。
-
A/B 拆分测试（Split Testing）：对不同产品假设进行并行对照实验。
-
纸质原型（Paper Prototypes）：对于设计驱动的项目，直接展示 Photoshop 高保真原型甚至纸质草图，观察用户的真实眼神与情绪波动（判断他们是毫无兴趣，还是急切询问”我什么时候能买到”）。
-
客户探索与验证（Customer Discovery & Validation）：遵循史蒂夫·布兰克《四步创业法》的前两个阶段。
-
主动剥离功能（Feature Removal）：初代 iPhone 在发布时甚至没有”复制/粘贴”功能。尽管该功能看似不可或缺，但剥离它并不影响初代 iPhone 获得巨大成功，反而大幅缩短了上市时间。
阻碍团队执行MVP的三大心理恐惧
构建 MVP 在技术层面通常极其简单，真正阻止我们践行它的，是人类大脑中普遍存在的心理防御机制：
text
【阻碍 MVP 的三大恐惧】
1. 害怕假阴性 (False Negative) ---> 害怕听到真实负面反馈，宁愿选择"无反馈"
2. 远见者情结 (Visionary Complex)---> 认为用户不懂需求，拒绝接受行为测试
3. 忙于构建而无暇学习 (Too Busy) ---> 将 MVP 视为额外负担，忽视最大的浪费
害怕假阴性（Fear of the False Negative）：人类在潜意识里其实并不渴望反馈，我们只渴望赞美。只要不主动收集反馈，我们就能继续沉浸在”大家都觉得我的产品很棒”的幻觉中。然而，当你把一个不完善的 MVP 推向市场并收到谩骂时，绝不要灰心。
在 MVP 的测试中，最糟糕的结果不是被用户谩骂，而是被市场彻底无视（如同 IMVU 的竞选形象事件）。当用户愿意花时间痛骂你的产品粗糙时，恰恰说明你触碰到了他们极其关切的真实痛点。
远见者情结（The Visionary Complex）：许多创始人常说：”用户根本不知道自己想要什么，所以问他们毫无意义。”这种说法的误区在于：MVP 的目的从来不是向用户询问”你想要什么”（那是传统焦点小组的低效做法），而是给用户呈现一个具体的响应实体，测试他们真实的交互与支付行为。
忙于构建而无暇学习（Too Busy to Learn）：经常有创业者告诉我：”我也想做 MVP，但我太忙了，我必须抓紧时间把真正的产品做出来。”这种观念将产品开发速度等同于创业公司的进展速度。
如果产品的终局是做出一件根本没有任何人在意的东西，那么开发速度越快，造成的资金与时间浪费就越惊人。MVP 增加的少量测试成本，在宏观闭环上是巨大的时间节省。
现场互动与问答（Q&A）
提问1：MVP如何应用于线下服务型产品
提问：MVP 概念如何应用于线下服务型产品（如按摩理疗、医疗服务）？
埃里克·莱斯：对于服务型业务，可以从两个维度构建 MVP：
第一，获客与定位测试。在客户体验你的具体服务之前，他们必须先了解并决定使用该服务。你可以先测试营销话术、服务打包方案以及获客渠道，验证市场对该服务定位的意愿。
第二，低成本的服务交付版本。思考如何以极低成本快速交付一个”非最终形态”的服务。例如，有餐饮创业者在租用正式店铺前先设立测试厨房；有健身创业者在办公园区临时搭建简易健身房，以此测试用户对新型私人教练课程的付费意愿。MVP 的核心永远不是产品本身，而是经证实的认知。
提问2：如何区分界面问题与功能问题
提问：对于破坏性创新产品（例如 Facebook 早期改版时 90% 的用户都在强烈反对），如何区分这是纯粹的界面设计问题，还是功能本身的问题？
埃里克·莱斯：MVP 无法自动替你回答这个问题，但它能为你提供做出明智决策所需的基础事实。
当产品发生重大变更时，用户由于习惯使然，往往会产生极大的情绪化反弹。例如 Facebook 推出 Newsfeed（动态汇总）功能时，引发了大量用户的联名抵制。然而，Facebook 团队监控的数据表明：用户的实际参与度与停留时长在功能上线第一天就爆发式增长。
数据不会撒谎。绝不要仅仅依赖用户的言语反应，而要密切观测用户的实际行为变化。当事实数据呈现在桌面上时，团队才能进行理性的讨论。
提问3：新创公司与既有企业的差异
提问：零用户基础的初创公司与拥有既有用户群的企业，在执行 MVP 时有何异同？
埃里克·莱斯：缺乏用户对于初创公司而言，其实是一个巨大的竞争优势。
因为用户基数极小，你可以进行深入的一对一深度访谈与行为观测，而不需要像大公司那样依赖复杂的问卷分析与数据挖掘。
对于拥有既有用户群的大公司，若要测试高风险的新构想，可以通过将 MVP 仅暴露给一小部分子集用户的方式，重新获得类似初创公司的测试环境，从而在不伤害整体品牌资产的前提下完成验证。
提问4：双边市场的冷启动
提问（SlideShare 创始人补充）：在解决”双边市场/冷启动”问题时，SlideShare 最初是如何通过 MVP 吸引早期内容的？
埃里克·莱斯：SlideShare 早期非常清晰地梳理了单向依赖关系：他们优先聚焦于”需要将演示文稿嵌入到自己博客中的博主”这一特定极客群体，满足了这个早期预言家群体的主机托管需求后，才逐步积累起内容库，进而迎来了主流量产用户的浏览需求。
许多产品必须经历十几个阶段的演进，MVP 的关键在于厘清这一序列的先后顺序，并在早期剥离所有服务于后续阶段的冗余功能。
提问5：如何识别早期预言家用户
提问：在识别早期预言家用户（Early Evangelists）时，应该关注哪些特征？
埃里克·莱斯：在技术采纳生命周期曲线中，几乎所有成功的产品都需要先拥抱早期用户，随后在恰当的时机超越这群人去迎合主流市场。
如果早期只有技术极客愿意使用你的产品，请毫不犹豫地拥抱他们。但你必须保持清醒：如果你的终极愿景是主流市场，你就必须定期将 MVP 暴露给主流用户进行测试。
当早期用户夸赞产品”极易上手”，而主流用户抱怨”完全不知道如何开始”时，这个数据信号明确地告诉你：你的核心功能已经得到了验证，接下来你需要全力解决产品的易用性门槛问题。
非常感谢大家！