邱岳的产品实战
邱岳
十年资深产品人,无码科技产品经理
38996 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 58 讲
模块三:产品经典案例解析:小程序的生态与实践 (3讲)
模块四:产品会客厅——场景化处理你的产品疑难杂症 (18讲)
尾声 (1讲)
邱岳的产品实战
15
15
1.0x
00:00/00:00
登录|注册

05 | 如何快速利用 MVP 思想

简化对话实现难度
利用第三方平台进行验证
人工发货和联系用户
人工数据处理
MVP的局限性
MVP并非唯一正确的方法论
利用规则缩小场景
利用第三方系统
用人工替代系统
关注核心、差异化体验
裁剪短板,放资源到长板
数据准备和打点
数据项收集和结果推演
TDD(测试驱动开发)
MVP的局限性
低成本解决方案
验证长板
提前推演逻辑
MVP 的另一面
创造性的低成本方案
验证长板,而非短板
提前推演逻辑,不要盲目验证
总结
如何快速利用 MVP 思想

该思维导图由 AI 生成,仅供参考

你好,我是邱岳,今天我分享的主题是:如何快速利用 MVP 思想。
在上一篇 “用最少的资源给你的产品试试水”中,我们谈到了最小可用产品 MVP,并分享了几个关于它的经典案例。现在,让我们从例子里面跳出来,去看看怎么能快速地在自己的工作中利用 MVP 思想,这里有几个原则可以参考。

1. 提前推演逻辑,不要盲目验证

