一文了解增長黑客
前言
作為開發同學,你或許已經有過或即將遇到類似的困惑:增長黑客就是病毒營銷?開發參與增長過程就是搞搞報表;跑跑資料;且毫無挑戰?增長是產品同學的事情,對開發同學而言就是繼續以往 需求 > 實現 > 交付的常規流程,沒有其他變化?
如果你也遇到了這些困惑,或者你即將參與增長過程,希望在起步階段就能發揮主觀能動性,那就請繼續往下看。
本文主要是筆者針對《增長黑客》一書的總結:一方面,濃縮了書中的關鍵知識點;另一方面,結合筆者經驗,在必要的地方提供簡要的舉例說明。既算是筆者對《增長黑客》的知識梳理,也希望能幫助其他同學提高學習效率。
什麼是增長黑客?
兩個關鍵詞:資料指導;快速試驗
一個作用:促進 AARRR 中的一項或多項指標的增長
AARRR漏斗模型:獲客/Acquisition、啟用/Activation、留存/Retention、付費/Revenue、推薦/Referral。此外,還存在 RARRA 模型,5個概念沒有變,但提高了留存的重要性。
怎麼實踐增長黑客?
框架
這裡隱藏了細節,僅為了幫助同學們更快構建知識框架,詳細內容請前往文末獲取。
接下來,我們以這張腦圖為框架,逐步展開。
前提:確定產品是不可或缺的
你可以理解為找到產品的 “Aha moment”
- What?
“Aha moment” 就是產品使使用者眼前一亮的時刻,是使用者真正發現產品核心價值——產品為何存在、他們為何需要它以及他們能從中得到什麼——的時刻
- Why?
為什麼需要這一步?
浪費時間 —— 將精力浪費在推廣一個缺乏核心價值的產品上
不好的產品會使早期使用者流失,甚至成為憤怒的批判者
- How?
這裡提供 4 個方法來發現產品的 Aha moment
1. 向活躍使用者發起問卷調查,這裡需注意 3 點:
- 目標群體是活躍使用者
- 失望度比滿意度更能衡量使用者對產品的忠誠度。比如:如果這個產品明天就無法使用了你會有多失望?如果本產品無法使用了,你會用什麼替代產品?你向別人推薦過本產品嗎?等等。
- 相關負面評價達到40%。說明產品具備了不可或缺性(具備市場期待值)。如果在25%~40%,說明產品需要微調。如果不足25%,那你可能需要思考:你的目標群體和你的產品是否匹配?你的產品還需要完善哪些功能?
2. 衡量使用者留存 & 收集使用者資料
- 確定觀察的單位時間(月?周?日?
- 確定合理的留存率(60%?10%?90%?
- 收集使用者行為資料和一些屬性,並深入分析(這裡要注意隱私邊界)。某個群體的活躍行為,可能就是這個群體的 “Aha moment”。
3. 優化資訊傳達
最常見的就是 A/B Test,但 A/B Test 也有其侷限性。這裡還可以瞭解一下 bandit演算法(多臂賭博機模型)或其他測試方式
4. 針對產品進行高效試驗
涉及產品的修改往往成本較高,而且對使用者影響較大,因此這裡要注意應優先測試那些經之前的經驗證實能夠優化結果並改進使用者體驗的改動。對於耗時耗力的測試,團隊應當通過嚴密的論證將風險降到最低。
此外,對於工具型的產品,“Aha moment”需要場景化落地。以騰訊問卷為例,在用研方面,他可以為用研同學提供樣本庫、問卷管理、豐富的統計檢視和交叉分析、以及回收資料下載或同步到騰訊文件。顯然,這就是問卷的 “Aha moment” 路徑。但這個路徑顯然無法在教育、報名、政府/企業資訊收集等場景下復現。那麼,就要通過上述手段,更高效地找到這些場景下的“Aha moment”。
準備:獲得支援/組建團隊/找準方向
獲取高層支援
1. 增長團隊需要跨職能/部門溝通,這必然需要更高層對增長團隊的支援進行表態
2. 增長試驗需要資源,並要求高頻且連續的,這時候除了資源上的支援。在試驗的必要性被證明為前提,更需要高層的授權以及對試驗失敗的容忍。
3. 高層協助處理組織內部的敏感問題和可能出現的摩擦
增長團隊需要獲取足夠的資源進行快速試驗,必然會與其他團隊的資源相沖突。例如,團隊人員不足,導致增長團隊成員要兼顧產品的功能迭代。但兩三個月下來,產品的功能迭代擠壓了增長團隊成員的所有開發時間。這個問題使增長團隊徒有其名,具體增長工作幾乎沒有落實。要解決這個問題,顯然就需要相關職能團隊的上級負責人在資源協調方面給予支援。除此之外,也需要進行第一次增長團隊會議,就排期、試驗節奏和目標明確共識,保障後續增長試驗的持續推進。
組建增長團隊
公司發展初期成立獨立增長團隊的阻力是最小的,因為這時公司架構還沒有成型,資源歸屬和彙報制度還沒有正式確立下來
要保證試驗順利、快速推進,增長團隊不可避免的需要跨職能溝通,這時候,團隊裡面必然需要多個角色,如:團隊負責人、產品經理、工程師、資料分析師、設計師甚至營銷專員等等。需要注意的是:
- 這裡描述的是角色,一個團隊成員有可能同時擔任多個角色,尤其在專案和增長團隊的初期
- 負責人要能夠準確把控增長目標;管理試驗進度。但不限定負責人的專業背景,他可以是產品經理,可以是資料分析師甚至工程師等等。
- 營銷專員可以是僅在增長工作的某個階段才存在於團隊內的,短期目標達成後即離開,有時候他可能是產品經理兼任;有時候可能是外部顧問;有時候可能是團隊負責人。關鍵在於,從營銷的角度,可能給增長工作帶來更多有價值的建議
- 要激勵所有團隊成員毫無保留的提出關於增長試驗的想法,其意義不但在於廣泛收集創意,更在於保持團隊活力,確保增長試驗不至於停滯
- 團隊成員間的資訊高度同步,工作內容高度協調。其目的在於支撐試驗快速、連續地進行。
確定增長槓桿
前面我們已經介紹瞭如何找到了產品的 “Aha moment”。但要想穩定復現“Aha moment”,就需要更多的工作:
- 找到使用者對產品核心價值的體驗最直接相關的行為 —— 這就涉及到前面提到的,使用者體驗到 “Aha moment” 的操作路徑了
- 收集並整合資料資源 —— 但使用者反饋同樣重要
- 確定北極星指標,指標隨著團隊發展可能變化,甚至存在一個核心指標下,不同團隊進一步負責不同的更細節的北極星指標
- 確定核心指標和增長等式 —— 所有與增長相關的關鍵因素都在這個等式中有所體現,而這些因素相加共同驅動公司的增長
確定增長槓桿的另一層意義,就是為之後的增長工作指引方向。
實踐 —— 開始增長迴圈
核心方法
在開篇已經提及:資料指導 + 快速試驗。
快速試驗
這裡只提要點:
1. 鼓勵所有團隊成員毫無保留的提出試驗想法,這對保持增長節奏和團隊活力十分重要。
2. 試驗可能會有很多,因此需要一些打分機制來幫助我們排定優先順序 —— 但不要過渡糾結分數準確性,僅作參考即可,關鍵還是要看北極星指標,切勿本末倒置。書中列舉的可用的方法有:ICE、TIR和PIE模型(具體見下圖)。
A/B Test 存在其侷限性,例如,不能多維的描述測試結果。因此,我們常常還需要別的測試方法(如 bandit演算法)
快速試驗不等於一股腦的進行一堆不知道是否有效的試驗,所有進行的試驗一定是經過論證的、具有一定影響力的。
具體實踐 —— AARRR
這是常見的增長模型之一,亦指使用者在產品使用週期中的幾個關鍵過程。除此之外,也演化出了 RARRA 模型,甚至。以及更多這裡相信很多產品同學比我更專業。我僅從各個指標羅列一下具體方法。
最後的話
如果你以前對增長黑客沒有了解,看完此文,你可能會發現,雖然你沒有增長黑客的概念,但《增長黑客》中很多要求、方法、原理等,其實都已經在我們的日常工作中有所實踐,包括:成員間高度協調;資訊同步;在什麼時候獲取高層支援;資料洞察;病毒營銷等等。拆開來看,每個問題都有更多更詳盡的書籍值得推薦(見文末“延伸閱讀”)。顯然,《增長黑客》並沒有提出太多新的觀點或工具。筆者認為,這本書更多的是關於“促進增長目標”方面,總結了一系列經驗。
在傳統筒倉模式下,各個部門、職能崗位各司其職,互補相關,遵照著一套流程完成一系列的版本迭代。看起來各團隊、崗位的資訊是極容易不對稱的。實際上,現在很多公司在崇尚扁平化發展。筆者在 2017 至 2020 年間,在國內流行的招聘平臺上,也常看到一些招聘單位將扁平化管理作為賣點之一(甚至包括一些非網際網路公司)。但實際上,絕對的扁平隨著團隊規模增大,風險和問題會隨之而來(參考:企業管理層次 “扁平化" 跟 “金字塔” 各有哪些優缺點?- 知乎 )。筆者過去曾就職的某單位,團隊從不到 50人在一年內快速擴充至 100+ 人。扁平化在此帶來的問題就是多數成員都有數不清的大小會議和溝通成本,專注於本質工作的時間不足 50%。而不得不在管理上,對資訊進行逐層過濾(又迴歸了金字塔管理模型,只是層次並不算特別深)。因此,筆者大膽猜想,整體採用傳統的筒倉結構、或金字塔結構,在如增長團隊等特殊職能團隊上採用扁平化結構——在團隊內保持資訊高度同步,成員高度協調——會不會是最佳實踐?
說完書本內容和團隊,最後再講講增長過程吧。筆者作為一名團隊內的開發成員,一開始對增長黑客的概念其實是模糊不清的。或許其他同學(尤其是開發同學)也會有如我這般的誤解:增長是產品運營或其他產品同學的事情,與開發無關;增長黑客就是病毒營銷;增長黑客就是一堆AB Test……(實際上,除了AB Test,上面不提到了還有多臂賭博機嘛~)。實際上,增長黑客的核心方法,筆者認為就是上文總結的“資料指導 + 快速試驗”。無論是團隊組成、獲取高層支援、保持團隊高度協調還是明確北極星指標和增長槓桿,最終都是為保障快速試驗進行的。而開發同學,在這其中不但要協助實施具體試驗。也要根據自己掌握的資訊主動為團隊工作提供協助,或從自己的角度提出更多試驗構想(書中講述為何打破筒倉時,提供的BitTorrent的案例令我大受啟發,詳見下方引用)。
(來自《增長黑客》第一章第一節——打破筒倉)
接連不斷的成功讓BitTorrent移動團隊大受鼓舞,每一個人都開始提出可以測試的想法。他們測試的其中一個想法只有那些擁有無私精神的技術人員才能想到:自動關閉應用以節省手機電量。移動團隊在對免費版App的“超級使用者”(那些頻繁使用App但還沒有升級到專業版的人)進行專項調查的時候發現了這個增長機會。調查發現這些使用者的一個主要痛點是由於高強度使用造成的手機電量迅速流失。於是,工程師很快提出了一個想法:打造一個專屬於專業版的功能,當App檢測到使用者手機電量只剩不到35%時便自動關閉耗電的後臺檔案傳輸。他們在免費版App裡推廣這一功能,當使用者電量不足時,App便會提示他們專業版提供這個功能,吸引他們馬上升級。這個新功能十分受使用者歡迎,也使公司收入增加了47%。
這篇文章篇幅較大,因此就不在此羅列增長所需的資料分析方法和具體工具了,有興趣的同學歡迎關注後續的文章。
延伸閱讀
書單中,有的書筆者也沒看完,但就已讀內容而言,筆者認為對理解並實踐增長黑客有較大幫助,因此羅列出來,僅供參考:
《在你身邊為你設計. Ⅲ,騰訊服務設計思維與實戰》
注意到《增長黑客》書中,洞察使用者需求並改進使用者體驗既是增長黑客的要求也是實踐的基本方法。該書由騰訊的使用者研究與體驗設計部編著,關於如何洞察使用者需求;打造設計團隊;提出方案並推動落實等方面提出了系統的方法論。值得參考借鑑。
《OKR工作法:谷歌、領英等頂級公司的高績效祕籍》
一本兩小時就能看完的書。《增長黑客》實踐要求團隊以資料為指導,在明確的方向上,保持高度的協調和溝通,這個觀點與OKR工作法的要求高度相似。實際上,OKR目前也在包括騰訊在內的多家國內公司有推廣,要想更好落實、舉一反三,無疑很有必要先去系統的瞭解一下。
《敏捷軟體開發:原則、模式與實踐》
同樣,《增長黑客》描述的關於高度協調、快速試驗的觀點和具體方法,與敏捷開發持續迭代、持續交付的觀點也多有相似。目前,國內已經有很多網際網路公司都推崇敏捷開發,但在理解和實踐上,卻五花八門。瞭解敏捷開發的歷史背景和核心觀點,相必對增長黑客的實踐也有幫助。
《思考,快與慢》
本書從人在思考中存在的兩個系統(運用直覺、進行快速思考的系統1和需付出努力、執行更慢的系統2)展開,描述了人的思考和選擇過程。其中有許多基於消費者購買行為的案例(實際上,作者也是一名曾獲得諾貝爾獎的經濟學家)。在《增長黑客》第八章 “變現:提高每位使用者帶來的收益” 的“優化定價” 一節中也有提及,因此也安利一下
《上癮》
筆者還沒看過,不過是《增長黑客》書中有提及的一本書,專門講如何讓使用者“形成一種習慣的”,並提出了一個由觸發物、投資、行動、回報四部分組成的“上癮模型”。似乎對提升使用者留存很有幫助。
附件
怎麼實踐增長黑客詳情:
來源:騰訊大講堂
原文:https://mp.weixin.qq.com/s/t4Xsm-xWYEi7wpYpopHJAQ
相關文章
- 增長黑客國內落地實踐黑客
- 一文了解MysqlMySql
- 一文了解cookieCookie
- 增長黑客怎麼做運營資料分析?黑客
- 產品讀書《增長黑客:創業公司的使用者與收入增長祕籍》黑客創業
- 8個祕訣成就頂級增長黑客 | 如何運用資料試驗打造增長引擎黑客
- 一文了解:Redis事務Redis
- 一文了解Text-to-SQLSQL
- 一文了解HAProxy主要特性
- 一文了解Dart語法Dart
- 一文了解java列舉Java
- 一文了解Flink State Backends
- 一文了解M-Tree
- 一文了解DNS(域名系統)DNS
- 一文了解Docker基本概念Docker
- 一文了解什麼是PostgreSQLSQL
- 一文了解 DataLeap 中的 Notebook
- 一文了解SAP IBP是什麼
- 一文了解:Redis的AOF持久化Redis持久化
- 一文了解有趣的位運算(&、|、^、~、>>、<<)
- 一文了解Promise使用與實現Promise
- 以增長黑客的思維來做廣告變現,能成功嗎?黑客
- 快速加入Health Kit,一文了解稽核流程
- 一文了解授信審批策略及流程
- 一文了解前端與全棧工程師!前端全棧工程師
- 一文了解Spring Boot啟動類SpringApplicationSpring BootAPP
- 一文了解 NebulaGraph 上的 Spark 專案Spark
- 一文了解怎麼獲取代理IP
- 一文了解主流大資料ETL工具大資料
- 一文了解 Java 中的構造器Java
- 一文了解萬用字元SSL證書字元
- 騰訊QQ大資料 :從“增長黑客”談資料驅動的方法大資料黑客
- 一文了解Android中路由(Router)的實現Android路由
- 一文了解CDN(內容分發網路)
- Java14版本特性【一文了解】Java
- 一文了解Python反射機制(很詳細)Python反射
- 一文了解微服務的流程和組織微服務
- 一文了解 Nebula Graph 上的 Spark 專案Spark