码迷,mamicode.com
首页 > 其他好文 > 详细

生于MVP,死于PMF

时间:2018-11-11 23:34:53      阅读:272      评论:0      收藏:0      [点我收藏+]

标签:.so   -o   活动   prototype   告诉   空间   故事   ges   复杂度   

本文的主要内容会按照是什么、为什么以及如何做的逻辑展开,主要包括以下几部分:

  • 什么是MVP与PMF;
  • 为什么要有MVP与PMF;
  • 如何创建MVP;
  • 如何验证PMF。

什么是MVP与PMF

MVP(Minimal Viable Product),意思是最小可行性产品。即通过一个最小化、却可以满足核心需求的产品来测试市场的反应。

为了能更好的理解MVP的概念,可参考下图。

技术分享图片

PMF(Product/Market Fit),意思是产品符合市场需求,这个概念最早出现在马克·安德森2007年的一篇博客,他在文章中这样定义“在一个好的市场里, 能够用一个产品去满足这个市场”。

为了能更好的理解PMF的概念,可参考下图。

技术分享图片

以一个简单的例子来说明下MVP与PMF,抛开市场分析、竞品分析、产品定位等不谈,仅从MVP与PMF的角度来说明一下。

你看到身边有不少人穿着有特定图案的T恤,比如漫画人物、表情包、有趣的文案等,于是蹦出来一个念头,要不做一款支持自定义创建T恤图案的产品?

那首先需要验证的就是用户是否真的有这个需求,我们应该用什么样的解决方案来满足,我们的MVP可以只给一个简单的展示网页,交易走微信/支付宝转账,商品从淘宝上买,然后发给买的人…

之后需要验证的就是用户是否愿意埋单,有多人会来买,客单价是多少,复购率是怎样的等等…这就是PMF的验证,即达成了什么样的标准证明了我们的方案是可行的,

换句话来说,MVP是你在发现某个问题之后给出的一个解决方案,而PMF则是看这个解决方案用户愿意不愿意埋单。

为什么要有MVP与PMF

说完了是什么之后,简单的说明下为什么要这么做。

需求不一定存在

下图为2015年CB Insights总结的146家失败初创企业的20大原因,可以看到高居前三位的分别是没有市场需求(42%)、没钱了(29%)、团队不合适(23%),从中可以看到没有市场需求的占比高达42%。

技术分享图片

需求本身已经不存在了,那解决方案就很难被用户接受了,更不要说用户会为解决方案埋单了…

资源永远是有限的

资源永远是有限的,不管是创业公司还是大公司,一方面公司总会有基于现状更大的野心,也就需要更多的资源,另一方面资源是公共的,可能会有其他的团队来争夺。

所以,相同的资源为什么不放到性价比更高的项目上去,而且做这个事情还有机会成本。

窗口期越来越短

窗口期变得越来越短,也就意味着留给你犯错的空间越来越小,试错的成本也越来越高,甚至你的一个错误就可能给竞争对手带来反超的机会。

有时候你赢了可能并不真的是你赢了,可能只是你的对手都输了…

产品生命周期规律

产品本身是有着自己客观发展规律的,就是我们通常说的“S曲线”,从探索期到成长期,再到成熟期、衰退期…

MVP与PMF的思想是和产品规律相吻合的,MVP主要对应的就是探索期的阶段,先不断的探索可行性。

PMF对应着的就是探索期与成长期的临界点,验证了PMF之后就可以进行大规模的推广了,帮助产品快速达到成长期。没有被验证可行的产品/模式强行进行推广的话,甚至可能会起到反作用。

上面絮絮叨叨说了那么多,都是在说明MVP与PMF是什么,以及为什么要这么做的,下面就来看下如何做。

如何创建MVP

既然MVP指的是针对问题的解决方案,那方案就要明确是解决什么人在什么场景下的问题,同时和现有的一些解决方案相比,有什么优势…

下面按照产品从需求到方案的流程来说明下如何创建MVP。

用户、场景和需求分析

首先要明确产品是要解决什么人在什么场景下的什么问题,用户的表层需求是什么,深层需求是什么,更底层的需求是什么。

定义产品方案

之后要明确方案的方向是什么,比如多快好省这几个维度选择哪个点进行切入,不同的方向,需要做的事情是不同的。

这部分涉及到产品的定位,决定着后续的具体实现路径。

用户行为流梳理

根据用户的目标和任务梳理用户为了达成目标需要完成的子任务,然后按照相应的顺序进行组织。

比如在互联网在线教育产品里,用户最终的目标是学习知识,为了实现这个目标,用户要来选课、上课。那整个主线行为流就是浏览课程》下单购买》支付》课程学习。

功能罗列

结合上两步中的产品方案、用户的行为流来梳理对应的功能模块,可以先按照用户的行为流将所有可行的功能先列举出来。

下图为最近罗列的一个互联网在线教育App的一个MVP版本示意图,背景不再说明,仅作参考。

技术分享图片

