從Uber、臉書團隊發展模式中,能學到什么?
我們采訪了二十位公司主管來幫你解答這一至關重要的問題,他們的東家都是有著最快發展速度的企業,例如Pinterest 和 FanDuel。
在經過了長達三十多個小時的采訪之后,我們弄清了一件事:選擇正確的團隊發展模式不僅利于企業的發展,同時也能強化企業文化。
團隊發展模式
從我們的采訪中可以總結出兩個較為流行的團隊發展模式:
一 種是獨立模式,一種是功能模式。如果你想要組建自己的發展團隊,二者都是不錯的著手點。“當游戲開始時,要按正確的布局玩兒”(Zack Onisko,CreativeMarket***發展官)。每種模式都聚焦于“更為深入地了解自己團隊的發展模式”(Mike Duboe,Tilt發展官),然后全力解鎖盈利問題。
獨立模式
總結
Uber 和Facebook采用的就是獨立模式。我們在采訪中無意發現該模式主要有以下兩個版本:
在 這兩個版本中,都有一位發展副總裁在領導著團隊。舉個例子,在Uber ,Ed Baker就是發展副總裁,直接向CEO Travis Kalanick匯報。Ed所領導的團隊由100多人組成,與產品、市場、工程、設計以及數據部門的專家共同致力于供求雙方的發展。
根據采訪對象所提供的信息,Uber就是利用這種模式提高了團隊生產以及迭代的速度,建立了很強的團隊DNA。Uber極其重視速度和迭代,他們的發展團隊還為此搭建了一個穩健的反饋機制,轉而再將反饋體現在Uber的產品上。
反 饋機制能夠幫助一個老用戶群體發展出一個新用戶群體,這種情況通常由老用戶的搜索、支付以及舉薦機制所引發。例如,新用戶是聽了老用戶的推薦而開始使用 Uber,這就是推薦反饋的結果。司機是因為看了“成為Uber司機”的廣告而加入Uber,這就是支付廣告的反饋結果。在兩個案例中,無論是供方司機還 是需方乘客,都是老用戶利用反饋機制創造新用戶的過程。
Uber發展團隊的職責就是讓這些反饋機制盡可能的強大,以此來提高公司的乘數效 應。例如,在Uber推薦反饋機制的乘數效應中乘數是“10”。這也就是說,Uber通過線性手段(例如付費廣告)獲得的用戶將會再創造十倍的新用戶。如 果團隊通過付費廣告獲得了1000名用戶的話,那么這1000位用戶還會通過推薦反饋機制創造10000名新用戶。
乘數效應越好,那么Uber就發展的越快。
獨立模式中的沖突與解決方案
Pinterest發展部的產品經理Casey Winters認為獨立模式中的沖突是不可避免的。
當Pinterest采用獨立模式時,發展團隊的數據一直處于上升狀態。事實上,Pinterest的數據增長的如此之快,以至于其他團隊都開始擔心這種過快的增長是否是以犧牲廣大的用戶體驗換來的。
舉個例子,當發展團隊推出一個全新的注冊界面時,用戶的活躍度會得到顯著提升,但是憂慮也會同步而來。其他團隊認為這一過程讓用戶體驗變糟。然而,數據最終會給其他團隊的直覺性言論帶來反擊。
這種既要保證用戶體驗,又需要維持增長指標的強勁有力是在采用獨立模式過程中需要面對的***挑戰。
關于這種增長是否必須要以犧牲用戶體驗為代價的爭論一直不絕于耳,如果不采取措施,“這將會造成用戶對于平臺的信任缺失。” Winters表示,接著又說道“大家應該明白(也應該相信)發展團隊會盡全力為用戶帶來***的體驗。”
信任的建立
你要如何在不同的團隊間建立最基本的信任?
Casey針對上述問題給出了一個良好建議:讓發展團隊書面承諾自己不會為了增長指標而做出有損用戶體驗的行為。我們的某個采訪對象建議將該承諾書交由CEO保管,因為CEO是企業文化的開創者,與此同時,也請發展和產品副總裁簽訂此協議,以此來減少獨立模式中的沖突。
在 Invoice2Go發展主管Naomi Ionita(前印象筆記發展主管)看來,發展部門的工作將不可避免的與產品部門有所重疊?;谧约涸趲ьI這兩個團隊方面的經驗,她解釋道,如果分工明確 或者產品發展部的領導具備良好的溝通能力,那么這種沖突問題是可以避免的。問題又重新回到“了信任、透明度以及客觀性”上。
功能模式
總結
采訪對象們表示,當發展部門的員工需要向功能部門主管(例如產品、工程等),其他人就會覺得發展指標將會以正確的方式得以實現。
Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent采用的就是功能模式。
該模式的流行得益于以下三個優點。
1、功能主管(如產品、工程等)決定發展計劃。
2、由功能主管來平衡增長和非增長計劃。
3、產品副總裁通常扮演功能主管的角色,從而來掌管發展。
讓我們來看看第三條是如何在實踐中發揮作用的。
Pramod Sokke是BitTorrent的產品主管,能夠在平臺上與所有客戶進行接觸。他要負責BitTorrent的增長及非增長指數,這就意味著 Pramod的產品規劃必須圍繞著增長和非增長績效展開,因為他要為兩組的績效表現負責。BitTorrent發展團隊以外的員工也都非常信任 Pramod,因為他以一種平衡的方式來制定計劃,確保所有人都能成功。
功能模式中的沖突及解決方案
盡管如此,用戶體驗與用戶增長間的沖突在功能模式中仍然存在。因為上文中提到的幾個優點,沖突并不像獨立模式那么明顯。之所以沖突還在,是因為保證用戶增長的措施往往與用戶對產品的預期背道而馳。
這就是為什么我們的采訪對象會提倡縱向分析的原因。通過對用戶行為所進行的分析,我們能夠得知用戶增長是否會以犧牲用戶參與的積極性為代價。同時也會了解哪種發展計劃既可以保證用戶數量增長又能提高用戶的參與度。
我們還了解到,當增長指數的全權負責人是數據驅動型,并且認可產品是需要迭代及學習機制的,功能模式會***效果。這樣一來,產品的發展藍圖就不會是單憑直覺就規劃出來了。
例如,Pramod在產品上就采用了一種非常典型的數據驅動迭代方法。這使得團隊中唯一的發展項目經理AnnabellSatterfield變得更高效。因為這一方法將數據分析和迭代過程結合的非常好。
Annabell解釋說她所采用的增長過程就是數據驅動和迭代的,跟直覺沒有任何關系,而是全在于過程本身:觀察數據(分別從質和量兩方面分析)、制定假定方案、推出測試方案和最小化可行產品、觀察測試結果,判斷是將此次實驗性產品推向市場還是帶著教訓從頭再來。
現在讓我們以假設的方式來說明功能模式中另一個潛在的沖突,假設數據驅動和產品迭代兩個過程未能很好結合。
比 方說Pramod在管理產品時采用非迭代的方法,而Annabell 采用的還是迭代的發展模式。Pramod很可能要求Annabell在產品發展藍圖方面放出大招,這一過程需要6-12個月的時間。Annabell可能 會答應Pramod,但是她也可能在短短數周(或者數天)內就用數據驅動產品迭代的方法來證明這都是一些爛招。Annabell表示,無論是從收益還是用 戶的角度來看,這樣做將會增加產品的計劃成本。
我們的一些采訪對象將會通過改變產品藍圖的方式來對沖突進行解決。在上述假設的例子 中,Pramod可能想要雙管齊下,而不是將所有的產品工作全部壓在一種模式上。一個賽道用于實踐Pramod的非迭代方法,而另一個則使用 Annabell的迭代模式。每個賽道都有其獨立的產品、工程以及設計資源,以確保所有的功能都內在計劃的時間和預算內完成。
企業高層必讀(兩種模式必讀之處)
不管怎樣,為了促進發展,公司高層必須引入數據驅動迭代的思維模式。不然,無論你怎樣規劃自己的發展團隊都難逃失敗的命運。
結語
在我們所處的軟件世界中,發展與產品相互纏繞,意味著我們很難了解產品的終點和發展的起點在何方。這仍然是一個相對較新的現象,同時也使得選擇***的團隊發展模式充滿挑戰。
我們的采訪對象,二十位發展主管,無一例外的都提到了兩種最為流行的模式:獨立模式以及功能模式。在業務可伸縮之際,當你想要組建自己的發展團隊時,這兩種模式都是很好的著手點。
在運行增長試驗中,獨立模式能夠加快產品生產和迭代的速度。不過,這種模式也會導致團隊工作透明度的降低,導致企業內部不信任的滋生,而功能模式因采用更為平衡的發展模式而增加了工作的透明度。不過,無論如何,用戶體驗和用戶增長間的沖突仍然存在。
有趣的是,我們并沒有在兩種模式所造成的結果上發現太大差異,也就是說在實現產品更大的指數增長方面,任何一種模式都沒有好過另外一種。
這是一個非常重要的發現。
所以在為團隊選擇發展模式時,以企業文化、組織結構及戰略適應度為考量可能會得到更好的結果。不要單純為了企業發展而選擇模式,要選擇適合的模式。
兩種模式都具有各自的沖突,選擇那種沖突在你團隊能夠解決范圍之內的模式,然后選擇一位秉性能與之契合的人作為團隊領導。
發展部門主管與產品團隊的關系將會對你所選擇模式以及整家企業的成功與否起到決定性作用。
作者
Andrew (Drew) McInnes目前就職于Tradecraft。在此之前,Drew是一家社交移動游戲企業的發展產品經理(特別是在Zynga),并想要繼續致力于協助打造發展引擎。