听了一场可怕的需求评审，原以为这是产品新手才会出现的问题，却发现一些产品老鸟身上一样严重。
所以，如果没有自我觉察，身边也没有人及时指出，那么这个问题可能会伴随你很长一段的职业生涯。今天拆解出来，希望对你能有所帮助。
产品经理某种程度来说，确实是靠嘴吃饭，每天都奔走在收集需求、沟通需求、需求评审的路上，循环往复。而需求评审，就是产品经理所有工作能力的集中体现。
很多产品经理却连一场需求评审都开不好，犯了以下某个错误，甚至频频踩雷。
1、需求评审前，不介绍需求背景
严格意义上来说，产品经理是最清楚你自己需求的背景、需求方诉求、需求结构、应对方法以及方案风险的人。所以，在需求评审时，你是知道所有来龙去脉的人。但，下面听评审的人，他们并不清楚。
1、缩小谈判对象范围。评审的开始，你一定要确保这场会议中的所有人，对这件事情的理解是一致的；确保大家都能理解，做这件事的意义所在。【为了大家的XXXX】，人类都是受目标驱使的动物。
确保大家理解一致，给在听众赋予意义，并不是为了听众，而是为了主讲人你，为了你自己。通过讲故事的行为，缩小自己的谈判对象范围，把大家画在一个小圈圈内、在共同的语义下探讨问题，保证你交流的顺畅度。
否则，你会在后续的评审环节，不断的听到有人提问，“那我们为什么不用XXXXX”，这就是因为大家不在同一个立场，总会基于自己的立场，不断的去挑战你。
2、去解释，而不是说服。即使遇到挑战，也不要抱有说服人的心态，而是用解释的心态，解释原因即可，自己或许真的有哪些没考虑到呢。有说服就有立场，有立场就会有对立，有对立就会有矛盾。一定不要被激怒。
3、赋予意义，不要偷懒。最后，在解释做事理由的时候，千万不要说【这是老师的要求】、【这是业务的要求】，即使这就是我们产品经理的日常，但赤裸裸的搬过来，就是偷懒的行为，是对自己需求的不负责，也没发挥自己的主观能动性。
老板要的仅仅是【需求满足】，具体的实现方案，这不正是产品经理的职责所在，赋予你的产品意义，赋予你的产品生命力。
2、需求评审前，不做需求调研
这是一场需求评审，不是需求调研会、不是需求沟通会！这就意味着，需求评审只是一场个人表演秀，很多工作你应该在需求评审前，就已经完成了。这是一场确定性的演出，而不是一场茶话会式的讨论。
这就意味着，在评审会之前，产品经理就应该已经完成了以下工作：
1、对业务，了解需求，提供解决方案。接到需求之初，你就要去了解业务方需求的背后，真实诉求是什么；去评估业务方给的方案是不是合适。毕竟需求方要的是【满足需求】，而不仅仅是局限于他们历史经验的【解决方案】。相信我，他们不会拒绝更好、更专业的解决方案。
2、对开发，投石问路。了解目前开发手头上有哪些事，积压哪些需求；最好正式评审前，派个先锋探探路，和对应的前、后端开发问问，这个需求实现难不难、有没有其他解决方案，哪怕只是中午一起去吃饭的路上问几句，也是可以的。
3、对自己，检查粮草。我们自己的粮草怎么样，我们的需求是否准确，原型是否画好了，其中逻辑是否想的清楚了，至少保证评审时，已有的内容不要被开发问住。死在评审现场的感受，你一定不想过多体验。
3、需求评审后，不建立自己的需求跟踪矩阵
需求并不是评审完就截止了、就交付完成了。需求评审中，你会进一步了解当系统的建设情况、对需求的满足程度，去评估后续是否要调整的需求方案，有哪些需求需要调入需求池，哪些需求是要调出需求池的。
甚至，如果你在小公司，公司可能没有项目经理的岗位，产品经理就要兼职项目经理，时刻跟踪自己项目进度，是不是有什么异常、有什么风险，而不是等到需求交付的最后一刻，发现暴雷，然后带伤上线或者急着版本回滚。
建立自己的需求矩阵，可以更好的帮你了解自己产品地图的规划，明确各个需求的优先级，分配自己的时间投入、资源投入，而不是眉毛胡子一把抓，所有需求都是通通“重要”。
下一场需求评审会上，面对开发“砍需求”，你才会有所依据、有所取舍，否则，你只能跟开发硬刚，“都重要、我都要”。
如果你想了解如何写prd，戳《如何写一篇开发能看懂的 PRD（需求文档）》；
如果你还有什么内容想了解的、什么坑想避的，可以下方留言。
嗯，以上，祝我们早日成为一个不盲目搬砖、不堆功能的产品经理。
