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 周之間），我們的進度非?？?#xff0c;每次 5 個或 6 個 Intermission 和 10 個以上的迭代版本。我們用 Trello 來組織工作：

• Trello 中的所有事項都歸屬于產品經理
• 每個版本都有一個 Trello 卡片，卡片上都有對應設計工作的鏈接
• 我們有 5 個產品團隊，每個團隊對應一種顏色，卡片上有什么顏色就表明該任務由什么團隊負責

為了保證責任分明，我們有條規定，一個團隊才能擁有一個版本。如果有什么缺漏了，我們就貼一個紅色標簽，這樣我們就能知道它們都是怎樣缺漏的。

Trello 中的 Intermission 卡片

每個 Intermission 都有一個 Trello 卡片?？ㄆ蠋в许椖扛攀鰣蟾娴奈臋n（即前面提到的由產品經理負責的一頁紙文檔）的鏈接、要完成的版本，還有一個預防遺漏的清單。有時候，我們會故意劃掉沒有完成的任務，因為清單是用來查缺補漏的，而不是用來強制完成的。

Trello 中的版本卡片

每個版本都有 Trello 卡片?？ㄆ杏兄赶虍a品，以及產品說明（包括產品描述和決策說明）的鏈接。每個版本卡片也都有一個清單，分成設計、開發、QA、Beta 版本、完整版本和過往版本這幾個部分。同樣的，清單是用來查缺補漏的，而不是用來強制完成的。

4. 設定目標的文化

每周目標和 Hustle

為了保持專注，不走歪路，每個產品團隊都會設定每周目標。這些對應 Roadmap 的目標地圖，包含了像「減少 bug 數量」和「系統改善」這樣的內容，以確保我們在將來更快速地運作。為了記錄目標實施情況，我們開發了一個叫做 Hustle 的內部工具。說到目標，我們通過 Trello API 來接入Roadmap，并通過 Github API 來接入我們公開 bug 的概述。這里主要想說的是，我們的團隊會設定每周目標，并為之負責。

每天的目標和白板

為了完成每周目標，每個人都有一天和一天內的小目標。這鞏固了我們「每天必須有所為」的觀點。每個產品團隊都有一個用來記錄當天目標的白板，在早會時就會做好目標計劃。

每周的演示

每周五下午 5 點，大家都會帶上啤酒聚集在食堂大屏幕前，然后工程師開始演示他們這周的成果。

這強化了我們的理念。節奏感也很重要，畢竟我們在與時間賽跑。我們在做的所有事情，都應該分解成能在一周內完成的小項目。

這個流程已經不同了

我們在不斷地對這種工作流程進行檢查和迭代，每周都有新的收獲。這篇文章展示了我們在不斷試錯的艱辛之后獲得的經驗。在一個外部環境萬變，內部迅速成長的公司里打造產品絕不容易。希望這有助于你反思和改進打造產品的流程。

---

歡迎關注微信公眾號 BuildForever（ID：build_forever），爭取每天為你推薦 5 篇原汁原味高質量英文文章（主要側重在產品、設計和 UX 方向），以及不定期的產品好文翻譯和產品心得。

總結

以上是生活随笔為你收集整理的我们从产品团队扩大中学到了什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。