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

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

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

而关于“如何打造产品”，我们总能看到这样的建议：

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

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

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

• 一系列的决策指南
• 责任分明
• 轻量、透明、全面的产品改进清单
• 设定目标的文化

对于这个流程，请注意：

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

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

1. 我们有一系列的决策指南###

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

踏出一小步，强过想象一大步

不积跬步，无以致千里。我们相信，通过不断优化，解决那些最快、最小和最简单的事情，能让我们更快地达到目标，并让我们了解到是什么东西在真正起作用。我们的所有项目都会被分解成小而独立的版本，一步一步实现出来带给客户价值。为了加速开发，同时避免竹篮打水一场空，每个人都应该相互督促，尽可能缩小项目范围并使之更为简洁。

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

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

充分利用面对面协作

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

不产生额外工作

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

看重结果，而非计划

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

2. 责任分明###

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

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

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

3. 我们紧跟轻量而透明的产品改进清单运作###

我们的产品改进清单是为产品的未来几个月制定的，分为三个时间段：

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

其他关于产品的想法都会放在一个列表，由PM负责管理，团队定期审查。

我们做产品改进清单时的考量因素主要有三：

1）我们相信的东西

它源于我们的意见而非研究，尤其是产品领导团队的意见。它包括我们看到的趋势和拥有的观点。

2）客户的定性反馈

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

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

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

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

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

译者注：仔细研究上图有助于对后文的理解

产品战略主题

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

每一个白板都有一个标题、一个描述了我们为什么相信它很重要的章节、我们目前在解决的问题、它将带来哪些回报，以及带解说的概念草图。（注意：下图是以前的一个板块图，我们已经将 Salesforce、Zendesk、Slack 和 Zapier 一起整合到其他主题了）

团队目标

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

项目概述报告（我们称之为 Intermission）

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

译者注：Intermission 有“中场休息、间歇、停顿”之意，但将其翻译后对于文章的理解作用不大，甚至带来困扰，故此沿用该英文单词。当然，如果你仔细看了第一张图，也不妨将其理解为“中间任务”。

在 Trello 中的改进清单

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

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

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

Trello 中的 Intermission 卡片

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

Trello 中的版本卡片

每个版本都有 Trello 卡片。卡片同样有设计工作，和其他能够解释产品和决策由来的支持文档的链接。每个版本卡片也都有一个清单，分成设计、研发、答疑、测试、完整版本和过往版本 6 个部分（译者注：原文说有5个部分，可能为笔误）。同样的，清单是用来查缺补漏的，而不是用来强制完成的。

4. 设定目标的文化###

每周目标和 Hustle

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

每天的目标和白板

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

每周的演示

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

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

这个流程已经不同了###

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

参考###

[1] 原文发布时间约为 1月份，作者为 Intercom 产品副总裁 Paul Adams。Intercom 是一家互联网企业，为企业级客户提供用户沟通工具。
[2] 《精益创业》：即 The Lean Start-Up 的中文版，作者为Eric Ries。
[3] Spotify：全球最大的正版流媒体音乐服务平台之一。
[4] Trello：一款轻量级团队流程协作工具。