編輯導語：溝通有利于消除彼此之間的誤會，確立互信的人際關系。在實際工作中，一個人的溝通協調能力是很重要的，善于溝通往往會使人很快在工作中打開局面，更能讓工作效率大幅提高。溝通是雙向的，一方面你要獲取對方的真實信息，另外你也必須向對方傳達你的真實信息。作為PM，你真的會溝通嗎？

用戶調研、需求拆解、邏輯思維、數據分析、交互設計……所有市面上常見的PM核心能力中，最少被提及的就是溝通能力。

可事實上，溝通能力是PM最核心的基礎能力。

有這樣一句話形容PM的崗位性質——“沒有管理權力的管理崗位”，我們從來都不是真正的“經理”，只是產品的“代言人”。

所以具備良好的溝通能力，才能保證PM順利開展產品工作。如果邏輯能力決定了一個PM的能力上限，那么溝通能力就決定了一個PM的能力下限。

1. 什么是溝通

人是社群動物，溝通占據了我們每天的絕大部分時間，工作會議是溝通、日常閑聊是溝通、發朋友圈也是溝通。我們無時無刻不在主動發起溝通，也同時在接受多方發起給我們的被動溝通。

1.1 溝通的本質

其實溝通的本質很好概括：有目的性地信息傳遞，無論是一對一，還是一對多地溝通，我們都在傳達特定的信息，以直接或間接地達到自己的某種目的。

大家可能很好理解工作中的溝通，因為我們總在不斷和他人協作，以達到自己的工作目標。但是對于生活類的溝通，比如朋友間的閑聊，或則發個朋友圈真的算溝通嗎？我真是為了某種目的在溝通嗎？

發朋友圈有目的嗎？

答案：是的。無論是朋友間的閑聊，還是一條朋友圈，我們都在經營自己的“人設”，隨口的一句話也是我們的價值觀輸出。我們渴望朋友的認可和“點贊”，期望對方能夠認同自己的觀念和行為。

沒有人向周圍傳遞信息是渴望被否定的，除非我們的本意就是被否定，然而這本身就是目的了。

1.2 溝通的基本要素

溝通的內容和方式千羅萬象，但是有效的溝通都必然包括4個基本要素：

1. （溝通）發起者：每次溝通都會有一個主動發起方；
2. （溝通）接收者：溝通的被動接收方（一個或多個）；
3. 信息：包含發起者產生的原始信息和通過信息媒介加工后傳遞給接收者的加工信息；
4. 目的/意愿：所有的溝通都由發起者的目的驅動，而發起者的目的需要轉化為接收者的行動意愿來實現。

這4個基本要素的相互轉化又會涉及到5個基本轉化流程：

1. 發起溝通：溝通發起者產生原始信息；
2. 傳遞信息：原始信息經過媒介轉化為溝通接收者可以獲得的加工信息；
3. 接受溝通：溝通接收者成功接收加工后的信息；
4. 采取行動：溝通接收者根據接收到的加工信息采取一定行動；
5. 獲得反饋：溝通發起者觀測接收者的行為，判斷目的是否達成以決定否繼續溝通。

溝通的信息流

舉個例子：我給同事A發郵件通知明天下午4點開會，那么：

• 發起者——我自己；
• 接收者——同事A；
• 原始（加工）信息——明天下午4點開會；
• 目的（意愿）——同事A明天下午4點按時出席會議。

1.3 溝通的常見問題

評價溝通是否有效的標準非常簡單：發起者的目的是否達成。那么常見的無效溝通都有哪幾類呢？

1.3.1 無效的信息發起（目的–>>原始信息）

溝通的第一步是發起者將自己的“目的”轉換為“原始信息”。

完整且清晰地表達信息是溝通的基石，如果發起者本身都無法準確的將自己的目的轉化成清晰的語言結構，那么這次溝通大概率是無效的。

1.3.2 無效的信息傳遞（原始信息–>>加工信息）

信息失真是一種相對常見的溝通問題，發起者構建的原始信息與接收者收到的加工信息經過傳遞媒介處理后往往存在一定偏差。疫情期間大火的Zoom就是一種適合多對多的高效溝通媒介。

