編輯導讀：產品迭代是做用戶增長的一個重要的實操方法，通過用戶的反饋不斷細化需求。那么，如何做好迭代以促進用戶增長呢？本文作者將從實踐案例出發，對此進行分析，希望對你有幫助。

前段時間，臨時支援了我廠的互助業務產品工作，這是個我廠S級項目，是大老板欽點必做的業務，規格高，因為這是一個被驗證可以聚集海量用戶的產品形態，有產品價值、社會價值，當然也有潛在可能的商業價值。

從前期的項目WIKI文檔結構就可以看出，這是一個高舉高打的項目，從市場到產品到運營都做了前期詳盡的分析與規劃。

就像戰略是打出來的，對于互聯網從業人員來說，最好的能力提升方法即是在高規格的戰場里真刀真槍的打出來。

前兩年主要都是在做場景業務。

場景業務不同于營銷轉化，考察的是用戶洞察、商業產品設計、資源整合，而互助業務是一個典型的2C業務，前期主要考驗的是產品的用戶增長能力。

關于用戶增長，很多年前在網易時即做了很多相關的工作，比如優化登錄方式、商品詳情頁、極簡交易流程、優惠券營銷等等。

以前關于用戶增長是產品和運營推廣協作完成的，用戶增長產品經理的職位的出現在我理解又是一次需求決定供給的要求，就如我曾經在（萬字深度）如何正確的學習《俞軍產品方法論》里寫到：

歷史上第一個產品經理源自1927年寶潔，背景原因在于日用品產品同質化嚴重市場競爭激烈，發現找一個人對產品結果負責，對于產品在市場上的成功最有利，所以有了產品經理這個崗位。

這個源頭揭示了一個重要的事實，企業內部的崗位劃分屬于是需求決定供給，產品經理崗位的出現是為了彌補原有流水線式分工的不足，新的崗位是為了讓企業的運作更有效率，而產品經理的最大意義在于面對市場不確定性時的需要，因為為如果流水線式分工就能解決的問題是沒有產品經理存在的必要的。

用戶增長產品經理的出現也是因為需要有具備產品經理思維和技能的人為用戶增長指標負責，權責利相互匹配，這種崗位設置對于用戶增長目標而言是最高效的。

迭代是做用戶增長的一個重要實操方法。

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了定義、需求分析、設計、實現與測試。采用這種方法，開發工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，并開始新一輪的迭代。

迭代方法的內核是：提出假設-方案實施-數據驗證

好比是目標是以最快的速度走出一個異常復雜的迷宮，我們無需冥思苦想去浩如煙海的資料庫中尋找蛛絲馬跡從而得出一個正確的路徑走法，而是根據手頭有限的信息分析后快速制定一條可行的路徑，記錄下自己推理過程，快速出發，去迷宮中驗證。

如果走到死胡同，我們浪費的時間和精力也是可控的，但根據走的過程中的觀察和沿路向路人的咨詢，我們除了收獲到此路不通的認知外我們還極可能排除10條類似錯誤的路徑。接下來再次重復以上步驟。

實踐證明了這是面對一個高度不確定性的目標時非常有效的方法。

01 V1.0版本

先來看看V1.0版本。

最初版本的加入落地頁可以看出當初的設計者是借鑒了當前支付寶的相互寶的樣式。

整體操作路徑為：

首頁補充實名信息—點擊加入—健康告知—開通代扣

02 V1.1版本

V1.1版的假設：

產品是于6.18期間上線的，上線前做了一些預熱宣傳，前幾天的轉化率很高，接手項目后，通過簡單的“診斷”，我判斷轉化率馬上就會掉下來。

判斷依據是：

• 當前加入互助落地頁偏向專業用戶，對大眾用戶吸引力不足
• 對于用戶而言要要完成是否加入的決策、填寫實名信息兩個任務，會嚴重影響用戶加入的意愿

實際上數據表現出來的趨勢的確如此。

當時我提出的解決方案是：

針對大眾用戶的心理特征進行優化。

以下就是我多年前一直在使用的套路，使用四宮格的方式對用戶進行簡單的分類。因為互助產品本質上還是“低端保險”，所以關于用戶的消費決策而言，最關鍵的兩個要素仍然是：風險意識和“保險”專業能力。

簡單抽象出幾個關鍵要素，將用戶的特征及相應對策歸納如下表：

如此本次迭代的概要信息如下：

