知易行难 | 新项目MVP版本上线后，我总结的一些踩坑点

编辑导语：在项目中，我们或许会犯一下小错误，很多人觉得不要紧，没有犯大错就行了。其实，这样一个个小错误才是大问题，它会影响项目的上线情况。作者通过其项目经验，总结了一些自己踩过的坑，与你分享，希望你在成长路上能够吸取教训。

大概在11月中旬的时候，我负责的新项目MVP版本就算是正式上线了。虽然团队内部已经搞过了一个简单的总结和反思会议，但是我觉得在产品经理个人成长的角度来看，有些东西还可以继续挖掘一下，所以我写下了这一篇文章。

MVP版本上线虽然强调小步快跑，快速试错，也能容忍很多不足，但是其中很多细节或暴露的问题，都是很值得总结和沉淀的，毕竟从0到1的机会不会太多。

11月中旬做总结时候记录的初稿

我从事产品经理行业其实并没有很长，也就是大概4年多的时间，大大小小做过的项目大概十来个，真正从0到1的项目也做过挺多。再加上这次的项目和之前的项目业务内容几乎是一致的，所以我自信这次哪怕是从0开始组建团队，再去从0到1做项目也应该不会踩很多坑。

但是从实际上线的结果来看，似乎我还是被打脸了。虽然大问题不是很多，但是小问题其实还是足够给我上一课了。我将这些问题整理出来，一方面是对自己的过往的回顾和沉淀，另外一方面也希望未来自己在类似事件上可以做得更好，最后也希望能对阅读这篇文章的朋友一些帮助。

一、关键性原则的总结

1. 只有理解了需求，才能理解什么是真正的MVP

需求和MVP这两个词几乎是产品经理天天挂在嘴边的，但是这两者的关系要正在的领悟和使用，还是得要实际项目真正验证了之后才会有切身的感觉。

在前期的时候，由于人力资源不足，客户资源不足，压根没时间调研和访谈，很多需求都是根据之前的个人经验推出来的，或者是转了多手之后来到产品经理的手里。

于是在做产品规划，产品特性梳理，优先级和其他信息决策的时候，往往很难把控住符合MVP的需求到底是哪些。最后该做的可能只做了一点点，不该做的或者不是这个阶段做的却做了很多。

说白了就是，本应该是好钢用在刀刃上，可结果却用在了刀把了，没有击中要害。

所以，要想确定MVP自己想要什么，本质上还是得要理清楚需求，而需求从哪里来呢？

肯定是从实际的客户上来，如果没有客户或者相对明确的用户画像，那么起码应该少量多次的试探，而不是一把梭哈到一个不确定的因素上去。

2. 简单，简单，一定要简单。删除，删除，直到不能再删除为止

对于SaaS类的B端产品来说，由于需要满足各种客户的不同的业务场景，肯定是希望自己的系统做得灵活和强大。

灵活意味着用户自由配置的空间就很大，可以动态地调整系统逻辑和功能，而开发者也不用频繁的发版或者定制。

但是对于MVP版本的产品来说，产品经理在这个时刻去思考这种灵活配置化的功能是极度危险的。因为每次在设计功能的时候总是会想着以后这个地方要灵活，要可配置，要支持自定义，然后就会情不自禁的留口子，留缓冲的余地。最后导致出来的功能相对复杂，且其他辅助类功能没有形成闭环，最后导致用户体验不佳。

本来可以给用户一个写死的，确定性强的解决方案和流程，但是却做成了给用户多个选择，但是用户选择了之后可能会遇到死胡同（有些功能没有闭环）的尴尬场景。

「简单」意味着确定性强，而给多了选择，留多了口子，肯定会变得「复杂」。

3. 看竞品有可能犯错，但是不会走歪路

对于新产品来说，学习和参考竞品的方案是常有的事，这几乎可以算是业内不成文的规定了。

但是作为产品经理来讲，别人虽然做得很好，自己在学习的时候肯定不会一股脑全部抄过来，肯定会加一些自己的理解，或者是刻意地和竞品做的不太一样。

这算是产品经理的态度，也可以理解为一种渴望超越而不服气的精神，总感觉自己可以做得更好一些。

于是乎，这次MVP很多的大框架和主流程等，我都有意识的和竞品做的不太一样，同时也沿用了大量自己的过往的项目经验。

