05 | 如何快速利用 MVP 思想

请问打点是什么意思呢？

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

内部想孵化一个项目，市面上有完备的竞品，业务需求很大很多，怎么确保是mvp？

1. 其实推演基本所有产品经理都会做，问题是，有些人的推演就是自己在意yin而已，所以推演的结果就不尽如人意了。 2. 长板理论逆袭木桶理论，赞。 3. 创造低成本方案这个我尝试补充一个，现在很多的业务和系统全都是云端化，但是 MVP 阶段其实可以不去搭建复杂的云端配合系统，虽然那个很灵活，但是处于验证的目的，完全可以使用硬编码，或者规则文件来做前期的配置，等量级足够大的时候，再去搞云端化。 4. 根据「增长黑客」的理念，MVP 主要是为了找到产品的 PMF 状态，所以二爷说的 MVP 思想，我理解为就是验证或者探寻产品真实的 PMF 状态，所有精力优先聚焦在这个上面即可。 以上，欢迎沟通交流，公众号「sylan215」

上面某位朋友，打点也称为埋点，解决数据采集的问题。

印象最深的利用MVP快速验证产品的是多抓鱼，最早他们就是建立微信群人工发书单，人工下单转账来使业务跑起来的。

之前我在制作MVP产品有两个误区。 一是认为动手比推演重要，觉得推演很久不如动手制作，认为动手才是获得结果的捷径。实际上产生这个误区的原因是战略上的懒惰，没有深入思考制作MVP产品的目的，结果绕了一个大弯路。 之前读过一篇文章，依稀记得，某个大牛在短短一个周末就鼓捣出了一个MVP产品，验证了想法。我只记住了结论，却没有记住逻辑推演过程，以及项目之前的准备。他之所以能做成，一是之前做过推演，二是有自己想要验证的明确目标。 第二个误区是要求完美，过度担心用户的负面口碑，这就导致不仅把资源浪费在产品的短板上，还下意识的拒绝采用灵活的低成本方案，比如人工方案。 会使用工具的人，比如会写代码，某种程度上也是受到知识诅咒，很容易一大步跨入产品细节，考虑实现方式，考虑如何做出一个完美的产品，而不是投入时间在推演上。 明确目的，然后行动。

有个小优化提下：播放可操作的进度条，比如返回重复听那一段话，倍速听；可跳选时间进度；

关于人工替代系统，这对创业公司来说，更是常见。很多时候，我们想要验证一个功能的适用性，我们想得特别完美，可是资源有限，也只能先实现最核心的特性。例如，在赛事系统中，组织者很希望在报名结束后导出名单，这一需求并不着急，我们完全可以通过人工导出 Excel 表格的方式进行沟通。 还有一点，产品不够，运营来凑，这话一点都不假。哪有上来就完美的产品？我们更重要的是展现自己的理念和态度，建立产品与用户之间的信任，然后快速响应和迭代，这样才有重视感和成就感。运营工作的确不必可少。

这一节超实用，我们在做B端产品时，很多时候一些功能都是低频的操作，这时候人工反而比系统更优化些（从成本和灵活性角度来看，毕竟新产品的体量还没有那么大）！