1. 大多数人理解的MVP其实是半成品先聊一个我在不少产品社群和创业活动里反复看到的现象一说要做MVP团队的第一反应往往是那我们先把功能砍到最少尽快上线一版。于是大家开始删需求、砍页面、去掉所有不必要的按钮最后做出一个功能少得可怜、界面粗糙、很多流程根本走不通的版本然后硬着头皮推给用户。用户用完反馈一堆问题团队又用这是MVP本来就不完整来安慰自己。这个循环我见过太多次了它的问题不在于MVP这个理念本身而在于大家对MVP的底层理解从一开始就偏了。MVP全称Minimum Viable Product中文常翻译成最小可行产品。注意关键词里有可行没有这个词整个概念就塌了一半。它强调的是你交付的产物能够闭环地验证一个核心商业假设让用户在真实场景里完成一次完整的价值体验而不是把功能数量压到极限的半成品。说得再直白一点MVP不是功能少的产品而是用最低成本、最快速度造出一个能验证核心问题的产品。做个类比可能更好理解。你想验证大家愿不愿意在有雾霾的天气里买个便携空气检测仪这个需求最低成本的做法不是先研发一款带屏幕、带App、带历史记录、带社区分享的智能硬件而是先做一个能显示实时PM2.5数值的小方块甚至可以用现成的传感器模块加一个数码管就搞定。用户拿到它能感知到原来我办公室的空气这么差并愿意为这个感知掏钱核心假设就被验证了。如果你上来就做完整产品三个月后才发现用户其实根本不关心数据可视化那这三个月的时间、人力和钱全部白费。所以这里要先立住一个对MVP的正确认知框架后面所有实操方法都建立在这个框架上。我把它拆成三层最小Minimum不代表功能最少而代表成本最低、链路最短、风险最小的验证路径。这里的小是手段不是目的。可行Viable指的是这个产品必须能独立解决一个真实问题用户用了之后能明确感知到价值而不是能跑起来就算赢。产品Product它依然是一个面向用户的交付物要有完整的使用体验闭环哪怕这个闭环是通过人工在后台补位完成的。这三层里可行最容易被忽视也最致命。我见过不少团队花小成本做了一个很粗糙的页面放了个很长的表单用户填到一半就放弃了。你问他为什么做这个页面他说这是MVP先验证有没有人愿意填表单。问题在于这不是验证需求这是在测试用户的耐心。用户放弃的不是你的产品而是那个体验极差的流程你根本得不到任何关于需求是否成立的结论。换一个角度来理解。MVP的价值不在于它够不够多而在于它能不能帮你学到东西。每一版MVP都是一个实验装置你的目的不是造一个完美的东西而是设计一场能够给你清晰信号的社会实验。判断MVP做得好不好标准不是功能都上了吗而是这个版本能让我对用户的认知有一个确定的进步吗。如果答案是不能那这个MVP无论功能多少都没有意义。2. 动手之前先想清楚你要验证的到底是哪个假设我见过太多人做MVP的姿势是这样的脑子里冒出一个想法马上画原型找开发排期两三个月后做出来然后发现没人用。整个过程非常努力但唯独漏掉了最前置的那步——你的想法背后到底藏着一个什么样的核心假设所有产品想法本质上都包含几个层次的假设你要验证的重点不同MVP的做法就完全不同。第一个是需求假设用户是不是真的有这个问题这个问题是不是足够痛、足够频繁第二个是价值假设如果给你一个能解决这个问题的东西用户愿不愿意付出成本去换取这里的成本可以是钱、时间、注意力和行为改变。第三个是增长假设即使前面两点成立产品能不能形成口碑传播、复购或者自增长不分清这几点你就容易做出一版什么都想验证结果什么都没验证清楚的MVP。举一个我在文章里常见的例子假设你想做一个帮宠物主人找临时寄养家庭的平台。需求假设是很多宠物主人出差时找不到靠谱的寄养服务价值假设是宠物主人愿意为了省心和安全付费增长假设是体验过的人会主动推荐给同样养宠物的朋友。针对需求假设你甚至不需要做产品花几天时间去做用户访谈就够了。你只需要找到20个近半年内出差超过三天的养宠人问他们当时是怎么安顿宠物的卡在哪个环节花了多少钱还有没有下次再遇到同样问题。如果20个人里有18个人说都是找朋友帮忙实在不行就送去宠物店价格贵但也没办法那这个需求是真的如果问下来发现大家觉得寄养这事麻烦是麻烦但能忍你就要谨慎了。针对价值假设你需要一个更接近真实产品的验证方式。可以是做一个简单的预订页面放几张寄养家庭的照片和价格用户填写预订信息后你在后台手动完成后续对接。用户愿意走完这个流程并在付款环节没有明显犹豫价值假设就初步得到验证了。但很多人容易在这里犯一个错误把验证需求假设和价值假设混在一起。他们直接做了一个完整版平台又是地图、又是即时聊天、又是电子合同、又是订单追踪然后期望用户来用。结果上线后用户量寥寥无几你很难判断到底是因为这需求是伪需求还是因为你的产品太难用了。一个精心设计的MVP应该每次只验证一个核心假设这样无论结果如何你都能获得一个明确的信号。还有一个很多人忽略的关键动作在动工之前把验证成功的标准写下来。没有成功标准MVP上线后的数据就会陷入公说公有理、婆说婆有理的境地。你说转化率3%不错他说太低了你说只有10个人付费他说已经比想象中好了。请你在做任何东西之前白纸黑字写下这样三句话这个MVP上线后在30天内要有多少个人完成注册这中间要有百分之多少的人走到关键行为最理想的情况是有多少人愿意为此付钱。只有把这些数值提前定死MVP上线后你才能用达标/未达标来下结论而不是靠感觉。这里给新手一个参考模板可以用来设计自己的验证标准核心假设写一句我认为____用户有____需求他们愿意通过____方式解决并为此付出____成本。成功指标至少一个定量指标比如40%的访客愿意留邮箱一个定性指标比如访谈中超过一半人主动问这个什么时候能用。验证周期给MVP限定一个时间窗口建议2到4周时间太短数据不充分太长成本失控。预判结果提前写下你预测的数字MVP上线后拿实际数据跟预测对比差异本身就是最有价值的学习素材。这套准备工作看起来不产生任何代码或页面但它的价值远远超过后面几个月的开发工作。我在实际辅导项目时经常让团队先只做这张纸不做产品。多数人写着写着就发现问题了要么核心假设描述得太模糊要么成功指标定得太主观要么根本说不清楚用户在什么场景下触发需求。这些问题如果在动工前没想清楚做出来的MVP基本是白做。3. MVP落地的四步实操法从想法到能拿去测试前面的部分把想清楚讲透了接下来这部分直接讲怎么动手。我把MVP从想法到上线的落地过程拆成四个步骤这套方法我自己在多个项目里用过也给不少团队做过引导整体流程相对固定新手可以直接照抄。3.1 第一步做减法之前先做一次需求穷举很多人一上来就砍功能这是顺序错了。真正该做的第一件事是把你脑子里的所有功能全部列出来不要管技术难度不要管成本先追求穷尽。你可以在纸上画一张草图把自己能想到的用户从接触产品到完成核心目标的整条路径写下来每一个接触点都可能成为一个功能点。举个例子还是拿宠物寄养平台来说。你能想到的可能包括用户注册登录、宠物档案管理、寄养家庭搜索、地图定位、寄养家详情页、在线聊天、价格计算器、在线支付、订单管理、评价系统、客服中心、售后保障、分享邀请。先全部列出来这一步不用做判断。然后对每一项功能问三个问题它是不是用户完成核心任务所必需的它是不是能直接影响用户决定用还是不用这个产品的如果去掉它用户解决核心问题会不会受影响基于这三个问题把所有功能分成三组必须保留、暂时可以人工处理、直接砍掉。关键点在于第二组它特别容易被忽略。很多看起来必要的功能其实在上线初期可以通过人工后台来顶替根本不需要开发。这恰恰是MVP最巧妙的地方——用人工模拟那些还没有被验证过的功能等验证通过了再考虑用技术手段把它自动化。这样既保证了用户流程的完整性又把开发成本压缩到了极限。3.2 第二步按风险顺序确定MVP形态功能梳理完之后你就需要决定用什么形式来做这个MVP。这里有一个非常重要的原则MVP的形态不是只有做一个能用的产品这一种不同阶段、不同假设适合的形态完全不同。常见的有下面几种我按照成本从低到高排列宣传页/落地页只做一个介绍产品价值的页面配上一个我要预约或获取内测资格的按钮。这适合验证用户对价值主张的兴趣程度。你的核心指标就是访问量和转化率如果投放一点流量过来点击预约的比例低得可怜那说明价值主张还没被用户买账。假门测试Fake Door在某个已有流量的页面放一个看似能点的功能入口用户点击后发现还没开放可以留下邮箱。这适合验证用户对新功能的真实需求。邮件/社群手动服务不建任何产品只通过微信群、邮件或私人号提供人工服务完整地走一遍你设想的产品流程。这适合验证服务的需求强度和用户的工作流。单品功能版只做那个最核心的功能其他一切靠人工和周边工具辅助。这适合验证单点价值能不能成立。众筹页面把产品做成一段演示视频用众筹来验证购买意愿。这适合硬件类、实物类产品。很多新手会直接跳到最后一种做一个能跑起来的App这是最大的误区。请记住MVP的形态选择不是根据最终产品会是什么样子来定的而是根据现在最需要消除哪个不确定性来定的。3.3 第三步用最短路径造出第一个可用版本确定了形态之后就到具体执行这一步了。这里给新手三条建议能大幅降低落地难度。第一条把眼界从开发一个系统放宽到组装一套流程。你能用的素材比想象中多得多现成的表单工具可以做需求收集设计工具可以做出高保真原型低代码平台可以快速搭出带数据库的后台个人号加表格就能管理线下服务流程。MVP阶段不需要任何东西都是自己写的。第二条做一个有人工参与的自动化。最理想的MVP组合是用户看到的产品体验尽可能接近最终形态但背后所有复杂环节都由人肉先顶上。比如你是做在线订餐的上线初期完全不需要接支付系统用户下单后你手动给他发一个收款码不需要做配送追踪你手动发消息告知进度。这不丢人这叫用人力换学习速度。第三条压缩交付周期。一个MVP从决定做到上线我建议的最长时限是6周。超过这个时间要么是你做的功能还是太多了要么是你选择的技术方案太重了要么是你根本还没想清楚核心假设。1到2周的MVP比比皆是关键在于你敢不敢把那些觉得很重要但其实是锦上添花的部分先放掉。3.4 第四步带着学习目标去收集反馈MVP上线的第一天你的角色就从建造者切换成观察者了。这时候最重要的不是盯着后台数据看好坏而是带着第二步写下的验证问题去找真实用户聊。建议你用快速回访的方式在用户完成核心操作后的24小时内找到他问三个问题——刚才你在使用过程中哪一步让你觉得最顺畅哪一步让你想放弃如果明天这个产品就消失了你会觉得遗憾吗第三个问题尤其重要它直接测出产品在用户心里的不可替代性。我在陪跑项目里发现一个规律很多团队在MVP上线后的第一周会陷入数据低迷的焦虑但真正和用户聊过之后他们得到的启发远比看数据多。因为早期MVP的数据量本来就少统计意义不强但用户的原话里藏着大量原来他们是这么想的的瞬间。这些瞬间才是指引下一轮迭代的真正路标。4. 新手做MVP最容易翻车的5个坑理论和方法讲完了这部分专门讲坑。这些坑几乎每个新手团队都会踩一两个而且很多都是用的时候完全不觉得是坑事后回头看才发现问题很严重的类型。我把它们单独拿出来讲希望大家提前看到。4.1 坑一把MVP当成降低预算的工具这是最常见、也最隐蔽的坑。很多团队做MVP的动机不是我想快速验证一个想法而是我只有这点钱/这点时间所以只能做个简单的东西。一旦你带着穷的心态去做MVP你一定会做出一个廉价感十足、用户根本提不起兴趣的东西。MVP应该被视为一种学习策略而不是省钱策略。它的核心价值是让你在确定需求是否成立之前避免过早投入大量资源。如果你的做法的确达到了这个目的那它是成功的如果你只是把一个不完整的方案扔给用户然后省了钱那这个MVP是失败的。因为省下来的钱全部变成了时间成本和用户信任的损失代价更大。我给几条判断标准你可以对照检查自己是不是掉进这个坑了用户拿到产品后第一反应是这是什么还是这个东西挺有意思用户的使用过程里是否有超过一半的人在有帮助的情况下依然中途放弃你的团队在内部讨论时提到这个版本用的词是先凑合还是刚好够用如果你发现答案是前者那你要警惕了。4.2 坑二功能确实是少了但核心链路是断的有一类团队很听话确实把功能砍得很少砍到用户进来之后走不完整个流程。比如做了个点餐产品用户看完菜单、选完菜但下单按钮是开发中比如做了个健身计划产品用户设置好目标后生成的计划只有一天的量。这种MVP是最让用户生气的因为它给人的感觉是你让我来用但根本没准备好。MVP的小必须建立在一个完整闭环的前提下。这个闭环可以很短但不能断。所谓闭环指的是用户从第一次接触到完成核心价值体验的整个过程是流畅的。哪怕这个流程只有两步这两步必须是通顺的。如果有些环节你暂时没法用技术实现就用人工顶上坚决不能让用户卡在半路。我自己的判断标准很简单如果你不好意思把这个MVP拿给朋友或家人当面演示完整流程那它还不能上线。注意关键词是完整流程不是完整功能。4.3 坑三没有测愿不愿意付钱只测了喜不喜欢很多团队做完MVP兴冲冲地拿给朋友看朋友都说不错挺好的如果出了我一定买。他们信以为真结果上线后销量惨淡。原因很简单朋友说喜欢不付出任何成本真正的付费才是用户用自己的真金白银投票。MVP在早期阶段可以测很多指标但如果你想做一个商业产品最终一定要测到用户是否愿意付出真实成本这个层面。这里的真实成本可以指钱也可以是时间、隐私或行为改变。比如你做一个信息聚合产品让用户手动把其他平台的账号授权给你就是一种付出成本的行为你让用户把原来的习惯改了迁移到你的产品上这也是成本。如果MVP阶段完全不敢触碰任何用户付出的环节你验证出来的需求很可能是虚假繁荣。我见过太多团队在产品做得很好、口碑也不错的情况下倒闭原因就是始终没有人愿意为它掏钱或付出关键成本。4.4 坑四没有定义失败的标准这个坑在前面第2部分已经提过但因为太重要这里再展开一次。我观察到一个现象如果团队在MVP上线前没有写下失败标准那他们几乎永远不会承认这次验证是失败的。为什么因为人天生倾向于给自己的行为找合理化解释——数据虽然不好但可能是渠道问题虽然没人付费但说明我们品牌还没打出来现在市场环境不行再等等看吧。你会发现没有失败标准就永远有借口。而创业里最贵的不是试错是在明显已经跑不通的路上继续消耗。所以在MVP上线前你必须明确写下如果XX数据在XX时间内没有达到XX这次验证就是失败的我们会选择调整方向或停止投入。这句话写得越具体越好。有人可能会担心标准定得太死会误杀好项目。我的回应是如果你连明确定义失败的能力都没有说明你对这个项目的核心逻辑还一无所知那它根本还没到值得继续大规模投入的阶段。MVP的学习价值恰恰就藏在我原本以为会达到X结果只有Y的落差里。落差越大学到的东西越多。4.5 坑五MVP周期拖太长验证结果已经过期最后一个坑是MVP做得太久了。这里的太久不只是绝对时长还包括验证的时机已经错过。比如你想测试春节期间宠物寄养的需求却等到3月份才上线MVP这时候用户刚经历过需求高峰反馈就不准了。又比如你基于某个热点话题做产品热点过了MVP才上线数据完全失真。更隐蔽的问题是MVP周期太长会导致验证疲劳。团队在开发过程中投入了大量精力心态上已经认定这事能成很难再客观看待上线后的数据。很多团队做MVP做到后来不是想验证而是想证明自己之前的选择是对的。这种心态一旦形成再好的验证方法也失灵了。我建议新手给MVP设定一个硬性的截止日期这个日期一到无论功能是否做完都必须拿当前版本去测试核心假设。如果你发现功能还没做完导致没法测试那恰恰说明你违反了第4.2条提到的闭环原则。在MVP这件事上速度本身就是一种验证指标如果你连快速做出一版可用产品都做不到那后续的迭代速度大概率也跟不上。5. 真实案例拆解做对了的和做翻车的案例是所有方法论最好的检验。这个部分我选了四个典型的MVP案例前两个是正确的示范后两个是翻车现场每个案例都能印证前面讲过的某个关键原则。5.1 做对示范一Dropbox的演示视频Dropbox正式推出产品之前创始人做的其实是一个3分钟的演示视频而不是一个能同步文件的软件。视频里演示了一个正在实现中的产品拖拽文件进文件夹自动同步到其他设备。这个视频被发布到科技论坛后一夜之间带来了几万人的注册等待名单。注意这才是MVP的教科书级操作。他们选择的形态是演示视频成本极低但验证价值极高。视频验证了三个关键假设一是确实有人有多设备同步文件的痛点二是用户看完视频能理解并相信这个解决方案三是用户愿意为此注册并排队等待。这个案例里最关键的学习点是他们完全没有做一个真实可用的产品却完成了最有价值的验证。因为最需要验证的这个需求到底痛不痛靠视频就能得到答案没必要花几个月把产品写出来。等到注册名单数量证明了需求之后他们才开始投入做真正的产品。5.2 做对示范二Zappos的人工代购验证Zappos这家卖鞋的网站今天看来是一家大型电商公司但它的起点非常草根。创始人的MVP是他去附近商场拍了一堆鞋子的照片挂到网站上如果用户下单他就去商场把那双鞋买下来再寄给用户。这套流程里网站、库存系统、物流体系、支付系统一个都没有。他用的就是前面说的人工模拟方法。但你可以看到用户在那个网站上体验到的流程是完整闭环的——浏览、选购、下单、付款、收货。唯一的区别是后台的履约全凭创始人自己跑腿。这个案例完美验证了价值假设用户确实愿意在网上看到鞋子并下单买鞋。等到订单多了、模式被验证了他才开始与品牌方谈库存合作逐步搭建仓储物流。如果一开始就学传统零售商压几百万库存来做电商那么即使模式是通的也大概率被现金流压力压死。5.3 翻车现场一功能全上、周期半年的智能硬件App这是一个比较典型的新手团队案例。一个做智能手环的团队花了半年时间做了配套App里面包括健康数据图表、运动计划、社交排行榜、勋章系统、社区动态、在线课程等十几个模块。App做出来后团队发现核心用户经常使用的功能其实只有两个看心率数据和记录跑步距离。其他百分之八十的功能开发投入巨大但启用率连百分之二都没有。这半年时间和几十万开发成本里绝大部分是浪费的。他们完全可以只做连接手环看心率跑步记录这一个最小闭环用三个月甚至更短时间上线先把用户愿不愿意戴着手环跑步这件事验证清楚再考虑要不要做社交和社区。翻车的原因就是我在第4.1条里说的把MVP当成省钱版的完整产品而不是验证核心假设的最小实验。团队不是没做MVP而是做一个功能变少但结构没变的半成品。用户来看一眼感觉信息很丰富但不知道干嘛就流失了。数据证明不了任何有价值的结论。5.4 翻车现场二样样都想验证的平台类产品另一个很常见的翻车模式是把做一个平台作为MVP的目标。有个团队想做一个连接自由职业者和创业公司的兼职平台他们计划的功能包括需求发布、智能匹配、在线沟通、项目托管、支付担保、评价体系、发票管理。开发计划整整排了八个月。问题出在这个团队想在一个MVP里同时验证自由职业者有没有接单需求创业公司愿不愿意在线上找自由职业者双方愿不愿意用线上工具完成交易平台抽成能不能被接受这四个完全不同的假设。每个假设都没法通过同一个版本获得干净的验证信号。更致命的是在线支付担保和评价体系这类功能本身就是拉动平台信任的基础设施做不好用户流失但做好了其实不代表需求成立。他们应该做的是先选一个细分场景比如PPT设计需求的对接用人工方式连接几个设计师和几个需求方自己充当客服和匹配者亲身体验整个交易流程。通过这几十单去感受真实的需求强度、价格敏感度和交易阻碍。如果这些最基础的东西都没验证清楚一上来就做全功能平台等于把整个产品置于一个巨大的假设之上任何一个假设不成立整个大厦都会塌。把这两个翻车案例放一起看你会发现一个共性他们做的东西其实都不难难的是他们根本没有定义清楚要验证什么。所有功能都是凭想象堆出来的这就导致开发投入越大验证效果越差。6. MVP跑通之后数据怎么看、下一步怎么走如果你已经按照前面的方法做完了一个MVP并且拿到了真实的用户反馈恭喜你你已经比大部分停留在幻想阶段的团队走得远了。但接下来这一步同样关键也很少有人讲清楚MVP的数据回来了到底该怎么解读下一步往哪走首先要区分两种MVP验证结果。一种是信号明确型就是你预先设定的核心指标清晰地指向了某个方向比如注册转化率远超预期或付费意愿接近于零。另一种是信号模糊型就是数据不上不下看看好像有人用但活跃度不高说没人用吧又还有几十个人每天在访问。大多数团队的情况是第二种但这恰恰是最考验产品判断力的地方。面对模糊信号我建议你做三件事。第一回来重新看当初写的核心假设描述看它是不是太模糊了。很多时候不是MVP失败了而是你当初想验证的那个假设本身就没说清楚用户的行为自然无法给你一个明确的答案。第二去做定性回访数据没给你答案用户的原话大概率能给你。找到那几十个还算活跃的用户一个一个聊问他们用这个产品的场景和动机。第三重新检查你的成功指标定的是否合理有些产品早期不适合用付费率衡量应该用留存率或邀请率。当验证结果出来之后下一步一般有四个走向。第一个走向是坚持加优化如果核心假设成立、数据达标那就继续把MVP里的人工环节逐个自动化把体验打磨到可以规模化。第二个走向是局部转型如果产品整体不太成立但某个功能、某个用户群或某个场景下的表现很突出就调整产品方向聚焦到这个被证明有价值的小点上深挖。第三个走向是暂时搁置如果数据不理想、回访也没有亮点那说明现在不是好的切入时机可以考虑把资源挪到其他更值得验证的地方。第四个走向是彻底停掉这里要说一句可能不太中听的话在创业这件事上快速止损也是MVP的重要价值之一它不是失败的象征而是你终于确定了一条路不需要再走。不管走向哪个方向MVP结束之后都有一个几乎必做的动作把整个验证过程复盘成一份学习文档。文档里不需要写流水账只需要回答五个问题我原本相信的假设是什么我做的MVP能不能有效验证这个假设实际的数据和反馈告诉我什么我原本哪里想错了下一步如果继续哪个环节最需要重构这份文档比你做出来的MVP本身更有价值因为MVP是一次性的而这个认知框架可以迁移到后续所有产品项目中。最后再多说一句关于MVP心态的话。我见过很多新手做MVP时最大的心理障碍是害怕做小了被别人嘲笑总觉得拿出来一个只有一两个功能的东西很丢人。但我的经验恰恰相反那些真正在行业中站稳脚跟的团队都特别擅长用极小的切口去验证巨大的想法。因为他们知道用户的信任不是靠功能堆出来的而是靠一次次有人真的理解我需要什么的瞬间积累起来的。MVP就是你创造这种瞬间的第一张入场券别把入场券浪费在追求面面俱上这件事上。按照这套逻辑来做你大概率会少走很多弯路。我在实际参与的项目里反复验证过愿意在MVP阶段花时间想清楚假设、敢于用小产品去和大市场碰一碰的人后续产品迭代的路径往往清晰得多。反倒是那些不肯做小、总想一步到位的人最后多半会卡在做了很多但什么都没验证出来的泥潭里。你会发现MVP这件事表面上是产品方法论本质上是一种面对不确定性时的思考方式——先用最小成本去触碰现实再根据现实反馈决定下一步。希望这篇内容能帮助你在自己的项目里少踩几个坑。等你做完第一版MVP拿到第一批真实用户反馈的那天你一定会回来感激当初那个愿意把产品做小、把验证做透的自己。7. 附加建议从MVP到下一个周期你可以准备什么这篇文章讲到这里核心的主线已经完整了但我在辅导新人的过程中经常在MVP跑完之后听到同一个问题接下来还有什么是我应该提前准备的这里给你几项实在的清单不一定现在全部做到但至少心里有个底。第一项建立一个简单的用户反馈渠道。不要等到下次迭代开发完了才开始找用户MVP验证期间就会有很多用户主动给你提建议你需要一个统一收口的地方。最简单的办法是拉一个微信群或飞书群把核心用户放进去你本人亲自在里面回复消息。这个群里的聊天记录就是你下一版迭代最真实的需求池。注意这个群不是让你去听取所有意见的而是要你从中观察用户表达需求的方式、频率和情绪强度。第二项提前梳理如果验证成功最大的瓶颈会是什么。很多团队MVP成功之后反而乱了阵脚因为突然涌进来的用户量超过了他们的承接能力。如果你做的是服务型MVP瓶颈是人工履约效率如果你做的是软件型MVP瓶颈可能是服务器成本和获客渠道。现在的MVP阶段就去思考这个问题不是为了马上解决它而是为了让你在验证成功后不会惊慌失措。第三项把你学到的东西产品化。这里说的产品化不是指开发而是指把你对用户的认知整理成文档、画像和决策原则让团队的每个人都能理解我们的用户为什么会用这个产品。很多团队做得不错但一扩张新人加入就变味了根子就在于MVP阶段的隐性认知没有转化为显性文档。这个整理工作不需要花很多时间但收益很大。有了这三项准备你从MVP进入下一轮优化或扩张时底气和节奏都会好很多。产品这件事最难的不是做一个功能而是持续做对每一个决策。MVP给你提供的就是一个低成本做决策的框架用得越多你对市场的手感就越准。