最后产品肯定可以快速完成，但是在实际交付客户试用体验的时候，就发现花了很多时间做的功能用户并不太认同，反而是一些和竞品做得比较类似的基础功能，客户却很喜欢。

最根本的原因就是两套方案面向的客户群体，用户画像是不一样的，而我的方案瞄准的恰恰不是MVP阶段的目标客户群体，所以试用的时候才会被用户吐槽用的太麻烦，不太好用，建议我们做的简单一些。

看竞品的时候，除了基础的功能和业务逻辑之外， 还有一个很关键的因素就是看双方的用户画像群体是不是一致。如果大方向就不一致了，那么细节的功能点参考起来就很容易走歪了。

4. 相似的项目经验是好处，也是坏处

之前我写过一篇文章，讲有经验的产品经理反而容易吃亏，其实就是从这个项目引发的感慨。

相似的项目经验看似很美好，直接上手可用，直接Copy一套，但是隐藏在各处的坑坑洼洼的细节，积累多了还是很容易让老司机翻车。

关于这一块我不再赘述了，感兴趣的可以去看我之前写的文章《纳尼？有经验的产品经理反而容易吃亏？》

想要提醒大家的就是：别困在过往经历中，随时打破更新自己的固有观念，才能更加有效地避开这些小坑小洼。

二、细节方面的总结

一些细节方面做得不好的地方

1. 功能尽量一次性闭环，别做一半留一半，总是留点边边角角会给自己挖坑。闭环是指核心流程的功能要做完，而不是所有内容做完才是闭环。

2. MVP期间如果要赶工期，那么就要考虑减少接口的开发，例如查询，提交，删除，频率低的异常功能等，很少用上的，不确定能不能用上的，一律就先不做了。

3. 减少非必要字段和功能的拓展，当前用不上就别加，加了再去掉就很麻烦。很多时候会考虑未来这个地方要拓展，所有就留着一个字段放在那里，结果前后端理解有差异，测试理解也有差异，该做的漏了做，不该做的却做上去了，徒增麻烦。

4. 在MVP期间，太远的事别想，太复杂的方案别想，太难落地的方案别想。先确定一个基础的目标，先完成再完美。初期以人工+系统的方式解决也未尝不可，不一定任何事情都需要用系统来解决，别陷入“手里有锤子，看啥都是钉子”的怪圈中。

5. 设计核心业务方案的时候，别想着优化用户体验或者交互问题，琐碎的事情专门去做，效率更高。例如项目初期的时候，没有UI，没有标准组件库，然后在出原型的时候一方面要考虑业务的问题，另外一方面要考虑前端交付的问题，最后导致产品出原型慢，前端看到的交付物也丢三落四的，反而效率不高。还不如先专心搞业务的事情，然后统一时间或者让专人来负责原型标准化组件，与前端交付的问题。

6. 产品经理要敢于认错，方案有问题，决策有问题，错了就是错了，坦坦荡荡地承认、道歉，然后及时改正。别羞于承认错误而固执坚持，最终项目失败，辜负团队众多同事的心血，这样的后果更加严重。

7. 当面说，小会议说，然后文档说，需要循序渐进地来推进。很多时候产品经理自己写了很多规范和标准放在原型的某个角落，然后群里@各位开发、测试去看一下，这种情况下大多数人都不会去看，只有到用的时候，出问题的时候才回去查文档。团队协作的规范推动是一个急不得的事情，只要还有问题没解决，就需要不断地强调和推动，过程会很累，但是这必不可少。

8. 要给团队清晰明确的规划和指令，未来要做什么，要做到什么程度，这些规划可能由于某些东西还不够清晰，所以只存在产品经理自己的文档里。不清晰的规划别乱公布，如果需要公布则最好做好相应的注释说明或者通过会议+文档的形式传达。对产品经理来说，职业天性就是和模糊不定的东西打交道，而对开发和测试来说，清晰和准确无误的信息是他们特别在意关注的。所以产品需要将不确定性转为确定性，将模糊的东西清晰化后，再准确无误地传达给他们。

作者

我叫维他命（Vitamin），微信公众号：PM维他命。前PHPer，做过在线教育类产品，也做过4年多的跨境仓储物流方向的产品，目前是一位外贸SaaS领域的供应链产品经理。主要专注于WMS/OMS/TMS/BMS/ERP等领域，分享供应链相关的产品知识。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！