通过使用MVP的方法设计产品，能减少时间和资源的投入，并使用户满足产品。如何设计MVP呢？让我们跟随作者一起了解吧~希望本篇文章能对你有所帮助。

这周参与了一次需求评审会，同事打一开头就沉浸在讲解功能点上的细节，反而对为什么要设计这个功能、功能可能有什么预期的好处等关键信息讲解不明。用了快2个小时，大家发现他没有定义好用户场景上的“起承转合”，即他没法讲出一个“合理”的用户使用路线。

(资料图片仅供参考)

这2个小时中，几乎每个人都在表达不同的意见，会议从“需求评审会”演变成了漫长、无目的的“脑暴会”。

最终，会议只能偃旗息鼓、草草收场，他们决定整合好需求下次再提。

你可能会觉得“需求评审会不就是这样吗？”。或许，我们能尝试一个新的思路。

一、不要追求“想清楚再去做”

传统公司对产品经理的要求是要让产品经理“想清楚再做决策”。

于是会有这么个循环：

为了想清楚，产品经理花大量时间琢磨功能逻辑，像憋大招一样提需求；同事知道产品经理在憋需求，随着时间的流程，他们对需求的预期会提高。但一个人的视角绝对会有盲区，所以产品经理攒了很久的需求中会有大量实现困难或者逻辑疏漏或者根本没必要这么做等等问题。这会被指出。产品经理为了避免收到同事的负反馈，进一步花时间琢磨需求。

所以，“想清楚再做决策”这件事，有点像刻舟求剑，也有点像“计划经济”。但因为世界是复杂多变的，就产品设计这件事，“市场经济”更有力量。

二、不如试试MVP吧，居家旅行必备良药

我始终觉得，与其在会议室里争个高下，不如到“现实”的操场上去练练。“是骡子是马，拉出来溜溜”。而最有效的溜溜方式，就是MVP。

下面开始科普MVP，更关心要怎么做的同学可以跳到下一个标题处。

MVP是指“最小可行产品”，如下图：

MVP立足于自下而上设计产品的思想，它的核心在于通过多次快速的实验，来和现实世界碰撞，从而提高我们设计出有价值产品的可能性。

为了方便理解，你可以把它类比成抽卡游戏：我们想获得极品角色，然而极品角色的出卡概率很低，如果抽一次卡会消耗很多资源的话，在资源有限的情况下，我们就很难获得这个角色。

MVP的想法是：我要通过降低抽卡消耗的资源，来进行多次的抽卡。从而在一次次尝试中，提高我抽到极品卡的概率。而不是把所有资源，都破釜沉舟式的压在少数的几抽中。

比方打完了，这里“极品卡”指的就是“成功的产品”，跟游戏里一样，现实世界中，成功的产品少之又少。比如，创业公司存活3到5年的概率只有10%左右，而这些存活下的公司，还有挺大概率会被员工大骂老板的决策，那这就更别提市场上有多少产品算是优秀产品。

说远了，回到比方中去，“抽卡”消耗的资源就是指研发、运营或者说整个项目组乃至全公司的人力物力。

题外话，MVP其实和敏捷开发相辅相成，它出现的原因也是因为传统的瀑布开发会浪费太多资源，历史故事如下：

在80年代前，美国国防部一直要求其软件开发商在开发过程中使用严格的瀑布开发模型。但到了1987年末，国防部开始“建议”使用增量开发（敏捷开发的一项理念）作为软件开发模式。

后来，在对美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。

三、怎么设计MVP

回顾一下，MVP是为了保证最终开发的产品有价值，它是通过节约成本，快速给出最小可行性产品这个方式实现的。

那要怎么设计一个MVP呢？

具体到实现方式上，MVP有这么三种类型：手动测试、假功能测试、售卖测试。

1. 什么是手动测试

手动测试是指你几乎不调用研发资源，而是手动构建产品体验。比如在教培行业，通过纸模来验证激励系统设计，你可以约上家长，让小朋友体验你的桌游设计，看看能不能打动孩子。还比如，使用人工来创建产品体验。

在王兴的《美团产品方法论》中，他就提到：“一个产品在早期可能是非常糙的，现在消费者下单是系统自动推送到商家和配送员，最早根本没有这个东西。最早的时候美团的客服人员给商家打电话下单”

你看，用户根本不关心你的产品是怎么实现的，他们关心的是能不能解决问题。而用手动测试这种方法，就能快速贴近用户，得到反馈。

2. 什么是假功能测试

你可能会觉得，手动测试太占用人力了，没法大规模推广，那么假功能测试应该能帮助到你。它建立在增量设计的基础上，即是说我们在构建产品时，应该逐步渐进地去添加、丰富功能，而不是一口气就去预设一个很复杂的系统。

假功能测试需要一些研发资源。比如，你想了解下新增一个功能是否会改善MAU（月活跃用户数），你可以先添加一个这个功能的按钮，在用户点击后，告诉他之后会上线，敬请期待。这里，你会觉得“那怎么行，怎么可以在已有的产品上做这种儿戏一样的动作”。

所以当然，假功能测试会和AB测结合在一起，你会找到一部分用户，收集他们的数据，进而得到继续开发或者转向的证据，这些来自现实世界的证据而不是仅仅听起来高大上的关键词，会帮助你更有力地争取来自其他部门的支持。

