mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-07 18:46:40 +08:00
92 lines
9.2 KiB
Markdown
92 lines
9.2 KiB
Markdown
<audio id="audio" title="05 | 如何快速利用 MVP 思想" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1d/25/1dcb1e297e274a13ca5d8f6214660925.mp3"></audio>
|
||
|
||
你好，我是邱岳，今天我分享的主题是：如何快速利用MVP思想。
|
||
|
||
在上一篇 “用最少的资源给你的产品试试水”中，我们谈到了最小可用产品MVP，并分享了几个关于它的经典案例。现在，让我们从例子里面跳出来，去看看怎么能快速地在自己的工作中利用 MVP 思想，这里有几个原则可以参考。
|
||
|
||
## 1.提前推演逻辑，不要盲目验证
|
||
|
||
在设计最小可用产品之前，一定要想清楚自己想验证的问题，要收集哪些数据项，还有这些数据项可能出现的结果，以及不同结果代表的结论。
|
||
|
||
这个事情有点像软件工程中的 TDD（测试驱动开发），先把想要得到的结果列出来，再反推设计，以免设计逻辑不清楚，或者漏掉数据打点，反倒浪费了资源。
|
||
|
||
比如我前面举的那个数据分析功能，我也是在推演的时候才发现需要多做一些数据功能，否则如果功能本身太简陋导致使用率高留存低的情况，就会难以辨别哪里出了问题。
|
||
|
||
另外，推演的时候还会提前去准备一些数据，比如使用率高，那么多高算高呢？这就需要去查一下在同区域其他类似功能的使用率。
|
||
|
||
这个过程本身也很有意思，你在心里默默估一个可能出现的数字，然后把功能做上去，再看看实际跑出来的数字，这个过程就好像谜底揭晓一样。
|
||
|
||
我觉得这个过程本身也是一种训练，就是你有判断，然后再看结果。时间久了，你可能会逐渐形成自己对于用户习惯，以及一些具体数字项的感觉。
|
||
|
||
最后再多提醒一句，别忘了打点。我还真见过做测试或验证不打点的，这样不但浪费时间，还会让别人觉得你不靠谱。
|
||
|
||
## 2.验证长板，而非短板
|
||
|
||
做最小可用产品必然会涉及裁剪，一个产品要能够完整提供服务，就需要有很多特性，那裁什么呢？
|
||
|
||
答案是尽量裁掉短板，把资源放到长板上。比如类似 Instagram 要做 MVP 测试，它的核心优势，也就是它的长板是与众不同的图片分享体验。那就意味着它的评论功能、用户管理功能等等都不重要，有资源就做到及格，没资源的话即便不及格也不会受到太多影响。
|
||
|
||
尽量去关注核心的、差异化的体验。比如，我经常开玩笑说 12306 的第一版产品就是个 MVP，整个产品体验烂到爆，但长板还是完全体现了：它有票。
|
||
|
||
用户捏着鼻子也要在这里抢票，这当然说明了需求很旺盛，动机很强烈，后续逐渐补足短板就好。时至今日，12306 产品的体验也不可谓优秀，但作为用户我已经非常满足了。
|
||
|
||
现在这个时代，各种产品形态基本都被人想到了或者实施过了，我们要在市场上立住脚，靠的不是平均分更高，而是在单一维度上做到现有方案的十倍好。所以做 MVP 更重要的是验证这个长板，而不是做一个不犯错但平庸的尝试。
|
||
|
||
## 3.创造性的低成本方案
|
||
|
||
在设计最小可用产品时，我们需要创造性地想出低成本的解决方案，来验证最关键的命题，比如我前面提到 Dropbox 的纸片视频，维珍航空的真按钮假功能；但是，并不是所有场景都能用类似取巧的方式得以支撑，大部分情况下，我们还是要真的做出东西来。这里我想分享三个常用的思路。
|
||
|
||
### 3-1. 用人工替代系统
|
||
|
||
我在上面提到的后台数据分析功能的例子中，就用了这个策略。本来报表数据应该是系统实时计算的，但为了快速进行验证，我们当时采用的方案是：线下算好结果，然后手工定时更新上去。虽然说功能上逊色了一点，但研发成本却大幅度降低。
|
||
|
||
类似的思路也可以用在其他场景中，比如我们曾经希望测试在某个业务环节上，用户购买的转化率。我们起初不去做订单、购物车、物流追踪等完整的功能，而是放一颗“购买”按钮，点击之后用表单收集联系方式和收货地址，然后支付。
|
||
|
||
运营人员每天导出提交的表单，人工发货和联系用户。虽然下单不实时也不自动，但用来做转化率的测试完全够了。
|
||
|
||
[Readhub.cn](http://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，可以给我留言，我们一起讨论。感谢你的收听，我们下次再见。
|
||
|
||
|