定义优先级

首先需要明确优先级的标准是什么,然后再来确定优先级,我一般会从使用人数、使用频次和重要程度这几个维度来进行评估。

还有其他很多的评判标准,比如目标贡献度、紧急程度、实现难度等等,选择合适的标准,达成共识之后,再按照这个共识来定义就好。

明确MVP版本功能

最终就是结合优先级明确下来MVP版本需要有哪些功能,这里面有几个原则可以参考一下:

  • 一次最好只解决一个主要问题;
  • 优先保证主流程能够走通;
  • 活动或者H5先行,最后再产品化。

如何验证PMF

这部分就是如何验证产品达到了PMF的标准了,在产品上线之前就应该有一个预期目标,达成了目标可视为已找到PMF的点。

市面上目前常用的方式有两种,一种是通过定量的数据指标验证,一种是通过定性的用研结果验证。

定量验证

这组参考数据指标来源于Andrew Chen,在网上或者其他一些书籍里面也能够看到它的身影。

Andrew Chen是硅谷的创业者,之前领导过Uber的增长团队,还为湾区的数十家创业公司提供过咨询和投资…

用户级产品标准

  • 每周使用天数超过3天
  • 初始日新增用户(DNU)超过100
  • 30%新用户次日留存率
  • 达到10万用户量

Saas产品标准

  • 5%付费转化率
  • LTV/CAC>3,即用户生命周期价值/获取成本>3
  • 月流失率<2%
  • 月销售流水达到10万元

这些数据指标在不同行业、不同业务模式的产品中对应的数值应该是不同的,核心思想在于需要找到一些关键的数据指标,然后通过数据指标来判断产品是否达到了PMF的标准。

定性验证

这个方法又叫做Sean Ellis 测试,测试的方法是告诉现在的用户“你们今后无法再使用这个产品了。”如果有40%的人对此表示“非常失望”,那么你的产品就达到了PMF。

Sean Ellis是最早提出增长黑客理论的人,在 Dropbox 任职期间,践行着他自己的这套理论,曾经用一年的时间把用户的基数和使用频率提高了500%...

需注意的是,这个测试方法最好采用问卷调查的形式,并且回收的有效问卷的数量最少在40-50份,而且选择发送问卷的用户必须是使用过产品的核心功能,且最近2周还在活跃的用户,不然问卷的结果可能会存在偏差。

 

一日一日又一日,又到一周发文时。上次介绍了一个概念,MVP(Minimum Viable Product,最小可行产品),不知道大家还有多少印象。忘了没关系,先来复习一下。

 
技术分享图片
(传统方法和MVP对比,图片来自网络[1])

传统的产品开发流程,先定义最终产品,然后逐步进行开发测试上线,这通常需要花费数月甚至数年的时间。当投入使用后,才知道产品是否和市场契合,用户是否喜爱。如果失败了,则浪费大量的人力物力财力。而MVP呢,倡导先开发一款具有基本功能和吸引力的产品,立即投入运行,视市场的反馈来决定是继续还是转型,有效地降低了风险、而且能及时获取用户反馈。更具体的内容,请看《如果你有一个创意》

 
技术分享图片
(MVP示意,图片来自网络[1])

上一篇文章算是对MVP做了简单介绍,这篇文章打算讲一讲MVP和原型(prototype)的区别。

位于硅谷的Dropbox公司开发了一种非常简单易用的文件分享工具,可以在多个设备间共享文件。初创之时,由于技术限制等原因,暂时无法开发可操作的产品来验证想法,CEO Drew Houston想出一招,他拍摄了一段3分钟的视频,以演示软件使用情况,结果视频吸引了几十万人访问他们的网站,公测版等候名单一夜间从5000人增加到了75000人[2]。现在的Dropbox是什么情况呢?不说市值,就说一个情况:Dropbox目前共有38位厨师,而且不止一位曾经在米其林餐厅工作[3]。

斯坦福的一个创业团队打算在无人机上安装高清摄像头,拍摄(每一颗)农场作物的病害、施肥和灌溉情况。农场主可以根据采集并经过处理的数据来决定如何更好地播种,团队则可以通过销售数据来盈利。创业者们本想先购买无人机、超清摄像头、图像处理软件,然后花费数月时间来进行开发整合。但是Steve Blank(Steve Blank和下文的Eric Ries均为MVP推广者)的建议是:既然团队目标是想确定农场主是否愿意购买数据,而农场主并不关心数据是来自卫星、无人机或者魔法,那么,只需要租借一个手动控制的飞机模型、安装上普通相机,然后飞跃农场拍摄、手动处理数据,再验证农场主是否愿意为这些信息付费即可[4]。

以上两个事例,哪一个是MVP,哪一个是原型呢?它们似乎都是为了验证初创团队的想法和测试用户的反应,二者有何不同?先说明一下,在知识的掌握上,我是奉行“无招胜有招”的,就像张三丰问张无忌,刚刚教你的太极拳记住了吗?张无忌答道,已经忘记了(然后便以“无招”大获全胜)。这里要区分MVP和原型,主要是希望大家认识到此处有歧义,注意到不清晰的定义无益于沟通,了解到融会贯通、为我所用的前提是理解准确。

