MVP是埃里克·莱斯所著《精益创业》中提到的概念，它的目的是验证两件事：一是产品满足了用户需求；二是产品能够创造商业价值。这恰好跟前文我们提到的，初创团队的产品经理应该探讨产品模型和商业模式对应。MVP就是验证它们的手段。

许多产品都是从小做大的，而非起初就做得非常臃肿。打开微信，我们能看到它有许多功能。在图3-1中，我们可以看到微信大致的功能概览。作为已经有五年多寿命的国民级产品，微信的功能远称不上臃肿，但仍然可以列出40个左右的功能点。

而微信最早的版本，其实也只有核心的通讯录和文字聊天功能。如图3-2所示。

很多新人产品经理在刚开始做某个产品，或者刚开始做某个产品中的新模块时，会认为好的产品应当是“面面俱到”。但越是早期的产品（或者某个成熟产品中的新模块），越需要做得更关注产品的核心功能，实现产品的核心价值，原因有以下两点。

之一，产品模型的合理不能确保功能也会受到用户认可，快速投入到市场中进行验证是最妥当的***。互联网产品的迭代速度快、耗费资源少，也就提供了低成本试错的机会，让我们能够用这样的***来检验产品功能。

第二，产品的核心功能就可以解决用户问题，所以从理论上说，就未必要等到产品非常复杂、完善之后，才能吸引用户。只要能解决问题，越快把产品提供给用户，就能越快获得这些用户。

在我们做出了MVP之后，要考虑的就是使用MVP来发现用户的痛点了。硅谷的一些创业公司流行着一个概念，叫做PMF（Product/MarketFit），也就是产品和市场的匹配点。被称为投资教父的网景联合创始人马克·安德森在2007年提出这个概念，定义它的含义是在一个好的市场里，能够用一个产品去满足这个市场。这个定义更偏向从市场角度来看待问题，但跟痛点的含义相仿，都是解释产品要在市场或者用户之上，找到最契合的那个点。

PMF理论认为，产品的增长曲线会在找到契合的这个点之后，快速增长。在这之前，一直是在较低范围的波动状态，如图3-3所示。

如图3-4所示，是一段可能的创业历程。我们做出了一个MVP1.0，然后投入市场，逐渐达到了预期A和预期B（它们代表我们对产品阶段的预期，比如获取了100个用户和获取了1000个用户），但可惜MVP1.0并没有坚持更久，我们再接再厉做出了MVP2.0，这次很快达到了预期B但也遇到了瓶颈。我们不断优化MVP的功能，使其更符合用户的要求，最后终于达到了更高的预期C（比如获取10000个用户），这时我们就认为产品已经击中了用户的痛点。

产品经理在整个过程中，未必是按部就班只管设计、实践，还要做好判断：现在的产品处于什么阶段？它的运转是否良好？产品是否被用户承认？

一个MVP对产品的要求是：达到可用与最小成本的平衡。对于很多并不了解MVP的产品经理来说，做产品的主要模仿对象就是微信、***这样的平台级产品，做出来的之一个版本就会异常臃肿、成本过高。

对听说过MVP的产品经理来说，有时又过于简化，把产品功能做得太过简陋，甚至到了残缺的程度。残缺的产品会影响到用户的正常使用方式，也就无法达到检验的效果了。在实现成本和可用性上，找到平衡点，就是最关键的一步。

很多80、90后应该都接触过帝国时代、魔兽争霸这样的即时战略游戏。熟悉它们的话，就会知道经济、军事的稳步发展才是最终能够组建大军赢得战役的关键。首先，我们要把最需要的提供人口的住房、提供基础兵力的军营建好，再不断获取资源，在军事能力上升级、增加部队的多样性。如果刚开始就憋着劲儿造最昂贵的兵种，那么很快就会被敌人连窝端了。

道理是一样的，要先做五脏俱全的麻雀，再去做所向披靡的雄鹰。

在设计MVP时，推荐参考的***如下：

奥卡姆剃刀是由14世纪逻辑学家奥卡姆提出的原理，大意是“如无必要，勿增实体”。做产品时我们也可以遵循这个原理，把预期完整的方案简单罗列出来，然后从最不重要的部分一点一点砍掉其中的功能。直到再砍下去正常功能就无法使用为止，这时候的版本就可以算是最基础的一个版本了。

提供几个复杂程度不同的方案，做成便于理解的演示作品。比如幻灯片、Demo或者图片。召集一些目标用户来评价。他们认为会接受的更低限度的版本就是最小可用版本。

