用戶運營的本質在於跟用戶有效地溝通。本文作者結合自己工作中的所思所想，對用戶溝通的4個階段展開了分析總結。
做好用戶溝通，瞭解用戶習慣和用戶目標對於一個B端產品的成功來說十分重要。所以今天我想聊一聊關於用戶溝通我個人的一些思路。在產品迭代中，按照產品的輸出過程，我把用戶溝通可以分為以下幾個階段，需求溝通，方案確認，上線培訓，產品灰測。
01 用戶溝通
從需求方提出需求開始到產品方案的輸出期間產品經理和需求方發生的溝通我將其統稱為需求溝通階段。主要是產品經理和用戶基於當前產品使用過程中發現的問題或者基於本人/本業務的目標期望而對產品提出的需求和想法進行溝通。在這個階段最重要的一點是要明確用戶到底需要什麼（用戶需求），他為什麼需求（用戶價值）。
1. 用戶需求挖掘
通常用戶需要一些引導才能得出真實的需求。你可能會問，作為用戶，應該是最清楚自己要什麼的，為什麼要引導，引導什麼？舉個實際案例，某天用戶A提出用戶崗位中包含關鍵字“運輸”的用戶在填寫用戶資料時要求強校驗用戶的“運輸工具”是否已經填寫，如果未填寫則提示保存失敗。那麼作為產品經理的你要怎麼做，是否直接按照用戶提出的要求通過崗位名稱的判斷在填寫頁面增加用戶要求的校驗嗎？
————（此處請思考三分鐘）————
需求方說他想要的真的就是他想要的嗎？NO。
在溝通過程中建議用5W1H來定位用戶場景，使用5Why挖掘用戶真正的需求，同時需要完整瞭解現狀（這個以後有機會我再展開聊）。
在剛剛的例子中，可以試試通過以下簡單的問答來真正明確需求。
- 問：為什麼這些用戶必須要錄入“運輸工具”？
- 答：因為系統需要根據錄入的“運輸工具”進行派單計費，如果他們沒有錄入就會影響工資結算。
- 問：具體是哪些用戶會需要根據運輸工具派單計費呢？
- 答：比如調度司機啊、派單人員啊這些。
- 問：那為什麼你提的需求是有崗位名稱中有“運輸”的人員要求必填呢，兩者有什麼必然聯繫？
- 答：因為現在我給這些人取的崗位名稱都有“運輸”兩個字呀。
- 問：那崗位命名會一直由你來負責嗎，後續如果其他人來處理，他們知道這個規則嗎？
- 答：emmm…也許吧
所以其實用戶的需求是，對於要使用“運輸工具”的用戶進行錄入項目的管控，和崗位關鍵字無關。用戶犯了把最終實現結果作為需求的典型錯誤。
2. 需求價值挖掘
需求價值明確要求需求方在提出需求時明確這個需求為業務帶來的價值，並且最好是可量化的價值。
這個階段需要明確得向業務方問出這個需求的實現能夠幫你解決什麼問題，帶來多大的收益。
要知道，和需求量相比開發資源永遠都是不夠的，總是有成堆的需求等待開發。所以，明確業務價值可以有助於產品經理更好的判斷優先級，完成更好的產品迭代。而需求方自身在思考價值的同時，也可以對該需求進行更加深入和完整的思考，可能會有意想不到的發現哦。
對於比較大的項目需求，甚至需要明確到每個功能點的價值，便於產品經理進行需求的拆分。
02 方案溝通
基於用戶需求，產品經理需要根據需求點評估和經驗通過產品方案設計來達成用戶的需求。在方案確認後正式進入開發前，需要和需求方進行最終的方案確認，通過文檔演示的方式向需求方展示需求的實現方式及效果，以確保可以真正解決業務問題。
這裡需要註意的是，完整的產品方案除了明確功能實現方式（滿足需求）外還應該包括預計交付時間、交付範圍、項目推進進度（灰測計劃）。
1. 功能需求
功能需求即指能夠滿足業務需求的整體方案設計，其中包括了功能點、頁面、交互等用戶可以直觀看到、感受到的內容，也就是我們通常所定義的需求文檔。
這點其實是屬於基本內容，我就不再過多贅述了。
2. 交付時間及範圍
站在用戶的角度來說，他除了關心自己的需求能否得到解決外，他還關心什麼時候可以得到解決，也就是我們提到的交付時間。所以我們在進行方案溝通時，也需要基於實現的難度給業務方一個初步的預估上線時間。
對於實現周期較長的需求，通常需要拆分需求迭代，此時則需要明確每個迭代涉及到的功能點和交付時間。這裡通常需要結合功能點價值、業務痛點以及迭代的完整性來指定。前面兩個點比較好理解，迭代的完整性是指此迭代上線後應該是一個完整的、可以使用的功能，而不是需要等下個迭代上線後才可以一起使用，那麼分期實現就沒有意義了。
產品經理在接收到需求後即使是對於實現難度大而暫時無法實現或優先級不高需要暫時擱置的需求，也應該明確的給予業務方答覆，做到事事有回應、件件有找落，讓需求方可以及時啟動備選方案，避免產品的實現過程成為業務瓶頸。
3. 灰測計劃/運營計劃
在雙方確認好產品方案和上線時間後，產品經理需要確認用戶在項目上線後的灰度計劃/運營計劃。
對於推廣面比較廣的需求，為了避免全面上線帶來的風險，通常會選擇分區域或分用戶群逐步上線，稱之為灰度計劃，簡稱灰測。
灰測計劃往往是由業務方根據需求特性、業務覆蓋面進行定義。並且在產品交付後開始按照灰測計划進行逐步推進，以確保實施的項目能達到預期效果、收穫項目價值。
產品經理也有責任確保需求價值的實現以體現自身價值，所以在這個階段雙方也需要對後期的運營確定一定的方案。
（悄悄的說，如果需求方無法明確運營推廣計劃，那麼對於這個需求，他們可能沒有想象中那麼“急”，我們可能需要重新回頭評估下產品的價值，看是否需要把資源安排給其他更有價值的需求了。說實話，我們有時候還是會碰到需求方在需求階段催著上線，而上線後遲遲不開始使用的情況，確實令人頭疼，所以前期的明確還是很有必要的）
03 人員培訓
產品正式上線前，為了確保後用戶可以正確的使用並且達到使用效果。產品經理通常需要進行上線培訓並提供相關功能的操作說明。
1. 上線培訓
公司中，基於溝通層級劃分的問題，通常需求的提報會是通過各部門內部的收口人向產品經理進行提報，同樣的，需求方案的溝通通常也是會由幾個代表或負責人和產品經理進行確認。因此在上線前還會涉及到對其他系統使用方的整體培訓，主要的內容也會是針對於本次上線的功能點、變更點。
（此處也偷偷說一句，註意培訓過程中要把握培訓節奏，不要讓培訓會變成需求收集會，我相信你們都懂的~~）
2. 操作手冊SOP
上線前，千萬不要以為培訓完了就完事兒了哦。不要忘記還有操作手冊的更新。完整的操作手冊可以幫助新用戶快速掌握系統使用，減少大量無效的溝通詢問時間。
04 產品灰測
在上文方案溝通中我們提到了產品經理和需求方都是有責任在前期明確運營和灰測推進方案以確保需求落地。因此在實際灰測階段，產品經理也需要花一定的經歷跟進灰測進度，以確保實施的項目能達到預期效果、收穫項目價值，並確保灰測過程的異常得到及時處理。
1. 異常跟進、計劃調整
灰測過程一定程度是為了能在全面推廣前處理可能潛在的風險問題，避免問題的擴大化。所以在灰測階段，產品經理需要更多的關註線上的異常問題、及時反饋測試和技術進行異常處理，避免影響正常業務運行。
此外，如果真的不幸發生了比較大的異常，則需要重新評估異常點、提出解決方案、快速迭代上線，並及時和需求方一起調整灰測計劃，確保正常推進上線。
2. 優化點的積累
此外，在這個階段產品經理還需要多傾聽“用戶的聲音”，聽一聽那些“吐槽的聲音”，發現需求中的可優化點，判斷這些迭代時候是需求中的遺漏點、是否會影響業務操作、是否需要加入下一輪迭代。
結合用戶反饋和上線數據進行項目復盤，吸收本次的pros和cons，揚長避短，減少後續迭代中的“坑”。
總結
良好的用戶溝通機制可以幫助產品經理建立和用戶之間穩定的溝通橋梁。
從上面的文章篇幅其實也可以看出，溝通環節中最核心的其實是在於需求溝通和需求挖掘，正確把握用戶痛點瞭解用戶痛點可以說是成功了一半。最初的方向如果錯了，後面的溝通可能要多走很多彎路甚至於直接走錯路而造成開發資源的浪費。
當然，後續的方案溝通、培訓和灰測時的關註等都能幫助產品經理在用戶心中建立更好更專業的形象。
以上就是本篇的全部內容，希望本文可以對你有所幫助。
作者：麋鹿產品，公眾號：麋鹿產品手冊
本文由 @麋鹿產品手冊 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CCO協議。