04 | 用最少的资源给你的产品试试水

Aug 6, 2018

04 | 用最少的资源给你的产品试试水-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

04 | 用最少的资源给你的产品试试水

2018-08-06 邱岳来自北京

《邱岳的产品实战》

课程介绍



讲述：邱岳

时长08:42大小3.99M



你好，我是邱岳，今天我分享的主题是：用最少的资源给你的产品试试水。
如果前面的信息收集、沙盘推演和做调研都算是纸上谈兵的话，这一部分则是到了真刀真枪动手的阶段。
只不过在全面投入和集团军作战之前，我们通常需要用尽可能少的资源去试试水，验证我们在做推演阶段的一系列假设。
这里有几个名词，或许你在其他地方见到过，我们简单解释一下。MVP 是最小可用产品（Minimum Viable Product）的首字母缩写，意思是：剧烈缩减产品范围，用最少的资源构建出符合预期的最小功能集合并投入验证。
从产品经理的视角来看，就是围绕一个核心问题，创造性地提供解决方案，实现一到两个核心用例。以验证这个核心问题是真实存在的，或者解决方案是用户喜闻乐见的。
MVP 算是精益思想在科技行业中的一种应用方法论，核心是：不断用尽可能少的投入创造尽可能多的价值。说白了就是：走一步看一步，不憋大招，低头拉一步车，抬头看一步路。
市面上介绍 MVP 的书或资料已经有很多，再写也很难写出新意，所以，我这次打算通过几个案例，试着介绍一下 MVP 作为一个工具，怎样在我们的产品规划和设计过程中为我们创造价值。
未完成的功能键第一个案例是我很久以前在书上看到的，说的是维珍航空计划在自己的机上娱乐系统中加入一个新功能，为了测试乘客是否真的会对这个功能产生兴趣，设计人员在还没有设计任何功能的情况下，就向菜单中添加了一个入口按钮。
如果真的有乘客点到了这个按钮，系统会显示：“该功能尚未完成，或许下一次搭乘维珍航空的班机时你就可以使用它了。”通过这个按钮的点击率数据，来验证用户动机和需求。
类似的快速验证案例有很多，比如微信在刚改版订阅号展示方式时，长按订阅号文章会弹出菜单“未完成的功能”。又或者前些日子在朋友圈看到的一个案例，某软件的“设置”菜单点击后没有任何可设置项，而是弹出一个表单，向用户询问，他希望在这里设置什么。
类似的 MVP 设计是最常见，也是最容易实施的，它的目的是验证用户动机或习惯，它甚至不考虑解决方案，而是用最少的资源去验证场景是否存在。这应该是所有产品创意和产品设计的逻辑起点，也是用户转化漏斗的开口。
除了可以借鉴这些未完成的功能，验证自己的产品逻辑之外，我们还应该得到的另一个启发，就是提醒自己想一想“我们是否已经论证了产品创意的起点”，或者说我们有没有回答一个问题：“用户真的会感兴趣吗”。后续所有的设计、研发和资源投入，都将会建立在这个前提之上。
一个失败的产品创意这里，我可以分享一个真实经历，曾经我们在设计用户管理工具时（内部系统），有个想法为客服同事提供数据统计工具（统计用户分布、订单分布等等）。经过调研，客服同事的反响也不错，表示对工作有价值，还列出了一系列希望看到的数据项。
可是因为“数据分析”本来并不在他们的工作流程中，这个设计是否真的会被使用，我自己心里也没谱。所以我一边做具体的报表需求分析，一边找工程师直接在系统中加了一个数据功能的入口，打开页面只有几个简单但重要的数据加和汇总，以及几个报表名字，下面标注：开发中，敬请期待。
然后我就开始盯这张页面的 PV，在自己心里设计了几种可能出现的情况，最理想的当然是使用率和留存都很高，大家会不断回来看数据，并且会有声音催促我们尽快完成报表开发。
次之是使用率一般，但留存不错，也就是说确实对一部分人有价值，或许可以通过培训推广开。
可能会产生的纠结情况是开始时使用率高，但留存差，这种情况下我们很难通过数据来分辨，究竟是因为功能没做完导致大家不来，还是因为它本身就是伪需求。
为了尽量避免模糊，早期我们投了一些资源，根据优先级和成本做了几个重要的数据指标，这些指标背后的算法也没有完全自动化，而是我定时线下算好了手动更新上去。我还默默做了打算，如果真的出现这种情况，就根据日志找到点进这个页面的用户，推心置腹地聊一聊，争取问出真实原因。
事实证明我想多了。数据分析功能入口上线之后，几乎没什么人点进来，而且留存也很糟糕。沮丧和庆幸交织之余，我还是找了一些点进来和没有点进来的同事聊了聊。他们依然对这个功能赞不绝口，而且认为能看到数据当然很好，只不过这确实不是他们工作流程中的刚需，看不到也不影响。
所以这里要注意，当你有了一个点子，并且你去拿这个点子去询问别人的意见，别人都特别客气而且礼貌地说：“哎呀，很好呀很好呀，我觉得有用啊”。这个时候通常是会有危险的。他们越客气，表面很急迫，但是实际上是一个伪需求，做上去没人用。这一点，大家一定要小心。
后来，这个功能当时被暂停，直到工作流程和考核方式发生变化才又被重新提出来，那是后话了。
MVP 的商业化验证作用除了上面提到从微观的角度验证用户动机之外，MVP 有时还可以验证产品模式是否成立。比如坊间流传的比尔·盖茨忽悠 IBM 的故事，说的是在 IBM 跟微软合作之初，盖茨号称自己的软件多么多么牛，IBM 答应合作试试。
但其实当时微软什么都没有，合作谈完之后他花 5 万美金买下了 DOS，稍作修改就发布了。还有 Dropbox，最先出现的是一段有点简陋的纸片视频，结果一炮走红，万人空巷，而此时产品根本连影都还没有呢，用户的积极反应和强烈的付费意愿成了 Dropbox 的产品起点。
总结今天我跟你初步分享了 MVP 最小可用产品这一应用工具。通过类似于“未完成的功能键”这样的快速检验案例，你可以用最小的资源测试产品的应用场景是否存在。当然了，在使用工具的过程中，也不要忘记了去验证产品的创意起点，也就是“用户是不是真的会对此感兴趣”。
然后我还跟你分享了一个我在实际过程中去应用了 MVP，然后通过 MVP 发现了我自己的想法是伪需求，并且叫停了工程这样的一个经历。
你有没有用过 MVP 的方法呢，在试水中又遇见了哪些事情，你可以提出具体的问题，我们一起思考，共同成长，感谢你的收听，我们下次再见。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 39

