05 | 如何快速利用 MVP 思想

Aug 8, 2018

05 | 如何快速利用 MVP 思想-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

05 | 如何快速利用 MVP 思想

2018-08-08 邱岳来自北京

《邱岳的产品实战》

课程介绍



讲述：邱岳

时长13:11大小6.04M



你好，我是邱岳，今天我分享的主题是：如何快速利用 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，可以给我留言，我们一起讨论。感谢你的收听，我们下次再见。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 31

提建议

04 | 用最少的资源给你的产品试试水

06 | 如何做好产品立项

 写留言

精选留言(28)

sylan215
2018-08-08
1. 其实推演基本所有产品经理都会做，问题是，有些人的推演就是自己在意yin而已，所以推演的结果就不尽如人意了。 2. 长板理论逆袭木桶理论，赞。 3. 创造低成本方案这个我尝试补充一个，现在很多的业务和系统全都是云端化，但是 MVP 阶段其实可以不去搭建复杂的云端配合系统，虽然那个很灵活，但是处于验证的目的，完全可以使用硬编码，或者规则文件来做前期的配置，等量级足够大的时候，再去搞云端化。 4. 根据「增长黑客」的理念，MVP 主要是为了找到产品的 PMF 状态，所以二爷说的 MVP 思想，我理解为就是验证或者探寻产品真实的 PMF 状态，所有精力优先聚焦在这个上面即可。以上，欢迎沟通交流，公众号「sylan215」
展开
共 1 条评论
24
木头人
2018-08-09
上面某位朋友，打点也称为埋点，解决数据采集的问题。
共 1 条评论
13
刘奥纳多
2018-08-08
请问打点是什么意思呢？
作者回复: 就是@木头人提到的，通过在访问中记录用户行为轨迹（也就是打点）来进行统计分析。
共 2 条评论
11
牛小妞
2018-08-14
印象最深的利用MVP快速验证产品的是多抓鱼，最早他们就是建立微信群人工发书单，人工下单转账来使业务跑起来的。
共 1 条评论
7
laulend™
2018-08-08
最近一直跟产品在争论一个功能，由于我们的用户特性，喜欢抽奖、抽券或者实物奖品，也做过小范围的测试，哪怕是插件，后来二爷家的抽奖助手支持嵌入功能，一直想接入二爷家的抽奖助手到自家的小程序做个MVP测试，如果效果反馈和好的话，那么就自己在页面上开发一个抽奖功能，支持自家优惠券抽奖等等，但是，产品一直不给做，非要自己搞一个抽奖功能，运营的延期和用户活动只能拖到一个月以后，对于这件事一直在撕逼，看完二爷的文章，我打算再去撕逼一次，不管成功与否，还是得去尝试一下。实在不行，推荐他们来看二爷的课程。
展开
作者回复: 不一定非要撕，换个思路，用别的方式绕一下，比如导进公众号里
6
CC
2018-08-14
之前我在制作MVP产品有两个误区。一是认为动手比推演重要，觉得推演很久不如动手制作，认为动手才是获得结果的捷径。实际上产生这个误区的原因是战略上的懒惰，没有深入思考制作MVP产品的目的，结果绕了一个大弯路。之前读过一篇文章，依稀记得，某个大牛在短短一个周末就鼓捣出了一个MVP产品，验证了想法。我只记住了结论，却没有记住逻辑推演过程，以及项目之前的准备。他之所以能做成，一是之前做过推演，二是有自己想要验证的明确目标。第二个误区是要求完美，过度担心用户的负面口碑，这就导致不仅把资源浪费在产品的短板上，还下意识的拒绝采用灵活的低成本方案，比如人工方案。会使用工具的人，比如会写代码，某种程度上也是受到知识诅咒，很容易一大步跨入产品细节，考虑实现方式，考虑如何做出一个完美的产品，而不是投入时间在推演上。明确目的，然后行动。
展开
6
听天由己
2018-08-08
关于人工替代系统，这对创业公司来说，更是常见。很多时候，我们想要验证一个功能的适用性，我们想得特别完美，可是资源有限，也只能先实现最核心的特性。例如，在赛事系统中，组织者很希望在报名结束后导出名单，这一需求并不着急，我们完全可以通过人工导出 Excel 表格的方式进行沟通。还有一点，产品不够，运营来凑，这话一点都不假。哪有上来就完美的产品？我们更重要的是展现自己的理念和态度，建立产品与用户之间的信任，然后快速响应和迭代，这样才有重视感和成就感。运营工作的确不必可少。
展开
4
胡氏
2019-02-25
有个小优化提下：播放可操作的进度条，比如返回重复听那一段话，倍速听；可跳选时间进度；
4
Symon
2018-08-23
这一节超实用，我们在做B端产品时，很多时候一些功能都是低频的操作，这时候人工反而比系统更优化些（从成本和灵活性角度来看，毕竟新产品的体量还没有那么大）！
共 1 条评论
3
时间之树
2018-08-08
特别关注了二爷讲到的关于MVP的局限性。任何理论和方法，都有他的使用条件和适用边界。只有充分了解它的局限性，才能更加有针对性的去使用。
3
J不湿
2019-04-22
MVP是种思维，可以根据不同情况进行调整优化方法
2
丁丁历险记
2021-03-29
每一个MVP其实是需要洞见的，不然真的是瞎hb乱扯。舍弃是一种能力
1
孙伟贤
2018-08-09
局部最优和全局最优的思考也很重要，产品其实都在努力控制系统和产品的熵，也就是局部系统有序和全局系统有序，也是走向产品架构的必由之路，回去想某个局部最优解可能会导致全局系统紊乱，到这个阶段的产品思考能力就是上等了，比如竞价排名，负面反馈，举报，敏感词等功能的意义，以及如何控制他们的负面效应
1
张叔夏
2018-08-08
订阅数码博主的内容推送不会是不鸟万如一的会员吧
1
听天由己
2018-08-08
与其更好，不如不同。这话放在今天这个时代，更是如此。中国这样的人口特征与需求分层让我们有机会尝试各种各样的产品设计与理念，可是同类产品的核心功能特性在哪里，一定要在第一版产品上线初就想好并且完善。产品本身是服务的一部分，二爷提到的 12306 就是典型的例子，这样的资源型产品，有足够多的资源可供用户来选择，才是最为关键的一点，因而产品体验要更靠后了。若是连票都没有，这样的产品有作用？梁宁老师说，产品要有系统能力，无论是技术支持、核心资源、市场营销、后勤客服等方面，每一项都是用户体验的一环，光靠产品本身出彩，是不足以支撑后续发展的，这样的例子就像几年前大火的足迹、脸萌等。
展开
共 1 条评论
1
冯广
2021-09-27
MVP最大的优势就是节省资源，让关键目标关键服务快速实现，但是不是所有的事情都可以借用MVP，或者说MVP的程度需要好好把握，因为当前处于流量红利消失殆尽的阶段，我们左右有大量的同质化竞争，很多时候是能不能成拼的是系统能力，拼的是细节的体验。
铛丹丹
2021-04-13
那么mvp是由产品还是运营来确定呢？毕竟产品觉得合适的mvp可能运营觉得不合适。
1
JianXu
2020-12-26
我们最近在做Kubernetes 的前端体验，我其实也在想我们的长板到底是什么？目前Kubenetes 各个对象之间互相navigation 非常不方便，所以我们用graph DB 做了一个索引，但是问题是为什么用户需要在不同对象之间navigate 呢？我觉得一个是看到自己应用的相关资源，一个是排查问题。相关资源的展示方式我觉得还是应该从用户角度来看，比如我们内部的TFAP , TFD 这些概念不是最优展示方式；而排查问题应该是我们在做上层的抽象上直接给出来。
展开
你是谁呀
2020-12-19
长短板理论很赞，不过短板差到不及格应该也不太行？结合负面口碑效应，短板太短也会损害产品
Ivan.YAO
2020-12-16
二爷对于MVP的讲解非常透彻

