知果：我对B端产品MVP的5点感悟与3点总结（实战版）

关键词：MVP

你有没有在学过MVP思想后，依然不知道在实际产品中如何去落地？

 

对于哪些功能可以归属在MVP中，哪些不应该归属在MVP中，不知如何下手？

刚开始，我以为我学完MVP理论就已经懂了MVP，而实际上并不是如此。

一方面，在实际工作中，总想一次性做个完美的产品出来，给客户“哇”的感受。

另一方面，研发时间紧张，根本没时间思考MVP的事儿，只想快速梳理出一堆功能，试图赶紧开发完。

直到我在自己负责构建一款0-1的产品时，我发现我不懂MVP，我无法灵活地应用它，以致于没办法在关键时刻给出合理的结论。我深刻地感知到“纸上得来终觉浅，绝知此事要躬行”。

今天，我想和你分享下我对MVP的一些感悟。因为在MVP模式的指导下，我们的产品在半年后不仅有了种子客户，验证了产品的可行性；还获得了公司内部比赛的优胜奖（如下图），这是大家对我们产品的认可和鼓励。

这也让我在实践MVP的过程中，对什么才是可行的MVP产生了新的思考。

首先，我们先来看看理论中的MVP到底是什么？

MVP全称是Minimum Viable Product，也就是最小可行性产品，这是埃里克·莱斯在《精益创业》这本书中提出的理论。

在MVP产品设计理论指导下研发出来的产品具有功能极简、可被使用、开发成本低、适合快速迭代等特点。

产品以低成本快速实现核心功能后，顺势推向市场，交给用户去验证产品的可行性，通过用户访谈等方法获取用户使用的体验反馈，基于此快速迭代产品。

在我的书籍《B端思维-产品经理的自我修炼》中，我也提到过，如何在确定最小可行性范围？我们可以遵循以下原则：“少了某些功能，产品就无法正常使用，这些功能要做。多了某些功能，产品没有使用起来更好，且又增加开发成本，这些功能不做。要做满足用户刚刚好需求的核心功能点。”

MVP相比原始的瀑布式研发流程来说，可以规避团队辛辛苦苦研发完一款产品后，推向市场，市场不接受的情况。这会严重浪费资源、时间与金钱。

那么如何构建一款MVP产品呢？大约5步骤：

第一步：明确产品目标。明确做什么产品？产品解决客户哪些痛点？能给客户带去什么价值？在此之前客户是如何解决该痛点的？

第二步：梳理用户流程。围绕要解决的用户痛点，定义用户操作流程，引导用户达成目标。（这里不要忘了去和客户沟通，了解客户对你想法的大致思考）

第三步：定义产品功能。依据流程，梳理出实现用户目标需要涉及到的功能点。

第四步：功能优先级排序。根据研发资源、交付周期等情况，对功能进行排序与删减。

第五步：绘制原型图。完成碎片化功能到一个可满足客户痛点、刚需的原型图。

基本上到此，我想你对MVP有了概貌性的了解。

对于MVP，总结起来一句话，即是：“做最小单位的市场刚需产品，验证通过，则持续投入；验证不通过，则迅速调整方向。”

接下来，我将和你分享下，我在实际做产品中，对MVP的一些感悟吧。 

这个问题我在带团队研发产品中思考了不下数次，即，高保真原型算不算一个MVP？我也问了一些小伙伴，基本没有明确的答案。

为什么我会思考这个问题呢？

因为我在带团队研发一款产品的时候，研发资源不够，这就不得不促使我去思考一个问题：如何才能在开发中胸有成竹，每开发一个功能不是怀疑，而是尽可能自信。

因为资源甚少，我不希望把资源浪费在任何一个地方，一定要打到实处。

每一步都要走稳，才可以用时间换取最大成功的可能性。

后来，我看到Zappos的MVP做法后，我的思路被打开了。

Zappos是一家卖鞋子的网站。起初，创始人有个想法，想从事鞋类零售。但是假如他先拿货，再去卖，就会出现库存的情况。于是他放了鞋子的照片在网站上（实际上他没有鞋），如果顾客拍下了鞋子并付款了，他就会去购买鞋子，从而出售。

我想，或许MVP不应该是理论上的，而是基于你实际情况的。

后来，我觉得可以试试通过用原型的方式去展开我们产品的MVP。

我在启动与客户交流之前，完成了“业务流程图”、“用户行为路径”、“界面流程图”的梳理，然后约上客户，进行一对一沟通。

他们在面对以上可视化内容后，对我们团队将要做的产品就基本很清晰了，因此毫无保留地给出了他们的期望、需求、思考、想法，我也逐一进行了记录（真的是宝贵的资产）。

虽然是原型化的MVP，但说真的，已经可以测出客户的痛点、需求、偏好。

将原型作为MVP，是非常好的低成本验证方式，屡试不爽。

为什么我忽然想到这个了呢？

