增長黑客專家 Andrew Chen：50 頁 PPT，手把手教你打造增長團隊
編者按：“增長黑客”是網際網路創業者Sean Ellis發明的一個術語，指的是一個介於技術和市場之間的新型團隊角色，主要依靠技術和資料的力量來達成各種營銷目標，而非傳統意義上靠砸錢來獲取使用者的市場推廣角色。不過這個詞的流行是Andrew Chen的功勞——曾在Uber當過增長副總裁的他寫了一系列文章來介紹增長黑客。不過相對於增長黑客的單打獨鬥，增長團隊則是集體協作。那麼什麼是增長團隊？為什麼要建立增長團隊？增長團隊與增長黑客的區別在哪裡？增長團隊的關注點應該是什麼？就這些問題，Andrew Chen用50張片子的幻燈片來 ofollow,noindex">釋疑 。
建設一支新的增長團隊很難。你得找出巨集觀的組織性問題——如何適應營銷、產品等職能——以及微觀方面的，如怎麼去衡量這些團隊的成功。這是一個棘手的主題，也是目前很多團隊正在思考的東西。
幾個月前，我給Uber的增長團隊上了一些課，就自己從不同的組織結構中學到的東西談了談，內容可以分為這5大類別：
-
為什麼要建立一支增長團隊？
-
“增長黑客”與增長團隊的區別在哪裡？
-
增長與營銷/產品/其他的區別在哪裡？
-
增長團隊的焦點應該放在哪裡？
-
我正在創立或者加入一支增長團隊！我應該有哪些期望？
為了回答這些問題，我和Brian Balfour基於Reforge的材料（這方面的話題可以到他們的網站去了解更多的實用參考材料）做了一份演示片。
以下就是演示片，希望能對你們有所幫助。
上圖：今天我想講幾個建設公司的增長團隊所需要的關鍵主題。首先，是為什麼需要建設這麼一支隊伍。然後是個人從業者與組織所需的不同技能集——以及跟現有的像產品和營銷等職能所需技能集的不同。最後，是團隊應該聚焦什麼地方以及如何在早期產生影響。
這些主題的想法源自若干地方——跟Slack、Dropbox、Hubspot、Pinterest等的增長團隊負責人的交流和討論，但也包括了我在Uber的個人體會。
上圖：你們當中很多人也許還記得Uber曾經是這樣的。
這支增長團隊起初是由Ed Baker在2013年創立的。它曾試驗過很多不同的組織配置——我在它成立了幾年後加入，在那裡呆了3年，並且把自己的很多時間用在推動平臺乘客端的增長上面。
上圖：我在Uber的時候，有很多出色的專案都是在增長團隊發起的。我的中國同事（China Growth）取得了不可思議的進展——當然美國和其他地方也有不錯的發展。
巔峰的時候包括中國增長團隊在內的整個增長團隊規模達到了500人以上。對於這家公司來說這是一個令人吃驚充滿活力的時段。我從中獲益良多並且對今天能夠分享其中的一些想法感到興奮。
這些年來Uber的變化很大。我們變更過logo好幾次。但我認為Uber仍然有好些東西可以傳遞給生態體系的其他人。
先從基礎講起……
關鍵問題#1：為什麼要建立增長團隊？
上圖：為什麼要建立增長團隊？我們知道很多公司都有正式的增長團隊，有的則是由增長PM/營銷人員等組成的非正式團隊。
上圖：上圖是建立了增長團隊的公司，從這些公司的行業跨度和新鮮性就可以看出增長團隊的普及度。
我們也聽說了很多董事會都在讓他們的CEO要往增長團隊的建設去投入。為什麼會出現這種情況？
產品死亡週期
上圖：討論產品死亡週期的最簡單方式。
不幸的是，這往往就是我們的產品交付和釋出方式。有人有願景，有人開發了一些功能並且進行了釋出。一開始產品可能有點衝勁，但是當增長放緩時，卻不知道該作何著手。他們跟一些客戶交談，問對方想要什麼，然後再次嘗試。他們又增加了一些功能，重新發布，於是這個週期周而復始。
這個週期跑得太多之後，突然之間，你就死了。
酒好還怕巷子深
上圖：事實表明，做了未必就能吸引客戶。更好的產品，更多的功能未必相當於增長。
很多推動更多使用者獲取、留存、互動的關鍵槓桿有時候並不在大多數出色的產品領導的工具包裡。對增長很關鍵但往往不被視為產品核心的技能可以列一長串：廣告技術整合，註冊渠道A/B測試，優化通告發送，測試價格點，測試聚類曲線等。是，偶爾有人都懂這些——但是很罕見！
此外，沒人可以驅動這個。相反，你需要將其注入到你的組織目標和DNA裡面。你需要在公司的更大框架內集中這些努力。
增長是工具，工具是解決不同型別問題的流程
上圖：因此，我們尋求建立一個增長的框架，這是一個門類，本身就是一個組織結構。
不同的流程
我們把“設計思維”與“敏捷工程”視為不同的組織結構、工作流、哲學與技能集體系。這些是公司內部工作機制的關鍵。
同樣地，我們也可以把增長團隊當做一個體系來建設。
上圖：產品增長是一門把科學方法應用到業務KPI上面的學科。
這為提高指標提供了一個基礎系統，不管這些指標是收入、獲取、留存、互動還是其他的關鍵業務指標。
增長流程的主要步驟
上圖：就像你對科學方法的預期一樣，增長流程的主要步驟包括理解資料、建立識別特定流程之所以會出現的假設，對那些想法進行優先排序，進行試驗，然後重複這個迴圈。
這樣一來，如果你認為自己的活躍使用者數低的話，就可以分析資料，然後瞭解到你需要更多漏斗頂端的使用者獲取，接著假設付費廣告和推薦的組合也許管用，再去執行計劃來驗證想法。
相對於開發更多使用者不想要的功能然後指望會出現魔術般的增長，這種做法要好得多，有針對性得多。（也許你還是應該開發那些功能，但原因不要是為了增長！）
關鍵問題#2：增長黑客與增長團隊之別
上圖：第二個主題。談談“增長黑客”與“增長團隊”之間的區別。這一點很重要。
孤膽英雄註定失敗
上圖：在增長技能集的早期階段是沒有團隊的。會有一些個人和初創企業創始人把必要的想法、工作流和策略組合到一起。其中一些傢伙會以玩笑的口吻自稱為“增長黑客”。
隨著技能集的發展，有一件事情開始變得明朗，那就是如果想發揮真正影響，尤其是在更大/更復雜產品的背景下發揮影響，你得把一群人組織起來。
增長是一項團隊運動
上圖：因此增長團隊就應運而生，其哲學是你想要的不是有所有手段的孤膽英雄以及一群幫助者。相反，你需要建立一個有著廣泛技能集的組織。
增長是一項團隊運動，為了對你的KPI實施科學方法，你需要一堆能幫助你的人。
大多數使命需要跨職能配合
上圖：對於增長團隊的大部分使命來說，你需要很多不同的職能角色的幫忙——從產品、營銷、工程，到資料、運營、財務等。你要把來自獨立團隊的所有這些傢伙整合起來成為一個增長組織。
增長團隊的5種潛在角色
上圖：這些角色都是幹什麼的？
-
增長經理（Growth PM）：負責試驗路線圖的產品經理
-
增長工程師（Growth engineer）：聚焦技術決策和執行試驗的工程師
-
增長營銷師（Growth marketer）：具備特定渠道（付費營銷、SEO、電子郵件等）專業知識的全能營銷人員。
-
增長資料分析師（Growth da）：聚焦於建立洞察（使用者生命週期的巨集觀方面以及特定試驗的微觀方面）的分析師
-
增長設計師（Growth designer）：領導UX的設計師，同時強調速度
你可能還得涉及到其他的職能——比方說在Uber，很多圍繞著激勵開支的決定必須把財務或者定價方面的人員納入。而且你總是得把運營放進來去考慮其影響。
例子：增長團隊——NUX（新使用者體驗）
上圖：視你要解決的問題而異，增長團隊的構成可能會略有不同。對於新使用者體驗來說——這可能包括了增加註冊轉化，甚至可能還包括整合進廣告裡面——你也許會特別強調工程師。你可能想要Android和iOS工程師。此外甚至還包括營銷績效的人，一些資料分析師去看看指標等。
例子：增長團隊——SEO（搜尋引擎優化）
上圖：另一方面，如果你在做SEO的話，就未必需要工程師了。這更多是與優化網頁結構、內容去向等有關。這種情況下，你可能會強調SEO營銷、資料以及web全棧工程師。
沒有完美的組織結構
最終的目標是要根據你的洞察和假設定義問題，並且配置好團隊成員來解決特定問題。不同的團隊也許強調不同的技能，視其他團隊的使命不同，增長團隊所適應的巨集觀組織結構也許也許有一些複雜性。
跨職能團隊結構
上圖：一個常見的結構是把增長團隊當作一組pod，每一個都對應各自職能。比如增長經理向產品等彙報，所有的人組成增長團隊。很多產品團隊都是這個樣子，所以相對比較適合。
獨立團隊結構
另外一種做法是像Facebook和早期的Uber增長團隊，其結構類似一個業務部門。那些角色得向總經理彙報。這種結構的好處是團隊內部有很大的獨立性，但是拆分各種組織也會帶來複雜性，有時候還會引起衝突。
混合結構
上圖：顯然你也可以選擇混合模型。
關於增長團隊3個要回答的關鍵問題
上圖：太多初創企業都是從“我需要一個增長團隊!”開始，然後隨便建立一個組織而沒從根本上去思考過。最終，你得從你要解決的問題開始。從KPI、你產生的洞察開始，然後再去執行。你要按照問題領域和想要的執行型別配置人員。組織結構要根據這些來設計。
關鍵問題3：增長跟營銷/產品/魔法/等等有什麼不同？
上圖：我經常會被問到這個問題。難道增長和營銷不是一回事兒嗎？難道增長跟產品不是一回事兒嗎？難道讓大家都負責增長不行嗎？
在這個環節裡，我們將審視一下它們的不同。
增長與營銷
首先，說到營銷與增長，其中有很多方面是你想要解決的：
-
品牌營銷
-
活動
-
內容營銷
-
電子郵件
-
付費營銷
-
病毒式傳播/推薦功能
-
新的使用者體驗
-
使用者對使用者通知
-
......
所有這些你可以採用一堆不同的配置，但大概而言通常歸為3類職能：
-
品牌
-
增長營銷
-
增長產品
通常很顯然的是，品牌最後還是要歸結到營銷。類似地，像NUX和產品生成通知最終都要落到增長團隊身上。但一些中間手段，像SEO/付費營銷/電子郵件等，也都有可能出現。這些我都見過。Facebook把很多效果營銷放到增長團隊裡面。Uber就是這樣開始的，但最終都放到了營銷上。可能的配置有很多。
增長與產品
上圖：如果核心產品團隊有工程師、設計師和PM，那增長團隊也有這些角色，有什麼區別呢？一切都要取決於他們做什麼。產品團隊聚焦於創造核心價值。隨著時間轉移去增強產品/市場匹配。這意味著在核心的互動週期中要把心思放在每一次小小的互動上面——這是一個寸距之賽，積小勝為大勝。
另一方面，增長團隊應該專注於傳播核心價值——要讓儘可能多的傢伙體驗到那種價值。
在讓使用者儘可能頻繁體驗到核心價值上面可以進行妥協——你可以想象把這件事情放到另外一個團隊，但如果解決方案往往需要經常反覆/量化驅動的話，也許就應該由增長團隊去做。
3種所有權模型
上圖：你還得決定所有權模式。有兩個極端：增長即服務（GaaS）以及自動化。以及介乎其間的一切。
“增長即服務”這種模式下，團隊在技術上並不擁有任何功能或者程式碼庫。他們跳到了產品的最高價值部分，進行他們的分析和優化，交付一堆的改進，然後繼續。團隊要保持溫柔，這一點很重要，因為他們是客人，但他們保持輕量也很重要。如果增長團隊最終擁有他們碰到的每一塊程式碼的話，那他們最終就會陷入到一切的維護模式當中。
另一方面，完全的所有權模式意味著增長團隊可以擁有新的使用者漏斗、通知、廣告技術、A/B測試平臺、支付流，以及許多其他數字勝過直覺的關鍵領域。這樣可以管用，但然後團隊需要恰當地配置人員。
不同模型的優缺點：GaaS——優點是敏捷，缺點是容易衝突；自治——優點是可控，缺點是會臃腫；混合——優點理論上是各取所長，缺點很難劃清團隊之間的界限。
上圖：每一種模式都會有各自的優缺點。Uber各自模式都試過，不過慢慢地開始擁有產品越來越多的部分。但是你得根據自己的約束、組織和產品需求決定選擇哪一種。
關鍵問題#4：增長團隊的關注點應該是什麼
一旦增長團隊建立起來之後，其關注點應該放在什麼地方？就像之前討論過那樣，他們的使命和工具包應該跟營銷或者產品團隊使用的那些有所不同。尤其是在團隊的早期階段，應該有一些唾手可得的東西選用。
儘管直接跳到使用者獲取或者看看流失情況很容易，但是從更高的角度去看看這個體系還是很有幫助的。先從優先順序框架開始。
確定優先專案的框架
上圖：最終有3樣關鍵的東西需要進行權衡——有一個尤其棘手：
-
投入。執行需要付出多少的設計/工程/營銷資源？
-
成功。取得成功的可能性有多大？
-
提升。這個比較棘手——如果管用的話，對整體增長會產生多大的影響？
每一次增長試驗最終都是根據這三樣東西的排名選擇出來的優先事項，慢慢地，你的增長團隊在如何選擇方面就會變得很明智。但我還想就增長團隊可能會出問題的地方提供一些注意事項。
選擇增長專案最常見的反模式是把影響到0.01%使用者的功能改進+50%視為可喜可賀，卻覺得一項影響50%活躍使用者的功能改進只有5%很小。當然你只要算一下就知道後者要重要得多，因為你最終希望那些自下而上的試驗要實現自上而下的KPI。
另一個常見的反模式是把焦點放在大規模的、好處巨大的專案而不是不需要太多努力、但好處不大或適度的專案。幾乎每個人都會過高估計自己的成功機會，所以最好是多進行試驗而不是孤注一擲……除非你已經窮盡了好做的想法，或者你已經有了足夠的資源來建立大小專案的池子。
關於每一種因素的一些注意事項：
-
一般而言，投入是最容易理解的。如果你定義好了專案，你的團隊就能夠像其他任何東西一樣針對它來執行。我一般建議增長團隊早期要向低投入的專案傾斜。
-
成功可能會引起爭議，因為對增長有效的東西未必是使用者自己會報告的東西——因此，團隊成員通常會說，“我永遠也不想要這個。我永遠也不做這個。”是的，你執行了最佳實踐並且管用。典型的例子是渴望給登入頁增加全面內容，那些東西會連結到無數新地方。但是一個很好理解的設計模式是隻需提供必要的資訊完成登入即可——不要畫蛇添足。
-
提升在這三個因素當中是最難理解的。但同時也是最強大的手段，因為它為增長團隊應該關注產品的什麼地方提供了有力的指南。
那麼我們就進一步看看這個因素。
提升=覆蓋 x 影響
上圖：提升最終都是靠絕對量來衡量的——獲得了多少額外的訂戶，產生的註冊數等。可以用兩個元件來計算——接觸和影響。接觸是指有多少終端使用者接觸到了某功能的變化。影響是指作為變化的結果指標改進了多少。
這兩個因素裡面，影響的隨機性往往最強。有時候一個改變可以推動改進+5%，有時候可以改進+50%。基本上絕大部分專案的結果都在這兩個數之間。對於某些專案來說，如果產品體驗可以發生多次的話，影響會非常巨大——比方說，一個新的高度相關的統治在產品的核心互動迴圈裡面發出。或者某個顯著放大病毒式迴圈的東西，導致飛輪轉得越來越快。（但這已經超出常規了——不過這也告訴你有這種途徑去創造巨大影響）
另外接觸則是一個經常被誤解的出色手段。這往往是理解那種最好專案的最有效點。
上圖：基本上，大多數產品團隊都聚焦在讓他們的核心產品體驗更好上，這對他們的核心使用者是有好處的。這有很多好處——畢竟，他們是參與度最高的一群人，從貨幣化的角度來說是最有價值的，在多邊平臺裡，是他們產生的照片/內容/銷售等維持了整個生態體系的其他部分。
另一方面，核心使用者往往只佔你的總活躍使用者的一小部分。
上圖：視你如何定義核心使用者而言，這個群體往往只佔到活躍使用者群的5-25%。如果光看能產生內容而不僅僅是消費的那部分使用者群的話，這部分人通常只佔很小的比例。或者創作大量內容的那部分硬核使用者，相對被動消費者而言總是很小的比例。
因此，如果你有定向瞄準你的活躍使用者而不是核心使用者的專案的話，那你的到達量會多4到20倍！
但這還不是全部，還有更多的同心圓。
上圖：平均而言，在任何一個月的時間裡你的註冊使用者裡面可能只有10-50%是活躍的。50%已經是世界級的表現——就像Facebook及其家族。通常大多數產品都在10-20%附近，因為絕大部分產品都有大量的曇花一現式的奇蹟：那些試過產品一次，然後就永遠不再回來的人。
這種層面的專案應該聚焦在啟用上。如果你知道是什麼讓使用者變得活躍的話，那就可以在使用者引導流程中把那個東西引入進來，從而將他們轉化為活躍或者核心使用者。
對有著大量已有受眾的產品來說，另一組活動就是從不活躍/流失的狀態轉移到迴歸使用產品的狀態。他們有沒有收到相關郵件讓他們重新啟用呢？如果他們忘了密碼，你有沒有像對待註冊一樣重視優化相關流程呢？
獨立訪客
上圖：當然，對於很多產品來說（更多是web相關的），有些人是光看產品但從未註冊的。大多數登入頁可能只有10-50%的轉化率（註冊）！此外，很多產品都有“側門”——像Dropbox的共享檔案連結，或者YouTube的視訊頁面——是這些產生了絕大部分的流量。那些地方就成為優化的關鍵地方。
上圖：當然，除了所有跟你的產品互動過（即便在登出的狀態）的所有人之外，還有一個更大的群體範圍——也就是你的主要獲取渠道範圍內的每個從未聽說過你的人（無論是在Facebook還是Google或者其他）。這才是真正的漏斗獲取的頂部。
當然，還有各種你還沒有試驗過的渠道。所以這就是為什麼增加新渠道（比如在還沒有的時候嘗試一下推薦系統）會成為一大推進器的原因。
跳出當前使用者群去思考到達規模
上圖：說了這麼多其實是想說如果你要找提升增長空間的最大手段的話，這個東西可能就在於到達（Reach）。當你發現你的增長團隊的專案跟核心產品團隊發生衝突時，不妨考慮上述同心圓——一步步地切入到更大的使用者範圍，無論是面向新使用者、流失使用者，以及所有尚未認同你產品的邊緣人等。
另一個極好的練習是看看現有的功能和路線圖，把一切接觸非使用者（或者不活躍使用者）環節圈出來。你會驚訝地發現它們一般都是很新的。
上圖是Airbnb的增長團隊的分享，他們做的就是這種練習——在所有33個環節裡面只有6個是針對非使用者的。增長團隊可以迅速擴充套件這個列表，給處在邊緣的受眾一些愛。
關鍵問題#5：對增長團隊的預期
上圖：最後一個話題。假設說你作為個人正在思考加入（或者成立）公司的增長團隊。你應該作何預期？又應該怎麼去評估這個機會呢？
上圖：建立一支成功的增長團隊涉及到很多組織和文化方面的東西。首先，要有領導DNA——是否理解了增長團隊是幹什麼的？尤其是在產品和營銷的同行那裡。或者這個東西是不是由CEO或者董事會硬推而沒有獲得領導層認同的？如果大家根本不理解增長團隊的使命的話，事情就會很痛苦。
公司文化也是一個重要方面。如果文化像鼓勵試驗的Uber 1.0那樣的話，只要每次試驗的範圍在1、2座城市之內，或者影響面只有1%的話，那就很好。“快速行動打破陳規”。另一方面，如果公司設計極端並且具有品牌意識額話，做起來就會更加困難。蘋果和Snap就以很少進行A/B測試著稱，這種情況直到最近才有所改變。在評估一家公司的試驗時，比方說了解他們對主頁大的變化的接受程度就是很好的。或者對新使用者流的改變。
就像之前討論過一樣，所有權模式可以是兩個極端：SWAT團隊模式，很少/沒有程式碼所有權，或者很強的所有權領域，像NUX/通知/廣告技術等。這兩種都能用，只是要確保知道你要做的是什麼，以及相應的人員配置與之匹配。
在我看來，最好的情況是要有這麼一支團隊：
-
認同要有一支增長團隊，並且知道它如何補充現有職能
-
支援試驗，即便是極端的試驗，只要試驗是在小範圍內進行
-
專門人員已經安置就位，對於活躍使用者群以外的一切偏向於強所有權。
當然，最糟糕的版本是大家其實不明白為什麼要成立增長團隊，對快速試驗存在大量風險規避，並且不配置員工……就只是到處跑期望說服其他團隊實現你的驚豔想法。這是失敗的配方。
實施過程可能會碰到的問題
上圖：在實現增長團隊上有一些常見的異議。有時候公司的激勵手段是為了獎勵大型複雜的專案（有代號、有高管跟進的那種）而不是很多輕量的改變。這種做法融入到了專案的評審方式，績效考核等一切。
類似地，在創立增長團隊之前，幾乎肯定會有傢伙會留意產品的增長部分。因為把那些責任移走，或者開始侵蝕跟核心產品團隊有重疊的“互動”部分，導致出現抗體，令增長專案進展變得緩慢許多。
確保大家達成共識
上圖：組織的基礎必須是已經準備好接受一支增長團隊，而這個則要從對環境已經發生改變有了根本理解開始：
-
增長技術產品已經改變，指導手冊在過去10年也已經有變化了
-
為了實現增長，必須配置專門的人員以及有明確的路線圖——“開發好他們就會來”不管用了
-
建立增長試驗的管道需要不同的流程。這種科學方法同樣應用到KPI上。這不僅僅是營銷和產品專案的子集
-
最後，要想使增長取得成功的團隊結構和技能是不一樣的
你能想象的是，形成這種互相理解的基礎本身就需要很大的努力。你還需要取得所在初創企業CEO或者部門經理以及更高層的幫助。以及你所有的同事。
上圖：這些是克服不可避免的組織摩擦的一些策略。其中包括1）理解文化根源2）CEO/創始人認同並授權3）教育，教育，不斷地教育4）著眼全域性，小處做起5）分出輕重緩急，積小勝為大勝6）用資料總結得失
感謝觀看！
原文連結： https://andrewchen.co/how-to-build-a-growth-team/
編譯組出品。郝鵬程編輯。