B2B2C 產品經理（五）產品測試＆驗證、上線策略＆規劃
《B2B2C 產品經理（一）使用者研究、競品研究的挑戰》
《B2B2C 產品經理（二）目標、指標、產品團隊的資源分配》
《B2B2C 產品經理（三）從初創、成長到成熟期，不同階段的產品策略》
《B2B2C 產品經理（四）產品設計心態、產品共通特性》
《B2B2C 產品經理（五）產品測試＆驗證、上線策略＆規劃》
前面幾篇文章中分享了 B2B2C 產品前期研究與規劃、中期設計與開發的經驗，終於要進入到最後產品測試、驗證、上線的步驟了！
這篇文章的背景，可以想像成已經有許多活躍客戶的成長期 B2B2C SaaS 產品，其客戶類型有大有小、型態也愈來愈多元，在上線時需要考慮到各式各樣的情境。
【文章目錄】
- B2B2C 產品驗證：測試＆實驗
- B2B2C 產品的上線策略＆規劃
- 失控的多版本宇宙
- 結語▍B2B2C 產品驗證：測試＆實驗
「如何去驗證產品的成功？」這件事情應該在最一開始規劃產品、訂定產品策略的時候就要考慮進去，只不過因為執行的時間比較後期，所以現在才提到。
而如果團隊要做的是市場驗證、商業模式的驗證，那執行的時間點則會在更前面，甚至可以算是第一階段問題探索中使用者研究或市場研究的範疇了。
我待過的公司在這部分其實都還在非常幼兒的階段，這邊就稍微紀錄一下我們遇過的狀況與現階段的想法～
▧ 什麼是產品驗證？
產品驗證就是在產品規劃時或正式上線前先驗證我們的假設，確認這東西是否足夠好 — — 能夠達成商業目標、解決使用者問題、滿足客戶的需求，再來規劃上線策略，或持續進行產品的調整。
這其中的方法包含：較前期的原型測試（Prototype Testing）、試探性質的假門測試（Fake Door Testing）；正式上線前的 Beta Release 與使用者測試訪談、A/B Testing 的量化分析等等。
在之前的文章中提到過，B2B2C 產品為了符合不同類型客戶的使用情境與需求，可能會在後台提供各種可以自行客製化開關的功能，而每個客戶會找到各自最好的搭配方式來滿足自己的需求、服務 C 端，因此他們開啟的功能的排列組合會非常不同。
這導致做測試與實驗的時候非常麻煩，用「有開啟某功能類別」來做客戶的 Segmentation 也不是什麼非常好的方式。
▧ B2B2C 的三種產品改動類型
在做 B2B2C 產品的時候，大概可以分為三種類型的產品改動 — — 純 B、純 C、BC 端連動，接下來會再次以第一篇提過的 Shopify 線上開店平台舉例。
不同類型的產品改動會牽扯到的使用者不同，而要碰到 C 端有時也要經過 B 端同意，所以每個面向適合的驗證方向也會略有不同。
如果要講出一個大原則的話，B 端著重質化分析與各種訪談、 C 端可以使用量化資料來驗證，若是 BC 連動產品改動就比較複雜，可以試者幫 B 端分群來選擇使用不同的測試、驗證、上線模式。
▧ 純 B 端的產品驗證
純 B 端改動舉例：優化 B 端的商品成效報表/分析工具、讓 B 端可以設定不同員工的使用權限
我必須很誠實的說，我們做比較大型的 B 端新功能與改動時，幾乎都是抱持著「我們一定會上線這個功能！只是到底這個版本足不足夠好來釋出給所有人？」的心態。畢竟照常理來說，訂閱制 SaaS 產品有愈多功能時愈能留住老客戶、也愈能吸引新客戶。
也因此我們會花比較多力氣在前期的客戶訪談、原型測試等階段，以確保方向是沒問題的、資源投入會是值得的。
產品驗證與上線策略則是用分批次的 Beta 測試來分階段釋出，搭配客戶測後訪談、實際使用數據分析來蒐集回饋與調整方向，詳細方式請見：
除了 B 端使用上提供的質化回饋，也要去關注後台頁面、功能、改動的使用頻次與相關數據，確保 B 端給的訪談內容跟他們的使用行為一致。我們也曾經針對純 B 端做過 A/B Testing 來進行純數據的產品驗證，主要用於現有功能的改動、使用流程的改動。
▧ 純 C 端的產品驗證
純 C 端改動舉例：優化 C 端使用購物車的體驗、優化 C 端的商品搜尋功能
關於接觸 C 端的困難之前也提過，就是他們是我們 B 端客戶的客戶/使用者，因此在某些情況下、端看客戶的龜毛程度，B 端客戶們通常不希望我們在未告知的情況下大改了 C 端的介面、功能等等，甚至也不一定會允許我們在他們的 C 端使用者身上進行 A/B Testing 或假門測試。
有些客戶是聽到「測試」兩個字就覺得功能或改動是否還不完全？是不是有可能壞掉、讓使用者體驗很差？有些客戶則是聽到 A/B Testing 會有兩種版本，覺得可能會需要額外進行內部教育訓練很麻煩，例如客服遇到歧異的使用者問題該如何處理？有些客戶則是認為 A/B Testing 如果新版本成效不好、我們最後選擇不上線，那對於終端使用者來說介面改版反反覆覆，令人感覺不專業。
總之，我們大概分為以下幾種情況處理：
- 小型的改動，我們會直接默默的在所有 B 端客戶、所有 C 端使用者身上進行 A/B Testing
- 大型的改動，找出曾經提過相關改動需求、或我們假設有類似需求的 B 端客戶，詢問是否願意針對這個新功能或新改動協助我們進行A/B Testing
- 大型的改動，最保底的就是再次找回客戶結盟 Partnership Program 中的「友好客戶」來當第一批測試白老鼠！他們當初願意讓我們找他們的使用者進行訪談與測試，通常也會願意讓我們進行上線前測試
不管是 2 或 3 其實都有一定的偏誤風險，畢竟 A/B Testing 講求的是隨機測試，那客戶那端我們都精心挑選挑過了，請問哪裡隨機？我就問？
最明顯的風險就是，每個客戶狀況不同，這個新功能能讓甲客戶的 A 指標數字上升，但可能讓產業或使用情境不同的乙客戶的 A 指標數字下降；或是更複雜一些，甲客戶的 A 指標、B 指標數字都上升，而乙客戶的 A 指標數字上升、B 指標數字卻下降，我們如果沒注意到可能會害乙客戶大抱怨甚至損害到客戶的收入。
要試圖解決這個問題，一方面是在訂定指標和看數據時，一定要關注健康指標（Health Metrics）與反指標（Counter Metric）來確保總體利大於弊。
另一方面是如果客戶類型、使用者類型比較多，要做好 B 端客戶類型、C 端使用者類型的 Segment 分類，如果無法很理想地針對不同類型 B 端客戶的使用者進行測試與驗證，至少要很清楚這份結果是有偏見的，可以當成做決策的一個資料來源，不過還是需要搭配其他的考量點。
如果很順利的找到不同類型的 B 端客戶來進行測試與驗證，在分析的時候除了看總體數據狀況，也必須針對不同 Segment 來看，來理解在不同類型、使用情境下使否有所差異。
如果發現數字有很大的差異，產品團隊與數據分析團隊就必須討論出一些新的假設，看是否需要繼續做些改動、測試、驗證，或是讓這個改動變成一個能由 B 端在後台自由設定開關的功能，也就是上一篇文章中提到的「需求管理：允許 B 端自行變更各種設定與模組」的作法。
若是決定做成設定或模組的形式，那就會變成下面這種 B、C 端連動的改動。
▧ B、C 端連動的測試＆實驗
B、C 連動的產品改動舉例：
・B 端可以在後台上架商品、C 端可以在前台瀏覽與購買商品
・B 端可以在後台確認訂單資訊並出貨、C 端可以在前台會員訂單頁面查看訂單與物流狀態
・C 端可以從前台發送訊息詢問店家問題、B 端可以在後台回覆訊息並查看會員資料
其實 BC 連動的產品驗證心態跟處理純 B 端是幾乎相同的，比較不同的地方是：
- 一樣要去注意不同類型的 B 端客戶，其 C 端使用者的行為或帶來的效益是否有異同，來決定模組設計方式是否需要調整、以及上線方式
- 若是需要 B 端從後台主動打開後才能使用的功能，可以將其分為三種類型來觀察：
- 有開始試用、且有持續使用新功能（Active Users）
- 有開始試用、但沒持續使用（Abandoners）
- 根本沒發現有新功能、有發現但沒開始試用（Non-starters）
▍B2B2C 產品的上線規劃
這邊就先撇開如果有多國市場要先上哪個市場這類型較廣的上線策略，而聚焦在客戶們身上。
▧ 上線策略一：驗證結果正向、直接上沒在怕
使用情境：新功能、小改動
最直觀的做法，就是當我們產品驗證的結果是正向的，那就可以在各個測試與迭代都告一段落後，釋出新的版本給所有客戶與所有使用者。
那反過來，如果產品驗證結果並不理想，我們不想要上呢？
有時候麻煩的地方是，當某個改動或功能已經給一部分客戶 Beta 測試後，就算總體成效不好，但只要某些已經在使用新功能的客戶覺得很棒很想持續使用，就會自己騎虎難下。所以事前、事後如何好好溝通，跟客服、業務、AM 團隊配合是非常重要的。
▧ 上線策略二：分階段上線、淘汰舊版本
使用情境：現有功能改動、介面大改版
當改到了現有功能或介面，也就是客戶已經每天使用習慣的後台、或是客戶覺得 C 端使用者已經習慣的前台，那就比較麻煩些。（不過若你們的產品是後台使用頻率較低的，那通常就不太會遇到這類問題）
針對 B 端後台，客戶想要好好教育訓練他們的內部員工，再讓改版上線，因此有時候我們就會使用分階段的方式，先將改版釋出給所有不在意的客戶，再訂定好時程並分批次釋出給較謹慎的客戶們。
針對 C 端前台，客戶要煩惱他們的使用者會不會用不習慣，所以可能也會想要先準備好新的使用手冊新的使用手冊（User Guide）或是更新他們的 FAQ 頁面後，再讓改版上線。如果客戶不願意改用新版本（覺得新介面比較醜、覺得新邏輯比較難懂），那我們前面產品驗證所得到的 C 端數字成效就可以拿來說服他們。
另一個在各種產品都很常見的上線技巧是，提供一個「升級至新版本」的選項，並說明強制更新至新版本的時間。在這段時間內，使用者可以隨意地切換至新版本、舊版本來習慣或提供回饋，然後時間一到就會釋出新版本給所有使用者。
▧ 上線策略三：大客戶優先的公關行銷手法
使用情境：與公司策略部門討論過後，優先給大客戶使用，後續再搭配上述一或二方式
這是我們公司之前用過的方法，也就是經歷了產品驗證的過程後，只優先將新功能、新介面、新改動釋出給一個事先談妥的大客戶，共同開一個記者會或進行一些公關行銷，雙方都展現自己的影響力，客戶搶先試用、我們借助品牌曝光，過一陣子後再陸續釋出這個新版本給其他所有使用者。
▍失控的多版本宇宙
前面提到有些客戶比較謹慎，在產品改動前需要過內部的審核流程、並且完成教育訓練，才願意讓我們把新版本放到他們後台。
這個時程週期之長，有時候可以拉到好幾個月、甚至年！再加上使用 Feature Flags 進行 Beta 測試的時間，其實技術團隊可能會有很長一段時間都要維護兩個、甚至多個版本的 code，這對於產品品質控管、以及之後在他之上做新改動都會有很多的困難，因此跟各部門溝通，盡量縮短整個上線和 migration 的時長也是很考驗負責人的能力。
至於客戶被升級成新版本後，又想要回覆上一動，又是另一個鬼故事了。
▍結語
做產品驗證的前提，是你要真的相信這件事。
亦即，如果測試與實驗的成效不好，就真的不要上線，至少不要上線手上這個版本。
在實驗文化還不盛行的公司中，這真的不是一件容易的事，一來是可能連實驗都不做、二來是只要指標沒下降原則上都會讓他上線。當然如果原先的目的就不是為了影響指標，而是為了其他理由，因此效果不顯著的話，那這個上線的決策又另當別論。
B2B2C 產品經理系列文就在這邊暫告一段落，如果有什麼想了解的主題，歡迎在底下留言，或到我們的產品三眼怪的臉書粉絲團許願唷～
《B2B2C 產品經理（一）使用者研究、競品研究的挑戰》
《B2B2C 產品經理（二）目標、指標、產品團隊的資源分配》
《B2B2C 產品經理（三）從初創、成長到成熟期，不同階段的產品策略》
《B2B2C 產品經理（四）產品設計心態、產品共通特性》
《B2B2C 產品經理（五）產品測試＆驗證、上線策略＆規劃》
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多商業模式與產品心法相關文章，請盡情長按拍手（max 50）讓我們知道 👏🏻記得追蹤「產品三眼怪實驗室」的粉專（◉◉◉）才不會錯過最新文章和 Podcast！
歡迎參考「文章列表」並善用標籤來搜尋與篩選我們所有的文章與分類！