想象一下,小花(甜点师兼创业者)的老公小草(互联网从业者)一时兴起,给小花普及了MVP,小花听得心潮澎湃,对小草说,她也要做MVP,然后让老公带去公司宣传。于是,小草通知同事们不要吃早餐,等他老婆的糕点。第二天一早,小草拿着小花包装好的精美礼盒去到了单位,在饥肠辘辘的同事面前拆开后,但见盒里躺着一本精美的相册,相册中罗列着小花制作的各种糕点照片,却哪里有蛋糕的踪影?小草只能报之以一脸尴尬。之后小草责备小花,说好的MVP呢,为什么是本相册?小花委屈道,照片就是MVP呀,Dropbox的MVP不就是一段视频么?小草心有不甘,却也无言以对,毕竟他们两都没错,问题在于各自理解的偏差。诚然这情节是虚构的,但是团队如果对概念理解不统一,将可能造成比故事中更严重的后果。

在MVP相关文章和书籍的例子援引中,几乎是不区分MVP和原型的,就连Steve Blank说的也是“原型MVP”(prototype minimum viableproduct);Eric Ries则将原型归类到MVP中,在他看来,P不一定必须是切实可行的产品,只要能以最快的方式、最少的精力完成“开发-测量-认知”的反馈循环即可[2]。而Marty Cagan(《启示录》作者)认为Eric Ries的MVP其实是测试具体假设的最小可行实验,称作“MVP测试”更为恰当,这样可以避免混淆“实验”和真实“产品”[5]。这里的“MVP测试”其实就是原型。

在《Managing Software Requirements:A Use Case Approach》一书中,不止一次提到原型是应该用完即弃的,是个一次性的玩意儿。在日常项目中,也都是用Axure等工具进行高保真原型开发,而真实产品开发则是另起炉灶。原型和产品隔离,一方面可以加速原型开发、激发创意,另一方面可以提高产品稳定性,因为避免了通过对原型进行修修补补来制造产品。而MVP呢?是最小可行产品,也是第一代产品,是可以让用户使用的产品——尽管功能不丰富。原型背后的逻辑都是软件模拟的、是假的、用户是不能真正用其解决问题的,它只是看起来像真的而已。因此,在上文的两个例子中,Dropbox的视频是原型,Steve Blank建议的遥控飞机是MVP。

 
技术分享图片
(原型和MVP比较)

知道了原型和MVP的区别,那么我们是不是需要在验证创意的时候犹豫用哪个呢?其实大可不必纠结在概念上,还是那句最实用又最没用的话,视情况而定。当然,通用原则还是有的:如果产品复杂度高,那么建议先尝试原型、再开发MVP;如果产品开发不复杂,如Unsplash(例子可以看《如果你有一个创意》),那大可以直接产出MVP。再次强调,不要在区分概念上钻牛角尖,区分的目的是在于更好的交流讨论和融会贯通。无论是MVP还是原型,又或是MVP测试,认准了,就动手吧!

【花事】

在为本周文章搜集材料时,看到一些有关Apple的轶事,忍不住又写了一段题外话:

神秘的Apple

每一次iPhone的发布,都是各种“内部消息”“揭秘”类资讯大火的时刻,就拿iPhone 8来说,前置指纹识别、后置指纹识别、侧面指纹识别,以及没指纹识别(人脸识别代替指纹),各种说法都煞有介事,吃瓜群众也纷纷捧场。正是Apple这种接近神秘的保密举措,吊足了大众胃口,才引起了各种猜测——从产品的猜测到运作的猜测。据说,早在1977年,当Apple还是一家初创公司时,在大厅里就有一块写着“言多必失”(loose lips sink ships,直译是“口风不紧船舰沉”)的告示牌。因为作为一家硬件公司,Apple知道如果新产品细节被泄露的话,会危及到现有产品的销售,所以Apple在早期就已经把保密作为企业文化。Apple不允许员工告诉合作商他们当前的工作;不允许无关人员参加会议,以至于在一个会议中,当下一个主题与你无关时,你将会被邀请离开;实验室中的未发布产品都用黑布盖住,以免被不相关的人员看到[6]。更有甚者,API名称都会伪装,在iPhone 5S发布以前,iOS7 beta版已经发布了一段时间,为了防止其他开发者通过iOS接口名称提前知悉iPhone 5S的静止图像稳定功能,于是相关的接口名称:

(BOOL)isStillImageStabilizationActive;

被伪装成了[7]:

(BOOL)isYoMamaWearsCombatBootsActive;

生于MVP,死于PMF

标签:.so   -o   活动   prototype   告诉   空间   故事   ges   复杂度   

原文地址:https://www.cnblogs.com/dadadechengzi/p/9943472.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!