無效的信息傳遞主要發生在兩個方面：

1. 時效性；比如天氣信息，我告訴小明昨天下雨了，是無法幫助小明決策現在出門是否要帶傘的。
2. 準確性；比如跨語言溝通，我對不懂中文的Michael說一段古詩，無論他用什么翻譯軟件都很難理解。

1.3.3 無效的信息內容（加工信息–>>行動意愿）

當接收者準確及時地收到信息時并不意味著發起者的目就達成了，接收者是否能產生相應的行動意愿依賴于信息本身對接收者是否有價值。

無效的信息內容意味著信息發起者完全沒有考慮過接收者的感受，強行把自己的目的附加給接收者，所以這種信息傳遞方式注定是低效的。后面在展開PM的日常工作時會詳細介紹這點。

2. 如何高效溝通

作為PM，我們需要跟項目組的多個角色打交道，同時以項目負責人的角色去推進整個產品的演進和迭代。正是我們工作內容的特殊性，也要求PM學會高效且有目的性地溝通。

下面我們根據不同的溝通角色，介紹下常見的溝通技巧和方式。

2.1 Leader

對大多數人來說，上下級溝通是一件比較難的事情。因為我們總是給不同的職位疊加了太多不必要的刻板印象。超越崗位本身的職能去考量一個人，本身就是一件事情很不合理的事情。

產品的上下級溝通更多是需求拆解的承接，大多數情況下PM是作為信息的接收者。這時溝通的重點在信息流轉的末段——我們有沒有將接收到的信息轉化成Leader預期的行為。

與PM Lead溝通的信息流

這里我推薦大家采用“復述”的方式建立一套反饋機制，把自己對任務的理解和計劃，用語言傳達給Leader。

這樣反復不斷的溝通和修正，能讓發起者和接收者始終確認雙方有沒有達成一致的行為預期。而且這樣的“復述”應該始終貫穿在版本周期中，不斷將與預期不一致的行為和結果反饋給Leader，并及時確認后期的調整策略。

很多新人PM總是不敢提出自己對原始任務的疑問，只知道埋頭把Leader布置的任務做完。

其實這樣并不叫高效工作，PM的高效從來都不是通過工作量來評定的，“做對的事情”比“把事情做好”要更重要。所以這里的溝通更強調反饋，強調不斷修正內部團隊的預期。

2.2 開發

與開發溝通是PM的硬技能，我們的PRD就是產品和技術溝通的范本，如果開發都看不懂你的PRD，那么大概率這個需求會實現地有偏差。

在和這個典型角色的溝通中，PM往往是作為發起者將自己的需求傳遞出去，所以這個時候的重點在需求溝通的中后段，PM需要確認開發同學收到了正確的信息，并轉化為自己預期的行為。

與開發溝通的信息流

下面我們將和開發的溝通拆解到具體的業務場景中來分析：

2.2.1 版本開發

高效溝通是敏捷開發的必要條件，PM必須不斷提高自己的信息質量，減少信息傳遞的失真，確保開發同學充分理解需求并以合理的時間實現出來。

2.2.1.1 需求評審

需求評審的前提是一份完備的PRD，那么什么是好的PRD？這個問題就和PM是否需要懂技術一樣，在各個論壇上反復被提及。

然而答案永遠都是”no silver bullet”. 每個公司，甚至每個項目組都有自己的工作模式和方法，很難給一套完全標準和規范的PRD模板給所有PM。

但是我們可以按照溝通的信息流拆解出PRD的關鍵要素，這樣可以清晰地定義出高效的溝通（PRD）應該是什么樣子的。

舉個例子，我們想開發一個注冊的功能：

• 發起者——PM；
• 接收者——一線開發；
• 原始信息——用戶注冊功能需求說明（PRD）；
• 媒介——電子文檔和企業內部溝通工具；
• 加工信息——用戶庫表設計說明，用戶庫表更新接口說明，等等（開發文檔）；
• 目的——提供用戶注冊功能，擴大用戶量；
• 意愿——實現開發文檔的功能細節。

