我们从产品团队扩大中学到了什么

Paul Adams 是一位极具洞见和实战经验的产品管理者，对于互联网和产品的观察和理解都令人佩服。他曾就职于 Facebook 和 Google，现任 Intercom（为企业提供在线咨询和沟通工具的创业公司）产品副总裁。下文是他在今年年初的文章：《Lessons Learned From Scaling a Product Team》，讲述自己团队协作流程方面的经验和心得，长篇却实在，值得借鉴。

译文最初于五月发布，今早再读后勘误不少，故此重发。

---

从《精益创业》之类的书籍，到谷歌风投基金发表的一些文章，关于「互联网公司该如何打造产品」的见解层出不穷，却鲜有关于「创业公司应该从哪里并如何着手打造产品流程」的案例。

早在 2013 年，Spotify 曾经分享过他们是如何打造产品的，但其他公司的详细案例却难以寻觅。也许是因为现实太混乱，公开分享让大家感到不自在吧。而关于「如何打造产品」，我们看到的建议总是这样的：

• 虚空、抽象
• 基本上来自于专家顾问，而不是有过实战经验的人
• 缺乏快速成长创业公司的案例

相比起来，我们认为分享关于「我们在 Intercom 是如何打造产品」这样的内容显得更有价值。在过去的 12-18 个月里，从细节功能改进到大幅度设计改版，我们发布了超过 12 个版本，并从中学会了如何扩大产品团队，如何快速地打造深入细节的有价值的产品。

我们的流程可以分成 4 个主要部分来看：

• 系列决策指南
• 责任分明
• 轻量、透明、全面的 Roadmap
• 设定目标的文化

对于这个流程，请注意：

• 它不一定适合所有公司，因为它深受我们公司文化的影响。而你的公司文化肯定是不一样的，所以你的流程也应该不一样。
• 它绝对不是完美的，还在不断更新迭代中。当你看到这里时，也许我们已经有所调整。
• 它只适用于当下，以及我们现在的团队规模（4 位产品经理、4 位设计师和 25 位工程师）。当我们团队规模还小时，我们并不是这样进行的，而等到我们规模增大时，可能也不适用了。

无论如何，我们都希望能够通过这个分享引起大家的思考，甚至从根本上起到改进的作用。

1. 系列决策指南

为了扩大产品团队并让大家有所成长，我们需要建立一套标准来帮助大家更好地做出与目标契合的决策。因此，我们有了这么一套指南：

小步快跑强过大步远跳

不积跬步无以至千里嘛。我们相信，通过不断优化，解决那些最快、最小和最简单的事情，能让我们更快地达到目标，并让我们了解到是什么东西在真正起作用。我们的所有项目都会被分解成小而独立的版本，一步一步实现出来带给客户价值。每个人都应该相互督促，尽可能缩小项目范围并使之更为简洁，这样才能跑得更快，并且避免把时间浪费在不重要的事情上。

想到产品，我们就会想到每天和每周的目标

我们认为，Intercom 站在了风口上，但必须与时间赛跑，每天必须有所为。我们有一周目标，并将它分解成一天和一天以内的工作安排。每个成员在开始一天工作时都知道他们当天的目标是什么，以及如何与团队的一周目标和产品版本关联起来。

充分利用面对面协作

我们相信，面对面沟通能更快地解决问题。比起我们所见到任何形式，两个人在白板面前能碰撞出更多的想法，更快地达成共识。诚然，远程协作也有许多好处，但在（沟通）速度和效率上就差强人意了。因此，我们团队所有成员都共处在一个作战室，而且，我们有一个原则：能当面沟通就当面沟通。

不产生额外工作

使用白板和便利贴总比使用软件来得快。对于任何事情，我们都力争轻装上阵，用最少的软件工具来解决问题。如果管理一个产品需要用尽 Google Docs、Trello、Github、Basecamp、Asana、Slack、Dropbox 和 Confluence，那肯定存在严重问题。

看重结果，而非计划

