實踐：ToB產品研發完成後還需要做哪些工作

到了這個階段，產品的一次迭代流程基本上就接近尾聲了。

這個階段是產品經理比較忙的階段，主要工作內容聚焦在驗收測試、市場支持、銷售支持方面。

一般情況下文檔量會比較多，接下來咱們就捋一捋這個階段產品的主要工作內容，以及完成這些工作內容的一些技巧和要注意的示項。

當然，這個階段還是以我個人的工作經驗為核心描述，僅供參考。

一、產品驗收

產品驗收是研發團隊和產品團隊的工作交接過程，產品驗收標誌着產品正式完成研發的相關工作，轉為後續迭代升級維護階段，也標誌着產品部門有了新的武器到市場上衝鋒陷陣了（是死是活就看產品自己的能力了）。

1. 交付物完整性驗收

產品研發上線後，產品經理首先要對研發提交過來的交付物是否完整進行整體性的檢查。

通常我們會在驗收啓動前跟研發對一個交付物清單，對研發提交的整體成果物達成一致。

對於ToB類型的產品，通常的交付物包括：

1. 產品本體：要明確產品版本號，模塊文件/源代碼文件清單（如果有必要的話），安裝程序等。
2. 文檔手冊：包括產品安裝手冊、測試報告（包含功能測試、壓力測試等）。

拿到產品交付過來的產品後，產品這邊需要根據成果物清單逐個進行對照檢查，如果對照過程中出現了任何的問題，直接給產品這邊的Leader發郵件（注意！一定要發郵件），要求他們重新檢查後，重新發送。

這個階段一定要注意：因為交付物是一個整體的概念，儘量不要研發一點一點發給你，你來替換某個或者某幾個文件，畢竟你對整體產品包不夠了解，容易替換出來問題；在完整性驗收的階段，一定是研發給你一個整體產品包過來做驗收。

2. 產品安裝驗收

確認了產品比較完整了，產品這邊需要協調現場部署人員對產品安裝過程進行驗收，來確認產品安裝過程的可執行度。

這個過程通常會包含兩個方面的功能：

• 一個方面是需要現場部署人員熟悉部署流程；
• 一方面也是驗證產品整體安裝部署的可執行能力。

過程就比較簡單，由現場部署工程師按照產品安裝手冊裏面的要求準備測試環境、安裝基礎的軟硬件平台，部署軟件產品。

這個過程中如果出現了任何問題，就需要提交產品級別的BUG，由產品研發相關人員做修正；一般情況是安裝程序BUG或者文檔BUG，都需要錄入到BUG管理系統進行追蹤維護。

3. 產品功能驗收

產品安裝驗收通過後，產品部門團隊就有了一套用來驗收的環境了。

產品部門就要根據需求對產品的功能進行整體性的試用和體驗。

這個過程中通常會產出以下的內容：

1）產品使用手冊：

產品使用手冊是產品的重要組成部分，產品團隊需要按照產品需求、產品原型來一邊做功能方面的驗收，一邊切圖製作產品使用手冊。

注意，產品使用手冊通常是給用户應急用的，用户一般情況不會看產品使用手冊，只有出現問題的時候才會使用。

那麼產品使用手冊除了常規的操作説明外，一定要加上Q&A的部分，把驗收過程中產品遇到的問題及解決方案都放在裏面。

2）產品BUG：

驗收過程中，可能會出現產品級別的BUG，通常我會把產品級別的BUG設置為以下幾種：

• 功能BUG：就是功能實現上跟預期不符，屬於嚴重BUG，需要修復後再發布；
• 體驗BUG：就是功能上滿足需求，就是使用過程中會有一點不舒服或者反人類習慣，這類的BUG一般情況下會加入到需求池觀察，如果客户提的多，就迭代改進（誰讓我們做的是ToB的產品呢？就是有這樣的優勢）。

3）快速使用手冊：

還記得再做產品設計的時候不是做過業務流程圖嘛？

為了能夠快速的幫助用户使用產品，我們通常會製作快速使用手冊。

這個快速使用手冊屬於指南性質的文檔，主要是以業務流程來串聯產品各模塊的功能的。

產品使用手冊是按照模塊視角來講解各個功能如何使用，那麼快速使用手冊就是用業務流程來串聯各個功能模塊的，用户可以通過快速使用手冊來高效的完成業務流程切換。

產品功能驗收完成後，我們就做了整體產品包的驗收及完善，產品包的內容就包括了以下內容了：

1. 產品本體；
2. 產品手冊（使用手冊、快速使用手冊、安裝手冊等）。

這個產品包就具備了上市的基本條件了，接下來產品就需要對市場人員、銷售人員進行後續的支持工作了。

二、市場支持

還記得市場分析階段的工作嘛？