整個溝通的信息流中，最容易出現偏差的就是原始信息到接受信息的轉換過程。

我們的PRD寫得再長，再詳細，對一線的開發同學而言都要落到具體的開發文檔。所以高效的PRD必然站在開發同學的角度去描述需求。特別是涉及到功能的極端情況和運轉邏輯時，一定要盡量用開發可以理解的語言來表述。

還是用注冊的例子，比如我們想表達注冊時需要校驗郵箱的有效性。初級PM的描述可能就是“注冊時需要校驗郵箱有效性，有效則……無效則……”。

這里的邏輯本身沒有什么問題，但是這里有兩個很明顯的細節問題：

1. 什么時候校驗？
2. 什么是有效？

我知道很多PM都覺得，“這都很基礎啊，光標移出輸入框校驗不是很通用的交互邏輯嗎？郵箱的有效性應該是業內的基礎常識了，我為什么還要浪費時間去說明具體的校驗規則呢？”

可是當我們站在開發的角度，就會發現自己的理解變得完全不一樣了：

1. 所有的行為都有觸發條件：“注冊時校驗”——那我應該只用在點擊注冊按鈕的時候校驗了。不是每個開發都有UE經驗，PM想當然的交互邏輯一般都實現得有偏差。
2. 所有的判斷都有一套運轉規則：“郵箱有效性”——那我是需要調第三方郵件服務確認郵箱真實存在，還是只用判斷郵箱格式（@和.）?

回過頭來看，這次的溝通是不是很低效呢？

有預期不一致功能細節，還有需要二次確認的實現方式。當然，辯證地看這個例子，我們的PRD是不是需要面面俱到，事無巨細都提到呢？當然不是。

就像前面提的，每個公司，每個團隊都是不一樣的，我們的重點是站在開發的角度看待需求。

如果是合作多年的團隊，特別是核心組員沒有變化過的團隊，或則項目組內部對交互組件和常見的功能邏輯已經有了規范的情況下，都是沒必要長篇累牘地描述的。

記住了PRD的重點始終是高效溝通，而不是刻意雕琢細節。

2.2.1.2 需求開發

理想狀態下，在需求開發的過程中，PM是不應該頻繁地和開發同學溝通的。因為信息傳遞的工作已經在前一個步驟完成，這個階段PM只需在提測時確認自己的需求是否被完全實現。

然而理想情況畢竟是少數，比如參與需求評審的技術一般不直接參與需求開發，所以PM在這個階段也會遇到給不同的接受者反復溝通的情況。

當然我們的溝通目的仍然沒有任何變化，但是溝通的形式值得我們注意。因為和一線開發同學溝通時，往往不像需求評審那么正式。

所以我們要做到：所有的重點溝通都可追溯，這個時候就要求我們選擇一個可靠的溝通媒介?？陬^交流的確更為方便，但是每次溝通結束后，通過即時聊天工具或則郵件通知對方二次確認是一個更好的選擇。

2.2.1.3 緊急需求

沒有人會喜歡緊急需求，大家都更愿意做有準備的事情。

但是商業環境往往不允許我們的產品完全按照計劃迭代，所以PM一定要擁抱變化。對于緊急情況得有自己的溝通套路，而不是單純的傳達命令。記住，所有的溝通都是有目的的，而不是單純的傳達信息。

“這個需求是老板要做的”、“這個功能是大客戶加急要的”、“臨時加個班，明天上線這個新功能”……

沒有人會喜歡這樣的溝通方式，這種情況下開發的行動意愿只來源于工作職能的強制要求，接收者并沒有真正地產生主觀行動意愿。這樣的溝通一定是不順暢，而且低效的，也難怪大家都會討厭緊急需求了。

這個時候PM需要運用自己的同理心，擴展傳遞信息的維度，不要因為時間緊急就只說功能。產品的愿景和價值對開發也是一種激勵，而且可以更好的確保開發同學理解需求，轉換為更為妥善的行動。

