產品經理工作中，有很多一部分就是溝通了——和運營、設計、開發、老板溝通等。那么在耗費不少時間的溝通中，產品經理能否從中找到一些總結經驗以及汲取產品知識的方法，避免重復溝通但是又沒學到什么東西。本文中，筆者就介紹了相關的方法，希望對你有所幫助。

01 我是誰

我是入行兩年的產品人鐘傾，一直做B端的產品，以后會一直往B端的方向發展。

02 問題

做B端產品兩年下來，從實習生到初級產品經理，我發現很多需求都是通過運營人員反饋得到的，而溝通工作會占據大量的時間，剩余的工作時間也被一些評審會、第三方對接會瓜分。

時間長了我就覺得我只是在重復勞動，自己的產品技能并沒有提升；而且還會出現大量的紕漏，需求沒有整理到位，在評審的時候需求會漏掉；上線的時候沒有通知到相關運營人，導致運營人員在服務不到位；然后下一波需求又來了，完全沒有空隙去深度思考產品。

所以為了改變這個工作狀態，我自己反思了整個工作的流程，發現我們大部分的時間用在溝通需求上，而需求又是聯結用戶和產品的紐帶，所以我可以通過日常的需求溝通來不斷練習產品的相關的技能，那么如何做呢？

03 如何做

1. 解析需求，思考產品

在溝通之前需要做的事情，對需求進行篩選，排除偽需求和bug型需求，篩選出有價值的需求；然后我們通過對產品的理解去解析這些需求，列舉出可能的實現方案以及需求場景，對現有產品進行查漏補缺。

1）我們為什么要這樣做？

• 對產品本身來說：篩選出對產品有價值的需求能更貼近用戶，增加用戶對產品的粘性。
• 對個人來說：加深我們對現有產品的理解知道我這個功能最終是為了滿足什么樣的場景，解決用戶什么樣的問題。

2）具體怎么實踐？

我把需求分為四大類：bug型需求、體驗優化型需求、偽需求、值得深挖的需求，通過對需求的分類能節約我們對需求篩選的時間，提高團隊協作，提升我們的工作效率。

在分類的基礎上，我們要對需求進行簡單的處理。

①Bug型需求

線上出現的問題，偶爾出現的；或者是大面積問題急需解決。

自己先驗證這個需求是否真實存在，通過跟研發協同，每周給出一個小版本來快速迭代這些需求，通過需求的方式來快速解決bug，讓運營人員和用戶能快速感知到自己提出的問題得到完善；

如果沒有這個需求，需要轉交給相關的技術支持人員進行單獨排查，讓他們協助運營人員解決單個用戶的偶然性問題。

②體驗優化型需求

用戶在使用產品時，有些步驟會反復操作會影響到他們的工作效率，希望通過優化組件或者相關功能提示來達到節約操作時間成本。

這樣的需求需要協同UE和UI人員，看看能不能優化操作體驗，根據優化的程度對其進行排期。優化程度比較復雜，需要重新設計組件或者連同整個功能一起優化的，那么需要排進功能性優化的大版本；優化程度比較簡單的，排進bug型需求小版本中盡快優化。

③偽需求

看上去跟值得深挖的需求接近，但是多次提出沒有解決的、技術上無法實現、與用戶行為相違背。偽需求容易耗費我們大量的時間和精力去思考，而且需要花費一些時間給運營人員解釋。

這樣的需求，我們要想清楚，以前為什么沒有這么做，這個需求確實對產品起到非常大的優化作用，但是為什么我們一直沒有實現，這時候就要請教相關技術人員進行咨詢；根據需求設計出來的產品放到場景中是否符合邏輯，如果不符合邏輯說明，這與用戶行為習慣相違背。

④值得深挖的需求

符合產品規劃的，在產品設計中并沒有想到的，對現在產品設計不滿意的。

這樣的需求，需要我們重點關注，在需求列表中也需要標注出來，然后我們對相關的場景和用戶行為進行進一步的研究，與運營人員進行精準溝通，在確認需求后進行歸檔和排期。

2. 精準溝通，深挖場景

在進行溝通時最重要的就是知道用戶想要什么和怎么使用。??

?1）我們能獲得什么？

• 對產品設計來說：明確了需求的價值，完善了產品覆蓋的應用場景，幫助用戶解決問題；
• 對個人來說：增強同理心，通過了解用戶行為，加深對場景的理解，對產品上的創新有更多的幫助；驗證自己的想法，強化對產品的理解。

?2）我將提問形式分為兩類

①直接提問

一般用于運營人員對需求描述缺少我們對需求判斷的信息，比如用戶使用場景或者具體的用戶行為。

我們需要通過提問的方式引導運營人員表達超出用戶的原話，或者通過實際案例來說明這個需求是如何產生的。

②反問法

一般用于運營人員描述了完整的用戶行為或者用戶場景以及功能需要修改的地方，這樣我們通過反問對方你猜想的修改后的用戶場景和需求理解是否正確來驗證。

