文 / Marty Cagan 译 / 黄捷文，唐丰能

Marty Cagan是享有世界声誉的产品管理专家，曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享，描述了产品开发需要遵循的产品原则以及成立产品评审团的必要性。

产品原则

产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是一系列明确的、体现团队特色的产品价值准则。

每次加入新团队，我要做的第一件事都是制定产品原则。这意味着要决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。

产品原则不是产品功能的清单，不依赖于任何单独的产品，而是整个产品线的战略指南和公司的价值宣言。好的产品原则还可以激发设计产品的灵感。制定产品原则的过程也是学习的过程，可以从中了解新公司的企业文化，以及公司创始人设立的企业目标。产品原则是一套价值判断的框架，帮助公司作出正确的决策。

举例来说，某电影网站的产品原则是相信社区用户的影评比专业人士的影评更有价值。当某家制片厂想借网站发表评论时，产品团队就可以根据这条产品原则决定是否采纳。产品原则是否公开因公司而异。它既可以用做团队内部的指导工具，如产品战略文档，也可以公开给客户、合作伙伴、投资人，用于向公众宣传公司的理念。此外，产品原则还可以用来团结产品团队，让产品经理、产品设计师、开发团队和营销团队形成共同的价值观，在认识上保持一致。这是任何产品说明文档都做不到的。注意，只罗列出产品原则还不够，还要按原则的重要性排序。所有产品都要既易于使用又安全可靠，但总有需要优先考虑的原则。最重要的究竟是易用性，还是可靠性？

[caption id="" align="alignright" width="150" caption="打造用户喜爱的产品"][/caption]

• 制定产品原则时，容易出现以下两类错误。
• 原则过于空泛，失去了指导作用。

把设计原则误当成产品原则。比如，为用户提供清晰的导航路径(方便用户完成下一步操作)属于常见的设计原则，不是产品原则。

如果你所在的团队还没有制定清晰的、有关产品理念的产品原则，那么应该把大家召集起来，花点时间来讨论分析，确定团队最看重的价值理念。

解决意见冲突

不少产品经理向我抱怨，他们受够了没完没了的会议(既无议程也无结果)，以及会议中的那些争论和冲突。公司高管还时不时打断会议进程，扔下没头没脑的意见，拂袖而去，留下他们丈二和尚摸不着头脑。

这种情况在产品决策过程中经常发生，原因主要有以下几点。

• 每位同事对产品都有自己的看法。
• 大家都非常在乎产品，明白公司盈利得靠用户，只有产品才能吸引用户。
• 许多人以为自己比其他人了解目标用户，事实上并非如此。

另外，产品团队大多不必向产品经理汇报工作，产品经理没有管理产品团队的实权。在需要产品团队的配合时，产品经理只能摆事实、讲道理，不能强制执行。所以产品经理总觉得施展不开拳脚，非常沮丧。

有时大家各持己见，僵持不下，只能请高管出面定夺。出现这种局面，说明沟通方式有问题。产品创意在辩论中可以得到完善，但前提是大家形成一致意见。请高管出面决策、解决冲突会激化团队内部矛盾，得不偿失。

制定产品决策的过程中存在的困难着实不少，且是不可避免的，因为建设性的辩论和论证是定义优秀产品的必由之路。不过即使认识到这一点，我也很难把争论当成一种享受。

为了鼓励创新，改善讨论效果，同时降低外界干扰，在作产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点上达成共识。

• 究竟要解决什么问题？
• 要为哪类人物角色解决这个问题？
• 产品要达到什么目标？
• 每项目标的优先级是什么？

在我看来，每当团队内出现严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。

比如说，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性，还是用户隐私？只有先统一对产品目标和目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。

务必认真分析产品目标的优先级(从最重要到最不重要逐项排序)，让团队达成共识。切不可把所有目标都贴上“关键”和“重要”的标签。一定要区分什么最重要，什么第二重要……

我常被请去解决产品决策中出现的争议，发现多数团队跳过了这关键的一步。由于缺少基本评估标准，每个人对目标和优先级的理解都不同，大家往往情绪激动，在细枝末节上争执不下。

即使大家已经达成共识，也应该在讨论开始前再次予以强调，最好把目标按优先级顺序写在白板上，这样每位同事都可以看到评估方案和制定决策的确切依据。

制定决策的过程和依据必须完全透明，不要让人觉得你只凭直觉判断。务必告诉大家决策的依据和理由，清楚地展示每一个决策环节。

激烈的会议争论会影响大伙的斗志和工作效率。如果再出现这种情况，请先回顾产品目标和目标优先级，确保大家达成共识。

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

即使对小公司来说，制定决策通常也是既耗时又费力的。产品公司需要一套机制让决策者和相关人员及时作出明智的产品决策。我认为成立产品评审团是最好的解决途径。

我通常不热衷于出席会议或参加各种委员会，但产品评审团除外。产品评审团让所有决策者坐到一起，为把产品推向市场共同制定决策，可以有效地加快研发产品的速度。

