想要讓你的產品在短期內實現指數級的增長，你可能需要組建一個發展團隊幫你實現這一目標。那麼，你要怎樣為你的團隊選擇最佳發展模式呢?本文作者通過對20名來自不同公司的發展部主管的採訪，向大家介紹了兩種不同的發展模式。
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的漂亮的增長資料時，其他團隊卻擔心過快的增長是以犧牲廣大的用戶體驗為代價換來的。
好比當發展團隊為產品設計了一個使用者註冊介面，使用者註冊後才可以使用產品。這個步驟的確會顯著地提升用戶的活躍度，但同樣也會帶來一些憂慮。其他團隊認為這個步驟讓使用者體驗變糟了。然而最終資料會說話，會反擊其他團隊的直覺言論。
這種既要保證使用者體驗，又要維持資料增長的衝突是我們在獨立模式中需要面對的最大挑戰。
我們經常聽到關於“是否用戶的增長必然要犧牲用戶體驗”的辯論，“這會造成用戶對平臺失去信任。”Winters說，接著它又說“大家應該瞭解(也應該相信)發展團隊會竭盡全力去為用戶創造最佳用戶體驗的。”
如何在發展團隊和其他團隊間建立信任
你要怎樣跨部門建立團隊最基本的信任?
Casey針對上面的團隊衝突問題，提出了一個建立信任的方法：讓發展團隊書面承諾自己不會為了增長資料漂亮而去犧牲使用者體驗。另一個被採訪人也建議CEO可以保留這份承諾書，以此宣揚一種企業文化，同時也請產品發展部副總裁簽訂此協議。這種方法可以降低獨立模式產生的衝突。
Invoice2Go發展部主管Naomi
Ionita(前印象筆記的發展部主管)認為，發展部門的工作不可避免地會與產品部門的工作有所重疊。基於她領導這兩個部門的經驗，她解釋道，如果員工所有的角色和責任都被明確定義，或者公司的產品及發展部主管有很強的工作溝通能力，那麼衝突問題就可以避免。然後又會有新的問題：“信任、透明度和客觀性。”
功能模式
總結
根據我們的採訪顯示，當發展部門的工作需要向功能部門主管(比如產品、工程等)回報時，其他部門的人就會相信產品的發展模式是正確可靠的。
Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent就是使用的功能模式。
該模式之所以流行是因為其有如下三個優點：
功能部門主管(如產品、工程等等)決定發展計畫
功能部門主管可以平衡增長和非增長計畫
產品部副總裁常以功能部門主管的身份掌管發展部
我們來看下第三個優點是如何在實踐中發揮作用的。
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’最能夠解決衝突的一個模式，在選擇與這種模式最搭人作為發展部主管。
你的發展部門主管與產品團隊的關係將對模式的成功與否起到決定性影響
留言列表
