第14章 产品评审团

The product Council

制定更及时、更可靠的产品决策

    即使对小公司来说，制定决策通常也是既耗时又费力的。产品公司需要一套机制让决策者和相关人员及时做出明智的产品决策。我认为成立产品评审团是最好的解决途径。
    我通常不热衷于出席会议或参加各种委员会，但是产品评审团除外。产品评审团让所有决策者坐到一起，为把产品推向市场共同制定决策，可以有效地加快研发产品的速度。
    组织产品评审团的难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队的具体工作，比如亲自参与设计产品。

不少公司都有类似的组织，但我认为最早提出这个概念的人是eBay前COO梅纳德·韦布(Maynard Webb)。多年来，我一直在实践中不断规范产品评审团的具体职责，完善其流程。

产品评审团的工作目标

成立产品评审团的目的是决定产品战略方向，从宏观上监督公司产品的研发流程，合理地配置资源。产品评审团不制订公司的商业战略，而是在给定商业战略的条件下，提出与之相匹配的产品战略。产品评审团的决策直接影响企业的运营。

产品评审团的成员组成

产品评审团由公司各个部门的管理者组成。虽然各个公司的情况不同，但通常都包括以下人员。

·首席执行官／首席运营官／部门总经理

·产品管理总监/副总监

·用户体验设计总监／副总监

·市场总监／副总监

·开发总监／副总监

·网站运营总监／副总监

·客户服务总监／副总监

    产品评审团的工作效果很大程度上取决于会议组织者的技巧。他必须不受干扰，善于阐明问题、促成决策。在大公司里，组织者通常由公司的产品负责人担任：在小公司里，则通常由老板担任。

要确保每个关键部门都有代表参加产品评审团，但最好把人数控制在十人以内。如果有的部门不止一人参加评审团，应该选一个人代表部门陈述观点。例如，销售总裁代表市场部发言，质检(OA)主管代表开发部门发言。

产品评审团的职责

产品评审团并不是设计和开发产品的团队，它的职责是监督产品研发流程，制定关键决策。它根据研发产品的四个里程碑来评审产品，制定决策。

1.评审产品战略和产品路线图，启动评估产品机会的工作，即选择值得投入精力的产品，请产品经理开始评估产品机会。

2.根据评估产品机会的结果，决定是否开始定义产品的解决方案。

3.评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。

4.评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。

注意事项

1.小公司的产品评审团通常负责评审公司所有的产品；大公司可能需要根据业务单位的大小，设立若干个产品评审团。

2.产品评审团不负责评审对产品细节的更新或修正。这是为了加快对细节问题的处理，保证公司业务运作流畅。

3.产品评审团不负责具体的产品设计工作。如果产品存在缺陷，应该由产品团队着手处理，然后重新提交产品评审团评审。

4.在2号里程碑处，由于产品解决方案尚未形成，不可凭直觉估算产品的成本．至多只能估计大致的项目规模；但是在3号里程碑处，应该仔细估算开发时间和成本，让公司上下做好准备。

5.尽量避免产品评审团讨论具体执行策略，讨论这些问题非常费时间。如果必须讨论。一定要控制好时间，不要影响产品评审团监督产品流程的主要工作。

6.产品评审团开会的频率取决于具体产品的进度，可以每个月开一小时会议，或者每个星期开两小时会议。

7.产品评审团还应该回顾、分析产品上市后的表现。可以在产品发布3～6个月后，请产品团队汇报产品的市场业绩表现，产品评审团可以反思之前的决策是否明智，今后应该如何调整。

8.每次评审会议，最好由产品经理向产品评审团汇报产品的进展情况。由产品经理的直接领导指导产品经理准备陈述内容，确保产品经理准备充分。在会议召开前，产品经理最好逐一向产品评审团成员做简要汇报，存在疑问应及时解决，避免在汇报过程中措手不及。

如果公司制定产品决策的效率太低，应该考虑组织产品评审团。产品评审团可以替代以往各种冗长的决策会议，大大缩短决策时间，制定明智、及时、透明的产品决荒。

何时估算项目成本?

    尽管软件行业早就有估算成本的传统，但直到今天仍然容易出现混乱的估算结果。我认为混乱的原因在于管理层总是希望尽早获悉成本信息，但开发人员往往要较晚才能精确估算成本(至少要等到具体的解决方案出炉)。结果，要么过早估算导致结果与实际出入很大，要么结果虽然准确，但远远超出预算，让管理层难以接受。
    我这里要介绍的估算方式虽然源自我提倡的产品研发流程，但同样能解决大多数公司的问题。
    开始研发产品前，应该先评估产品机会(参见第11章)。评估产品机会的目的是看产品创意宣称要解决的问题是否有价值。此时，解决方案尚未出炉，手头但有产品创意和待解决的问题，所以产品团队只能大致估算项目的规模(建议分成小型、中型、大型三个等级)。再根据项目规模粗略估算项目成本。虽然这种估算与实际情况会有出入，但通常不会出现跨级别的误差。
    确认产品机会有价值，粗略估算的成本也可以接受，管理层才能允许项目组着手定义产品解决方案。理想情况下，详细的产品解决方案还应该包含可供用户测试的高保真原型。
    在定义解决方案的过程中，产品经理和交互设计师需要一位开发人员的协助来评估不同解决方案的成本。然后产品经理和交互设计师根据评估结果进一步调整解决方案。待完整的产品说明文档形成后，即可根据文档细节生成详细、可靠的成本估算结果。
    此时，手头有了详细的产品说明文档、可信的成本估算结果，管理层可以很方便地决定是否开始开发产品。如果解决方案有问题，或者成本估算结果超出了预算，管理层可以马上叫停。如果决定开发产品，产品团队就可以在充分了解产品定义与成本细节的条件下全力开始工作。
    总而言之，我建议分两个阶段进行成本估算。在评估产品机会时做粗略估算；根据最终的产品说明文档做详细估算。