如何在产品交付会上舌战群雄？思维导图

本身产品评审就是个枯燥的工作，产品人员不停的讲，研发人员不停的脑补。如果提前不做准备的话，还真不知道产品在BB什么。

所以我通常的做法是：

上文也提到了，交付的过程也是PK的过程。研发可能会提出的问题大概有这么几种：

A：一般交付其实不用说的太详细，我曾经也细致到单个字段，但是发现效果并不好。既浪费时间，而且也没有人能耐着性子那么长时间都集中注意力听你BB，所以捡主要的讲即可。如果你没听明白，没关系，我再稍微具体点跟你说清楚。如果我说完，你没问题了，就视为你认可了。

A： 此时可以搬出用户的需求、市场的需求、竞品的分析等等来说服研发，最后来一句：我们所做的每一个功能，都是经过深思熟虑的，这你放心好了。但是千万不要说，这是我们定好的，你们执行就行了，不用管他合不合理。如果你真的这么说了，研发人员内心已经把你捅了N多遍了。强压之下给你来个罢工，那你就没辙了。

A： 如果你已经考虑到了，那最好，请直接陈述即可。如果你本身没有考虑到，这时就要赶紧服软。因为当你说这个功能的时候，程序猿同学已经在脑海中遍历一遍了，他们是思维严谨的单线程生物，只要他们提出来的，绝大多数都是会真的产生影响的，你也没必要嘴硬死不承认。此时最好的方式就是赶紧说好话：哇塞，猿哥想的好全面啊，我都没有想好，我回去要好好补上，多跟猿哥你请教请教。那这一块等我补上之后再发出来大家看看，成不？

A： 可爱的程序猿不是执行任务的工具，他们很有自己的想法，所以当他们提出这个问题的时候，多半其实已经帮你想好解决方案了。你只需要说：具体要的嘛，就是这么一个功能，猿哥你有什么好的意见，如果实现简单，那当然是按照你的方式来执行了。可是前提要满足我这个功能哦。

A： 遇到这样的问题，就好比产品人员心理出现了个晴天霹雳。。来，哥我们慢慢说，哪里不符合逻辑了，如果确实是有逻辑漏洞，如果影响比较大，建议会议结束吧，产品人员回去好好反省去吧。如果是小的漏洞，那我们就商量下怎么弥补了吧。

惊险过后，继续开会，下一个功能，又是一次PK的开始。

评估工作量的时候，我个人基本是不会插嘴的，除非是大家需要回顾刚才的功能点，我会再简单帮大家梳理一下。毕竟研发需要多久，研发心里面更清楚，大家都是一个团队的，合作就是建立在互相信任的基础上的，也没有必要特别去压迫别人的时间。

会议结束，此时通常一个半天就过去了，产品赶紧要把会议中承诺要完善的部分完善起来，因为接着就要进入开发了，如果迟迟不调整，等于间接压缩了研发的时间，这样大家心情就不美丽了。

跟研发人员合作这么多年，我始终认为，研发哥哥们，是一个很可爱的群体，虽然经常会被我给坑到，也会经常背后吐槽（没关系，只要你们开心，尽管吐槽好了），但是真心来说，只要你本身做的够好，研发人员基本不会故意推脱工作。偶尔不开心，哄一哄很快就没事了，所以我个人特别喜欢跟程序猿混。