计划很重要，却不可能完全按计划行事。计划是根据你目前所拥有的信息来制定的，但只有当你执行时才能完全明白这些信息是怎么一回事儿。好团队能及时吸收新信息并采取措施。哪怕环境万变，他们也始终都能随机应变，并在相同的时间限制内取得相同的结果。

2. 责任分明

我们以小型产品团队的形式展开工作，每队负责 Intercom 的一部分。这些小队包含产品经理、产品设计师、工程主管和 2-4 位程序员。对于这样的分工，责任分明的制度非常重要。

我们有这样一个机制：

• 如果问题分析不当，那罪在产品经理。产品经理务必保证完成足够的调研。
• 如果设计不能解决问题，那罪在设计师。设计师务必保证理解调研和问题的本质。
• 如果设计解决了问题，但与 Intercom 不合、不能交付最佳实践或者作用太弱，那罪在设计师。设计师务必保证理解我们的理念、模式和原则。
• 如果编程项目不能按设计完成，或者延迟交付，那罪在工程主管。工程主管务必保证理解要解决的问题和设计，并在开始敲代码之前合理、准确地安排计划。
• 如果产品有太多 bug 和有问题的用例，那罪在产品经理。产品经理务必保证团队在实际情况和极端情况中测试。
• 如果团队在修复 bug 上消耗太多时间却没给 Roadmap 增加价值，那罪在工程主管。工程主管务必保证每个项目都能改善所有代码质量。
• 如果我们不知道产品效果如何，那罪在产品经理。产品经理务必保证成功标准的定义和检测。
• 如果产品不能解决问题，那罪在产品经理。产品经理务必保证有个计划，逐步完善产品直至产品能完全解决问题。

产品团队的责任划分本身就是个灰色地带，对此，相互间的协作便意味着一个更好的（共同承担责任的）方式，所以团队自己就能解决（责任）问题。但当我们分析宝贵的时间都去哪儿了的时候，划清责任界限就变得至关重要。

3. 聚焦在轻量、透明的 Roadmap

我们的 Roadmap 是未来几个月的产品计划，分为三个时间段：

• 未来 4-6 周很明确，有清晰的版本计划
• 未来几个月则有规划，有高级别项目的概述，描述了问题和机遇
• 更久远的几个月则见机行事，有与产品使命相符的较为宽泛的想法

其他关于产品的想法都会放在一个列表，由产品经理负责管理，团队定期审查。我们做 Roadmap 时的考量因素主要有三点：

1） 理念

它源于我们的看法而非研究，尤其是产品领导团队的看法，包括我们看到的趋势和我们的思考。

2）来自客户的定性反馈

我们主要有三个定性反馈来源：

• 向客户征求的反馈，包括用研团队的研究，以及产品经理和客户之间的交流。我们的产品经理使用 Intercom 与客户交流。
• 客户的主动反馈。每周，我们的客服团队都会将上百条对话进行标签化，进而由产品经理们评审，并添加到未来产品功能列表中，其中一些则会进入 Roadmap。
• 销售沟通中获取的反馈。我们的销售团队会与产品经理们共享沟通记录，这样产品经理们就知道客户在使用过程中会遇到哪些问题。每周，销售和产品团队的领导都会评审 Roadmap，确保我们解决那些问题。

3）基于产品效果评估的定量数据，主要来源有两点：

• 每个项目中定义的成功指标
• 产品和团队层面的成功指标

Roadmap 中的任何项目都会被分解成多个团队项目，再分解成个人项目，这对拥有「以最快速度打造最具价值产品」价值观的我们而言至关重要。我们也有跨团队、目标、项目和版本的战略产品主题。下面是我们如攻克决每个阶段的总结。

（译者注：留意上图，尤其是 Intermission 那部分，有助于对后文的理解）

产品战略主题（Strategy）

目前，我们所有事情都涵盖 8 个主题。为了在这些主题下沟通，我们为每个主题都做了一个白板挂在办公室里。