在设计最小可用产品之前,一定要想清楚自己想验证的问题,要收集哪些数据项,还有这些数据项可能出现的结果,以及不同结果代表的结论。
这个事情有点像软件工程中的 TDD(测试驱动开发),先把想要得到的结果列出来,再反推设计,以免设计逻辑不清楚,或者漏掉数据打点,反倒浪费了资源。
比如我前面举的那个数据分析功能,我也是在推演的时候才发现需要多做一些数据功能,否则如果功能本身太简陋导致使用率高留存低的情况,就会难以辨别哪里出了问题。
另外,推演的时候还会提前去准备一些数据,比如使用率高,那么多高算高呢?这就需要去查一下在同区域其他类似功能的使用率。
这个过程本身也很有意思,你在心里默默估一个可能出现的数字,然后把功能做上去,再看看实际跑出来的数字,这个过程就好像谜底揭晓一样。
我觉得这个过程本身也是一种训练,就是你有判断,然后再看结果。时间久了,你可能会逐渐形成自己对于用户习惯,以及一些具体数字项的感觉。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何快速利用 MVP(最小可用产品)思想的方法和原则。作者首先强调了在设计最小可用产品之前,需要提前推演逻辑,不要盲目验证,并且强调了验证长板而非短板的重要性。其次,作者提出了创造性的低成本方案,包括用人工替代系统、利用第三方系统以及利用规则缩小场景。这些方法可以帮助读者快速验证产品想法,降低开发成本,提高产品迭代效率。文章内容丰富,涵盖了实际案例和具体操作方法,对于想要快速验证产品想法的读者具有很高的实用性和指导意义。文章还提到了MVP并非唯一正确的方法论,需要注意其局限性。总的来说,本文为读者提供了快速利用MVP思想的方法和原则,同时也提醒了MVP的局限性,对于想要快速推进产品规划和发展的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(28)

  • 最新
  • 精选
  • 刘奥纳多
    请问打点是什么意思呢?

    作者回复: 就是@木头人 提到的,通过在访问中记录用户行为轨迹(也就是打点)来进行统计分析。

    2018-08-08
    2
    12
  • laulend™
    最近一直跟产品在争论一个功能,由于我们的用户特性,喜欢抽奖、抽券或者实物奖品,也做过小范围的测试,哪怕是插件,后来二爷家的抽奖助手支持嵌入功能,一直想接入二爷家的抽奖助手到自家的小程序做个MVP测试,如果效果反馈和好的话,那么就自己在页面上开发一个抽奖功能,支持自家优惠券抽奖等等,但是,产品一直不给做,非要自己搞一个抽奖功能,运营的延期和用户活动只能拖到一个月以后,对于这件事一直在撕逼,看完二爷的文章,我打算再去撕逼一次,不管成功与否,还是得去尝试一下。实在不行,推荐他们来看二爷的课程。

    作者回复: 不一定非要撕,换个思路,用别的方式绕一下,比如导进公众号里

    2018-08-08
    7
  • Cindy
    内部想孵化一个项目,市面上有完备的竞品,业务需求很大很多,怎么确保是mvp?

    作者回复: 并非所有的产品形态都适用 MVP,比如有个著名的段子就是「生孩子是没办法通过对第一版试错迭代逐渐完善的」。

    2020-02-20
  • sylan215
    1. 其实推演基本所有产品经理都会做,问题是,有些人的推演就是自己在意yin而已,所以推演的结果就不尽如人意了。 2. 长板理论逆袭木桶理论,赞。 3. 创造低成本方案这个我尝试补充一个,现在很多的业务和系统全都是云端化,但是 MVP 阶段其实可以不去搭建复杂的云端配合系统,虽然那个很灵活,但是处于验证的目的,完全可以使用硬编码,或者规则文件来做前期的配置,等量级足够大的时候,再去搞云端化。 4. 根据「增长黑客」的理念,MVP 主要是为了找到产品的 PMF 状态,所以二爷说的 MVP 思想,我理解为就是验证或者探寻产品真实的 PMF 状态,所有精力优先聚焦在这个上面即可。 以上,欢迎沟通交流,公众号「sylan215」
    2018-08-08
    1
    24
  • 木头人
    上面某位朋友,打点也称为埋点,解决数据采集的问题。
    2018-08-09
    1
    13
  • 牛小妞
    印象最深的利用MVP快速验证产品的是多抓鱼,最早他们就是建立微信群人工发书单,人工下单转账来使业务跑起来的。
    2018-08-14
    1
    7
  • CC
    之前我在制作MVP产品有两个误区。 一是认为动手比推演重要,觉得推演很久不如动手制作,认为动手才是获得结果的捷径。实际上产生这个误区的原因是战略上的懒惰,没有深入思考制作MVP产品的目的,结果绕了一个大弯路。 之前读过一篇文章,依稀记得,某个大牛在短短一个周末就鼓捣出了一个MVP产品,验证了想法。我只记住了结论,却没有记住逻辑推演过程,以及项目之前的准备。他之所以能做成,一是之前做过推演,二是有自己想要验证的明确目标。 第二个误区是要求完美,过度担心用户的负面口碑,这就导致不仅把资源浪费在产品的短板上,还下意识的拒绝采用灵活的低成本方案,比如人工方案。 会使用工具的人,比如会写代码,某种程度上也是受到知识诅咒,很容易一大步跨入产品细节,考虑实现方式,考虑如何做出一个完美的产品,而不是投入时间在推演上。 明确目的,然后行动。
    2018-08-14
    6
  • 胡氏
    有个小优化提下:播放可操作的进度条,比如返回重复听那一段话,倍速听;可跳选时间进度;
    2019-02-25
    4
  • 听天由己
    关于人工替代系统,这对创业公司来说,更是常见。很多时候,我们想要验证一个功能的适用性,我们想得特别完美,可是资源有限,也只能先实现最核心的特性。例如,在赛事系统中,组织者很希望在报名结束后导出名单,这一需求并不着急,我们完全可以通过人工导出 Excel 表格的方式进行沟通。 还有一点,产品不够,运营来凑,这话一点都不假。哪有上来就完美的产品?我们更重要的是展现自己的理念和态度,建立产品与用户之间的信任,然后快速响应和迭代,这样才有重视感和成就感。运营工作的确不必可少。
    2018-08-08
    4
  • Symon
    这一节超实用,我们在做B端产品时,很多时候一些功能都是低频的操作,这时候人工反而比系统更优化些(从成本和灵活性角度来看,毕竟新产品的体量还没有那么大)!
    2018-08-23
    1
    3
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部