组织产品评审团的难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管干预产品团队的具体工作，如参与产品设计。不少公司都有类似的组织，但我认为最早提出这个概念的人是eBay前COO Maynard Webb。多年来，我一直在实践中不断规范产品评审团的具体职责，完善其流程。

产品评审团的工作目标

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

产品评审团的成员组成

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

• 首席执行官/首席运营官/部门总经理
• 产品管理总监/副总监
• 用户体验设计总监/副总监
• 市场总监/副总监
• 开发总监/副总监
• 网站运营总监/副总监
• 客户服务总监/副总监

产品评审团的工作效果很大程度上取决于会议组织者的技巧。他必须不受干扰，善于阐明问题、促成决策。大公司里，组织者通常由公司的产品负责人担任；小公司里，则由老板担任。要确保每个关键部门都有代表参加产品评审团，但最好把人数控制在十人以内。如果有的部门不止一人参加评审团，应该选一个人代表部门陈述观点。例如，销售总裁代表市场部发言，质检(QA)主管代表开发部门发言。

产品评审团的职责

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

它根据研发产品的四个里程碑来评审产品，制定决策。

1.

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

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

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

注意事项

• 小公司的产品评审团通常负责评审公司所有的产品；大公司可能需要根据业务单位的大小，设立若干个产品评审团。
• 产品评审团不负责评审对产品细节的更新或修正。这是为了加快对细节问题的处理，保证公司业务运作流畅。
• 产品评审团不负责具体的产品设计工作。如果产品存在缺陷，应该由产品团队着手处理，然后重新提交产品评审团评审。
• 在2号里程碑处，由于产品解决方案尚未形成，不可凭直觉估算产品的成本，至多只能估计大致的项目规模；但在3号里程碑处，应该仔细估算开发时间和成本，让公司上下做好准备。
• 尽量避免产品评审团讨论具体执行策略，讨论这些问题非常耗费时间。如果必须讨论，则一定要控制好时间，不要影响产品评审团监督产品流程的主要工作。
• 产品评审团开会频率取决于具体产品的进度，可以每月开一小时会议或者每周开两小时会议。
• 产品评审团还应该回顾、分析产品上市后的表现。可以在产品发布3~6个月后，请产品团队汇报产品的市场业绩表现，产品评审团可以反思之前的决策是否明智，今后应该如何调整。
• 每次评审会议，最好由产品经理向产品评审团汇报产品的进展情况。由产品经理的直接领导指导产品经理准备陈述内容，确保产品经理准备充分。在会议召开前，产品经理最好逐一向产品评审团成员做简要汇报，存在疑问应及时解决，避免在汇报过程中措手不及。

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

何时估算项目成本

尽管软件行业早就有估算成本的传统，但直到今天仍然容易出现混乱的估算结果。我认为混乱的原因在于管理层总是希望尽早获悉成本信息，但开发人员往往要较晚才能精确估算成本(至少要等到具体的解决方案出炉)。结果，要么过早估算导致结果与实际出入很大，要么结果虽然准确，但远远超出预算，让管理层难以接受。

这里要介绍的估算方式虽然源自我提倡的产品研发流程，但同样能解决大多数公司的问题。

开始研发产品前，应该先评估产品机会。评估产品机会的目的是看产品创意宣称要解决的问题是否有价值。此时，解决方案尚未出炉，手头仅有产品创意和待解决的问题，所以产品团队只能先大致估算项目的规模(建议分成小型、中型、大型三个等级)，再根据项目规模粗略估算项目成本。虽然这种估算与实际情况会有出入，但通常不会出现跨级别的误差。

确认产品机会有价值，粗略估算的成本也可以接受，管理层才能允许项目组着手定义产品解决方案。理想情况下，详细的产品解决方案还应该包含可供用户测试的高保真原型。

在定义解决方案的过程中，首先产品经理和交互设计师需要一位开发人员的协助来评估不同解决方案的成本。然后产品经理和交互设计师根据评估结果进一步调整解决方案。待完整的产品说明文档形成后，即可根据文档细节生成详细、可靠的成本估算结果。

此时，手头有了详细的产品说明文档、可信的成本估算结果，管理层可以很方便地决定是否开始开发产品。如果解决方案有问题或成本估算结果超出了预算，管理层可以马上叫停。如果决定开发产品，产品团队就可以在充分了解产品定义与成本细节的条件下全力开始工作。

总而言之，我建议分两个阶段进行成本估算。在评估产品机会时做粗略估算，根据最终的产品说明文档做详细估算。

Marty Cagan，作为负责定义和开发产品的高级经理人为多家一流企业工作过，亲历了个人电脑、互联网、电子商务的起落沉浮，致力于通过写作、演讲、培训帮助客户打造富有创意的产品。

本文节选自华中科技大学出版社《启示录：打造用户喜爱的产品》一书和作者的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢华中科技大学出版社与Marty Cagan先生授权。

本文选自《程序员》杂志2012年04期，未经允许不得转载。如需转载请联系 market@csdn.net

《程序员》2012年杂志订阅送好礼活动火热进行中