这是昨天读到的一篇文章，原文在 Medium 上，读完后发现去年就有很多人翻译成中文了，网上传的也比较火。作者写的非常详细，有些观点和我在做产品过程中的感受非常相似，也很有借鉴意义，下面的内容当作个人的阅读笔记。
Intercom 创立于 2011年 的旧金山，是一个社会化客户关系管理平台，致力于帮助公司更好地与客户交流。今年 4 月获得一轮 5000 万美元的融资，至此，Intercom 的融资总额已达 1.16 亿美元。目前已有 250 名员工。公司营收去年也翻了两番至数千万美元。Intercom 目前有 10000 多付费客户，包括 Expensify、Trunk Club、Rackspace、IBM、Heroku、Hootsuite、雅虎、Perfect Audience、ZenPayroll、Shopify 和 Visual.ly 等。（信息来源：36Kr）
产品的流程被分解成了四快：
1. 制定决策的依据
2. 责任分配到具体的成员
3. 有一个灵活、清晰、全面的 Roadmap
4. 制定目标的文化
作者注：这个过程并不试用于每个公司；而且这个过程是变化的，我们内部也在迭代这个过程；这个流程适用于我们现在规模，当我们还是小规模的时候，或者当我们规模变大后，流程也会变化。
一：我们有一系列制定决策的原则
“小步迭代胜于大步更新”
我们相信通过 1000 次的微小改动，同样能获得成功。我们所有的项目都划分成独立的小块来发布，员工间相互推动来缩小范围并简单化，以确保不会在不重要的事情上浪费时间。
“我们谈论开发工作的时候，着眼于‘日目标’和‘周目标’”
我们相信产品可以成功，但是时间非常紧迫。每天的工作都非常重要。每个团队都有“周目标”，“周目标”会分解成“日目标”和“半日目标”。每个员工每天来到公司后就知道当天的任务是什么，以及与后续任务的联系，
“我们倡导面对面协作”
面对面协作能够提升效率。两个人在白板前能够快速的形成 idea，然后快速的达成结论。因此我们有一个原则就是，能当面说，就当面说。
“我们不做形式工作”
我们试用最少量的开发工具完成工作，并且维护“轻流程”。当你在管理成品过程中需要用到Google Docs, Trello, Github, Basecamp, Asana, Slack, Dropbox, and Confluence时，那么肯定是有问题的。
“结果比计划重要”
虽然计划是成功的关键，但是并不是一切都要按计划来。计划只是在当时的信息条件下产生的，好的团队会吸收新信息并做出反应。在不断变化的环境中，创造性的实施计划，并努力在确定的时间范围内获得同样好的结果。
二：清楚的划分责任
我们有一个小的产品团队，每个人负责 Intercom 的一部分。团队构成：一个 PM，一个设计，一个主开发工程师，2-4个开发工程师。我们有一个责任列表：
· 如果问题的分析不正确，PM 需要承担责任。请确保做了适当的研究。
· 如果设计没有解决问题，那么是设计的责任。确保你明白并研究了问题。
· 如果设计解决了问题，但不适用于 Intercom，那么是设计的责任。确保你明白我们的信念、模式和原则。
· 如果开发没能按时完成任务，那么是开发的责任。写代码前，先想好计划。
· 如果有太多的 bug 并且破坏了用例，这是 PM 的责任。确保团队测试的可用性情况和边缘情况。
· 如果团队在修复 bug 上花太多时间，在 roadmap 上没有增加新价值，那是开发的责任。确保每个项目能够提高总体的代码质量。
· 如果我们不知道产品的表现如何，那是 PM 的责任。确保定义了成功标准并展现。
· 如果没有解决问题，那是 PM 的责任。确保有提升产品的计划。
产品开发团队有天然的灰色区域，协作能够获取更好的结果。当我们在分析时间占比时，责任必须非常明确。
三：我们维护轻量的、清晰的 Roadmap
我们的 Roadmap 是我们在接下来几个月开发的计划。它有三个时间段：
·接下来的 4-6 周，有清晰的发布规划
·接下来的数月有制定计划，并有项目简述定义问题和机会
·几个月后是一些推测性的松散的 idea
所有其他可能会开发的 idea 由 PM 维护在一个 list 上，由团队审阅。
我们的 Roadmap 有三个来源：
1.我们相信的东西
来源是我们的想法（特别是产品领导团队的想法），而不是研究得到的。
2. 客户的定性反馈，分为三个来源：
·征集的反馈，包括研究团队的结果、PM 和客户的对话。
·通过 Intercom 获得的反馈。我们的客户成功团队将对话分类，发给 PM 审阅，PM 记录在开发的 List 上，有些会被放入 Roadmap。
·销售的反馈。我们的销售团队会将和客户的对话发给 PM，确保没有反复沟通带来的歧义。我们的 Roadmap 每月也会由销售和产品主管审阅，确保我们会解决这些反馈的问题。
3. 依据现有产品性能得到的定性数据
我们有两个定性反馈的来源：
·每个项目的成功标准
·产品和团队级别的成功标准
产品策略主题
我们现在分为 8 个主题，在办公室内为每一个主题分配一块白板。每个白板有标题、有描述（为什么重要、能解决什么问题、能够获得的好处、以及概念的图解）。
团队目标
每个产品团队都有一个目标。这是策略性目标并且必须要花数月时间才能实现，组合起来才能实现我们的产品策略。
项目简述（INTERMISSION）
这份文档由产品经理负责。它被限制在一页范围内，并且列出我们面临的所有问题，我们怎么定义成功，以及项目范围。不包括解决办法，因为后面会涉及到。文档的目标是让团队理解我们在开发什么样的产品以及为什么开发这样的产品。
TRELLO 中的 Roadmap
由于我们的发布周期非常短（一天至两周），我们可能同时会有5到6个INTERMISSION，同时发布10个以上更新。我们使用 TRELLO （国内有类似的工具，如 Worktile、teamabition）进行组织，由 PM 负责。每一次更新都会对应一个 TRELLO 卡，带有设计链接。
TRELLO 中的 INTERMISSION 卡片
每个 INTERMISSION 在 TRELLO 中都会对应一张卡片。卡片链接至 INTERMISSION 文档，同时包含一个 checklist，防止有遗漏。
TRELLO 中的发布卡片
每一个发布在 TRELLO 中都有对应卡片，链接至设计以及支持文档。每一次发布也包含一个checklist，分为五个方面：设计、开发、QA、测试版、整体发布、发布后。
四：制定目标的文化
每周目标和Hustle
为确保我们专注于主任务，每个产品团队都设定周目标。这些目标图是我们从 Roadmap 中发布的，包括减少 bug 发生次数，系统优化。我们开发了一个内部工具——HUSTLE，用来记录目标。
每天目标和白板
为了完成周目标，我们分解成日和半日目标。这增强了每日工作重要性的观念，每个产品团队都有一个白板来记录这些日目标，在早上的站立会议中设定。
每周演示
每周五下午 5 点，我们会集中在一个大屏幕下。没人一瓶啤酒，工程师演示每周的工作成果。这增强了我们的信念以及时间观念。
过程不断更新
我们经常检验、迭代流程。在快速增长的公司，和时间赛跑是非常有难度的，希望这篇文章能帮到你们。
注：此文是 Intercom 的产品 VP Paul Adams所写。