每一个白板都有一个标题、一个描述了我们为什么相信它很重要的章节、我们目前在解决的问题、它将带来哪些回报，以及带解说的概念草图。（注意：下面的截图是以前的了，我们现在还整合了 Salesforce、Zendesk、Slack 和 Zapier （这些第三方工具）进来）

团队目标（Objective）

每个产品团队都有一个目标——一个需要数月才能实现的战略性目标。每个团队目标都是我们下的大赌注，聚合形成了我们的产品战略。

项目概述报告（Intermission）

「Intermission」是我们为一个项目概述报告起的代号。这份报告文档由产品经理负责，限定在一页纸内说清楚我们在解决什么问题、怎样才算解决成功，以及要解决的项目范围。不需要将解决方案写进来，因为后面就有。Intermission 的作用是在于让团队达成共识——我们在做什么，以及为什么要做。

在 Trello 中的 Roadmap

（译者注：Trello 是一款团队协作工具）

对于较短的产品发布周期（1 天到 2 周之间），我们的进度非常快，每次 5 个或 6 个 Intermission 和 10 个以上的迭代版本。我们用 Trello 来组织工作：

• Trello 中的所有事项都归属于产品经理
• 每个版本都有一个 Trello 卡片，卡片上都有对应设计工作的链接
• 我们有 5 个产品团队，每个团队对应一种颜色，卡片上有什么颜色就表明该任务由什么团队负责

为了保证责任分明，我们有条规定，一个团队才能拥有一个版本。如果有什么缺漏了，我们就贴一个红色标签，这样我们就能知道它们都是怎样缺漏的。

Trello 中的 Intermission 卡片

每个 Intermission 都有一个 Trello 卡片。卡片上带有项目概述报告的文档（即前面提到的由产品经理负责的一页纸文档）的链接、要完成的版本，还有一个预防遗漏的清单。有时候，我们会故意划掉没有完成的任务，因为清单是用来查缺补漏的，而不是用来强制完成的。

Trello 中的版本卡片

每个版本都有 Trello 卡片。卡片中有指向产品，以及产品说明（包括产品描述和决策说明）的链接。每个版本卡片也都有一个清单，分成设计、开发、QA、Beta 版本、完整版本和过往版本这几个部分。同样的，清单是用来查缺补漏的，而不是用来强制完成的。

4. 设定目标的文化

每周目标和 Hustle

为了保持专注，不走歪路，每个产品团队都会设定每周目标。这些对应 Roadmap 的目标地图，包含了像「减少 bug 数量」和「系统改善」这样的内容，以确保我们在将来更快速地运作。为了记录目标实施情况，我们开发了一个叫做 Hustle 的内部工具。说到目标，我们通过 Trello API 来接入Roadmap，并通过 Github API 来接入我们公开 bug 的概述。这里主要想说的是，我们的团队会设定每周目标，并为之负责。

每天的目标和白板

为了完成每周目标，每个人都有一天和一天内的小目标。这巩固了我们「每天必须有所为」的观点。每个产品团队都有一个用来记录当天目标的白板，在早会时就会做好目标计划。

每周的演示

每周五下午 5 点，大家都会带上啤酒聚集在食堂大屏幕前，然后工程师开始演示他们这周的成果。

这强化了我们的理念。节奏感也很重要，毕竟我们在与时间赛跑。我们在做的所有事情，都应该分解成能在一周内完成的小项目。

这个流程已经不同了

我们在不断地对这种工作流程进行检查和迭代，每周都有新的收获。这篇文章展示了我们在不断试错的艰辛之后获得的经验。在一个外部环境万变，内部迅速成长的公司里打造产品绝不容易。希望这有助于你反思和改进打造产品的流程。

---

欢迎关注微信公众号 BuildForever（ID：build_forever），争取每天为你推荐 5 篇原汁原味高质量英文文章（主要侧重在产品、设计和 UX 方向），以及不定期的产品好文翻译和产品心得。