通過溝通我們能獲取比較詳細的場景信息和用戶行為，明確了需求的價值，然后我們進一步深挖場景。

3）如何進一步深挖場景？

①列舉滿足用戶需求后產生哪些有可能的結果，根據列舉的結果再反過來思考功能是否能滿足用戶達成這些結果。

對于需求的解決方案有很多種，在我們還沒有定下來最終解決方案的時候，我們需要思考的是每種解決方案帶來的后果，以及對前后流程有什么樣的影響，你考慮的越周全，最終定下來的最優解就能越貼近用戶。

②思考產品中有沒有其他類似的應用場景。

在我們平時生活中其實也會遇到很多相似的場景，我們能更好的把自己想成是一個用戶，將自己的遇到的場景帶入產品中，將更多場景綜合到產品中，增強產品的通用性。

③根據用戶操作數據統計，分析跟該需求相關功能的指標。

需求對應的功能會產生大量的數據，數據分析是支持我們為什么要改善的強有力的證明，比如這個功能下一步跳出的數量和繼續點擊的數量進行對比，如果相差很大說明用戶在這邊的操作讓他們放棄了，那么是什么讓他們放棄的，是我們需要繼續思考的問題；?如果相差不大，是不是用戶覺得使用這個功能的效率不是很高，浪費了用戶很多時間，或者是沒有按照常規的操作接著往下走。

通過數據我們能找出用戶行為超出常規邏輯的地方和出現異常的地方，能幫助我們對場景更加深入思考，慢慢完善用戶使用邏輯，讓用戶覺得使用產品時又快又高效。

根據上面三步，我們能從需求中看到更多復雜的使用場景，將這些場景通過功能快速解決用戶工作中遇到的問題，用戶才會覺得這個產品是在幫助他達成目的。

3. 及時歸檔，及時反饋

歸檔也是整理，最簡單的是整理產品需求，最復雜的是整理產品規劃，所花費的時間肯定是成倍增多，但是規劃總是從一點點小需求開始積累，不積跬步無以至千里，不積累需求無以成就好產品。

整理看似簡單，但是也是產品流程中最最重要的也是最容易被忘記的一環。

如果我們沒有整理的習慣，那么隨著產品越做越深入的時候，會缺乏整體思維，很難發現需求與需求之間的關聯，容易偏離產品核心。

當我們整理的技能不斷強化，養成良好的習慣， 我們能發現用戶需求出在哪里，根據收集到需求，加強對現有產品的理解，豐富產品使用場景，為后面產品做出新規劃；同時也方便我們自己了解產品規劃進度，及時跟進未完成的需求。

1）那么我們整理時候需要什么呢？

需求整理需要兩樣關鍵文檔：需求池和需求文檔；

①需求池

歸檔未到研發階段的需求；每天抽出十分鐘進行整理；通過需求池我們統計出，容易出需求的功能模塊，以及用戶的思考方向，能為我們下次產品規劃提供很好的支持；

②需求文檔

管理線上運行產品需求以及正處于開發階段的需求；每周抽出一個下午進行整理；通過需求文檔，我們方便掌握需求進展，以及產品規劃實現程度。

需求整理看似簡單其實是最需要我們自己不斷練習的技能，是幫助我們理清產品邏輯的好工具。有了好工具，也需要我們利用好需求文檔向運營人員及時反饋。因為運營在提出需求之后會需要我們的及時反饋，對于他們來說客戶的提出的需求會有一個時效性，我們給出的反饋越快越精準，那么他們給到客戶的反饋就越快越好，用戶就不容易失去耐心。

?2）那么如何反饋呢？

我把兩種方式結合起來使用：文檔記錄和一對一解釋。

①文檔記錄

把拿到的需求和對應的處理情況通過文檔的形式記錄下來，給到運營人員。方便運營人員有需要的時候及時查看，也能在運營人員急需的時候給出回復。

在自己的需求池中增加“是否反饋”的屬性，幫助自己完善這個步驟。越到后面你會發現很多運營人員愿意相信你，找你解決問題；在以后的工作配合會越來越默契。

②一對一解釋

遇到偽需求的時候，我們需要將完整解釋跟運營人員說明白，讓他理解，給他提供較為合理的說辭，照顧用戶聽到時候的感受。

反饋無論在什么時候都是容易被忽略的，特別是忙起來的時候，給出反饋不僅能提升自己工作效率和團隊協作，也是對自我整理一種監察機制。

04 總結

我通過對日常需求溝通總結出的一些經驗，當然其中還有更多值得深入探討的空間，希望通過我的總結能幫助大家更好的總結自己的日常工作。

盡管被溝通工作占據了大部分的工作時間，但是通過思考、溝通和整理，產品技能不斷提升，通過量變達到質變，那無論多么枯燥重復的工作你都能從里面汲取到跟產品有關的知識。

也希望大家能與我分享更多的經驗。

本文由 @鐘傾 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

上一篇： 為什么說策略產品經理是產品界的明珠？策略產

下一篇：沒有了