假設基礎：

隨著產品的持續推廣勢必觸達更大比例大眾用戶，需要針對大眾用戶的心理特征進行落地頁及流程優化

迭代動作：

• 落地頁增加需求激發、從眾、口碑、稀缺等要素，增強營銷氛圍
• 將原本落地頁的完善實名信息（姓名、身份證）環節拆分至第二頁，落地頁專注營銷

迭代目標：整體轉化率提升1倍

兩天時間完成了V1.1版本的落地實施工作。

發布時選擇了一個流量第二大的渠道進行了測試，最終通過兩天的測試，數據觀測結果卻與預期差別很大：首頁加入互助按鈕的點擊率并沒有明顯提升，整體加入流程轉化率也并沒有明顯提升。

當然整個實驗過程中有一個小失誤，那就是并沒有采用A/B測試，沒有實驗組、對照組的對比，坦白來說V1.1版和V1.0版本會受到流量質量這個變量的影響，不能得出最客觀的結論。

當然數據反饋與預期有這么大的差距，明顯是預測與現實之間算漏了什么變量。

這個變量是什么呢？

直覺告訴我，可能是實驗渠道的實名用戶比例很高（實名用戶會自動帶出脫敏的實名信息，無需填寫），如果是這樣的話，這樣迭代動作中的第二項實際上是無效的，甚至在某種程度上來說反而會讓實名用戶的加入流程變繁瑣，反而讓轉化率降低。

事實是不是這樣呢？

根據運營同學統計的數據來看，的確如此！

V1.1算是投石問路，低成本讓我們收獲了對于用戶構成的重要認知。

03 V1.2版本

就在V1.1版本測試數據出來后，負責增長的運營同學焦慮的提出了一個新的方案，模仿競品將落地頁改成一屏的短版。

我質疑的問這個版本的假設基礎是什么，該同學沒回答出來，事實上我明白他內心的真實理由是增長壓力下減輕焦慮的病急亂投醫。

其實從我的經驗來看，這種改動是不太會成功的，但是行勝于言對團隊成員的成長的意義是在實踐中踩坑可以讓人更深刻更快的成長，所以對于這版的改動我沒有加以阻攔。

V1.2版本上線后，負責增長的運營同學焦急的守在電腦旁等待數據反饋，半天后他垂頭喪氣的告訴我，這個版本的整體轉化率比V1.1跌了好幾倍，他已經回滾到了V1.1版本。

忽視因果性，據說上這是不少做用戶增長的同學會犯的錯，這也是外界對于“App工廠”-字節跳動的詬病所在，過于依賴A/B測試，盲目追求相關性，反而喪失了產品經理之于因果性追求的價值。

04 V1.3版本

基于V1.1版本的認知，我們決定對實名用戶的加入流程進行優化。

假設基礎：

目前已實名用戶、未實名用戶登錄過程相同，但針對已實名用戶可以縮減其加入流程；

迭代方案：

• 刪掉個人信息確認頁
• 增加初次進入時的彈窗（強化營銷氛圍）
• 對于引導開通代扣的浮層進行了調整（V1.0、V1.1版本采用了偏功能性的浮層），新版在設計上通過隱喻暗示用戶“紅包”“福利”，進一步增強營銷氛圍

目標：

實名用戶加入互助轉化率提升1倍

上線后第一天，反饋數據就超出了我們的預期，實名用戶整體加入轉化率提升了5倍！

這個數據表現后續也一直穩定下來。

05 寫在最后

整體三個小版本的迭代，花了不到兩周的時間。

通過V1.1、V1.2的低成本試錯，成功捕捉了對于V1.3的關鍵假設認知，最終通過V1.3版本取得了轉化提升的階段成果。

整體迭代版本的管理，是通過Teambition來操作，需求、缺陷、版本一目了然，方便追溯、管理。

面對不確定性，任何人都不可能在當下拿出完美的解決方案，而“假設-實施-觀測”的快速迭代則為我們提供了一條快速逼近正確答案的陽關大道。

#專欄作家#

奇文天翔，微信公眾賬號：產品一二三，人人都是產品經理專欄作家。8年產品經理經驗，曾在網易、國內某龍頭金融集團負責用戶產品，當前在某移動互聯網巨頭負責金融子業務。

本文原創發布于人人都是產品經理，未經許可，不得轉載

題圖來自 Unsplash，基于CC0協議