在很多互联网产品的创业初期，都是人工去处理很多事务，比如外卖平台最早的做法，很多都是工作人员看到订单，亲自给饭店***下单。那时候根本没有商家端的产品。把这些可以人工处理的功能丢掉，暂时用人力来完成，是降低开发成本、实现MVP的好办法。

务必确保在产品里只有一个功能，不管第二个功能看起来有多炫酷。在MVP中，只实现最重要的那个功能，其他的功能之后再说。当然，除非产品里这两个功能耦合在一起，分离就不产生价值了。在创投圈有句话很流行：“好的产品是一句话能讲清楚的。”如果创业者需要解释很多、用各种图表和知识来跟你讲才能说明白产品在做什么，那么这样的产品用户估计也理解不了。确保只有一个核心功能，也就是能让用户一下子有了心理定位，知道你是做什么的。支付宝和微信这样的产品都叠加了很多功能，我们依然能说出它们的核心功能是支付和聊天。这样的功能就是我们在MVP中要保留的功能。

设计好了MVP，运用的***也有很多。通常意义的MVP，就是可用的产品，投放到市场中让用户亲自体验，然后收集反馈，持续优化。互联网创业者们有很多有意思的手段，以更低的成本达到了MVP的效果。

Dropbox的MVP***经常被大家提起，广为流传。在他们团队想到做云盘的点子后，在根本没有实现时，就做了一条3分钟的广告，描述了他们的产品内容，并留下了产品注册方式。一夜之间，75000位用户注册了他们的产品。

广告形式实现MVP其实类似用户访谈的形式，不过会更有说服力。拉着用户问他爱不爱用这个产品，他未必会说心里话。但发布一则广告，看有多少陌生人对产品产生了兴趣，就能证明这个产品会有多少人买账。

假MVP的***有很多产品在用，与广告的***类似，大意就是，做一个视觉效果没问题的产品，但功能都是（或者部分是）假的。电子邮件营销公司Sendwithus的案例就很经典。他们团队不仅做了一个网站，甚至可以登录注册并看得到高仿真的使用界面，不过界面里功能都是假的，如图3-5所示。

每次当用户点击某个功能后，都会弹出界面，提醒用户正在开发中，并建议用户留下电子邮件，产品开发完成会有邮件通知。

通过这么机灵的***，他们收集到了用户使用他们产品的数据。但直到现在，他们还没有真正的产品。

前面提到，能人工实现的部分功能可以考虑砍掉。那么如果线下也可以完全用别的办法实现，同样可以不考虑开发线上产品。

其实很多互联网产品都是由传统行业的产品或者服务衍生出来的。互联网提供的是信息化带来的高效、便捷，并没有改变本质。举个例子，近几年很火的家庭厨房+外卖的形式，其实最初并不需要有完善的产品。我知道很多这样的产品，最初都是用传单的形式在写字楼和小区里发放的，大家预订的方式也都是线下团购。模式运作清楚后，再考虑移植到了线上。

众筹也是一种***，在国内基本都运用在硬件领域。把对产品功能的设想预售，用户只要愿意付钱买单，那么东西就自然卖得出去。这是可以同时检验功能和商业价值的***。

上面提到的MVP***，大多看起来像是预热和测验。无论如何，最终MVP都是需要实现成真正的产品的。在实现的时候，产品经理要考虑以下问题。

在平台选择上，产品经理要考虑哪种平台性价比更高，切忌每个平台都做一套。作为最小可用版本，完全不需要在多个平台上尝试。比如未来希望的是微信公众号（手机网页）、iOS和安卓平台都提供服务，那么可以选择微信公众号，因为开发成本低、传播成本也低。即便公众号体验差，并不是未来预期的平台，那等时机成熟再弃用即可。

很多不怕麻烦的创业团队，不仅微信公众号、iOS和安卓平台的产品一个不缺，居然在还没有多少用户的情况下，又要开始做PC端和Web端。他们不光搞不清楚MVP是什么，也不知道做一个产品的正常顺序是什么。

现在随着手机网页端技术的飞速进步，在微信公众号这样的平台里，我们也能有很接近APP的体验了。相对的，APP的创业红利期已经过去，用户手机里不会愿意装太多APP，即使装了很多APP，有很多也几乎不会再打开。所以如果让我推荐，对于90%以上需要客户端的产品，我都会建议先用微信公众号。

产品经理还要关心技术实现方案吗？答案我们会在下文进行探讨。这里先提一句：在MVP实现用怎样的技术***，产品经理还是应该做个判断的。在产品相对成熟时，当然是产品优先，效果优先。但在MVP的阶段，产品和技术要平衡，产品经理必须参与进来。通过调整产品方案，来尽量减少成本。比如，做电商产品时，技术的同事认为在首页做广告展示位（横幅）成本很高，那么产品经理就可以考虑，是不是暂时不做专用的广告展示位，而是只提供一条公告形式的通知链接，能够实现引导和提示用户广告的作用，这样也是可以接受的？

