关键词:MVP

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

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

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

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

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

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

今天,我想和你分享下我对MVP的一些感悟。因为在MVP模式的指导下,我们的产品在半年后不仅有了种子客户,验证了产品的可行性;还获得了公司内部比赛的优胜奖(如下图),这是大家对我们产品的认可和鼓励。
我对B端产品MVP的5点感悟与3点总结(实战版) - 图1

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

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

MVP的概念定义

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

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

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

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

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

如何构建MVP产品

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

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

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

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

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

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

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

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

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

—— 1 ——

MVP一定要研发出来吗?一个高保真原型算不算?

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

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

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

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

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

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

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

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

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

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

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

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

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

—— 2 ——

MVP一定要研发出来吗?一个说的清楚的idea算不算?

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

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

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

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

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

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

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

—— 3 ——

MVP中到底哪些功能要保留?哪些砍掉?

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

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

当时的情况是这样子的:

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

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

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

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

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

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

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

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

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

—— 4 ——

技术无法实现MVP中的功能怎么办?

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

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

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

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

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

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

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

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

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

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

—— 5 ——

你的MVP只有你自己知道,多问自己为什么要做它。

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

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

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

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

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

最后的话

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

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

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

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

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

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

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