當然如果連你自己也不清楚這個緊急需求的目的，那么所有后續的溝通中你都無法保證真實的目的是否達成，因為你只是溝通信息流中的媒介，不是發起者。

2.2.2 日常問題

2.2.2.1 線上Bug

產品自身是無法解決bug的，所以及時和開發溝通，輔助開發解決bug才是我們的重點。這種特殊場景下，我們需要格外注意信息傳遞的質量。

2.2.2.1.1 提高信息本身的質量：PM需要準確地描述如何復現bug，以及bug的影響范圍和優先級。

很多PM會忽視bug的影響范圍，但這個條件往往決定了我們如何判定bug的優先級。而且如果產品能給出準確的影響范圍而不是簡單的“highest”描述，也更能讓開發同學意識到自己面臨的是什么樣的服務壓力，時間的緊迫感會更強烈。

注意并不是所有的bug都是最高優先級，有些bug影響范圍非常有限，而且需要占用極大的開發資源來修復，這個時候PM需要站在更高的角度看待這個問題，在溝通前有取舍的做前置判斷。

2.2.2.1.2 選擇合適的傳遞媒介：不要留言、不要留言、不要留言。

對于已經判定為高優先級的bug，一定要確保接收者及時地收到信息。能夠當面溝通，就不要用即時聊天工具。同樣的信息用不同的媒介傳達，接收者的感知是完全不一樣。

無法當面溝通，一定要打電話（包括語音電話）。有些新人PM會因為非工作時間或則職位上的差異，不敢直接聯系對應的開發同學。這樣一定是大錯特錯的，不要把事情的重要性交給其他人去決定，還是那句話：溝通是有目的的，不是單純的傳遞信息，溝通就結束了。

2.2.2.2 技術咨詢

技術咨詢是PM日常工作中的常規內容：提前論證設計方案的可行性；新的技術（比如AI）趨勢對產品功能的影響；合作產品接口文檔的具體實現功能，等等……既然是咨詢技術問題，那么就一定要求PM學會用技術語言溝通。

這些場景也同時在回答業內的一個經典問題——產品經理需要懂技術嗎？答案——需要。

如果PM完全不懂技術，PM發起的原始信息和開發理解的接收信息就有著巨大的鴻溝，這樣的溝通必然低效。因為這意味著開發需要理解PM的業務知識來將信息轉化為行為。所以只有PM懂技術，才能讓雙方盡可能地站在同一個維度溝通問題。

產品的工作就是不停地和技術打交道，和技術的溝通難度也是最大的。所以一定要學會如何和技術溝通，做真正的溝通發起者，而不只是信息的傳遞媒介。

2.3 銷售

一般B端產品的PM會頻繁和銷售溝通，特別是大型B端產品，有時銷售代表也會參與Roadmap的討論和制定?？紤]到PM往往是作為接收者介入到和銷售的溝通流程中，所以PM必須把握住銷售的真正目的，才能制定出合理的Roadmap。

與銷售溝通的信息流

銷售主動發起的溝通都是圍繞產品功能展開：

1. 我們有沒有這個功能；
2. 我們什么時候有這個功能；
3. 我們能不能盡快開發這個功能？

1）和2）適用于銷售售賣產品給中小型客戶；這類溝通的目的十分明確，本身并不存在太多的技巧性可言。但是如果這類溝通頻繁地發生在PM的日常工作中，則說明整個項目的信息流轉機制是有問題的。

這里不再延展討論如何去提升企業內部的信息流轉效率，但是就這類溝通而言，PM應該嘗試建立自動化的反饋機制，在銷售發起溝通之前就更快速的響應銷售的目的。

比如建立內部的knowledge base，加強對銷售人員的培訓，以及產品roadmap的及時同步等。

3）適用于銷售售賣產品給大型客戶；大部分PM都比較抗拒這類溝通，因為銷售的目的是改變PM的原有計劃，PM容易站在產品的長期愿景出發，本能地排斥這類需求。

但是產品在不同的生命周期，有著不同的商業目標，PM也更應該綜合商業價值去考量銷售提出功能的價值。

