大概在11月中旬的时候，我负责的新项目MVP版本就算是正式上线了。虽然团队内部已经搞过了一个简单的总结和反思会议，但是我觉得在产品经理个人成长的角度来看，有些东西还可以继续挖掘一下，所以我写下了这一篇文章。
MVP版本上线虽然强调小步快跑，快速试错，也能容忍很多不足，但是其中很多细节或暴露的问题，都是很值得总结和沉淀的，毕竟从0到1的机会不会太多。
11月中旬做总结时候记录的初稿
我从事产品经理行业其实并没有很长，也就是大概4年多的时间，大大小小做过的项目大概十来个，真正从0到1的项目也做过挺多。再加上这次的项目和之前的项目业务内容几乎是一致的，所以我自信这次哪怕是从0开始组建团队，再去从0到1做项目也应该不会踩很多坑。
但是从实际上线的结果来看，似乎我还是被打脸了。虽然大问题不是很多，但是小问题其实还是足够给我上一课了。我将这些问题整理出来，一方面是对自己的过往的回顾和沉淀，另外一方面也希望未来自己在类似事件上可以做得更好，最后也希望能对阅读这篇文章的朋友一些帮助。
关键性原则的总结
1. 只有理解了需求，才能理解什么是真正的MVP
需求和MVP这两个词几乎是产品经理天天挂在嘴边的，但是这两者的关系要正在的领悟和使用，还是得要实际项目真正验证了之后才会有切身的感觉。
在前期的时候，由于人力资源不足，客户资源不足，压根没时间调研和访谈，很多需求都是根据之前的个人经验推出来的，或者是转了多手之后来到产品经理的手里。
于是在做产品规划，产品特性梳理，优先级和其他信息决策的时候，往往很难把控住符合MVP的需求到底是哪些。最后该做的可能只做了一点点，不该做的或者不是这个阶段做的却做了很多。
说白了就是，本应该是好钢用在刀刃上，可结果却用在了刀把了，没有击中要害。
所以，要想确定MVP自己想要什么，本质上还是得要理清楚需求，而需求从哪里来呢？
肯定是从实际的客户上来，如果没有客户或者相对明确的用户画像，那么起码应该少量多次的试探，而不是一把梭哈到一个不确定的因素上去。
2. 简单，简单，一定要简单。删除，删除，直到不能再删除为止
对于SaaS类的B端产品来说，由于需要满足各种客户的不同的业务场景，肯定是希望自己的系统做得灵活和强大。
灵活意味着用户自由配置的空间就很大，可以动态地调整系统逻辑和功能，而开发者也不用频繁的发版或者定制。
