05 如何快速利用 MVP 思想
你好，我是邱岳，今天我分享的主题是：如何快速利用MVP思想。
在上一篇 “用最少的资源给你的产品试试水”中，我们谈到了最小可用产品MVP，并分享了几个关于它的经典案例。现在，让我们从例子里面跳出来，去看看怎么能快速地在自己的工作中利用 MVP 思想，这里有几个原则可以参考。
1.提前推演逻辑，不要盲目验证
在设计最小可用产品之前，一定要想清楚自己想验证的问题，要收集哪些数据项，还有这些数据项可能出现的结果，以及不同结果代表的结论。
这个事情有点像软件工程中的 TDD（测试驱动开发），先把想要得到的结果列出来，再反推设计，以免设计逻辑不清楚，或者漏掉数据打点，反倒浪费了资源。
比如我前面举的那个数据分析功能，我也是在推演的时候才发现需要多做一些数据功能，否则如果功能本身太简陋导致使用率高留存低的情况，就会难以辨别哪里出了问题。
另外，推演的时候还会提前去准备一些数据，比如使用率高，那么多高算高呢？这就需要去查一下在同区域其他类似功能的使用率。
这个过程本身也很有意思，你在心里默默估一个可能出现的数字，然后把功能做上去，再看看实际跑出来的数字，这个过程就好像谜底揭晓一样。
我觉得这个过程本身也是一种训练，就是你有判断，然后再看结果。时间久了，你可能会逐渐形成自己对于用户习惯，以及一些具体数字项的感觉。
最后再多提醒一句，别忘了打点。我还真见过做测试或验证不打点的，这样不但浪费时间，还会让别人觉得你不靠谱。
2.验证长板，而非短板
做最小可用产品必然会涉及裁剪，一个产品要能够完整提供服务，就需要有很多特性，那裁什么呢？
答案是尽量裁掉短板，把资源放到长板上。比如类似 Instagram 要做 MVP 测试，它的核心优势，也就是它的长板是与众不同的图片分享体验。那就意味着它的评论功能、用户管理功能等等都不重要，有资源就做到及格，没资源的话即便不及格也不会受到太多影响。
尽量去关注核心的、差异化的体验。比如，我经常开玩笑说 12306 的第一版产品就是个 MVP，整个产品体验烂到爆，但长板还是完全体现了：它有票。
用户捏着鼻子也要在这里抢票，这当然说明了需求很旺盛，动机很强烈，后续逐渐补足短板就好。时至今日，12306 产品的体验也不可谓优秀，但作为用户我已经非常满足了。
现在这个时代，各种产品形态基本都被人想到了或者实施过了，我们要在市场上立住脚，靠的不是平均分更高，而是在单一维度上做到现有方案的十倍好。所以做 MVP 更重要的是验证这个长板，而不是做一个不犯错但平庸的尝试。
3.创造性的低成本方案
在设计最小可用产品时，我们需要创造性地想出低成本的解决方案，来验证最关键的命题，比如我前面提到 Dropbox 的纸片视频，维珍航空的真按钮假功能；但是，并不是所有场景都能用类似取巧的方式得以支撑，大部分情况下，我们还是要真的做出东西来。这里我想分享三个常用的思路。
3-1. 用人工替代系统
我在上面提到的后台数据分析功能的例子中，就用了这个策略。本来报表数据应该是系统实时计算的，但为了快速进行验证，我们当时采用的方案是：线下算好结果，然后手工定时更新上去。虽然说功能上逊色了一点，但研发成本却大幅度降低。
类似的思路也可以用在其他场景中，比如我们曾经希望测试在某个业务环节上，用户购买的转化率。我们起初不去做订单、购物车、物流追踪等完整的功能，而是放一颗“购买”按钮，点击之后用表单收集联系方式和收货地址，然后支付。
运营人员每天导出提交的表单，人工发货和联系用户。虽然下单不实时也不自动，但用来做转化率的测试完全够了。
Readhub.cn 早先希望尝试浏览器推送的功能，这个功能也是由人工操作的。我还订阅过一个数码博主的内容服务，服务刚开始的一段时间，也都是靠人工发邮件。大家不要看不起人工的灵活性和力量，很多服务都是踩在人力的肩膀上起步的。
很多产品经理希望在早期就将服务闭环起来，准备好各种可能性的应对方案：如果流量太大，怎么扩容；如果客服量太大，如何分配；如果有 Spam，应该怎么处理，等等。
其实大可不必准备得如此完备再上路，很多时候可以先用人力顶住测试一下。如果服务真的很靠谱，再快速迭代用系统化的能力去解决问题就来得及。
3-2. 利用第三方系统
除了人力之外，我们还可以先借助第三方系统或生态快速构建 MVP 进行验证。前几年有个朋友想要创业做非标品电商，他从内容入手，到商品管理、供应链管理，还规划了自己的电商平台和 App，想得很大。
他当时想让我给他一点建议，我就建议他先别想那么多，先注册一个公众号，或者用 WordPress 搭个简单的展示页面，如果还不够就开一个有赞或者微店商铺，先把买卖做起来。他连连摆手说这不行，没有供应链管理，订单肯定应付不过来，我说订单多起来再做也来得及。
后来他又问我用户关系管理系统怎么设计或者选型，我于是强烈地建议他弄一个 Excel 表格先凑合一下。
虽然将信将疑，但好在他是个执行力很强的人，就迅速注册了公众号和商铺，在小圈子里做了一些内容传播，因为有线下实体店做依托，于是商铺很快开始有了订单。直到今天他也没有做平台和 App，依然只是依托公众号和线下实体店卖卖东西，赚得也不少。
如今的互联网基础建设比那时高了不知道多少，从 SaaS 到 PaaS，从云服务到建站、电商、支付、小程序，于是，对我们来说，构建 MVP 的门槛越来越低，我们应当去尽可能地利用第三方的服务来快速验证自己的想法。
3-3. 利用规则缩小场景
假设我们打算投入资源做智能客服机器人，现在想要验证用户是否能够接受用与机器对话的方式来解决问题。在没有任何自然语言理解算法和数据之前，我们可以通过缩小场景去简化提供对话的实现难度。
比如，我们可以设置条件，当用户确认收货三天之内打开订单详情页面，则很有可能是要退货，这时出现一个退货咨询的入口，点进来之后，进入机器客服的流程。这个流程可以仅具备解决退货问题的能力，甚至用简单的 QA 对就可以完成，对实现难度的要求就会降低不少。
4.MVP 的另一面
要注意的是，MVP 并不是唯一正确的方法论，很多人对 MVP 和精益思想提出过不同意见，其中包括 PayPal 的创始人 Peter Thiel，在他的书《从 0 到 1》中，他很不客气地批评精益思想只不过是缺乏规划的托辞，最多是帮助创业者进行一些小修小补的把戏。
另外，有很多的产品模式是要求一定的体量和复杂度才能完成验证的，MVP 最多只能验证其中个别环节上的假设是否成立，千万不要把宝全部押到一个 MVP 上。尤其对于领域相对成熟的产品，产品体验细节的叠加才能构成核心竞争力，而在 MVP 中可能很难将它构建出来。
MVP 还有一个可能的影响是负面的口碑效应，有些不是特别刚需的场景，做一个 MVP 发出去，早期的用户一用发现不能满足期望，或许就放弃了。
即便后来做了更多的迭代和改进，再唤醒他们的成本或许是很高的。而通常愿意对早期产品进行尝鲜的用户，很可能在线上线下的小圈子里具备一定的影响力。他说你不好用，比一个沉默的用户流失可能带来的伤害更大。
所以说，MVP 有它的价值和好处，但也不是一个“放之四海皆有效”的唯一原则。对我们来说，要知道它的长处与短处，从而善于利用 MVP 快速推进产品规划和发展，同时也不能迷信它或信仰它，没有那个必要。
总结
好了，总结一下。今天我与你分享了快速地在自己的工作中利用 MVP 思想的几个原则。
首先是提前推演逻辑，不要盲目验证。其次是你需要验证的是你的长板，而不是短板。接下来我还分享了三种低成本的解决方案：用人工替代系统、利用第三方系统以及利用缩小场景来做到快速实现。最后我要提醒你的是，MVP也是有自己的局限，切记不要一概而论。
如果你在工作中利用到MVP，可以给我留言，我们一起讨论。感谢你的收听，我们下次再见。
- 刘奥纳多 👍（12） 💬（2）
请问打点是什么意思呢？
2018-08-08 - laulend™ 👍（7） 💬（1）
最近一直跟产品在争论一个功能，由于我们的用户特性，喜欢抽奖、抽券或者实物奖品，也做过小范围的测试，哪怕是插件，后来二爷家的抽奖助手支持嵌入功能，一直想接入二爷家的抽奖助手到自家的小程序做个MVP测试，如果效果反馈和好的话，那么就自己在页面上开发一个抽奖功能，支持自家优惠券抽奖等等，但是，产品一直不给做，非要自己搞一个抽奖功能，运营的延期和用户活动只能拖到一个月以后，对于这件事一直在撕逼，看完二爷的文章，我打算再去撕逼一次，不管成功与否，还是得去尝试一下。实在不行，推荐他们来看二爷的课程。
2018-08-08 - Cindy 👍（0） 💬（1）
内部想孵化一个项目，市面上有完备的竞品，业务需求很大很多，怎么确保是mvp？
2020-02-20 - sylan215 👍（24） 💬（1）
1. 其实推演基本所有产品经理都会做，问题是，有些人的推演就是自己在意yin而已，所以推演的结果就不尽如人意了。 2. 长板理论逆袭木桶理论，赞。 3. 创造低成本方案这个我尝试补充一个，现在很多的业务和系统全都是云端化，但是 MVP 阶段其实可以不去搭建复杂的云端配合系统，虽然那个很灵活，但是处于验证的目的，完全可以使用硬编码，或者规则文件来做前期的配置，等量级足够大的时候，再去搞云端化。 4. 根据「增长黑客」的理念，MVP 主要是为了找到产品的 PMF 状态，所以二爷说的 MVP 思想，我理解为就是验证或者探寻产品真实的 PMF 状态，所有精力优先聚焦在这个上面即可。 以上，欢迎沟通交流，公众号「sylan215」
2018-08-08 - 木头人 👍（13） 💬（1）
上面某位朋友，打点也称为埋点，解决数据采集的问题。
2018-08-09 - 牛小妞 👍（7） 💬（1）
印象最深的利用MVP快速验证产品的是多抓鱼，最早他们就是建立微信群人工发书单，人工下单转账来使业务跑起来的。
2018-08-14 - CC 👍（6） 💬（0）
之前我在制作MVP产品有两个误区。 一是认为动手比推演重要，觉得推演很久不如动手制作，认为动手才是获得结果的捷径。实际上产生这个误区的原因是战略上的懒惰，没有深入思考制作MVP产品的目的，结果绕了一个大弯路。 之前读过一篇文章，依稀记得，某个大牛在短短一个周末就鼓捣出了一个MVP产品，验证了想法。我只记住了结论，却没有记住逻辑推演过程，以及项目之前的准备。他之所以能做成，一是之前做过推演，二是有自己想要验证的明确目标。 第二个误区是要求完美，过度担心用户的负面口碑，这就导致不仅把资源浪费在产品的短板上，还下意识的拒绝采用灵活的低成本方案，比如人工方案。 会使用工具的人，比如会写代码，某种程度上也是受到知识诅咒，很容易一大步跨入产品细节，考虑实现方式，考虑如何做出一个完美的产品，而不是投入时间在推演上。 明确目的，然后行动。
2018-08-14 - 胡氏 👍（4） 💬（0）
有个小优化提下：播放可操作的进度条，比如返回重复听那一段话，倍速听；可跳选时间进度；
2019-02-25 - 听天由己 👍（4） 💬（0）
关于人工替代系统，这对创业公司来说，更是常见。很多时候，我们想要验证一个功能的适用性，我们想得特别完美，可是资源有限，也只能先实现最核心的特性。例如，在赛事系统中，组织者很希望在报名结束后导出名单，这一需求并不着急，我们完全可以通过人工导出 Excel 表格的方式进行沟通。 还有一点，产品不够，运营来凑，这话一点都不假。哪有上来就完美的产品？我们更重要的是展现自己的理念和态度，建立产品与用户之间的信任，然后快速响应和迭代，这样才有重视感和成就感。运营工作的确不必可少。
2018-08-08 - Symon 👍（3） 💬（1）
这一节超实用，我们在做B端产品时，很多时候一些功能都是低频的操作，这时候人工反而比系统更优化些（从成本和灵活性角度来看，毕竟新产品的体量还没有那么大）！
2018-08-23 - 时间之树 👍（3） 💬（0）
特别关注了二爷讲到的关于MVP的局限性。任何理论和方法，都有他的使用条件和适用边界。只有充分了解它的局限性，才能更加有针对性的去使用。
2018-08-08 - J不湿 👍（2） 💬（0）
MVP是种思维，可以根据不同情况进行调整优化方法
2019-04-22 - 铛丹丹 👍（1） 💬（0）
那么mvp是由产品还是运营来确定呢？毕竟产品觉得合适的mvp可能运营觉得不合适。
2021-04-13 - 丁丁历险记 👍（1） 💬（0）
每一个MVP其实是需要洞见的， 不然真的是瞎hb乱扯。 舍弃是一种能力
2021-03-29 - 孙伟贤 👍（1） 💬（0）
局部最优和全局最优的思考也很重要，产品其实都在努力控制系统和产品的熵，也就是局部系统有序和全局系统有序，也是走向产品架构的必由之路，回去想某个局部最优解可能会导致全局系统紊乱，到这个阶段的产品思考能力就是上等了，比如竞价排名，负面反馈，举报，敏感词等功能的意义，以及如何控制他们的负面效应
2018-08-09