編者按：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）。新框架幾乎馬上就被采納了。我們很快就看到了效果：

• 由于對項目的反饋變得更加具有針對性，審核變得更短了。

• 因為知道什么時候自己的反饋會沒有幫助，我們的CTO可以把部分審核工作授權出去了。

• 更大的公司能清楚知道項目的進展情況。

在幾周之內，一度感覺被項目之多壓垮的組織不但行動變得更快了，而且對承擔更多的項目也感到坦然了。這個過程中，我們增加更多的項目、更多的團隊并招聘更多的新人也變得更容易了。

Dropbox并非總是一帆風順，因為在快速發展的公司里面什么事情都有可能發生。但盡管有這些磕磕碰碰，我在那段時間最受啟發最有收獲的一點就是了解到了用像這樣的簡單框架來幫助團隊擴充。我發現這是我可以分享給新的、正在壯大的團隊最有價值的建議。希望它能夠幫助你在2017年完成多一點的事情。

編者按：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）。新框架幾乎馬上就被采納了。我們很快就看到了效果：

由于對項目的反饋變得更加具有針對性，審核變得更短了。

因為知道什么時候自己的反饋會沒有幫助，我們的CTO可以把部分審核工作授權出去了。

更大的公司能清楚知道項目的進展情況。

在幾周之內，一度感覺被項目之多壓垮的組織不但行動變得更快了，而且對承擔更多的項目也感到坦然了。這個過程中，我們增加更多的項目、更多的團隊并招聘更多的新人也變得更容易了。

Dropbox并非總是一帆風順，因為在快速發展的公司里面什么事情都有可能發生。但盡管有這些磕磕碰碰，我在那段時間最受啟發最有收獲的一點就是了解到了用像這樣的簡單框架來幫助團隊擴充。我發現這是我可以分享給新的、正在壯大的團隊最有價值的建議。希望它能夠幫助你在2017年完成多一點的事情。