另外，在技术实现时，如能使用第三方插件和工具减轻压力就尽量去用。在这个阶段，无须考虑太多拓展性的问题。产品都未必经受得住考验，技术实现得很完善，一旦推翻重来成本更高。

对于是否要用外包实现之一个产品版本，我的态度是：慎重。有以下几点原因。

之一，要考虑启用外包的团队，大都存在一个共性：对技术开发并不熟悉，甚至对互联网也不熟悉。这样的后果就是，找到的外包未必靠谱、产品对接未必顺畅。我见过的创业项目，如果请了外包团队，做出来的产品10个里有8个不会满意。

第二，产品负责人或产品经理跟外包团队通常是异地，沟通一般都不会很顺畅。在正常的流程里，产品经理与技术要完成很多设计、讨论、整理的协作，但在异地的情况下，比较棘手。更多的外包项目甚至只靠几页草稿去开发，三个月后才能见产品，这样的产品质量可想而知。

第三，外包团队大都不会维护后续的版本。对MVP来说，最重要的意义在能够检验效果，下一步就是开启快速迭代，优化版本。但开发者都不在了，谁来做迭代、谁来做优化？

除非在极端情况下，很紧急地需要帮手时，是可以把非核心的功能外包出去的。如果不是这样的情况，还是尽量雇佣自己的开发人员。连开发人员都雇佣不到的团队，说明对开发本身就不熟悉，出问题的概率会更高，就更加建议先用线下的形式或者用假MVP的形式运作，这样会保险一些。

“解决了用户的痛点”才是让用户使用我们产品的最主要因素，以及体现产品价值的关键点。在第2章里，我们探讨过做产品要有核心价值，那么痛点其实就是我们要找的核心价值的体现。

当我们设计出了一款简单的MVP并投放到市场中去，发现用户对这个功能买账，而且我们主要解决了他们想出门吃饭、寻找附近美食的问题，那么这就是痛点了。根据痛点，我们不仅可以确定用户是认可的，还可以了解到用户为什么喜欢、在什么场景下会用到。所以，发现了痛点之后，才是深挖需求、快速迭代的时机。

Airbnb是当今世界上最火的O2O服务之一，其团队的经历跟其他互联网创业团队一样，也是在寻找痛点的历程中摸索了很久。最初他们遇到的场景很具体：在旧金山参加会议，但旅店爆满，他们就在公寓里多摆了一些气垫床，出租给当时没有地方住的人。当然，他们自己也没太当真，把这个当成很正经的创业项目。但当他们继续观察时，发现其实是可以有市场的。他们敏锐地意识到，用户的痛点并不是在出差开会时旅店爆满这个场景，或者不仅是这个场景，更多的是在旅行中需要廉价、干净、舒适的住处。基于这样的痛点，他们做了一些改变：不只关注会议时的临时旅馆，而是面向所有旅馆；开始提供在线预订时间和地点；开始支持用信用卡支付。

后来，还有一个重要的痛点，也经常被称为Airbnb在发展中最关键的发现：用户需要对房屋情况做事前判断。Airbnb的创始人Gebbia和Chesky在看到成交量不够乐观后，决定找到问题所在。在跟很多用户了解之后，他们判断应该是出租者根本不会自我包装，展现出来的信息实在没有吸引力，或者不够健全。

于是，他们花钱租借了相机，免费给出租者拍摄精美的照片。后来，拍摄照片变成了标准化的***服务，屋主可以在平台上预约摄影师上门拍摄。

从Airbnb的用户量增长曲线，可以明显看到开始拍照之后的变化，如图3-6所示。

“痛点”的含义解释过了，那么到底怎样找出痛点呢？

在前面里，我提到过好的产品实现的价值X，应该大于用户转移的心理成本Y1和实际成本Y2的和。也就是产品功能足以让其他产品的用户或者用传统方式解决需求的用户，愿意转移到我们的产品上来。这样的方式比较不好量化，大都依靠估算。外在的表现也就是用户源源不断地来，增长曲线足够动人。我们可以制定一些标准来判断是不是发现了痛点。

最直接的***自然就是看数据。如果我们的功能或者服务，投入市场后得到了非常好的数据反馈，用户量或者订单量有了显著提升，那么显然就是找到了痛点。

对不同的产品，要关注的数据差别很大。建议关注以下数据。