我們在市場分析階段確定了產品的細分領域、重點客户羣。

在產品研發結束後，我們就需要從產品的角度對市場人員進行支持。

1. 試用

一般公司在這個階段已經圈定了一批客户做產品試用或產品新功能的使用，產品經理在這個階段就需要對用户羣體進行劃分。

我們通常劃分的原則是：

老用户 -> 試用新產品：

老用户一般是公司的穩定客户，關係比較深，不容易丟失。

新產品由於功能比較新，可能存在一系列穩定性的問題，我們通常會通過市場部門來聯絡老用户，免費讓其試用新產品或者新功能。

這個時候一定要注意做好產品的切換和備份，一旦出現影響到客户業務進程的問題，要能夠快速切換回老系統。

新用户 -> 推薦老產品：

新用户一般是公司剛簽約的客户，關係需要進一步維護，我們會給客户推薦運行比較穩定的老產品，逐步讓客户變成老用户。

潛在用户 -> 試用新產品：

潛在用户是指尚未承擔的客户，我們會給客户推薦新的產品，儘管產品本身穩定性上會有一點小問題，但是新產品往往會有一些新特性；這些特性既有可能打動潛在用户，形成購買，儘管會有一些風險。

客户羣體劃分完成後，我們會協助市場人員組織用户試用。

這時候需要編寫試用的方案，裏面包括安裝部署流程、應急預案、問題反饋流程等等內容。

切記，試用的目的是在風險可控的情況下蒐集用户反饋，所以反饋渠道一定要通常，最好能建立7*24小時的響應機制。

我們公司一般會派一個工程師做駐場，出現問題第一時間反饋、修復。

2. 宣講

在市場人員熟悉產品特性前，產品經理是最瞭解產品的人，因此我們在產品上線前的產品宣講主要是由產品經理來執行的，包括編寫宣講PPT、跟客户溝通、現場演示等工作。

市場人員主要負責組織跟客户的溝通會議。

後續市場人員逐步熟悉產品後，基本上就是市場人員來做這個工作了，產品就不再參與了。

我們的市場人員後續是要參與產品功能測試的，宣講PPT也是要市場人員來編寫，這樣的話市場人員講自己寫的PPT、自己做演示的時候就非常順暢了。

三、銷售支持

通過一系列市場行為，當產生一些成單意向的時候，就該我們的銷售團隊出馬了。

那麼銷售過程中需要做哪些支持呢？ToB的產品最大的坑來了。

幾乎每一個ToB的客户（至少是我解除的客户）都會有一些定製化的需求，那麼銷售在跟客户的時候就需要去客户現場蒐集需求；而很多客户在聊需求的時候都需要現場給出解決方案，那麼產品經理就需要跟着銷售去現場跟客户聊定製需求的解決方案。

解決方案的難以會直接影響到最後的成單價格，所以這個過程我們會非常謹慎，我的套路一般是這樣的（希望別有客户看到這篇文章）：

1. 引導使用現有功能

由於客户對產品不夠了解，提出來的需求可能現有功能已經可以滿足了，但是滿足的不夠徹底；那麼就需要產品經理通過引經據典憑藉三寸不爛之舌告訴客户：現在這個功能雖然麻煩一點，但是很強大啊，能完成你的要求的，要不您在試試？

2. 儘量減少改造範圍

如果引導失敗了，那就給客户出個改造非常小的方案，告訴客户這麼小小改一下，雖然不能完全滿足你的要求，但是功能上幾乎就一樣了，您看多好？

3. 拖延時間

如果上面的策略也不行，人家很強勢，就要按照他的要求改，就得用拖字訣，告訴客户：您這個方案確實比較好，但是影響範圍我現在還不好判斷，需要回去整體評估一下再給您出個方案，您看怎麼樣？

4. 讓客户選擇

拖延時間完成後，回公司整理客户需求解決方案，一次搞三個：

• 一個就是你提到的儘量減少改造範圍的方案；
• 一個是相對比較合理的方案；
• 還有一個就是完全按照客户需求的實現方案（比如這個方案你們不想做）。

然後這三個方案做個對比，想做的改造成本就寫的合理一點，不想做的改造成本就寫的虛高一點，然後甩給客户做選擇。

按照我的經驗，不管現場溝通會上客户咋説，最終選擇的方案大概率是你想做的那個，別問我咋知道的，反正客户就是這麼選的。

一般市場支持、銷售支持，工作都是比較瑣碎繁雜且時間比較隨機，所以產品需要做好時間管理，講一段時間內的重點工作安排好，這樣才能做到能夠完成階段性的重點工作的同時，不會由於忽略某些暫時不太重要的工作。

我一般是按照四象限的方法來對工作重點做規劃的，通常是一個月左右的時間做一次更新。

本文由 @Jimmy.jing 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議