需求评审和产品发布更加像是一个环节，这两个节点承上启下。
需求评审
需求评审是什么
需求评审的⽬的与形式
需求评审的过程
需求评审的经验和建议
产品发布
- 产品发布的过程
- 产品发布检查列表
需求评审是什么
定义：向各个利益相关⽅解释要做什么、为什么，动员投⼊，达成⼀致，开始⼲活。
- 前面都是从设计出发，而下面则是从流程视角出发
三个考量：受到什么影响、会有什么收益、需要什么投⼊。
一个是出钱的，一个是出力的，一个是用户
例子：自动续签功能
影响：开发、销售部门（自动续签影响销售的业绩）
收益
投入
利益相关⽅：开发（⼯程 & 设计）、资源（业务 & 财务）、⽤户、关联⽅。
在做任何事情之前，都需要知道，这是一件什么事情
需求评审的过程
背景 & 现状 & 问题
演示⽅案
- 一定要让所有人沉浸在这个过程里面
数据指标和期望
影响和伤害
成本 & 计划
真正的评审都是预先沟通的。
背景 & 现状 & 问题
具体的故事
真实的数据
与宏观整体的规划的关系
- 一定是要向一个更加宏观的问题负责
与其他同级别问题的关系
⼤概的投⼊和产出
真正的开会的时候，很多人会走神、玩手机，或者只能根据主持人的思路走
所以要讲一个好的故事
要有建立画面感的能力
先调动情绪建立感性，然后辅以理性和逻辑
演示⽅案
这是最核⼼的环节，也是最容易⾛神的环节
以总分总的推进逻辑来处理
介绍：⼤致的⻚⾯结构，⽤例列表（总）
表演：具体的功能逻辑，流程⽅案（分）
回顾：再看⻚⾯结构，⽤例列表（总）
不断吸引问题和疑虑，问题越多越成功
- 讲的还不错的一个标志是工程师在问具体的问题
演示的时候，要按照具体的用户例子来演示，而不是演示页面结构。要按照用户流程来讲，这样听众也更加能够发现问题
数据指标和期望
如何证明你对这个东⻄是深刻理解的？
如何证明这个事情成功或者不成功？
如何证明决策不是拍脑袋？
如何保证逻辑是完善的？
数据指标化
用户体验提升，这种也是可以量化的，通过目标能够表现出来
埋点
指标数据如何能够估准？心里会有一个经验判断，资深的产品经理都是能够判断的；另外也可以去查
影响和伤害
每个⼈都应该知道⾃⼰会为此付出什么，以及会被此影响到什么。
如果不能在此刻，收集到可能的负⾯影响，那项⽬很可能会出现崩盘的⻛险。
要有决策权限的⼈来判断，⽴场之争永⽆⽌境。
- 把正面和负面的信息都交给他
- 决策之前充分讨论，决策之后坚决执行，不要马后炮
成本和计划
⼤致的评估
- 即使不准，也要有一个评估，需要有一个模糊的判断
⾄少有不同模块的⽐例
⼤概可能的时⻓、步骤、优先级
各种可能的资源投⼊范围
- 大概需要哪些人投入
产品经理需要不停的输出产品设计吗？
乱象：产品不能断档，正确的阶段就是，就应该有一段时间，不做事情，就是要暂停，要观察
产品经理要有自己的价值观
需求评审的⼀些经验和⼼得
需求评审是胜利的凯歌，⽽不是冲锋的号⻆
提前做好准备，不要把问题集中在⼀次「会议」上
诉诸利益，⽽⾮「沟通」
（在需求优秀的前提下）优秀的评审：提前想得完善、⼤家不⾛神、讲得明⽩
态度：专业、投⼊、⾃信
需求评审中的对抗：牢记⽬标、认可动机、知错就改、线下讨论
- 目标就是和大家对清楚收益和目标，以及方案，除此之外都不是目标
- 先认可对方是为了用户体验、成本等动机
评审后应该有跟进
- 待澄清的、TODO 要记下来，要跟进
这里面一定要专业，文档、图、表达，等等，都需要有一个专业的态度，要投入，首先自己要投入
产品的发布环节
深⼊参与开发的发布过程，注意是否有严格步骤依赖和数据迁移前置⼯作
如果涉及停机，要提前跟⽤户沟通好；涉及其他系统，也要提前沟通。
准备验证⽤例（写下来）
⻆⾊、场景、环境、操作、结果、数据库表现
所有相关⼈的联系⽅式和备份列表
应对可能的失败，准备应对⽅案
发布后的持续⼼跳观察
记得有⼀个郑重的发布通知（和感谢）