提建议

03 | 要不要相信你的调查问卷

05 | 如何快速利用 MVP 思想

 写留言

精选留言(43)

听天由己
2018-08-06
我一直以为将一个未完成的功能给出入口，是不太友好的行为，这样的论断纯属想当然，我在手机游戏上经常遇见，他们的开发周期与产品节奏总是会提前放出一些惊喜，像是留下了钩子，就像评书和小说章节的未完待续。二爷在提及未完成的功能验证时，我却猛然想到了微信信息流改版后的未完成功能，大家总是以为有彩蛋，其实今天的内容可能也是微信团队考虑的一个维度。最后的商业化验证，Dropbox 的案例很震撼，可事实上用户需求与这则视频中提及的解决方案是否有必然联系，我们无从得知。我以为的验证，可能是对用户在某一场景下的产生不同动作的可能性，他们其实还是容易被带入到具体场景中，不一定是他们真实的需要。感谢二爷今天的启发，时不时告诫自己，自己做的东西是否真的是用户需要的。就像《启示录》中的最后两章的自问自答。关于建议，上面有位朋友提到了，这季的专栏内容说是偏实战，可还是理论性知识稍微多了些，缺少了实战操练，完全可以在每节背后加上我们熟悉的产品或是案例分析，这样更有动力，比如说最近争议颇多的拼多多。其次，我很怀念以前每周五的产品设计案例分析，那是开启我们了解产品世界的一扇窗，希望以后的专栏这一模块要回来啊。
展开
51
木头人
2018-08-06
有点和刘飞，在《从电子到产品》中mvp一章中的内容和观点很像。说一点我自己的感觉：mvp应该更抽象一点，早起最好通过人工来做，把场景和流程思考透，就像买东西这件事情一样，先要选择要买的东西，然后去结账，带回家。但是在不同的场景里面，买东西会有很多不同的情况，有目标、没目标。本质上互联网只是优化了物理世界，并没有颠覆物理世界，mvp我更倾向理解为场景验证而不是功能验证。 ps：最后还有一点小建议是对岳岳前辈的，文章内容我现在读起来有点难受，从我个人出发而言会选择偏向底层逻辑的解读或纯粹实操类的指南，这样也便于读者理解和分类。
展开
20
greatcl
2018-08-06
今天还在吐槽王者荣耀举报界面的反馈按钮，一直提示敬请期待，原来是点的人太少了…… 要是能早点读到这篇，感觉能少做好多无用功，之前封闭开发做的项目，没多久就凉了，累感不爱。感谢二爷分享！
19
青葵
2018-08-16
评论中有很多对MVP方法的疑问，这也是目前许多中小企业的顾虑，没做完就别拿出来。个人想法，对于这样的情况，在用户点进未完成功能时，提示信息尽量友好，安抚一下感觉被欺骗的心情。另外感觉靠点击率判断还有些欠妥，因为有时候点进入也许单纯是好奇想看看这是个什么功能，至于留存好坏，还是要看实际使用对用户起多大作用。所以除了友好提示，可以适当再加入几点关于功能的介绍，提供用户自行设计以及提供备选方案，最后做个方案投票，用户期待方案整合（不过感觉现实中大多数人会觉得麻烦不会去填，更期待别人去填，或者等产品上了之后直接试一试，因此尽量简洁，适当勾起兴趣来引导）。根据点击率、方案投票数、用户期待方案来决定，也许对后续的留存有一定帮助吧。另外，也要关注产品的性质，类似微信、微博等这种社交类，大家更注重的是情感表达交流，轻松的互动等，对于提示信息的表达以及产品功能的介绍，显得更亲近些比较好；类似工作业务类，大家会首先考虑相关工作流程，旨在保证工作为前提，综合考虑公司以及合作方各项因素，进行必要的有技巧的调研沟通，这方面相对于面向大众的产品会更容易，更有针对性。点击、填写过的用户肯定是对这项功能关注度比较高，对整个产品充满感情的，无论该功能后续是否成形，都应该给大家相应的回复，或者因为成本和业务考虑对预先功能进行了修改和缩减，都应进行说明和安抚。最大的感受，产品应该是有温度的
展开
共 1 条评论
11
WILLING
2018-08-06
邱老师，那点击率高但是留存率低的话，怎么判断这是需求真伪的问题还是功能的设计好坏问题呢
共 1 条评论
11
葡萄
2018-08-06
邱老师，那点击率高但是留存率低的话，怎么判断这是需求真伪的问题还是功能的设计好坏问题呢，同问
作者回复: 我那个情况容易一些，可以去跟用户直接聊或观察他们的习惯。如果没有这个条件可以做做调研试试
4
戴劼 DAI JIE🤪
2018-08-15
推荐《精益创业》和《重来》
4
李源
2018-08-06
邱老师你好，我可以这样理解吗？当自己设计出一个产品逻辑概念，先用自己最少的资源试探一下效果如何，同时你能解释下mvp是产品设计的什么意思？
作者回复: 是的后一个问题没大看明白…
3
sylan215
2018-08-06
之前确实听说也了解过 MVP，但是对「未完成功能的 MVP」关注比较少，这么一说，真有点开脑洞。不过再换位想一想，这些「未完成功能的 MVP」会不会让用户感觉到被欺骗了呢？怎么把握好这个度？抑或等这些功能实现完成后，是否还需要再花费成本「教育」用户说，之前你期待的功能上线了。以上，一个测试老兵的思考，欢迎沟通交流，公众号「sylan215」
展开
3
老可爱了
2020-10-10
很遗憾，在工作中很少用到MVP方法。工作中会将MVP功能撤回当作“产品经理没想清楚”，会阻碍这个方法的落地。
2
Tays
2018-08-07
听了几期，直到今天这期决定留言下，因为这个问题我遇到了几次. 运营部提出几个功能需求，表现出很急迫的样子，给到很多压力，我们满足了他们的需求，做到了想要的完整样子，结果上线之后，使用率极低，只有当初迫切需要的那个人有在使用，其他所有人都不在使用这个功能，如果使用MVP应该可以节省我们很多时间
2
丁丁历险记
2021-03-29
笔记 1 介绍mvp 2 未完成功能放出来，收集数据，确认必要性。 3 mvp 成功案例，盖茨忽悠ibm drop box 4 再补充一个自己想的很美好，事实没啥屁用的产品。
1
Libj
2021-02-08
针对to C的产品可以用“未完成的功能键”来进行快速验证场景的存在，进行快速迭代、兑现；但是to B的产品，因为不能快速迭代且覆盖低版本产品，如果有这种功能，那用户会认为是产品bug，影响用户体验以及对产品功能的信任度，这个如何解决呢？
1
中国梦
2020-05-13
问题：这节里面提到的MVP等等所有内容好像都有一个前提，就是这个产品已经做出来了，然后随后迭代动作怎么做，用户是否会需要的试探，但是我想这节应该讲的是最开始的状态，就是产品还没有，怎么去试水，用什么工具，什么方法？问卷调查？我想这节的内容还是有点局限狭隘。
作者回复: 谢谢建议。
共 2 条评论
1
大树
2019-02-18
我对mvp的理解是用最低的成本实现核心功能，验证功能的实用性或者为了给“这个我们特别需要”的运营打下脸（开玩笑..）。我觉得mvp的理想状态是，能用运营手段验证就坚决不动用开发资源...但我发现实操起来没那么容易。因为有的时候一不小心就把步子迈大了... QAQ 所以，文中提到的“未完成功能验证”对我来说，是一个好点子。我之前对一些类似的产品设计表示不理解，现在有些明白了。另外，作为后台产品，一直没有对后台用户的行为埋点进行数据分析，是一直以来工作的失误。以为直对业务，啥事儿聊就行了，但是人都是会“说谎”的嘛，还是客观数据靠谱，聊起来也更知根知底~
展开
1
Bob
2018-09-04
关于客服统计功能的价值，我觉得应当有更深入的分析。作为企业内部应用，相当于toB产品，最终客户价值体现在企业本身，不是实际操作的用户。如果数据本身有价值，但没人看，那就是运营过程本身的问题。产品设计要和过程改进结合起来才更有价值。产品本身要成为推动者，而不是等着业务来推。所以toB产品不仅要懂产品，而且要懂业务，懂管理和经营才能将产品做好。
1
CC
2018-08-13
之前尝试 MVP 中，发现执行的难点是明确目标。目标明确意味着需要清晰描述想要验证的内容（创意的起点），接着预估结果的几种可能性，然后倒推实现方式和执行细节，确定第一阶段的项目范围。文中两个未完成的功能案例非常有启示，准备在现在的项目中进行尝试。之前在项目中有遇到低使用率、高留存的情况，这种情况发生在一个免费工具类App上。由于该App设置一次后就一直运行，是低频应用。较难验证到底是伪需求，还是App设计的好。有可能用户因为是免费App，即使没有什么用处，也就一直装着。之后提供收费功能，才得以验证需求的真实性。
展开
1
白竹
2018-08-11
mvp 这概念之前拜读比较少，这2年才了解到，一直没有怎么实践过。单功能用最小化思想实现，还是挺需要协调好功能优先级，有可能要与领导pk。
1
我叫什么来着
2018-08-11
MVP可以验证需求真伪，但从来没做过，在我司这么做会被喷，世俗的压力太大，哈哈
1
Bob.Chen
2018-08-08
那个看数据的例子实在太有共鸣了。组内前段时间也做了个类似的，不是看数据，而是从已有的数据仓库拿数据然后做可视化给产品或者设计同学看。因为数据仓库一些接口的原因，速度很慢，而且每个页面有很多配置项，非常复杂，几乎没有人用。但是老板也不叫停，变成了一个 kpi 项目。
作者回复: 🤝
1

