未完成功能的 MVP

比如微信在刚改版订阅号展示方式时，长按订阅号文章会弹出菜单“未完成的功能”。
比如某软件的“设置”菜单点击后没有任何可设置项，而是弹出一个表单，向用户询问，他希望在这里设置什么。

可以通过这个按钮的点击率数据，来验证用户动机和需求。

除了可以借鉴这些未完成的功能，验证自己的产品逻辑之外，我们还应该得到的另一个启发“用户真的会感兴趣吗”？

比如你做一个类似的功能，有三种假设：

• 1.使用率和留存都很高，大家会不断回来看数据，并且会有声音催促尽快完成
• 2.使用率一般，但留存不错，也就是说确实对一部分人有价值，或许可以通过培训推广开
• 3.开始时使用率高，但后面留存差

像前2种都还可以，但是第3种情况下我们很难通过数据来分辨，究竟是因为功能没做完导致大家不来，还是因为它本身就是伪需求。可以向用户（无论是点击还是未点击的用户）回访沟通下原因，
更有甚者如果使用率都很低，怎么办？

所以一定要去想办法快速验证产品的创意起点，也就是“用户是不是真的会对此感兴趣”

快速验证产品的创意

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

在设计最小可用产品之前，一定要想清楚自己想验证的问题，要收集哪些数据项（埋点），还有这些数据项可能出现的结果，以及不同结果代表的结论(比如使用率高留存低的情况，可以参考其他类似功能的使用率)

2.验证长板，而非短板

尽量去关注核心的、差异化的体验。比如，12306 的第一版产品就是个 MVP，整个产品体验烂到爆，但长板还是完全体现了：它有票。
现在这个时代，各种产品形态基本都被人想到了或者实施过了，我们要在市场上立住脚，靠的不是平均分更高，而是在单一维度上做到现有方案的十倍好。所以做 MVP 更重要的是验证这个长板，而不是做一个不犯错但平庸的尝试。

3.用人工替代系统

没错，就是直白的人工操作，前期就说人工去做，等业务真正发展起来，可以快速迭代用系统化的能力去解决问题

4.充分利用第三方系统

除了人力之外，我们还可以先借助第三方系统或生态快速构建 MVP 进行验证，比如想做一个APP，前期可以先用微信公众号来试运行

MVP 的另一面

MVP 并不是唯一正确的方法论，有很多的产品模式是要求一定的体量和复杂度才能完成验证的，MVP 最多只能验证其中个别环节上的假设是否成立，千万不要把宝全部押到一个 MVP 上。尤其对于领域相对成熟的产品，产品体验细节的叠加才能构成核心竞争力，而在 MVP 中可能很难将它构建出来。

MVP 还有一个可能的影响是负面的口碑效应，有些不是特别刚需的场景，做一个 MVP 发出去，早期的用户一用发现不能满足期望，或许就放弃了。

即便后来做了更多的迭代和改进，再唤醒他们的成本或许是很高的。而通常愿意对早期产品进行尝鲜的用户，很可能在线上线下的小圈子里具备一定的影响力。他说你不好用，比一个沉默的用户流失可能带来的伤害更大。

所以说，MVP 有它的价值和好处，但也不是一个“放之四海皆有效”的唯一原则。对我们来说，要知道它的长处与短处，从而善于利用 MVP 快速推进产品规划和发展，同时也不能迷信它或信仰它，没有那个必要。

——读自极客时间