需求评审
第一阶段：需求评审前——准备
对内：即产品经理自己需要的准备
准备一：对需要评审的需求背后原因进行深入思考和分析，尽可能选用对方的术语或业界常见表达进行阐述
准备二：整理输出相关文档
- 文档包含以下几方面——主要指PRD文档
- 需求评审背景及预期实现目标
- 需求来源、类型、涉及用户及使用场景
- 各种图：原型图、用户操作流程图、业务流程图、权限边界、特殊情况说明图等
准备三：确认参与评审部门人员及人数，并梳理人员之间、以及人员与需求之间的利害关系
准备四：敲定评审时间、地点及流程，并通知相关人员，同时通过邮箱或协同APP发送相关文档
准备五：针对可能出现的突发事件准备planB，将风险控制在合理范围内
对外：即参评人员需要的准备
准备一：浏览相关文档，掌握本次评审主要内容和预期目标
准备二：对于文档中存疑之处进行标记，如果有时间机会直接找产品经理进行初步沟通
准备三：按时参加评审
注意：在需求评审准备阶段，大部分人认为这是产品经理的活，但如果每一个参与人员都在向着高效易懂、需求及时落地的目标前进，则要求每个人都需要在自己的主动边界内做出准备工作。
第二阶段：需求评审时——行动
动作一：简洁直接的开场白
- 表明会议目的、背景、预期目标（多次重复讲，让参与人员脑子里形成共识处于同一愿景下）
- 介绍会议流程及有关规则（给予对方清晰界限）
动作二：切入主题——讲需求
- 按照流程顺序，用对方听得懂的表达讲解需求（简洁、清晰，逻辑衔接，不拖泥带水）
- 需求背景、场景、涉及用户
- 相应图标展示
- 数据埋点及流动
- 异常情况，边界限制
- 预期实现目标
注意：把控时间，主次分明;表达清晰简洁，逻辑衔接
动作三：提出质疑——讨论
针对需求不合理或有疑惑之处，在场人员提出质疑，进行讨论
- 产品经理需要静心倾听，过滤有用信息，并思考解决方案
- 提问人员针对问题思考漏洞并提出解决方案
注意：把控时间，对于争议较大的需求暂时停止讨论，私下双方思考之后对接
质疑不是故意找茬，也不是推卸责任相互扯皮甚至人身攻击。质疑的目的是为了弥补产品经理在需求规划时未思考之处或现有能力无法完成，是为了让团队顺利地讲需求落地，实现迭代或者盈利；质疑的同时双方需要思考如何解决问题，并非提出问题就到此结束。具体的方案也可私下碰面也可直接提出。这个过程中，切忌将私人恩怨掺入其中。
动作四：总结回顾——加深印象
剩余一定时间将本次评审进行总结，再次阐明会议目的、预期目标以及后续主要工作:表明部门之间的利害关系及责任风险、如有疑问会后私下对接
动作五：向与会人员表达谢意
注意：需求评审时作为主要发言人产品经理既要准确清晰传达会议内容（需求），也要照顾参会人员。这里需要日常积累演讲的技能、与其他部门交流的沟通技巧，并时刻提醒自己需求评审的目的是推进需求落地，不是为了争强好胜。
第三阶段：需求评审后——跟进
- 跟进一：总结记录已明确、未明确内容，简要输出会议纪要
- 跟进二：将会议纪要和谢意再次发送至每位与会人员，并再次确认需求
- 跟进三：针对会议中未解决的需求和有关人员对接，并及时更新进度，告知与会关键人
总结：
需求评审不是一场唇枪舌战，更像是一种共识检查，不仅仅需要产品经理做出努力，而且参与其中每个人都要明白我们的共同愿景、预期目标以及所需工作是什么，通过这次检查，发现其中问题并改进，大家该如何互相友好配合，从而实现需求落地。