虎嗅注： 想要讓你的產品在短期內實現指數級的增長，你可能需要組建一個發展團隊幫你實現這一目標。那么，你要怎樣為你的團隊選擇最佳發展模式呢？本文作者通過對20名來自不同公司的發展部主管的采訪，向大家介紹了兩種不同的發展模式。本文來自Medium，原文標題為 《How Do You Choose the Best Growth Team Model?》 ，虎嗅翻譯。

我們采訪了20位來自發展最快速的公司的主管們，比如Pinterest和FanDuel （一款幻想體育游戲） 的主管，來回答這個重要的問題。

在長達30多小時的采訪之后，我們弄清了一件事：團隊選擇正確的發展模式既可以解鎖盈利大關，也會加強企業文化。

在我們的采訪中共涉及到了兩個較為流行的團隊發展模式。

一個是獨立模式（Independent Model）；另一個是功能模式（Functional Model）。如果你想去組建自己的發展型團隊，這兩個模式都是不錯起跑姿勢，“當游戲開局時，要按正確的布局玩兒”（Zack Onisko，創意市集網站Creative Market的首席發展官）。每個模式都要“更深入地理解自己團隊的發展模式”（Mike Duboe，Tilt的發展官），然后全力解鎖盈利問題。

獨立模式

總結

Uber和Facebook用的就是獨立模式。這個模式主要有兩個版本，如下：

在這兩個版本中，都由一位發展部副總裁在帶領團隊。比如，Ed Baker就是Uber的發展部副總裁，直接向CEO Travis Kalanick匯報工作。Ed帶領的發展團隊由100多人組成，與產品、市場、工程、設計、數據部門的專家一起，共同研究令供求雙方 （指服務提供方司機和服務需求方乘客） 用戶數都增長的方法。

而且根據被采者提供的信息，Uber就是用這種模式提高了團隊產品的生產和迭代速度，建立了很強的團隊DNA。Uber很重視速度和迭代，他們的發展團隊為此搭建了一個穩健的反饋機制，再將反饋體現在Uber的產品上。

反饋機制可以保證一個老用戶群體可以發展出另一個新用戶群體，這種情況經常發生在老用戶的搜索、支付、推薦行為后。比如說，首次嘗試Uber服務的乘客往往都是Uber的老用戶推薦過來的，這就是推薦反饋的結果。而有的司機則是看了“成為Uber的司機”的廣告，在此作用下成為了Uber的司機。兩個案例中，不管的供方司機，還是需方乘客，都可以靠反饋機制通過老用戶來創造新用戶。

Uber發展團隊的工作就是讓這些反饋機制盡可能地提高他們的乘數效應。舉例來說，乘數效應中的“乘數”在Uber的推薦反饋機制中是“10”。這個的意思是Uber通過線性手段（比如付費廣告）獲取到的乘客將會再創造10倍的新用戶。如果團隊通過付費廣告可以得到1000名乘客的話，那這1000名乘客還會通過推薦（反饋機制）創造10000名新乘客。

這個乘數效應里的乘數越大，則Uber發展得越快。

獨立模式中的沖突與解決方案

Casey Winters是Pinterest的產品發展部主管，他認為獨立模式中的沖突是不可避免的。

當Pinterest采用獨立模式時，發展部團隊的數據都是很漂亮的上升態。曾保持著持續擴張的狀態。而事實上，當發展團隊亮出Pinterest的漂亮的增長數據時，其他團隊卻擔心過快的增長是以犧牲廣大的用戶體驗為代價換來的。

好比當發展團隊為產品設計了一個用戶注冊界面，用戶注冊后才可以使用產品。這個步驟的確會顯著地提升用戶的活躍度，但同樣也會帶來一些憂慮。其他團隊認為這個步驟讓用戶體驗變糟了。然而最終數據會說話，會反擊其他團隊的直覺言論。

這種 既要保證用戶體驗，又要維持數據增長的沖突是我們在獨立模式中需要面對的最大挑戰。

我們經常聽到關于“是否用戶的增長必然要犧牲用戶體驗”的辯論，“這會造成用戶對平臺失去信任?！盬inters說，接著它又說“大家應該了解（也應該相信）發展團隊會竭盡全力去為用戶創造最佳用戶體驗的。”

如何在發展團隊和其他團隊間建立信任

你要怎樣跨部門建立團隊最基本的信任？

Casey針對上面的團隊沖突問題，提出了一個建立信任的方法：讓發展團隊書面承諾自己不會為了增長數據漂亮而去犧牲用戶體驗。另一個被采訪人也建議CEO可以保留這份承諾書，以此宣揚一種企業文化，同時也請產品發展部副總裁簽訂此協議。這種方法可以降低獨立模式產生的沖突。

Invoice2Go發展部主管Naomi Ionita（前印象筆記的發展部主管）認為，發展部門的工作不可避免地會與產品部門的工作有所重疊?；谒I導這兩個部門的經驗，她解釋道，如果員工所有的角色和責任都被明確定義，或者公司的產品及發展部主管有很強的工作溝通能力，那么沖突問題就可以避免。然后又會有新的問題：“信任、透明度和客觀性。”