實際的溝通中，銷售往往喜歡比較強勢地發起溝通，PM接收到的信息往往是非A即B的選擇，所以這時PM得主動要求提升信息的質量，無論是信息本身的廣度還是深度，都會更有利于PM作出對應的決策。

如果PM評估需求有價值，決定調整既定的Roadmap，除了積極地回復銷售結論，最好能嘗試縮短信息的傳遞路徑，直接向客戶確認可交付的產品和預期時間，避免信息傳遞失真帶來的無價值損耗。

如果PM評估需求價值不高，決定不做任何調整，一定要站在銷售的角度去反饋結論。

比如我們認為當前產品的重點是中小型客戶，目前產品的服務能力還不足以支撐大客；那么除了解釋當前產品的不足以外，還要解釋我們集中資源服務中小型客戶能方便銷售在該目標群體地售賣。

和銷售溝通一定要敢于說“NO”，要明確整個公司的大方向是一致的，從長遠來看PM也是在幫銷售提升獲得更多傭金的機會。

2.4 客服（CSM）

這個角色的職能是對已經使用產品的用戶進行支持和協助。C端產品一般叫客服，B端產品大多已經將這個角色定義為客戶成功經理（CSM）。下面我們都用客服代指這個角色。

與客服溝通和銷售有一定的相似性，因為他們都在代表真實的客戶向我們反饋意見（大多是功能建議）。

區別在于客服的反饋往往沒有那么激烈，除非產品初始的售賣對象不對，否則和客服溝通都不太會發生逼著PM改Roadmap的場景。

另外對于B端產品而言，PM也會需要經常成為溝通發起者，定期對CSM團隊培訓功能，以及分享最佳實踐方案（Best Practice）。

所以真實的溝通場景中，PM有時會是發起者，有時會是接收者。

與客服溝通的信息流

2.4.1 接收溝通

這個場景下的重點是選擇合適的媒介和挖掘溝通的真實目的。

優秀的客服可以當做半個產品經理，他們能理解和推測客戶提出疑問的動機，能夠有效的Push PM重新審視自己的Roadmap是否合理。

然而實際情況下，大部分客服只把自己定位為一個傳聲筒的角色。所以即使PM只是溝通的接收者，也要嘗試去提升整體的溝通效率，真實地解決客戶的問題。

2.4.1.1 選擇合適的媒介

大部分客戶問題都會被客服攔截，所以更要確保需要流轉給PM的單，及時高效地傳遞給了我們。

除了企業內部的轉單工作流程，也必須建立起工單升級的機制，確?？头卸喾N渠道觸達PM，至少在客服和PM間建立一種即時通訊方式。

2.4.1.2 挖掘溝通的真實目的

客戶都很難表達清楚自己的需求，更不要說經過客服處理過的信息了。網上已經有很多討論如何挖掘客戶真實需求的文章了，這里也不再贅述。

大家只需要注意，一定要讓客服提供上下文，需要拿到客戶真實的反饋原文或錄音，避免信息失真是挖掘真實目的的基礎。

2.4.2 發起溝通

PM主動發起的溝通都是關于產品功能的培訓或則運營策略的調整，需要注意的是這類溝通一般是1對多的形式。所以存檔我們的培訓視頻和文檔，是保證PM持續觸達客服同學的最佳媒介。

另外，需要明確我們的溝通目的并不是單純為了培訓客服團隊，真實的目的應該是提升客戶服務質量，培訓客服只是我們達到這個目的一種方式，我們也可以建立線上自助教程，引導客戶自己去學習和答疑。

所以這類溝通一定要有反饋，PM需要去監控甚至考核每次培訓后的效果，用目的去考量每次溝通（培訓）是否有效，而不是將發起溝通這件事本身作為目的。

3. 結語

我們每天都會通過很多形式溝通，卻往往忽視了溝通的重點————目的。

作為溝通發起者我們要達成目的，作為溝通接收者我們要理解對方的目的。PM也不用過分追求溝通的技巧，我們的工作核心始終在于思辨，想清楚溝通的目的和溝通接受者的角色，自然能以無招勝有招。

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

題圖來自 Pexels，基于 CC0 協議