评审会上产品经理常被怼的话

1、这个功能感觉没用啊，为啥要做

要把需求背景、来源说清楚，不仅要告诉技术怎么做，还要告诉技术为啥做，这样技术做起来有目的，甚至可以提出一些他们好的想法。

2、这个功能做不了

是真的做不了，还是不想给你做，这个你要考虑清楚。这就要求产品经理有一定的技术思维，知道哪些能做，哪些做不了，才能在设计的时候有的放矢，也才能不会被技术忽悠。

如果是不想给你做，那你就要考虑一下是否得罪他了，可以私下找他沟通一下，说一下为什么做这个需求，做这个需求有哪些好处，晓之以情动之以理，如果实在不行，那就公事公办，找他领导反馈情况，做到先礼后兵。

3、这个设计方案不合理，应该这样设计

技术就是单纯的觉得你的方案设计的菜，没其他内容，这个时候你可以和技术讨论，但要有理有据，不要我觉得。比如你可以引经据典，比如就近设计原则、路径最短原则等，我之前有写过尼尔森十大可用性原则，里面有说一些常见的可用性原则。

4、你有没有考虑过XX情况

这个时候，可能是你逻辑不严谨，遗漏了一些内容，技术可能是善意的提醒，也有可能是恶意的挑刺，但你一定要逻辑严谨。

如果临时反应够快，可以说自己考虑到了，还没来得及写上去，或者说还没说到。把节奏把控在自己的手里。

5、这个需求改动太大了，真的要改嘛？

技术这么说的意思是觉得改动量有点大，可能会牵涉到很多关系的系统，确认一下是否有改动的必要。技术说这种话，多少有点不情愿的意思，毕竟这样大的改动，说明以前的工作内容大部分可能都荒废了，这种情况下，产品经理就要把来龙去脉说清楚，把需求的背景说清楚，争取得到技术的理解与支持。

这种情况下，也尽量给技术多留一些时间，因为改动太大，如果工期再紧张，很容易出问题。

6、这个需求又改回去了，那你当初为啥要改呢？

当然，我们需求尽量不要改来改去，这样不仅会降低技术对我们的信任感，导致以后的技术工作不好开展，你自己也会觉得改来改去不好吧。如果遇到不确定的功能模块，可以采用a/b test的方式，也尽量不要做了以后又改回来。

如果遇到这种情况，可以安抚一下技术的情绪，或者找个借口，说当初是XXX要求改的，我也没办法，我当初也是极力阻止不要这样改，但改了以后发现说句并不好，我觉得还是改回来比较好。

7、这个地方能不能改成XXX

如果有业务参加的需求评审会 ，她们可能会临时该需求或者加需求，这种情况下，如果是小的需求，可以顺手给他改了，如果改动比较大，尽量不要修改 ，因为牵一发而动全身，可以说放到下一个版本里面去修改，尽量不要在这个版本修改，否则导致开发的周期变长，整体都得从头再跑一遍。当然，如果确实需要改，那也只能重新修改了。

8、你的需求不够完整，缺了很多东西

如果真的是缺了很多东西，那你就要检查一下，到底缺少了哪些东西，然后就事论事的和技术讨论一下，如果真的是缺少了很多东西，那你就要加强一下自己的能力，甚至可以在评审会之前和玩的好的技术沟通一下，让他从技术的角度给你看看，看看有没有遗漏啥东西，这样有保障一些。也可以在线下的时候，就搞定一些评审会的关键人物 ，一般搞定这些人物之后，其他的人物就会没啥问题了，那你的需求评审会也就是走个过场。

如果就是缺少一两个东西，可以和技术当面沟通确认一下，如果简单，就当面定下来，如果不是很简单，那你可能就需要线下再自己补充进去了。

你们还觉得有哪些技术常常怼人的话语呢？可留言讨论。

点击“阅读原文”

查看更多干货