功能模式

總結

根據我們的采訪顯示，當發展部門的工作需要向功能部門主管（比如產品、工程等）回報時，其他部門的人就會相信產品的發展模式是正確可靠的。

Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent就是使用的功能模式。

該模式之所以流行是因為其有如下三個優點：

1. 功能部門主管（如產品、工程等等）決定發展計劃

2. 功能部門主管可以平衡增長和非增長計劃

3. 產品部副總裁常以功能部門主管的身份掌管發展部
   

我們來看下第三個優點是如何在實踐中發揮作用的。

Pramod Sokke是BitTorrent的產品主管，直接在平臺上接觸所有的客戶。他要負責BitTorrent的增長和非增長模式。這意味著Pramod必須同時為產品的增長和非增長績效制定計劃，同時為兩組的績效表現負責。BitTorrent發展團隊以外的員工也很信任Pramod，因為他能用平衡發展的方式確保各部門在這場長跑中都能到達終點。

功能型模式中的沖突與解決方案

盡管如此，用戶數增長與用戶體驗的沖突在功能模式下仍然存在。因為上文中提到的幾個優點，所以這種沖突并不像在獨立模式下那么明顯。但之所以沖突還存在因為能夠保證用戶增長的措施往往與用戶對產品的預期背道而馳。

這就是為什么我們的采訪提倡縱向分析的原因。通過分析用戶行為，我們可以看出用戶的增長究竟是否會犧牲用戶參與積極性。我們也會發現發展模式既可以保證用戶數增長，也會提高用戶的參與度。

我們還了解到功能模式最有效的情況是，其負責人對于增長數據全權負責，并認可產品是需要迭代和學習機制的。這樣一來產品的發展藍圖就不會全部寄托在無根據的直覺上。

比如，Pramod就在產品上用了一個非常典型的數據驅動迭代的方法。Annabell Satterfield成為了他團隊中唯一一個業績有增長的項目經理，因為他們將分析數據和迭代這兩個過程結合得很好。

Annabell解釋說她的增長模式是數據驅動和產品迭代。這跟直覺沒關系，而跟這一過程有關： 觀察數據（分別從質和量兩方面分析）、制定出假定方案、推出測試方案和最小化可行產品、觀察測試結果，判斷是將此次實驗性產品發布還是從新再來一遍學習過程。

我們假設如果數據驅動和產品迭代兩個過程沒有很好得結合，那么會有另一個潛在的沖突存在于功能模式下。

可以說Pramod是用非迭代的方法管理產品，而Annabell則用的是迭代的發展模式。Pramod可能市場要求Annabell的產品憋出個大招，這個過程大概需要6到12個月。Annabell也許會給Pramod放一把大招，但她也可能用數據驅動產品迭代的方法僅用數周或者數天的時間就證明這些大招都是一些爛招。所以憋大招會增加產品生產的成本，無論是從收入還是用戶的角度看都是如此，Annabell如是說。

我們的一些采訪對象認為解決沖突可以通過改變產品藍圖的方法。在我們上面假設的情況中，Pramod可能可以讓兩個賽道同時跑起來，而不是將所有產品的工作都壓在一種模式上。其中一個賽道用于實踐Pramod的非迭代方法，另一個賽道使用Annabell的迭代式模式。每個賽道都可以有他們獨立的產品、工程師、設計資源以確保所有的工作都可以在預算內按時完成。

不管怎樣，公司高層需要為了產品的發展，引入數據驅動迭代的思維模式。不然無論你怎樣搭建你的發展部門，都終將失敗。

全文總結

在軟件主導世界的時代，產品數據的增長與產品本身有著千絲萬縷的聯系。因為我們不知道產品發展的重點在何方，也不知產品的增長點為何物。所以我們仍需觀察時下的趨勢現象，才能判斷出最佳發展團隊。

在我們采訪的20位發展部主管中，都提到了最流行的兩種模式：獨立模式和功能模式。當你想組建你的發展團隊時，這兩種模式都是一個很好的開始。

獨立模式可以加快產品的生產和迭代速度。然而，這樣就會造成發展團隊的工作透明度下降，造成公司內部的信任下降。而功能模式相對更加透明，讓發展模式更加平衡。但在用戶體驗和用戶增長之間的沖突仍在存在。

有趣的是，我們發現這兩種模式沒有造成結果上太大的差距。也就是說任何一種模式都沒有一定好過另一種。

這是一個很關鍵的發現。

所以選擇一個團隊發展模式時，要考慮到企業文化、組織結構、戰略調整可能會更好。不要去選擇成長模式，而是去找合適的模式。

選擇你們‘團隊DNA’最能夠解決沖突的一個模式，在選擇與這種模式最搭人作為發展部主管。

你的發展部門主管與產品團隊的關系將對模式的成功與否起到決定性影響，