评审前
将需求文档、流程图、原型提前发给有关人员，让大家知道评审的内容；<br>和核心参会者确认可出席时间并提前发出会议邀请，定好会议室；产品经理可提前到会议室进行准备。<br>
评审会上
讲解流程：需求背景-用户与需求-功能模块-流程-原型与交互-数据指标-资源和上线时间
先从需求背景或者用户故事说起，不要一上来就开始讲功能
在需求评审的开始阶段，首要讲解的不是具体的需求设计结果和功能点，而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉，这有助于大家建立初步的认知。从用户那边收集过来的，老板提出来的，业务部门提出来的，还是产品经理团队自己发掘出来的，以及需求产生的过程。<br>其次要让大家知道需求实现的目的和价值，这时更多都是预估的，若有相关的数据分析支撑，会更有说服力。价值能够量化的情况下尽量量化，用相对科学的方式去计算预估。不能量化的情况则需要定性的描述，把实现的目标和完成的标志说明清楚，这样大家就清楚的知道去实现的意义，价值越大，实现的必要性越高。
将需求文档内容分模块输出。有节奏和条理，控制好时间，阐述功能、流程和方案，并开展讨论
“总分总”的方式。可以先说明白整体步骤，先做什么，再做什么，最后做什么。然后再按步骤细评各个环节的细节，都评完后再阐述一下总的流程。
阐述逻辑时也一样，先讲述通用逻辑，后补充特殊逻辑以及一些异常情况。
控制时间：作为评审会主持人，除了交代清楚需求，控制评审的节奏和效率也是十分重要。一些与会议无关的话题，要及时收住，提示大家回归正题。（有时开发会陷入技术细节讨论，如果与会人员较多时，细节讨论时间过长时可以提示对方会后私下讨论）
记录重要争论点，评审中与会场所有人讨论做决定，如果会议中无法得到结果或者需要数据支持，则可以会议后通过下次评审或者通过书面形式进行；
确认需求目标，即功能上线达到什么目的，相关数据指标；
确认项目预计的上线时间和需要什么资源；