因为在问题1中，我发现了MVP可以是一个原型后，我就在想，是不是其也可以是一个idea。

后来，我发现了Dropbox，我的疑问迎刃而解。

Dropbox的MVP产品是一个假装准备好了产品的视频（是不是有点出乎意料）。该视频用来检验他们期望文件能在不同端上同步的想法，用户是否也同样喜欢。于是，创始人Arash Ferdowsi 和 Drew Houston设计了一段idea视频，而该视频在几个小时候被疯狂传播，并且他们收集了很多用户对此的想法与兴趣。于是，Dropbox就被研发出来了。

可见，MVP可以是一个当前不存在的产品，只要你能向用户表达清楚就可以。

所以后来，我会带着一些想得比较清楚的想法，直接去和客户聊，看看他们是如何看待这个问题的。

虽然客户不能给你答案，但是可以启发你的思路。

关于功能保留与删减的问题，也是我在做产品中慢慢想明白的。

这里我举产品中数据对象“复制”的功能。

当时的情况是这样子的：

我们产品中有一个页面，是对某种类型的数据进行管理，但这些数据对象会有被复制使用的情况。（试想下，你只想稍微修改下某篇文章的标题，发给另一个人，你会选择复制编辑，还是重写。我想大部分人都会采用复制去处理吧。）

我们在这块上投入了很多思考：包括数据对象复制那一刻是复制最新版本还是复制全部状态（对象有版本概念）；若数据对象复制到当前分类内，是否允许复制；数据对象是否可跨产品复制？等等，关于复制的一系列问题困扰着我们。

最终在MVP中，我砍掉了此功能，有以下三个原因：

第一：复制功能不是核心功能，以后加也可以。现在没有，产品核心流程依然可以跑通；

第二：复制功能要基于用户场景去设计逻辑，其不是简单的一个操作功能；

第三：即便复制功能研发出来，也未必是用户想要的复制形式。

以上，让我决定聚焦核心功能，在MVP中把一切想不明白，又不确定用户是否会真实需要的功能砍掉了。

我想，MVP中到底哪些功能要留下，哪些可以砍掉。一方面看核心流程是否因为此功能没有依然可以跑通；另一方面要看是否为必备功能（参见KANO来筛选）。

2011年微信1.0版本发布，就是MVP的典型应用。那时候的微信只有4个功能：设置头像和微信名、发送信息、发送图片、导入通讯录。

由于我们的产品比较特殊，有些功能实现起来确实难，就会阻碍MVP的展开。

此时，在MVP中又出现了一个问题，核心功能无法实现怎么破？

我举个例子。在我们的产品中需要使用到AI功能，但目前我们没有相关技能的人员，那功能如何实现呢？

于是我又想到了Zappos的MVP案例。我用其他技术方案替代了AI，先让产品流程跑通。

因为关于你产品的某个功能是不是AI实现的，其实用户压根不关心。用户的诉求就是能用、好用。

因此，我们产品的MVP中，关于AI的技术方案都用普通技术手段先去实现了。

其实，MVP中功能不能实现可以分两方面考虑：

第一：功能是否真的真的真的必须实现，即是不是没了这个功能产品无法运转了（评审过后的MVP功能也未必是仔细斟酌的功能，后期看情况是可以调整的）；

第二：若功能必须实现，那么考虑是否暂时用替代方案。

我始终相信，方法比问题多，没有解决不了的问题，只有你是否有想解决它们的坚定的心。

我在做产品中，试图去问过其他人，某些该怎么做，如何做更好。这个在MVP中要不要出现，那个在MVP中要怎么设计。

但最终发现，其实还需要回过头来多问问自己，只有你自己才知道你的产品价值主张是什么。未来要发展成什么样子。想去帮助客户解决什么痛点。为他们带去哪些价值。

我记得做第一个产品的时候，就没有考虑过MVP。小伙伴们也没有意识，那时候资源多，也就做了。

做第二个产品的时候，因为资源真的极度匮乏，不仅人少，还要求快速出结果。

所以，我不得不去考虑MVP，并在实践中调整。

有句话说：“不要自我设限。”

嗯，我觉得任何事情都一样，不能设限。我们也不要给MVP设限。

时代在变化，MVP也在进化。

最后，再对MVP做个总结吧。

第一：用MVP不是目的。目的是在最少的时间里验证你的假设，接着有规划的去做。

第二：MVP可以不是一个让用户去鼠标点点操作的产品，任何能说清楚产品价值的对象都可以成为MVP（要达到可验证的目的）。比如投票调研、众筹方式、看似真产品的假产品（如上“Zappos的MVP”案例）。

第三：MVP需要体现产品的独特价值主张。不因为现在是MVP而随意搞（就如不因为他是个儿童，而不关注其长期成长的价值）。它是谁？它要解决什么痛点？它的未来朝向哪里？都是需要去关注的。

本文来自微信公众号 “知果日记”（ID：gh_690a8b6479cb），36氪经授权发布。