1.5 組建獨立增長團隊：挑戰仍在繼續

早期取得了不錯的成果后，我感到公司內部對于“增長實驗”的態度慢慢發生了轉變，我能調配的工程師和設計師資源也明顯增多。于是，我乘勝追擊，又在產品內外的其他關鍵路徑上進行了一系列測試，也取得了很好的結果。

結果就是硬道理，我一直以來倡導的獨立運營的增長團隊，終于得到了CEO和管理層的全力支持。

但是我沒想到，組建增長團隊的過程，遠沒有想象得順利。招募增長團隊的成員是第一關。

在招募增長工程師的過程中，我感覺到公司里的同事有不少顧慮，于是我跑去和那些做過增長實驗的程序員們聊天，了解到以下想法：

“增長實驗都是些很小的改動，這邊換個文字，那邊換個顏色，沒意思……”

“做好幾個版本，最終肯定有一些版本的代碼是需要扔掉的，感覺自己白干了……”

“……但是我喜歡的部分是可以清晰地看到自己工作的結果，有時候做產品功能，做了很久，突然被停掉了；或者即使上線了，也不知道到底有沒有用……”

了解了程序員們的顧慮之后，我明確了以下幾點：

第一，應該盡量把程序員從煩瑣的文本測試和小改動中解放出來，讓他們去做更復雜、更有挑戰性的實驗。采用提前埋點的方法或者第三方測試工具里的高級功能，其實可以很有效地解決這個問題。

第二，程序員喜歡看到自己的工作有影響力，要充分調動他們的積極性，需要讓他們參與到產生實驗假設和實驗設計的整個過程中去，并且及時地把結果反饋給他們。

第三，不是所有程序員都適合在增長團隊，如果只追求技術深度，在增長團隊里顯然不是最合適的；但是對于那些有產品思維，喜歡看到自己的工作對用戶和業務有影響的程序員來說，增長團隊的工作其實是更有吸引力的。

本著這樣幾點原則，我終于成功地找到了幾位合適的程序員。在設計師方面，我們的一位資深設計師，很順利地加入了增長團隊。他是完美的增長設計師人選，業務水平高、出活快，最關鍵的是他對增長指標和用戶心理有深刻了解，認同“設計最終為用戶服務”的理念，不歧視“簡單卻有效”的設計。

有了這樣一個“全棧”團隊，增長實驗的上線基本上可以不依賴其他團隊了。每天早上，我們團隊會有10分鐘的站立會議，匯報昨天做了什么、今天要做什么，以及有什么障礙。以兩周為一個周期，一般我們能上線好幾個增長實驗。

得到其他團隊的支持是第二關。

很多增長團隊誕生初期，會面臨要向全公司證明自己的局面，我們也不例外，時不時聽到來自其他團隊的懷疑的聲音：

“為什么要有統一的增長團隊？不是應該每個產品功能團隊自己設計實驗驅動增長嗎？”

“程序員資源這么緊張，專門去做實驗那不是浪費了嗎？”

“我們辛辛苦苦做的設計，憑什么增長團隊說改就改？”

……

正如前文所說的，增長是一件“套路”“流程”和“文化”三位一體的工作。在組建獨立增長團隊的過程中，我再一次認識到增長文化的重要性。因為，“增長”對大多數人來說，是一個新鮮事物，大家對它的了解程度并不高，甚至有些人還會有種種的誤解和恐懼。但增長又是一個天然需要跨團隊合作的工作。因此，作為一個增長團隊的負責人，你需要花足夠多的時間，做好教育和宣傳工作，讓大家了解并認可你們團隊的工作，給予支持。

我的嘗試從組織一個每周實驗心得分享會開始。我邀請了產品部門、市場部門、設計部門和客戶服務部門的代表參加，每周分享實驗的結果和從中得到的心得。開始只是增長團隊分享，很快市場團隊的同事也開始分享廣告測試的結果。大家互相提問，提供意見，還經常一起玩“猜猜哪個版本贏”的游戲。沒過多久，這個會議就被很多人稱為他們在公司里“最喜歡”的會議。

除了這個每周實驗心得分享會，我還在公司的企業通信工具Slack上面開通了一個“實驗心得”的群組，每周定期發布實驗的結果和心得，針對不同目標組織一系列面向全公司的頭腦風暴討論會，并且組織了一個“每周管理層增長討論會議”。

經過一系列的努力，在不到一年的時間里，我從加入公司時公司沒有增長團隊，發展到建立了一個獨立運轉的增長團隊，這期間，我們通過增長實驗達成了好幾個領域指標的大幅度提升，并且逐漸地讓全公司對增長實驗感興趣，同時對增長文化有一定的認同。我給自己這一年的“增長黑客之旅”打80分。

而我所面對的挑戰，也是所有增長團隊負責人所面臨的挑戰，仍在繼續：

1）在“低垂的果實”慢慢被摘掉之后，如何持續保證產生好的實驗結果，驅動增長指標？

2）面對激烈的競爭和變化的環境，如何離用戶更近、如何持續創新讓增長實驗成為產品的競爭優勢？

3）如何保證增長流程高效運作、增長團隊內部緊密合作、有主人翁的感覺？

4）如何確保和其他團隊以及管理層的良好溝通和合作，得到大家支持，達成共贏？

5）如何讓增長實驗和數據驅動成為公司文化的一部分？

……

環境瞬息萬變，增長永無止境，挑戰層出不窮，這也是對我而言，增長最有意思的地方之一吧！