使用频次。对社交产品来说期望值会高一些，比如1～2天开启一次；普通的工具类产品期望值低一些，比如3～4天一次；而电商类、服务类的产品，可以根据用户的实际需求频次来确定，比如对美甲来说，每个月1～2次算是正常的，因为这说明用户每次要做美甲至少都会想到你的产品并打开来看。

日活跃用户、周活跃用户和月活跃用户。如果对找到痛点这个阶段的产品来说，日活的增长率可能突然呈现几倍的指数增长。在这种情况下，我们才能说“快速增长”。

用户留存。用户的留存率或者流失率有显著变化，也说明产品正在越来越吸引用户。较好的次日留存数据，或者对电商和服务产品来说的复购率，至少要在10%～20%。用户留存要看长效的统计，比如之一天的用户第二天留存还不错，但第五天都流失了，这就表示留存价值很低；而每天的用户总有一部分会一直留存下来，就意味着留存的效果很好。

付费转化率。注册过的用户有多少愿意付费？要根据最早设想的商业模式来计算这样的转化率是不是在预期中，是不是能在理论上支撑公司的运营。

LTV/CAC3，即用户终生价值/用户获取成本3。所谓用户终生价值，指的是用户在使用产品的整个时间周期中与产品互动所产生的全部总计收益；而用户获取成本，指的是获取同样的用户，要花费的总成本。这是一种很常见的用户获取成本衡量***。整体的用户终生价值要大于用户获取成本的3倍，这样成本才算可以接受，或者说这样的用户值得我们去获取。国内很多创业团队花了大量的钱，但最终用户并没有回馈价值，结局就可想而知了。

目前国内互联网产品，往往是不太看重商业数据，而只关注用户数据。不管大环境是怎么样的，作为一个有清醒认识的产品经理，还是要时刻关注商业价值的数据的。否则就跟很多徒有流量却总赚不到钱的产品一样，陷入两难境地。

另外，要根据不同的产品，选择观察的数据。对于现在的很多O2O产品，比如外卖，关键的数据还是订单量。而单纯的订单量未必能证明什么，还要看商铺入驻的数量和质量，看订单的来源是否合理。数据的增长到底来自于补贴够多，还是来自于用户的满意；这些数据以目前的增速，是不是算进入了正常的范围……要综合考察，才知道产品是不是已经达到了预期中的用户痛点。

对于内容社区类的产品，其核心是内容产生的数量。同样的，还要看用户的活跃度，以知乎为例，还要包括用户的关注、阅读、点赞、提问和回答的行为，以及问答内容的数量和质量。只看用户量在增长，但回答者变少了、回答者的整体素质降低了，这也不算是好的数据。

发现痛点跟运营有特别紧密的联系，因为本质上，就是要观察产品是不是到了临界点，也要知道产品受到欢迎或者不被喜欢的原因。这时要跟运营的同事很好地合作，用数据来做出判断。

数据分析能够定量地对痛点进行判断，而用户反馈可以定性地对痛点进行感知和理解。

对于产品最初的版本，用户会有很多话要说。一方面因为是比较新的产品，很多用户会表现出兴趣，以及他们为什么会感兴趣的原因；另一方面由于比较简陋，用户会有很多抱怨。这两种信息都非常重要，所以产品经理要特别善于获取它们。常见的信息获取***包括用户在线反馈和定向访谈。

对于用户在线反馈，建议在产品上增加比较醒目的反馈入口，或者主动创建一些用户群，在产品醒目位置推荐大家加入讨论。找到之一批种子用户的工作也许是运营的同学去做的，但维护他们，产品经理是一定要参与的。

除了官方渠道之外，要多观察哪里可能会有人讨论自己的产品。常见的是应用商店的评论区、贴吧、知乎、豆瓣、微博。多跟他们接触，并且针对他们提到的观点交流，会有非常多的收获。张小龙就曾经要求他麾下的产品经理们在了解用户方面做到“1000，100，10”，也就是“每周看1000篇帖子或微博，看100篇博客，做10个CE（CustomerEngagement，用户参与）”。小米科技在最初做MIUI时也要求产品经理每天都在论坛回帖。MIUI发布四年，收集的用户反馈帖过亿。这些对于观察MVP的效果来说尤为重要。

对于定向访谈来说，可以用访谈的形式跟用户确认以下几件事：

•“你喜欢我们的产品吗？”

•“你在用这个产品之前，在用什么产品？”

•“这个产品给你带来帮助了吗？或者解决了你的问题吗？”

•“如果继续用它，你觉得会用多久？”

•“你觉得要变成什么样，你就更不会离开它了？”

•“如果现在你用不到它了，你会有不适吗？”

•“如果我们收费/做广告/提供付费服务，你会接受吗？”

