再谈MVP｜日X：78

这段时间在做一个需求方案，今天算是方案思路定了。回头一看，这方案最初想用假数据+真页面去设计，但讨论到最后，就变成了一张张静态图……本来我还想争取一下，但同事一句说服了我：这东西做上去，还真不知道有多人用，如果用最初的方案，开发得麻烦死，而且肯定会有隐藏的坑……

以前PM是提需求方，自己是接需求方，而且大家不属于一个部门，因此接需求方的一种心态倾向是：“只要是我拿出来的东西，就必须是最好的，至少也是80分的水平”，因为，输出的东西差了，会影响部门的面子和影响力，领导最后回头看你工作输出的时候，也不会把那些妥协的理由，听得进去，也可能会反问，你为什么不去反向推动？……所以，经常会看到的是需求方，大多是PM，和接需求方，比如设计师，RD，测试等互相处于一种敌对的状态。另外，如果，你真的要保证输出质量，又要保证满足需求方的时间预期，那就只有一个字——加班。

而现在，我就是需求方，我的心态确实在发生变化。我关注的点，

不是一个拿的出手，看上去不错，优雅的，很好的，最好的方案。

而是根据不同的时间段，提出正确的方案，并且把这件事情推动下去。

回想一下，我当前这个需求，算是一个“0到1”。之前的产品上，并没有做个类似的功能，以前替代这个功能的是运营人员。因此可判断，这个需求功能是属于KANO模型中的预期功能，面对预期功能的策略是挑性价比高的功能来做。另外，这个功能上线之后，还存在成为一个无影响功能的风险，因此更加需要低成本的验证其有效性。

另外，我们内部讨论这个功能的过程，真的是MVP的那个段子说的一样

不是追求一分不能增，而是追求一分不能减少。

总结，判断一个功能和产品需要朝着多少分优化，不要用接需求方的思维，朝着最好的方向前进，而是要问自己这几个问题：

这个功能是0_1，12，2~3……？
这个功能属于KNANO模型那一类？

如果这个功能属于比较初级的阶段，且预估属于KANO模型中，预期功能或亮点功能，方案设计时，就应该考虑性价比，小步快跑，速度验证，力求一分不能减少！

最后引用前公司大佬的一句话，表达一下另一个延伸感受：

不是用户体验好，用的人才多，而是用的人多，用户体验才好。

这背后逻辑是，当一个产品用的人多了，资源才会向它倾斜，它的体验也会越来越来好。