本文编译自First Round Review，他们准备的文章既讲故事，同时还向创业者提供可操作的建议，以助力打造优秀的公司。这篇文章为我们介绍了流媒体音乐服务Pandora广告产品主管Jack Krawczyk的团队管理法则。
Jack Krawczyk曾就职于StumbleUpon和Google，有着丰富的工作经验。2013年Krawczyk加入互联网电台服务公司Pandora，负责广告产品团队的管理。他的工作不仅是要推出听众认可的智能广告产品，还需要带领团队快速地成长。
Krawczyk认为，领导一支产品管理团队首先做到以身作则。他在接手后立即投入到产品一线，参与到Pandora广告嵌入逻辑的重构。他说：“这个过程不仅让我更好地理解了产品如何运作，也让我真正认识到Pandora整个开发环节是怎样的。”
Krawczyk曾见证过许多创意演变成为真实的产品，也遇到过不少难见天日的失败品。他的团队经常能拿出创意十足的解决方案，但也有不少项目以失败告终。在这些经验的基础上，Krawczyk总结出6条具体的策略，帮助产品主管开发优秀的产品并培养杰出的产品经理。
1. 了解团队的邓巴系数
上世纪90年代，英国人类学家罗宾·邓巴提出一个理论：由于人类平均脑容量所导致的认知局限，一般人只能与150人维持稳定的社会关系。Krawczyk在管理中也运用这一理论，使每个人不需要处理与太多人的关系，确保同事之间交流的广泛而深入。
Krawczyk说：“我认为每个好的产品经理本质上都是领导者，只是没人向你直接汇报。但是产品经理必须激励那些并不算自己下属的工程师，同时还要满足公司其它利益相关方的需求。”管理产品经理的人则必须成为领导的领导，并且深入理解公司内部业务关系架构。以下是负责一支快速成长的产品管理团队时需要注意的几个关键点：
1.1和工程师搞好关系，让他们不仅知道该做什么，还知道为什么要这样做
Krawczyk说：“对于早期团队来说，工程师和产品经理数量的黄金比例通常是5:1。这个比例有利于产品经理和工程师保持足够亲密的关系，也让产品经理知道如何与工程师交流，如何激励他们，如何带来最大的产出。”
随着团队扩大，职能会变得更加分散。这时，PM和工程师之间的数量比就没那么重要了，取而代之的是双方关系的紧密程度。工程师不仅需要知道工作是什么，还要理解每个产品功能背后的决策过程。对于一支交叉职能的团队来说，了解一项工作的前因后果非常重要。Krawczyk说：“如果产品经理能够清晰表达出需要做的工作及其原因，那么他们最终就有可能会开发出惊艳的产品。”
1.2小团队需要更紧密的联系
Krawczyk建议，当一个产品团队在10人以下时，应该充分利用这种小规模的优势，尽可能让所有人聚在一起，开工作计划会议时可以邀请工程师和设计师也参与进来。在Pandora，这种方式不仅增进了同事之间的关系，也让产品经理在会后能对各方面情况有更加全面的了解。
在Pandora早年，前CTO兼执行副总Tom Conrad为所有参与Pandora产品开发的员工建立了一套“美元决策体系”(dollar-decision-making system)。每次季度会议上，来自公司各部门的参会者将讨论Pandora最重要的产品和创新点。为了确保员工的参与度，并对工作的优先级进行排序，每个参会者都会收到5“美元”，用于投资他们认为最关键的领域。尽管钱很少，但这种形式却促使人们仔细权衡自己手中的筹码。
1.3大团队需要重视流程
Krawczyk说：“我遇到的最大挑战之一，就是如何保持Pandora早期形成的合作机制，同时又不断调整，适应不断成长起来的专业化团队。”在Pandora人数不到500时，我们可以把所有负责产品的人召集到一起开会。但现在，公司有超过1600名员工，包括25个产品经理和主管，如果还用老办法只会导致混乱，有些话题被重复讨论，有时候部分参会者与会议内容毫不相干。
当你不得不为产品会议准备更大的会议室时，你就需要关注到决策流程了。
2013年Krawczyk加入Pandora时，只有3名PM负责广告产品。短短两年，PM的数量已经增加到了12人，其中既有产品管理的新手，也有具备十几年经验的老将，和他们一起工作的工程师还有55位。这些人都在Krawczyk的管理之下。
在产品经理数量接近两位数时，为了保持队伍的紧密联系和高效率，Krawczyk建立了一套“产品组经理”(group product manager)汇报制度，将12个产品经理分成3个功能组，覆盖到广告产品的各个方面：听众广告体验、广告分发技术、广告购买体验。每个组设置一名产品组经理，每组中有4名PM，每个产品都有专人负责。
这个结构使得团队行动更快，每次开会的内容更有针对性，将来PM团队进一步扩大也不用担心。Krawczyk说：“如果有很多人向你直接汇报，那你就没法对某一项具体事务做到深入理解，交流效果也会大打折扣。而且在这种工作方式下，作为管理者的你总会为工作增加障碍。你工作本应是为大家消除障碍的，而不是增加它们。”
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团队规模扩大而新增的文档。
在这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页面提出了一些新的要求，但是这个部门的产品经理看起来很困惑。于是他又进一步做出了解释，说明了之所以提出这些要求的完整背景。他说：“说明做出某个规定的原因比反复强调新规定的内容要容易得多，在大家充分理解之后，我们就能行动得更快。”（文/Yves-YAN）
- 本文固定链接: http://www.vicken.net/5587.html
- 转载请注明: vicken 于 vicken电商运营 发表
