需求评审被boss、开发、测试、运营、设计围攻，要不就是需求不靠谱；要不就是需求逻辑、技术实现没有考虑清楚。那么我们如何避免这种情况发生？

需求评审时由整体到部分的介绍，由总到分

比如：先讲整体的需求背景、需求目的，页面逻辑，再一步步沉浸到细节的逻辑设计上。

（1）业务场景

不要一上来先就看流程看原型。对于研发，他们职能的视野局限着他们对业务的了解，产品不把场景讲清楚，上来就是方案，懵逼了。比如：购物流程太繁琐，数据显示很多用户第二步、第三部就放弃支付，最终成交率才10%。（购物车销售漏斗）

（2）目标、目的

比如：转化率提升3倍，公司收益，用户体验吧啦吧啦。

（3）方案

打算怎么做？目前方式是否可行？还有没有更好的方案？

几点必须要注意：

• 需求背景需求目的必须是建立在理解公司的目标和发展愿景之上；
• 能清晰地告知团队，达成目标和完成产品指标，将会如何增强公司的整体战略部署；
• 把团队看作为公司服务，以及连接其他团队的力量。

需求评审不是让PM去说服程序去编码的而是就某个问题搞出一个最优的方案出来，能完美解决问题，且投入少（人力、时间、费用等资源），收益符合预期。

我们不可能就每个目标（每个功能都应该有目标），把需求方、开发等职能召集在一起头脑风暴，而是委派产品经理用自己的专业知识、经验、调研就这个问题先提出一套方案（产品经理存在的价值就是为了解决问题），这并不是说PRD（or MRD）就是唯一可行的且必要要执行的方案。

产品经理应该通过鼓励每个团队成员发表看法、暴露分歧、再调节冲突，来最终形成有团队共识的决策。也就是说，尽力确保每个成员都同意执行当前计划。产品经理自己可以有好的创意，但重点不应该是让团队盲目地执行产品经理的想法。恰恰相反，

搭建一个流程，和团队一起在充分的认同下，做好协同决策。保证团队在交付产品给用户的工作中不会踩坑。

 此外，表达更需要结构化的表达。

什么是逻辑化结构化表达？

大家在讲一件事情的时候比较容易有代入感，当我们在描述一个非常复杂的话题的时候通常可以采取两种结构去描述，Inductive和Deductive，这两种不一样的描述方式，可能会带来一些差异。

（1）归纳讲述

比如说，假设大家都知道普华永道是全球顶尖的会计师事务所，接下来就要描述它业务如何如何、为什么是业内第一，那最好的沟通逻辑结构最好就是将结论放前面。

（2）演绎讲述

如果要讲一个大家都不知道的事情，比如说：RPA如何应用在财务共享中心里面，让财务共享中心发挥最大的实际价值。像这样的问题呢，即便把结论放到前面，大家也不知道是什么意思。所以，要采用演绎讲述：就是从什么是RPA、什么是财务共享中心、到他们一般的应用场景再到如何使用，再到最后，点出最想点出的重点。这样会让大家更好地去理解。

完善产品本身的业务逻辑、页面逻辑

我们常常发生争论的其实不是目标，而是做法上的分歧。

（1）产品做法应该要有一套“理论”支撑，

可能是成熟优秀的竞品、可能是调研或者数据分析等，总之得找东西支撑观点和方案，在做方案的时候其实就是一个论证的过程，跟写作文一样，自己觉得写得很好，论据充分，中心明确，逻辑顺畅，别人看的时候可能就看出来问题。

如果在需求评审中，冒出其它方案来，看起来也能解决问题，有时候往往PM会不知所措，这种情况下更容易让现场失控。撕逼的时候，瞳孔放大，汗毛竖起，毛细血管扩展，是很难沉着冷静思考的。

所以，我建议PM有方案底稿后，先找更高阶的产品看看，指点下，也建议找找有经验的研发、测试、运营，特别是参与评审的领导（这个不用讲了吧）也问问他们的意见，争取把分歧消除在开会前，这样产品辛苦点，会议效率高一点。

（2）另外一点就是你应该想到别人可能发问的点在哪儿

别问为什么，因为我们是产品，我们要有从10种方案中论证出一种最优方案的本事。

写在最后

我觉得产品方案在评审的时候被人喷，是极好的，实打实的提升自己的产品能力。一怼二怼三怼的来回批斗和不断完善中，产品方案才能逐步完美，产出才能保证效果。

一个产品在想清楚的情况下，实现中还会因为这样那样的问题而无法达到预期状态，一个没有想清楚，怼一下就蔫儿回去的产品方案，又如何能保证线上的成功呢？

责任心的开发和UED才能如此以owner精神怼产品。而遇到这样的怼，是打是亲骂是爱的怼，遇到这样的虐，是虐恋的虐是打铁成钢的虐，应该开心有人帮忙发现这些问题，评审完马上针对这些漏洞找各种方法完善自己的产品方案和产品逻辑。

这样的过程才能真正做出好的产品，也才能真正建立自己在其它团队的影响力。而回过头来，当产品上线并有效果时，只能感谢这样虐的过程。

埃尔曼强调，没有任何一个产品会满足所有人。对的产品的诞生，都是一个不断调优和迭代的持续过程。产品需要撸起袖子帮助他的团队一起走过这场旅程。

总结一下被怼被虐不是一件坏事，如果有一天，需求实现方在评审上面对有问题的需求一句话也不说的时候，也许是内心深度对这个产品彻底失望的时候。而此刻作为产品才应该觉得悲哀。

产品经理既要有良好的直觉来判断对与错，也要擅长倾听早期测试人员或用户的反馈。同时，也要善于获得创始人或其他领导层的感受，来保证产品是在正确的方向上。

作者：次小吉，本职为一只产品汪、辅线运营。爱好广而杂，偶尔神经病，希望能与大家分享产品成长路上的血泪汗。

本文由 @次小吉 原创发布于人人都是产品经理。未经许可，禁止转载

题图作者提供