精細化運營實戰指南 |增長會議進行的四個階段
上一章節我們設想一個情景：一家大型實體連鎖食品商店剛剛成立了一個增長團隊。我們希望首先明確一點，這個過程適用於任何團隊或企業，不論規模大小。它也適用於任何產品或專案，不論是一個新的軟體工具、一家網路零售商、一個媒體產品、一家硬體公司還是一個部落格，或是一次廣告或公關行動。本章節我們將描述這個團隊的每一個成員在這一過程的每一個階段應做的工作，我們也會提供一個日程樣板，詳細說明增長會議應如何進行。
準備工作
在進入增長黑客迴圈之前，這家連鎖食品商店應召開一次團隊啟動會議，向每一個團隊成員說明如何推進這個過程。在會議上，增長負責人應明確說明每一個成員應發揮的作用，以及他們作為個體和團隊應如何開展工作。同時應向他們介紹提出測試想法並排定測試優先順序的方法，我們將在本章後半部分介紹這一方法。之後，增長負責人應當請資料分析師分享前期分析結果。同時，增長負責人應向團隊說明關鍵增長槓桿、北極星指標以及關注點或目標。然後，團隊應設定每週要開展的試驗數量和節奏，即每週能夠有效地管理並執行多少試驗。一般來說，資料分析師和工程師都能夠對此進行初步估算，而隨著試驗過程的開展，團隊自然而然地也會做出相應的調整。
假設這一連鎖食品商店的增長團隊被安排負責公司新的移動App的銷量增長任務。這個App於幾個月前釋出，當時公司開展了大規模的傳統營銷攻勢，吸引了一批早期使用者，下載量達到了10萬。但是迄今為止，應用內購買創造的收入仍然非常低。於是公司決定不再大規模開展新的獲客攻勢，而是嘗試一下增長黑客法。
產品團隊將App打造得十分出色。他們也進行了恰當的資料跟蹤設定，以便在使用者使用App時獲得最有用的使用者行為反饋。他們也在開發階段與潛在使用者一起對App進行測試，使用者的反饋非常好。App提供了很多十分有吸引力的功能，比如商品搜尋、商品推薦、庫存情況、健康食譜以及一鍵購買食材的選項。此外，App裡還有一個卡路里計算器，可以讓使用者迅速瞭解任何商品和整餐的卡路里含量。產品團隊還考慮到使用者很可能會喜歡“不含麩質”“猶太潔食”和“有機”等搜尋選項，從而對產品進行了相應的設計。總之，整個應用的設計非常巧妙，但結果卻銷量平平，這十分令人不解。
為解開這一謎題，公司聘請了一位資深增長團隊領袖。他做的第一件事就是從市場、工程、產品和資料科學部門招募團隊成員。接下來，團隊需要尋找App使用者的“啊哈時刻”，瞭解體驗了“啊哈時刻”的使用者有哪些特徵以及他們對於App的使用與其他使用者有何不同。假設團隊的初步研究表明，使用者的“啊哈體驗”是在手機上購買食品並且在家裡等著第二天送貨上門所帶來的便利。在準備第一次增長團隊會議之前，增長負責人和市場、資料團隊成員一起制定了App的增長等式，等式如下：
安裝量×月活躍使用者數×消費使用者數×平均訂單金額×重複購買率=增長量
他們選擇的北極星指標是每個消費使用者創造的月收入，這是因為他們的最終目標是促進銷量。他們不只是需要使更多人使用App，也要打造一大群高度活躍的消費使用者，使這些使用者可以經常進行高額消費。確定了“啊哈時刻”，設定了資料追蹤，明確了核心指標，搭建了增長團隊，在一切都準備就緒之後，就可以啟動快節奏增長黑客過程了。
你無須在第一次增長會議上就決定要進行哪些測試。團隊成員可以利用接下來一週的時間進行頭腦風暴，篩選第一輪週期要測試的想法，然後在下一週的增長會議上對這些想法展開討論並做出決定。我們將以這個食品商店App為例，在本章詳細介紹團隊會提出哪些想法以及測試流程如何具體開展。
第一階段：分析
在這一階段，增長負責人要和資料分析師一起深入分析初期使用者資料以發現具有明顯特徵的使用者群體。首先，要將經常性的消費使用者和其他幾乎不使用或下載後從未使用的使用者分離開來。為探索潛在增長機會，他們制定了下列問題來指導分析過程：
我們的最佳客戶有哪些行為：
• 他們使用了哪些功能？
• 他們訪問了App的哪幾屏？
• 他們開啟App的頻率如何？
• 他們購買了哪些商品？
• 他們的平均訂單金額是多少？
• 他們在一天中的什麼時間下單？通常在哪些日子下單？
我們的最佳客戶有哪些特徵：
• 他們是從什麼渠道轉化為我們的客戶的？是廣告、推廣郵件還是其他渠道？
• 他們使用什麼裝置？
• 他們具有哪些人口學特徵，如年齡、收入等？
• 他們居住在哪些地區？
• 他們距離最近的本品牌商店或其他商店有多遠？
• 他們還使用其他哪些類似的App？
導致使用者棄用App的原因：
• 哪些屏的退出率最高？
• App存在哪些阻礙使用者採取某一行動的程式錯誤？
• 與其他提供商相比本應用中的商品價格如何？
• 消費使用者的行為中有哪些是棄用使用者沒有的？
• 他們從開始到棄用App的過程是怎樣的？在棄用之前他們在App中花費了多少時間？
在資料分析師研究資料的同時，團隊的營銷專家則開展了一系列使用者調查和採訪。其中一項調查的目的是獲取使用者的人口學和心理學資訊，另一項調查詢問了使用者線上和線下的購物習慣，而最後一項調查則是關於使用者最喜愛的App以及他們的移動裝置的使用情況。
之後，資料分析師和營銷專員將所有資料分析結果和使用者調查與採訪反饋彙總，編寫成報告並在第一次增長會議的前一週傳送給團隊成員。籌備這場會議時，增長負責人撰寫了一份總結，說明截至目前的研究結果，其中就包括經常性消費使用者區別於從未消費或只進行過一兩次購買的使用者的幾個十分有趣的共同特徵。
第一個特徵是這些活躍消費使用者的平均訂單金額高於50美元，剛剛超過免運送費的最低金額。除此之外，很多經常性消費使用者都有很多會重複購買的食品，這些食品顯然對他們來說是必需的。最後，最為活躍的消費使用者中相當大的一部分是從商店的移動網站跳轉到App中的。
基於資料分析，團隊已經提出了一些增長想法，併為第一次會議做好了準備。他們將在這次會議中討論了調研發現，評估初步的增長想法以充分利用這些發現，選出第一批旨在提高App使用者所創造的收入的想法，並規劃初步的試驗流程。
第二階段：提出想法
“點子”是增長的催化劑。你需要一系列的增長點子以形成穩定的增長動力。正如萊納斯·鮑林所言，“形成一個好想法的最佳辦法是提出很多想法”。正因如此，能夠不加限制地提出想法對於增長黑客過程尤為關鍵。這並不意味著要不加限制地測試這些想法。測試應當是經過嚴格的優先順序排定的。但是你需要鼓勵增長團隊成員充分發揮想象力並且對想法毫無保留。這能夠保證團隊形成足夠多的想法，以便從中篩選最具價值的那些。
在團隊會議之後的前四天，所有成員都應當提交儘可能多的可能提高App使用者創收的增長想法。提出想法時不應自我質疑，沒有什麼想法是過於瘋狂而不該提的。團隊成員應當根據自己的特定領域和專長獻計獻策。例如，使用者體驗設計師可能會建議對某個屏的顯示進行一些修改，營銷人員可能會提議測試鼓勵使用者首次下單的不同方法，而工程師則可能會提出優化產品效能和速度的一些想法。當然，他們提出的想法也不應僅限於自己的領域。
增長負責人應當建立一個專案管理系統，用於協調想法的提交和管理以及測試結果的跟蹤和報告。請記住，跨職能合作和資訊共享是增長黑客法的關鍵原則。正因如此，增長團隊裡的每一個人都應當有許可權使用這一想法儲備庫，並且隨時都可以往其中新增新內容。在GrowthHackers，我們建立了自己的軟體程式，叫作“Projects”，任何有許可權使用它的人都可以在軟體中提交想法並對試驗過程及結果進行跟蹤、評論和查閱。對於團隊使用的專案管理軟體沒有數量要求，這些軟體都可以用來促進試驗管理及成員就試驗策略進行溝通。
想法應當按照一個事先制定的模板提交到“儲備庫”中。團隊應規範想法提交的格式，因為只有這樣團隊才能迅速地對想法進行評估，而不需要問很多問題。提交的想法不應該只是提出像“我們的登錄檔太複雜了，應該簡化一下”這樣模糊的建議，而是必須清楚地說明應該做出什麼具體的改變，並闡述為什麼這一做法可能帶來結果的改進，同時也要說明如何衡量測試結果。
為說明想法提出的正確格式，讓我們再回到食品連鎖商店移動App的案例中。在第一次和第二次增長會議之間的那一週，團隊成員可以針對促進使用者消費的幾個方法中的任何一個提出自己的想法。有的想法可能旨在吸引那些下載了App但還未購買的人下第一筆訂單。有的可能針對已經購買過的使用者，要麼是吸引他們更頻繁地消費，要麼是增加他們的單筆訂單金額。還有的想法可能是為了吸引更多使用者從公司網站轉到App，因為資料顯示，從網站跳轉過來的使用者往往創造的價值更高。
假設App團隊的產品經理提出了打造“購物清單”功能的想法，這個列表可以儲存使用者之前購買的商品，從而使使用者可以輕鬆地再次購買。那麼這個想法應按照下面這個格式提交：
想法名稱：我們發現，給每個想法起一個簡短的名稱可以使討論更容易也更高效。在GrowthHackers，為保證名稱簡潔明瞭，我們設定了不能超過50個字的限制。對於這個例子，我們不妨給它起名叫“購物清單”。
想法描述：想法描述看起來應當像執行大綱那樣清晰明瞭，說明“誰”“什麼”“何處”“何時”“為什麼”和“如何”等問題。這個想法針對“誰”？例如，是所有的訪客、新使用者、復活使用者還是從某個流量源獲得的使用者？要創造“什麼”？是一份新的營銷文案還是一個新功能？這個新文案或是新功能將在“何處”執行？是在App的主屏還是其他地方？它將在“何時”出現在使用者螢幕上？比如訪客初次訪問網站著陸頁的時間。除此之外，描述還必須說明“為什麼”，即想法背後的論證過程。也要說明“如何”，即建議開展的測試型別，比如是A/B測試，還是要開發新功能，或是要展開新的廣告攻勢。
對於這個購物清單，產品經理可能會這樣描述：
使使用者輕鬆地檢視並再次訂購之前購買的商品將增加重複購買的人數，也會提高他們下單的速度。更便捷的再次購買操作應該能夠刺激更多使用者回購。購物清單功能應當新增到App的導航項中，使所有使用者都能夠使用，方便使用者儲存並回購他們喜愛的商品。這一功能應該先在早期使用者中進行測試，再提供給所有使用者使用。
假設：像任何其他型別的試驗一樣，“假設”應當簡要說明預期的因果關係。同樣，對於假設不能只是給出模糊的原因和結果，像“重複購買的使用者不夠多，我們應該激勵使用者回購”這樣的話只是對問題和努力方向的一句陳述，而假設應該是：“通過給使用者提供便捷查詢並回購商品的功能，回購使用者人數將提高20%。”
有些團隊可能會選擇在假設中說明預期成果，有些則可能不會。這麼做的好處是能夠使團隊清楚地瞭解一個想法可能帶來的量化結果。如果預期會有40%的收穫但結果只有5%，他們就會知道還有很多工作要做。但另一方面，對試驗結果的預測不可能精確，所以很多團隊不會進行預測。在GrowthHackers，我們根據過去類似的試驗、網上可獲得的基準資料、試驗參與人數和試驗對他們當前行為可能產生的影響來估算預期結果。
待測指標：必須具體說明為評估測試結果需要追蹤哪些指標。大多數試驗都應當統計不止一個指標，因為一個指標的改善有時候是通過犧牲其他指標來實現的。比如你在測試著陸頁的一份新的登錄檔格時，可能會發現因為註冊變得更加方便，所以註冊人數增加了，但是新註冊使用者的活躍度卻比以前有所降低，因為他們並不十分清楚他們註冊的是什麼。最終，這可能成為實現增長的嚴重障礙。
確定要追蹤的指標，首先要看一看試驗會使哪些“下游”指標發生變化。例如，對於購物清單試驗來說，應追蹤的指標包括使用購物清單功能的使用者數、每個清單儲存的商品數、回購數、回購比例以及平均每筆訂單的金額。這些指標有助於增長團隊評估試驗結果及試驗對重要指標的影響。統計的範圍包括有多少人使用了新功能以及新功能對於他們購買行為的影響，這將幫助團隊確定試驗是否提升了核心指標，即每位消費使用者創造的收入，以及試驗假設是否成立，即使用這一功能的App使用者回購比例是否提高。
請注意，儲備庫中的點子越多，找到能夠刺激增長的絕佳方法的可能性就越大。在增長黑客迴圈的下一階段，你需要對大量的想法進行篩選並排定優先順序，即哪些先測試，哪些晚一些測試，哪些直接拋棄。
最後，由於我們的目標是形成儘可能多的想法，因此不僅需要團隊成員提出想法，也需要整個公司的同事都參與進來。銷售團隊可能對客戶痛點有寶貴的見解，市場團隊則可能瞭解到一個可以用於開展獲客試驗的新的推廣平臺。在開展增長攻勢的初期，你應當主要從公司內部收集來自不同部門的想法，而隨著時間的推移，你也應考慮在第三方供應商和合作夥伴中集思廣益。外部人士往往能夠提出非常寶貴的建議，幫助團隊打破思維慣性的束縛。比如，有的顧問可能有和同型別公司合作的經驗，他們往往瞭解其他公司有哪些極為成功的做法。邀請客戶特別是最為活躍的使用者分享他們的觀點也可能給你帶來很大的啟發。他們往往非常樂意提供他們的見解，而且他們對於產品使用的經驗可能比你的團隊豐富得多。
在GrowthHackers，我們一開始只在增長團隊內部收集想法，但是很快發現團隊總在做類似的試驗。於是我們去詢問其他部門同事的意見。起初，我們犯了個錯誤，沒有告訴他們增長槓桿和核心指標是什麼，這導致我們收到了很多模糊的回覆，比如“你們需要我幫什麼忙？”或者“如果我想到什麼好點子就聯絡你們”。但是後來，我們告訴了他們我們的關注點，一時間各種建議便如潮水般湧來。這帶來了非常積極的結果，於是我們進一步將收集想法的範圍擴大到投資人和諮詢顧問，最後又擴大到增長黑客社群裡我們十分信任的會員。
一開始，我們通過郵件接收建議，然後再按照正確的格式進行編輯，新增到儲備庫中。在開發了“Projects”軟體之後，我們就給所有收到我們邀約的人開放了許可權，讓他們直接登入軟體提交想法。
事實上，團隊測試過的一些最好的點子都是來自公司以外的人士。例如，我們最為活躍的社群會員之一建議我們在網站上設立與知名增長專家對話的問答欄目，這後來成了我們訪問量和使用者參與增長的重要引擎。再比如，我們的一位顧問跟我們分享了在他的網站上一些效果十分顯著的SEO策略，我們採納了之後發現這些策略極大地提升了我們在谷歌上的排名。而這只是我們從團隊外部收集的許多絕佳創意中的兩個。
在提交想法之前的最後一個步驟是給想法打分，這可以幫助團隊在第三階段比較不同的試驗想法並排定優先順序。我們將在第三階段介紹這個評分體系，並說明如何利用它給想法評分並做出選擇。
第三階段：排定優先順序
在一個想法提交到團隊討論之前，必須要給它打分。打分能夠幫助團隊在不同的想法之間進行比較，以確定在什麼時間開展哪一項試驗。分數應該由提交想法的人給出，在評分之後這一想法才能進入儲備庫。
在GrowthHackers，肖恩制定了“ICE評分體系”以整理第二階段形成的各種想法，ICE三個字母分別代表impact（影響力）、confidence（信心）和ease（簡易性）。
在提交想法時，提交者應以10分為滿分給想法打分，打分根據以下三個標準：想法的潛在影響力、提交者對於想法取得效果的信心以及相應試驗開展的簡易程度。三項分別打分之後，再相加平均便得到一個想法的綜合得分。對儲備庫裡所有的想法進行評分之後，團隊就可以根據得分排序，在核心關注領域選擇得分最高的想法開始試驗。例如，如果增長團隊目前關注的是提高客戶留存率，那麼即使在獲客方面的一個想法分數非常高，團隊也會將之擱置一邊，選擇分數稍低一些的關於客戶留存的想法。
下面我們以食品連鎖商店App為例對其團隊提出的想法進行了排序。排序可以在表格或者專案管理軟體中進行。如表4–1所示，通過評分，可以清楚地看到哪兩個想法是應該最先測試的。當然，綜合得分並不一定最終決定想法的優先順序，團隊可能會在增長會議上討論之後出於某些原因選擇分數略低的一個想法。但是，評分是一個很好的起點。
給自己的想法打分不是一件容易的事，因為打分涉及一定的主觀性和預測性。但是有了經驗之後，你很快就會掌握如何利用資料、之前的試驗結果以及行業基準來估算自己想法的價值。此外，隨著你看到越來越多的想法被測試並看到這些測試的結果，你對於某個想法的潛在回報的把握也會越來越準確。不過還是有必要先了解一下這三個標準的具體含義及如何對它們進行評估。接下來就詳細介紹一下這三個標準。
影響力： 影響力是指某個想法對於促進團隊關注的指標的預期提升程度。在食品商店App的案例中，這一指標是每位使用者創造的收入。你可能認為只有具有很高影響力的想法才值得提交，但是要記住，團隊應同時選擇具有潛在高影響力、通常實施起來也更復雜的試驗和一些更容易實施但同時也可能產生有意義的結果的試驗。團隊的目標是篩選儘可能多的高影響力試驗，但如果有的試驗需要幾周甚至更長的時間籌備，那麼就應該選擇一些相對來說更容易實施的試驗填補這段空檔，這也是為什麼測試的簡易性也是ICE評分的標準之一。
信心： 這個標準衡量的是想法提出者對於想法產生預期影響的信心。對於這個標準的評分不應基於主觀臆測，而是要根據某種實證經驗，不管是資料分析、行業基準、可查閱的案例研究，還是之前的試驗經驗。
如果試驗是之前的一次成功試驗的迭代，那麼信心評分應當更高。這是一個不錯的做法，增長黑客界通常稱之為“雙倍下注”（doublingdown）。比如一項試驗的內容是通過臉譜網上提供免費樣品的廣告吸引使用者跳轉到著陸頁填寫郵箱資料，這個做法為公司提供了很多新的潛在客戶的郵箱地址。下一次你可能會嘗試通過谷歌等其他渠道推廣同一個著陸頁。第一次試驗時，因為你以為填寫登錄檔可能會使很多人放棄申領樣品，所以對於試驗的信心值比較低，只打了4分。但是做下一次試驗時，由於第一次試驗的成功，你可能將信心值提高到8分。信心值很高也可能是因為了解到公司內或公司外的其他團隊做過類似的成功試驗。
簡易性： 簡易性衡量的是進行一項試驗所需投入的時間和資源。重新進行介面設計或是改進結賬環節購物車的樣式都是具有潛在高影響力的想法，但是這樣的想法往往不容易落實，可能需要幾周甚至幾個月的準備時間。簡易性得分不僅可以幫助增長團隊認清一些不太現實的想法，也可以幫助他們在每一輪增長迴圈中發現一些“唾手可得”的試驗。
在召開團隊會議之前，增長負責人應檢視各個想法的初始得分，他可能會發現想法提交者沒有想到的一些問題。增長負責人可以基於他的過往經驗以及其他團隊成員的意見給出分數調整建議。但是，團隊不應過分糾結分數調整。這個分數只是用來進行優先順序的比較，不需要盡善盡美。如果團隊成員浪費太多時間爭論一項試驗的影響力得分，那麼增長會議很快就會陷入僵局。團隊應把這一分數作為一個重要參考，而不是當作優先順序排定的唯一依據。如果團隊對於某個分數存疑，增長負責人應依據自己的最佳判斷果斷做出決定，以引導團隊推進工作。
這一評分體系並非萬無一失，測試結果也經常與預期不符。有些評分最低的試驗結果反而產生了最好的效果。在GrowthHackers，我們曾做過一個簡單試驗，調整了網頁上每週“最佳帖子”簡報郵箱登記表的位置。這個登記表原本是在網站主頁的底部，因為我們原以為需要給使用者時間先瀏覽我們在首頁上主推的最受歡迎的帖子，然後再決定是否登記郵箱地址以接收我們的每週簡報。後來摩根提出了一個建議，即把登記邀請改到頁面頂端，把它放在一個更顯眼的位置。事實上，他本來並不認為這個調整能帶來多大的變化，所以只打了4分。但是我們還是決定測試一下這個想法，這是因為基於工程師團隊的反饋，這個試驗比較容易開展，我們在簡易性一欄給它打了9分。同時摩根有比較大的把握這個調整將能夠使使用者更容易看到登記邀請從而會在一定程度上增加登記量，於是在信心一欄打了8分。結果非常令人驚訝——登記量增加了7倍，遠遠超出了我們原本的預期。
講述這個例子並不是要說明摩根能提出這個點子有多厲害，其實他也提過不少以失敗而告終的點子。提出這個案例是為了說明我們對於自己想法的預期並不總是很準確，同時也說明不要輕易拋棄分數較低的想法。
雖然我們傾向於使用ICE評分，但是其他增長黑客也提出了其他評分體系。比如被譽為“轉化率優化之父”的布萊恩·埃森伯格就提出了“TIR體系”，即time（時間）、impact（影響力）和resources（資源）。 另外一個體系是“PIE”，即potential（潛力）、importance（重要性）和ease（簡易性）。 雖然不同的體系細節上可能存在差異，但是它們的總目標是一致的，即以量化的方式評估試驗想法，幫助團隊篩選不同試驗選擇、決定下一個試驗內容。
經過評分縮小了選擇範圍之後，你手裡的試驗可能仍然超出了接下來一週所能完成的量。有些想法需要更長時間去準備，比如那些需要大量軟體開發或設計工作的試驗。對於這樣的試驗應當在諮詢試驗籌備直接參與人員之後設定一個具體的測試日期。如果籌備工作涉及軟體開發，工程師和產品經理就應當為增長團隊估算一個時間框架，而如果要測試一個新的獲客渠道，市場團隊就要負責為增長團隊提供一個時間表做參考。
在當週無法啟動的試驗想法都應儲存在儲備庫中。你可以從中選擇一些用於接下來一週的試驗，而保留其他想法日後使用。關鍵是團隊應以時間和資源利用的最優化為目標安排他們的工作，專注於增長負責人選定的關注領域中最緊迫的需求。
讓我們再回到食品商店App的案例中來看一看如何開展篩選過程。App團隊的目標是增加每個使用者創造的收入。在收集了一些點子之後，他們決定選擇“初次下單優惠”和“把免運費政策資訊放在更明顯的位置”這兩個影響力和簡易性評分較高的想法進行測試
初次下單優惠試驗很可能會交由營銷人員負責，而免運費試驗則交由產品設計師負責。
假設團隊同時決定購物清單試驗也值得一試，但由於這一功能的開發比較複雜，增長負責人可能會讓產品經理詢問產品團隊的時間安排。獲得了這一資訊之後，增長團隊就可以考慮設定試驗啟動時間了。
我們建議團隊通過協作來進行試驗選擇。在增長會議召開前一天，增長負責人應通知團隊檢視想法儲備庫並從中選擇他們認為最有潛力的想法（不一定只是新提交的想法，可能也包括已經在庫裡的想法）。這些想法將作為候選在增長會議上討論，屆時團隊將共同決定在什麼時間啟動哪些試驗。團隊成員可以通過郵件對想法進行提名，或者如果系統允許的話，也可以在儲備庫中設定突出顯示。例如，在GrowthHackers的“Projects”系統中，團隊成員可以給想法加星標，加星之後想法就會進入單獨的列表中，增長負責人可以檢視並在會議上與成員展開討論。為保證被提名想法的數量在可管理範圍內，我們通常限制每個成員每週最多提出三個想法。
這些被提名的想法將會在增長會議上由成員進行討論，並選出將於下一週啟動的試驗。我們將在下一部分作詳細介紹。
第四階段：測試
一旦團隊選出下一週的試驗專案之後，這些試驗就會進入我們所謂的“UpNext”（即將開展）列表，如果你們採用手動追蹤，那麼這個列表可以是一張新的資料表。而如果你們使用專案管理軟體，這些試驗則會進入系統中的一個特別工作序列或列表。接下來負責試驗的成員就要和增長團隊的其他成員（或和其他部門的同事）一起籌備並部署試驗了。
真正意義上的跨職能合作正是在這時展開。再回到食品購物App的例子中，市場團隊成員可能會跟圖形設計和郵件營銷團隊合作設計初次下單優惠資訊的圖片與營銷文案。他們也會和資料分析師一起確定對照組（不參與試驗的使用者群）和試驗組，並保證試驗結果可正常追蹤。
當一切準備就緒時，增長負責人將向公司所有同事傳送試驗啟動通知，以保證其他負責該產品的團隊知曉試驗情況。如果在啟動某些試驗時遭遇障礙，比如工程師忙於其他重要專案，有可能幾周內無暇顧及試驗所需程式碼的編寫，那麼負責試驗的團隊成員必須立即通知增長負責人，以便負責人篩選“UpNext”列表中的其他想法來替換暫時無法進行的試驗。
每一個試驗的執行都意味著另一個試驗的落選。因此，對於點子的篩選和測試方式的選擇都應當十分慎重。一次糟糕的試驗就意味著團隊失去了一次寶貴的學習機會，這會放慢團隊工作的進度，而錯誤的資料會誤導團隊走錯方向。因此，必須保證每一次試驗都能產生統計上有效的結果。應當制定確保結果可靠的完善的指導規則，同時，團隊裡的資料分析師應負責將這些規則落實到試驗中去。本書不會探討試驗設計的細節，但是我們希望提出以下兩個我們認為非常有用的經驗法則。
採用99%的置信水平： 很多工具都會自動設定或允許使用者自定義試驗的置信水平。常用的置信水平為95%和99%。雖然這二者之間4個百分點的差別看起來並不大，但是從統計學的角度來看這會產生顯著的差異。95%的置信水平意味著一個“成功”的試驗仍然有5%的概率出錯。這意味著，每20次看似成功的試驗中就可能有一次其實是失敗的。而99%的置信水平則意味著100次測試裡只有一次是“假陽性”。因此，當你不確定時，就選擇99%的置信水平，從而大大降低因為“假陽性”結果而選錯試驗的風險。
永遠以對照組為依據： 當試驗明顯失敗時，團隊通常能夠在檢視資料之後迅速認識到這一點。但當試驗結果並不確定時，達成共識就不那麼容易了，特別是當需要耗費大量時間和精力確定結果時。沒有人希望看到自己辛苦付出的結果卻是竹籃打水一場空，所以團隊成員可能會讓試驗執行超出合理時間，寄希望於試驗樣本的擴大能夠改變走勢。這樣做雖然可以理解，但是當結果不確定時，最好的辦法就是堅持試驗的最初版本或者對照版本。因為雖然結果不確定，但是增加新的變數可能會導致試驗最終的失敗，成為一個巨大的潛在風險。可以這麼想，把試驗當作試驗組和對照組之間的比賽，雙方打成平手時，勝利就應當屬於對照組。
回到第一階段：分析與學習
對於試驗結果的分析應由分析師或具備資料分析能力的增長負責人進行。分析結果應當寫進試驗總結中，幷包括以下內容：
• 試驗名稱和描述，包括使用的變數和目標客戶。例如，試驗是針對某個營銷渠道還是隻針對移動使用者，抑或是針對付費使用者？
• 試驗型別。測試的是產品功能、網頁或App某屏上的營銷文案的修改還是某個創意，抑或是新的營銷策略？
• 受影響的特徵。這可能包括試驗在網站上或是App中執行位置的截圖，或者某個廣告牌、電視或電臺廣告中某個創意的副本。
• 關鍵指標。通過試驗希望改進的指標是什麼？
• 試驗時間點，包括起止日期，也要說明當天是一週中的哪一天。
• 試驗假設與結果，包括最初的ICE得分、樣本量、置信水平和統計功效。
• 潛在干擾因素。比如試驗執行的季節，或者是否有其他促銷活動可能影響了訪客行為。
• 結論。
這份總結應通過郵件傳送給團隊成員，同時附上一份備忘錄，簡要說明從試驗中獲得的收穫。同時也要將總結儲存到儲存所有試驗總結的資料庫中，我們將這個資料庫稱為“知識庫”（knowledgebase）。這個知識庫可以是共享檔案伺服器上一個所有成員均可訪問的專門資料夾，也可以是公司維客 或內網上的一個頁面。在GrowthHackers的“Projects”系統中，知識庫是軟體的一個組成部分，裡面還會顯示某個試驗是成功、失敗還是沒有確定結論。不論試驗報告如何儲存，關鍵是要確保團隊能夠輕鬆搜尋到所有的試驗結果，以便日後查閱並考慮調整變數重做試驗的可能。這樣做也能保證試驗不會重複，這在快節奏試驗過程中很容易發生。
除了構建知識庫之外，很多團隊還會定期在整個公司範圍內或給相關部門傳送報告，使公司員工及時瞭解增長進展。根據不同的公司文化和規範，可以採用不同的溝通方式。以下是幾個例子。
• 建立“試驗成功”郵件傳送列表，使接收者定期瞭解哪些試驗取得了成功及試驗對公司業務的積極影響。我們在英曼採取了這種做法，列表裡有20個人，都是事先表明希望收到通知的同事。有的公司也會發送關於所有試驗結果的郵件，其中也包括失敗和結果不確定的試驗。
• 對於使用Slack等即時通訊軟體的團隊，可以考慮設立一個頻道或是群聊，專門用於分享並討論試驗結果。在英曼，我們在公司的Slack賬戶中設立了一個頻道專門用於分享新啟動的試驗和最近結束的試驗結果，不論結果好壞都會在頻道里通知。
• 在公司總覽圖裡釋出試驗結果。如果公司不使用總覽圖，那麼可以直接列印試驗結果並張貼在辦公室的公共區域，通過這種低技術含量的辦法也能夠有效地溝通試驗進展。
更多資料可掃碼關注21天產品經理讀書訓練營，百人產品經理手把手帶你實現進階。並可免費獲取大禮包
