如何当好PM的PM——Pandora广告产品团队的管理法则（2）

本文编译自First Round Review，他们准备的文章既讲故事，同时还向创业者提供可操作的建议，以助力打造优秀的公司。这篇文章为我们介绍了网络电台服务Pandora广告产品主管Jack Krawczyk的团队管理法则。原文篇幅较长，分成4个部分连载，这里是第2部分，阅读阅读其余部分请移步：Part 1、Part 3、Part 4。

2. 把所有工作落实到文字——然后进行分类

Krawczyk说：“把想法组织成语言，再形成文字，然后根据文字进行讨论并不是一件容易坚持的事情。很多人认为把想法写下来是重复性的工作，即使写也是草草记录一下。这种观念实际上是错误的，团队的人越多，就越要做好文字工作。”

Krawczyk之所以得出这样的结论，是因为有时候他发现在开完每周例会之后，产品经理、工程师、营销人员和执行团队看起来对会议所作决定的理解完全不同。在随后和员工的交流中他发现人们的观点确实存在偏差。如果每次开完会是这样的结果，那集中在一间屋子里开会还有什么意义？想要解决这个问题，团队管理者就必须经常与员工交流，确保他们对于手头工作的理解是统一、清晰的。

在某次无果的会议之后，Krawczyk团队中一位产品经理想出一个办法：把相关信息提炼出来整理成一个分类文档。

有一天，Krawczyk团队中的一位产品经理注意到，开会讨论时，一边是工程师拿着他们的产品需求文档（Product Requirement Document, PRD）在陈述观点，谈论的都是各种预测和用户故事；而另一边，营销团队则在解释他们自己的策划案。双方的信息是不对称的。为了弥合这种断层，这位PM决定把PRD中与营销有关的信息摘录出来，单独形成一份文档，保留原有形式，方便查找原文。通过这种方式，他给出了一份对双方来说都有用且比较熟悉的文档。

Krawczyk发现了这一方法，于是就把它运用到了整个团队中。他说：“要想成为一名强大的产品主管，关键并不在于你自己能提出多少想法，而在于倾听团队的声音，发现最优的工作方式，并决定如何将其运用到整个团队中。”经过一段时间的发展，现在Krawczyk的团队主要利用4种类型的文档来保持团队中信息对称（按照从基础性到拓展性的顺序）：

• 执行总结(Executive Summary)：关于产品团队在做什么的一份总结性、概括性的文档。是对产品的高度概述，让人们能够以最快速度了解产品。
• Wiki页面(Wiki Pages)：由各个产品部门编写，在内网流通，居于核心地位，是对每个具体领域的高度概括，包括工程进度以及要实现的里程碑。Wiki页面有每个分支部门的工作进度图以及按季度划分的时间线。
• 产品需求文档（Product Requirements Documents）：一份全面的产品规划文档，包括产品标准，产品特性，用户案例研究等。是一站式、细致的产品计划。
• 发布计划文档(Lauch Plan Document)：一份包括所有执行计划的综合性文档，用来协调产品、销售、营销和开发等各个团队之间的工作。这是两年多以前由于Pandora团队规模扩大而新增的文档。

                                          Pandora的Wiki页面模板                                          

在这4类文档中，Krawczyk特别强调了wiki页面对于团队的重要性。产品经理可以通过wiki页面说明自己的工作内容，设定季度目标，其它人也可以通过这些页面来了解产品的发展历程。那么，一个高效的wiki页面应该如何完成呢？以下是一些实用的原则：

• 透明性和可见性。wiki这个词本身指的是“由用户群共同维护、允许所有用户添加或修改内容的网站或数据库”，基于这个特性，我们的wiki页面是由大家合作完成的，公司内所有人可见。在每季度和管理层进行的业务总结会议上，我们就可以通过wiki页面清晰地看到我们的团队做了哪些工作。
• 简明的总结和清晰的表达。“每个wiki都链接到一份执行总结，让所有的参与者能够实时能保持信息对等。”此外，PM还需要简单说明他们正在做的工作，以及做这项工作的原因，在和领导、同事或者顾客交流的时候可以快速引用，非常有帮助。
• 季度目标的设定。“我们不会具体到这个季度要做的每件事。因为在公司快速发展过程中随时会有变化，比如某个季度可能新招来二三十位新成员。因此，我会建议产品经理逐步把这一季度中所有的测试、项目里程碑或者新产品上线写出来。当然，产品开发周期常常超过3个月，通过wiki的方式可以促使PM把大项目切分成小的版块和阶段。”
• 明确定义下一步要做什么以及不做什么。“在每组的wiki上，会有产品发展规划，列出了即将开发和发布的所有产品功能。同时我们也要求写出不准备开发什么。这样可以在将来避免模棱两可，导致开发出一些本不想开发的功能。”

如果说文档对于产品经理可以用“关键”来形容，那么对于产品经理的领导来说，文档就是“不可或缺”的。

Krawczyk把自己看做整个产品团队的产品经理，这个团队就是他在开发的产品。“不论是说明公司的价值主张(value proposition)还是我对产品的修改意见，我都需要向团队解释我的理由，让PM理解决策过程非常重要，这样，他们才能在充分了解各方面信息后完成艰难的工作。因此，这些文档对我非常有用。”

3. 做好团队沟通的组织者

作为产品经理，你需要清楚别人是否真正理解了你们所达成一致的内容。你不仅要让大家完全理解该做什么，还要让他们知道所做的事情与最终目标有着怎样的关系。

当Krawczyk和一位产品经理意见不一时，他会先质疑是不是自己的理解出了问题。他说：“我发现很多时候我不同意某个方案是因为我对于问题本身的理解不够清楚。这时，我会向PM坦言我可能理解不到位。但是如果我认为我没有错，是PM提的方案不合适，那我会进一步分析，消除PM对于我所做决定的疑虑，最终达成一致。整个讨论的注意力都是放在问题本身，而不针对这个人。”

然而，如果团队还是不理解你，那就是你的错了。你是团队交流过程的组织者，你需要确保大家在某些问题上达成一致的，也可以选择一些问题让大家各自保留意见。

寻求最适合团队沟通的方式，确保每个人都能理解关键信息。

“人们在提产品需求时常常只说‘我要你做这个。’实际上，接下来非常重要的一步就是说明为什么要首先做这些。”

几个月以前有一次，Krawczyk在一个部门的wiki页面提出了一些新的要求，但是这个部门的产品经理看起来很困惑。于是他又进一步做出了解释，说明了之所以提出这些要求的完整背景。他说：“说明做出某个规定的原因比反复强调新规定的内容要容易得多，在大家充分理解之后，我们就能行动得更快。”

未完待续。在接下来2个部分中，我们会讨论到产品团队中的沟通机制和新人培养等问题，敬请关注。