产品管理团队的快速扩充：用简单的统一框架进行沟通

2017-01-15 10:28:00

Sean Lynch在2012年至2015年间曾在Dropbox担任产品经理的工作。在那里他目睹了Dropbox的快速发展以及随之产生的项目多产品团队难以应对的问题。后来Dropbox的产品团队想到了一个简单的框架来快速扩充团队并加快项目进度，他觉得这个经验值得很多初创企业效仿。

2016年我花了很多的时间来担任辅导、咨询、顾问的工作。其中很多的交流都牵涉到产品管理团队的建设问题，通过这些对话，我对过去担任PM角色中学到的经验教训进行了反思。其中一些经验属于常识，为我交流过的大多数技术公司所共享。但有的就没那么明显了。

对我来说，其中最有价值的经历之一就是看着Dropbox的快速扩充（无论是客户还是员工规模），并且目睹了伴随着这些数字的增长而引发的问题。现在，我想谈谈我们为了让不断壮大的公司上下在产品研发过程中保持共识而形成的框架。

先交代一下背景。

我在Dropbox的大部分时间里，产品团队都是由我们的联合创始人和CTO领导的。他深入参与了产品研发的方方面面，包括工程、设计以及产品管理等。在早期日子里，几乎每一项产品决策他都要审核。说他很忙都是轻描淡写了，但是这种做法在我们的团队规模相对较小时是有效的。

但随后公司开始疯长，我们开始同时展开了很多项目。到了2014年早期时，我们遇到问题了。

一天就只有那么多的时间，但我们的CTO的时间全都被预约完了。PM想找时间见他寻求所需的反馈和批准很难。项目开始给人以拖沓的感觉然后陷入了僵局。大家不清楚他什么时候应该参与，什么东西的确需要给他过审，也不知道哪些反馈才有用。PM开始尝试绕开这些过程，导致领导层与团队所做的事情无法同步。所有人都觉得很沮丧。

为了解决这一问题，我们的产品经理Anand Subramani提出了一个简单的框架来标记项目生命周期的阶段。这三个阶段每一个都会有一次相关的审核，旨在回答一个特定的问题：

阶段0——我们要解决的问题是什么？为什么值得解决？
阶段1——我们打算如何解决这一问题？
阶段2——我们的解决方案看起来是什么样的？

先澄清一下，这里并不是说这个框架对所有项目或公司来说就是最完美的，我们也不提倡一定就要严格按照它执行，这显得教条主义。有时候针对小一点的项目团队会把阶段0和阶段1合并到一起，或者在阶段2产品发布前进行多次审核。对发布后迭代的目标进行审核并寻找改进机会也是有价值的。

不过这个框架最有价值的部分是三个微妙但至关重要的功能，你在定义自己的这些东西时是一定要牢记于心的：

1、阐明针对特定项目要提出并获得反馈的正确问题

Dropbox的核心价值观之一是仔细琢磨细节。在审核产品时，有很多细节需要推敲，视产品是否在研发当中而定，其中有的未必就是合适的。这个框架在任何时候都定义好了该关注什么的共同期望。

比方说，在这个框架之前，提出示意图中文本应该如何措辞的问题是很常见的。有了这样一个框架的话，就可以很清楚征求这类反馈是不是太早了，但同时这也会让领导层安心，知道一旦到了那个阶段项目就会回到那种层面的反馈上。在介绍清楚情况之后，审核者几乎马上就会自我批评说：“哎呀，我在阶段0给出了阶段2的反馈了，我的错。”

2、就问题达成一致与就解决方案达成一致要分开

在开始研究解决方案之前先就要解决的问题达成一致，我自己是很重视这一点的重要性的，尤其是当问题在企业内部存在很多利益攸关者时。

如果没有这个的话，往往就会看到当项目开发到后面时，由于利益攸关者对开发的产品是否就是他们想要发布的东西意见不一而导致开发进程被拖累。这是因为利益攸关者没有对真正的问题是什么达成共识。通过定义好问题并且在开始处理前取得一致，团队推进项目时对自己做对了的东西的信心就会大很多。

3、简单到整个公司都可以采用

这里的核心经验是，简明一致的沟通在对于大型团队一起高效协作非常重要。

讲同样的语言可以让公司的每个人马上就能理解项目进行到了生命周期的什么阶段。做工程的会知道团队需要多大的规模，紧迫性如何，做支持的会知道项目什么时候会影响客户，而营销团队知道什么时候整合营销材料还为时尚早，因为项目可能还会有很多的变更。

实际上，为了处理一些问题（比方说，发布或者发布后的迭代是可以增加一个相应阶段的），我们的确尝试过对这一框架进行重新设计。重新设计的首次尝试引入了一个新概念，这个概念导致理解起来更困难了。额外的复杂性避免了重新设计取代第一次的定义。

我们首先从一个项目尝试这个框架，然后再推广到一些项目，接着，我们的CTO开始使用这些术语（阶段x）。新框架几乎马上就被采纳了。我们很快就看到了效果：