編輯導讀：網際網路下半場，所有人都在討論增長。在國內，像滴滴、百度、阿里等公司，也開始引入國外專業增長駭客，基於資料的精準分析實現使用者增長。本文作者結合自己的所思所想，分享了關於如何執行使用者增長的非常有價值的知識，供大家一同參考和學習。
之前我在《使用者增長的三個階段》這篇文章裡，總結了我所理解的使用者增長的幾個基本階段和一些關鍵的概念。但是涉及到具體的使用者增長如何執行這件事，談的較少。
最近在看一些增長的書籍，剛好有這部分內容，所幸就摘錄出來和大家一起聊聊這個事情。
首先，我們來看看實現使用者增長的幾個步驟：
- 根據公司戰略，確定增長的階段性目標是什麼；
- 結合行業特性，深入思考，從目標倒推實現路徑和相應的增長專案；
- 根據專案思考組織保障，成立閉環團隊或打破部門牆的緊耦合功能團隊（FT，Feature Team）;
- 兼顧長期增長目標，提前思考如何跨越增長曲線，避免陷入“經理人窘境”；
- 在假設單個增長專案大機率會失敗的前提下，設計、執行具體增長專案；
這個其實還是比較好理解的，做任何事情之前，我們都應該先去確定做這件事情的目標是什麼。
如果沒有目標，一方面會讓我們對整個事情的重點缺乏判斷和把握，這樣往往在執行的過程中，會忘記最初是為何出發的，很容易導致執行的混亂和錯位；另一方面，有了目標我們才能更好的衡量我們所做事情的過程和結果，到底是好還是不好，好在哪裡，不好又不好在哪。
放到使用者增長這件事上，階段性的目標其實是類似「北極星指標」這樣一個概念，就是在做增長之前，我們還是要先確定產品當前的北極星指標是什麼，只有確立了北極星指標，我們才能更清楚地知道應該做什麼、應該不做什麼，更好地把有限的資源投放到更有用的地方去。
02 確定增長專案當確立了增長目標後，這個時候要去思考的就是從目標倒推實現路徑，這裡其實就涉及到對核心目標的拆解。
我以公眾號閱讀量的增長來舉例，如果要實現公眾號閱讀的增長，其實大方向來拆的話，可以分為站內（公眾號內）閱讀量和站外（公眾號外）閱讀量。
站內閱讀本質就是你的公眾號粉絲數乘以文章開啟率，而站外閱讀則包含比較多的渠道，例如微信內渠道（微信好友/群、朋友圈、看一看、搜尋等），還包含微信外渠道（如一些第三方平臺，如今日頭條、B站、簡書及一些垂直媒體等）。
這樣就可以得到如下圖所示的公式：
當我們得到這樣一個公式之後，其實就有了具體的增長專案的方向和想法了，比如說我要提高我的站內閱讀，我可能要想辦法去提升我的公眾號粉絲數和文章開啟率了。
03 增長組織保障在我之前做增長的經驗裡，其實都沒有一個單獨的增長團隊去做支撐，大部分要麼是產品自發發起的，要麼是運營那邊發起的一些增長專案。
整個的實施過程，雖然也算不上非常地流暢、順利，但基本的增長迭代還是能保障的。
相信也有很多人是和我有一樣的想法：組織保障是最容易的，不就是組建一個使用者增長團隊，去協調各種資源做增長專案，然後實現增長目標嘛！這種想法暴露了一個很嚴重的問題——實現使用者增長的組織保障常常是最容易被忽略的。
最近一段時間，我對增長組織保障也越來越有感觸，原因就在於我發現有時候我們的增長專案不能實現快速的迭代測試，由於我們的開發資源有限，大部分開發資源已經排期被安排做其他功能需求，放到增長這一塊的資源就相對匱乏。
增長本身是需要透過快速地迭代去試錯和發現機會的，如果沒辦法實現快速迭代測試，那麼就無法形成增長勢能。
所以，有條件的話最好是能成立一個專門的使用者增長團隊，這樣對產品增長的快速迭代測試也能起到更好的效果。
04 增長曲線跨越做使用者增長，如果只是沿著同一條增長曲線發力，那麼最終一定會走到死衚衕，無法實現持續增長。本質上，這是一個探索第二增長曲線的話題。
也就是在第一增長曲線還沒有走到盡頭的情況下，我們需要提前去探索和尋找新的業務增長點，在主營業務下滑之前，新的業務就已經嶄露頭角甚至能給公司帶來一定盈利，只有這樣才能更好地避免陷入“經理人窘境”。
關於這個話題，我的經驗也不是很多在這裡就不繼續贅述了。
05 增長專案設計與執行這裡蠻有意思的是，作者把增長專案分為這麼幾個型別：漏斗型增長、功能型增長、策略型增長、整合型增長。
什麼是漏斗型增長呢？本質上來說，就是透過提升產品核心漏斗的轉化率，來做的相關的增長專案。
AARRR模型可能是漏斗型增長裡，最基本的方法論了，從獲取使用者、激發活躍、提升留存、增加收入、病毒傳播幾個方面系統闡述瞭如何做使用者增長。比如我們平時做的提升註冊轉化率、提升下單轉化率等等，都屬於漏斗型增長的範疇。
功能型增長，則更偏向於產品驅動一些，是希望透過新增產品功能來實現某些指標的增長，比如很多的工具產品如wifi 萬能鑰匙，會在自己的產品內增加內容模組，這其實就是希望透過內容來提升使用者的停留時長，以達到更好的商業變現。
但功能型增長，本身並不是那麼好做，一般而言耗費的開發資源也比較多，而是否能帶來增長也是一個很大的未知數，所以功能型增長最好是搭配策略型增長一起來做會效果較好。
那什麼是策略型增長呢？作者也打了一個很形象的比喻，比如功能型增長就像一挺重機槍，不太容易被搬到其他地方，造出來擺在某個地點後，如果這個地點沒有出現敵人，那我們好不容易造出來的武器就浪費了，有點像馬其諾防線；但是如果把功能型增長和策略型增長相結合，就像把重機槍裝在了越野車上，它會瞬間變成使用者增長的大殺器。
一個會移動的“馬其諾防線”，我們可以想象一下它的強大！
比如產品的push系統，就是很典型的策略型增長結合功能型增長的案例，本身push推送的開發是一個後臺功能，我們的目的是希望透過push來提升產品的活躍和留存，但是光push推送開發出來不一定能實現我們的目標。
本身產品內不同使用者對內容的偏好是不一樣的，以及在不同時間開啟內容的機率也是不一樣的，是否能透過某些策略形成一定的使用者標籤或畫像，給內容也打上相應的標籤，這樣推送是否會更有針對性一些，然後根據不斷地測試迭代，來達到最佳的推送策略。
整合型增長，作者重點闡述地是整合線上和線下資源，我結合自己的理解，重新對「整合型增長」的理解，我覺得就是整合一切可以整合的資源，來達到我們的增長目標。
這裡說的整合一切可以整合的資源，就包含線上、線上、部門內、部門外、公司內、公司外… 凡是有助於目標實現的資源，如果我們有能力進行觸達和整合，都應該去做相應的整合。
為什麼要做整合型增長，就是我們提到的增長專案大機率其實會失敗的，為了應對這個問題，我們要不斷尋找各種方法和資源來提升專案成功的機率，要想到每個環節可能都不會按照我們預想的情況發展。
#專欄作家#壹百度，微信公眾號：倒退集，人人都是產品經理專欄作家。暢銷書《產品之旅》作者，AI、區塊鏈資深產品人，擅長多平臺產品設計。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議