首先PM在产品管理中会各种会议帮助沟通决策，一般来说对PM有两个必须有的最基础的会议：

  1. 产品功能设计review会议；
  2. 产品版本迭代计划review会议；

为什么要Review？

产品的目标确定，需验证策略有效性的前提下，我们需要尽可能的保证执行上不出问题。功能设计和迭代计划就是这里说的执行的具体行为表现。那么review的本意是，集合团队所有人的经验智慧去预判用来验证策略有效性的方案的可行性，最大程度的避免因方案失误导致的结果不准确，造成对假设的判断失误，并因此增加目标达成的时间成本和机会成本。

那么Review到底Review什么？

一、产品功能设计会议

这个会议由PM提出针对产品目标的解决方案——功能设计/改进，并邀请团队KOL/Lead、功能执行小团队、所有PM和相关运营参与评审（自愿原则，但必须邀请）。

Review过程中，需要PM同步以下关键信息：

  • 目标是什么？
  • 针对目标的策略是什么？
  • 竞品调研分析
  • 人家针对这个是怎么做的
  • 背后的逻辑推测和假设
  • 数据
  • 我的解决方案是什么？
  • 与竞品一致的点
  • 创新点
  • 数据佐证
  • 我对结果预判？

会议原则：

讨论尽量避免主观信息，“我觉得”、“我认为”，摆事实，讲道理，用数据（不一定是数字）说话；
互相学习，珍惜每一次讨论的机会；
要求每个与会者发言，针对没有发言的同学下次邀请会议的优先级降低；
会上只对功能设计方案的合理性和可行性做预判和优化，不讨论时间评估，合入版本计划等信息；
通过review的功能进入需求池。

二、迭代计划会议

这个会议由PO（Product Owner）来发起，并邀请团队KOL/Lead、功能执行小团队、所有PM和相关运营参与评审，其中Lead和执行小团队必须参与。

Review会议包含两部分：

  1. 决定在这个迭代中需要完成哪些工作；
  2. 结合产品目标和团队产能合理挑选需求池中的backlog，并对所有工作进行优先级排序；

这些工作如何完成

在会议前期需要线下沟通讨论，对Feature进行切成最小单元为backlog，以日交付为优，会议上只做切分的合理性和执行人员的分配做确认。

会议原则

  1. 不要将会议当成需求的沟通会，我们提倡和鼓励线下互动；
  2. 不讨论迭代交付时间，每一个迭代周期是固定的，不能随意变更；
  3. 会议结束由PM将迭代计划发出；