生于MVP，死于PMF
本文的主要内容会按照是什么、为什么以及如何做的逻辑展开，主要包括以下几部分：
- 什么是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呢，倡导先开发一款具有基本功能和吸引力的产品，立即投入运行，视市场的反馈来决定是继续还是转型，有效地降低了风险、而且能及时获取用户反馈。更具体的内容，请看《如果你有一个创意》。
上一篇文章算是对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；如果产品开发不复杂，如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;