•“你愿意在这个产品上花多少钱？”

访谈话题的重心可以参考当前的数据情况。如果数据是乐观的，那就聊用户喜欢的点，找到现在产品中最吸引他们的部分，发现痛点背后的逻辑。如果数据是不乐观的，可以问用户现在不爱用的原因，要更仔细地去发现他们已经在用的功能，切忌只看到用户都没在用，就贸然放弃这个产品功能，可能并非功能有问题，而是实现的***不够准确、不够好。

在做嘟嘟美甲时，我们仅仅花了两周时间，就完成了之一个MVP，可以说是真正能够给用户提供服务的版本。作为O2O服务，这意味着不仅可以在线预约，还能选择我们的上门美甲服务。

当时我们的经历是这样的。确定了我们的产品模型是手机预约、上门服务后，我们就把预期的产品功能都列在了白板上。暂且只说消费者端的产品，我们就应该有搜寻样式、下单预约、售后三个核心模块，而功能完整的情况是图3-7所示的样子。

优惠和导购是为了运营引流的，搜索和标签功能让用户更方便找到想做的样式，推荐提供给新来的用户，让他们产生兴趣。下单预约时，要有选择美甲师、地址和时间的步骤，然后线上支付。在售后的部分，要有订单管理，了解订单的状态并操作订单，还要有评价和评分的体系，要有申诉举报的途径，同时配套有奖惩的措施。

如果是作为MVP，显然不能全部完成。而且当时我们基于市场的现状，决定在月内就要推出之一个版本。所以我们首先去掉几乎所有的导购、搜索和推荐的功能，在MVP中我们只提供默认的几十款样式。在下单预约时，我们也仅提供时间和地址的简单填写，美甲师由我们人工分配，而支付也干脆使用线下支付。售后整个模块都砍掉，全部由***完成。

这样对于消费者端来说，就剩下了选择样式和下单的核心流程。下单功能做得十分简单，不考虑背后的库存逻辑，也就是任何时刻都可以向任何美甲师下任意样式，这样虽然当然不可控，但在我们前期单量极少的情况下，很多问题是可以通过***解决的。

我们选择的消费者端是微信公众号，网页的开发速度相对较快，而且不需要审核，也不存在应用商店的要求，所以最终在两周后我们就把十分简易的版本上线了，并且找到了用户，启动了我们的之一单上门服务。这就是我们最简陋的MVP。

经过这些调研、访谈和分析，我们逐步确定了后续要做的方向，找到了功能的优先级，逐步推出了更完善的功能，也修正了很多之前的问题。

使用MVP是基于一个前提，核心的产品功能是需要检验的。这点没有问题，但也并不意味着另一个极端：产品功能是不需要做太多思考的。

有的产品经理是理论派，喜欢套用各种概念，并且对自己的设计能力有极高的信心。他们相信乔布斯曾经说过的一句话——“用户不知道自己想要什么，除非你摆到他面前”[2]，所以好的产品都应该是设计出来的。

有的产品经理则是实践派，认为产品经理应该是数据分析师和用户研究员，一切来源于用户，用户说什么对就代表着什么是对的。所有的产品功能都应该基于用户来源的信息，这样的产品才能确保是受欢迎的。

MVP看似实践派的***，但实际上更像是二者结合。

我们要设计出一个足够好的可用产品，至少要在产品功能上做分析，要确定它的产品模型、核心功能。但并不意味着有足够自信就可以一蹴而就。我们大部分人并没有乔布斯那样强大的产品感，也没有他那样好的设计能力，许多时候要证明我们的产品有价值，有两个因素是必不可少的：在理论上成立，在实践中证明。

所以不要把MVP早晚要经过用户检验作为不认真思考产品逻辑的借口、不去设计产品模型的借口。雷军曾经说过一句很经典的话，不要用战术的勤奋来掩盖战略的懒惰，正是此意。

产品模型和对核心功能的设计像是指导思想，而MVP是实践的***论。很多产品经理沉醉于自己设计的美好幻想中，或者想法变来变去，或者埋头设计出一套太过完整却不实际的方案，但就是不尽快迈出之一步，验证自己想法的对错。

MVP很难一击必中，创业团队要在检验中判断产品功能有没有解决问题。如果及时发现问题，快速转向，也许生机就在别处；但如果太过留恋自己的设想，一直死磕一个方向，可能下场就不怎么好看了。

•大部分在等待功能完善、交互完美、界面出色才能一炮而红的产品，往往都没等到那一天。

•产品初期做设计要多做减法。

•初期把整体流程跑通时不用特别在意是不是用“互联网方式”。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！