假功能测试还可以应用于未上线的产品，你可以通过“制作假功能演示视频+等待清单”的方式收集反馈并评估市场需求。著名的Dropbox就使用了这个方法。

在开发功能前，Dropbox的创始人制作了一个简短的视频，向观众展示 Dropbox 的核心功能，如文件同步、共享和跨平台访问等等。这个视频的目的是向潜在用户展示 Dropbox 的价值，以便收集反馈并评估市场需求。

视频的风格轻松幽默，易于理解，吸引了许多观众的注意。 这个 MVP 视频的发布取得了巨大成功。在短短的时间内，Dropbox 的等待名单从 5,000 人激增到了 75,000 人。

这个结果表明，市场对这种类型的服务存在很大的需求。这个成功的 MVP 测试为 Dropbox 提供了宝贵的用户反馈，帮助他们优化产品并为正式发布做好准备。

如今，Dropbox 已经发展成为一个拥有数亿用户的全球性公司，为个人和企业提供文件存储、同步和共享服务。这个故事表明，通过 MVP 的方法，创业公司可以有效地测试市场需求，降低风险，并为产品的成功奠定基础。

3. 什么是售卖测试

实际上，售卖测试算是最后的临门一脚，毕竟，面对其他测试，用户可能会为了照顾你的感受而下意识地回应你的预期，但只要他发生了购买行为，那最有力的信号便出现了。

售卖测试即推出你的产品，看看用户会不会买，它常和假功能测试配合在一起使用，有点像“预约购买”的感觉，只有筹集到预定金额，商品才会被生产。在这时，你付出的所有宣传，不再是面向公司内部的领导，而是面向整个世界，来争取资源——“看看你的idea有多少人想掏出真金白银”。这也解决了我们制作感觉没有意义的PPT的问题。

4. 三种MVP的区别及共同点

在和用户接触深度上：手动测试>假功能测试>售卖测试。毕竟手动测试能让产品经理最近距离的接触到用户，而第一手的反馈总是难以被其他间接经验所替代。

在定义产品是否有价值的程度上：售卖测试>假功能测试>手动测试。毕竟，购买才是最有力的认可。

在三种测试时，你都需要注意：要分开测试用户动机和产品可用性。

这两点呈现出反函数的关系，用户动机很高的话，产品可用性低也无所谓，比如早些年，在春运时12306火车购票，你必须买，产品设计复杂也得用。再比如现在，为了使用ChatGPT，人们一直在找方法。

反过来说，如果用户使用这个产品的动机很低，比如有很多的替代品时，那么产品可用性越高，用户就越喜欢用，即用户留存就越高。

需要注意的是：你在一次测试中，要么测试用户动机，即产品价值；要么测试产品可用性，关注好不好用。你必须有所侧重。对于新产品而言，用户动机是最重要的，随着动机的逐步确定，可用性的重要性逐渐上升。

但如果你想同时测试用户动机和产品可用性，你就会得到一团混在一起、不知道是什么的东西，往好了说它会让你什么都得不到，往坏了说它会给你错误的指导。

四、怎么验证MVP的效果

在MVP设计时，你需要给出一个特定的门槛，来约束或者说指导之后的行动。

比如在售卖测试中，你可以说“如果筹集到5万金额，那么就在下周上线这个服务；否则，改变方向，尝试另一种思路”，或者在假功能测试中，你可以说“如果新功能点击率>5%，那么我们开始此功能设计；否则，降低此功能研发优先级并进行修改”。

你可以发现，这里的“门槛”是要附带一个决定的，否则，仅仅说明“MVP成功还是失败”，毫无意义。同时，在测试前就定下门槛有助于各部门达成一致的目标，而且也能锻炼你设定准确目标的感觉。

除了细化的目标，你还可以采用一种通用的目标，即衡量设计出的高价值功能与功能总数的比值，这个值越大，那么我们做的事情就越对。

我看过很多同事沉迷于设计功能、提需求，“让研发动起来”似乎就是他们的口号，但老板关注的永远是“你这个功能有什么用，实现了多少营收”，一味提需求让自己和研发忙起来听起来很不错，但是做明显正确的事情比做徒然无功或者不太错的事情，更有价值。

不要让你的产品无限膨胀下去，除了最小可行性产品，你还应当设置一个产品最大能承载的功能，用战略勤奋代替战术勤奋。

五、如何向领导推荐采用MVP

当然，对习惯于瀑布开发、排列出每一个时间节点的人来说（我们先假设你领导是这样的人吧），MVP会带来恐慌。

“什么？你说你要试一试才能开始设计？那我什么时候能拿到最终的产品，给我个时间”。

他们常常会说这种话，解决方法是：给出阶段性的回馈而非具体时间排期。

你要在每一个测试设计好后就通知老板，或者说在设计第1个测试时就向他展示你的思路，提高他的掌控感。你需要告诉他：测试并不意味着没有计划，相反，测试就像侦察兵一样，能帮助我们“用正确的、可预见的方式失败”。快速失败不是目的，目的是快速迭代，这能节省资源，并帮助你的老板。

当然如果他一定要个时间的话，你需要确定他是否有什么deadline，如果时间因素很重要，请在和技术、设计、测试、运营等人员一同商量后，给他一个时间，但你要说明白这样做可能带来的后果，请他权衡。

作者：探索者，公众号：探索者的神庙

本文由 @探索者 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。