起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理：達成共同的目標，才是有效溝通的關鍵
身為產品經理，溝通是一項必備的基礎技能，因為你不僅需要與業務人員、測試人員、運營人員、研發人員、設計師等人溝通，你還不想要與老板或者領導溝通。
本人曾經與一些做產品的朋友同事聊過，偶爾會問到一個問題：
“作為一名產品經理，最關鍵的一項技能，你覺得是什么？”、
大部分人不假思索的都會答到是“溝通”。溝通能力且不說是不是最關鍵，但絕對是成為一名合格產品經理的基礎技能。作為一名產品負責人，頻繁與之溝通的對象如下：
有人說產品經理在團隊中發揮的作用就好比膠水，把人粘在一起，把各項資源粘在一起。那要保證團隊的凝聚力，自然要建立起有效的溝通，但不同的溝通對象，溝通方式自然也不同。
老板/領導
與公司的老板/領導溝通，往往溝通的內容大都是產品戰略層面問題，以及老板對于行業、市場、人性、商機等方方面面的洞察。那老板與我溝通的目標，自然是為了讓我了解他的想法，從而完善一個可執行方案。所以，完成方案即是我與老板的共同目標，與老板的溝通更多是圍繞這個目標展開的。具體如何落地方案，不是本文的重點，在此只介紹一些溝通的關鍵點：
1. 在接受老板的想法時，遇到不靠譜的創意，不要急于否認。先接受這個創意，隨后提出自己的疑惑、顧慮?；ヂ摼W產品的優勢就是快速迭代，反復試錯，一切要等產品上線后看效果，不要妄下定論。
2. 要善于填補老板的思維空缺。公司老板都是比較忙碌的，作為產品負責人要抓住老板想法的關鍵點，隨后更完善、更系統的思考。將老板考慮不到（沒時間考慮的）整理好，并且提煉，能用圖表的盡量用圖表匯報，言簡意賅。一個產品、一個項目、一個功能的完成時間，在老板心里，向來都是以上線的時間為標準的，方案能夠及早的確認通過，這將會為后續設計、研發、測試、上線等贏的更多時間。
3. 要掌控溝通（匯報）的節奏。主動溝通往往要比被動溝通效果要好，在組織會議溝通之前，盡可能與參會其他人員（運營人員、業務人員）私下建立溝通，并將需要確定問題一并梳理，隨后組織會議溝通（匯報），切記，不要讓老板追著自己要進度。
業務人員
隔行如隔山，本人之前一直從事的是互聯網電商、社交行業，隨后進入了現在這家互聯網金融公司。初入公司可謂對業務并不了解，而剛入職我的第一個任務就是要做公司進件系統、風控審核系統、貸后管理系統等。
記得第一次與業務人員開會，對一些專業名詞“T+0”、“三證合一”、“詳版征信”、“簡版征信”、“仲裁”等等完全沒有概念。與業務人員的溝通，我感覺自己像個記者，不停的采訪各個業務人員，了解他們的需求，挖掘他們的痛點。隨著對業務的深入了解以及對功能的不斷完善，與業務人員間的溝通問題越來越多了。
不同業務人員的需求點是有矛盾的，例如：
進件人員（銷售）：盡可能少的提交進件資料，從而讓第一步變得高效。
風控審核人員：盡可能全的讓進件人員收集資料，從而保證審核期間資料完善。
不僅不同業務人員的需求是矛盾的，系統在流程設計上也有矛盾的地方，比如流程設計的嚴謹則必然不夠靈活高效，管理層更希望流程嚴謹，而執行人員則更希望靈活，這樣更貼合實際。以上種種問題，造成了與業務人員溝通極不順暢。隨后，我重新梳理了下各自的目標：
進件人員（銷售）目標：報件方便，快速的得到風控審核結果，拿到銷售提成，完成銷售業績。
風控審核人員目標：審核效率高，避免錯審、漏審引起績效扣分。 系統目標：提升協同工作效率，業務數據積累。
有了共同目標，隨后的溝通中，我更加能夠站在各業務人員的角度去看問題，同時原本溝通的話術也變了，一些產品層面的專業詞匯很少用了，更多的是用他們能聽懂的簡單表達。原本他們不懂也不愿意多問，到現在每次都有好多問題需要同他們解答。
由于業務復雜，我不可能讓每個業務人員都能了解系統每個環節的設計細節，但是可以找到不同業務人員的目標，通過建立共同的目標去解決他們的痛點，從而達到整個設計系統的平衡。
運營人員
與運營人員的溝通，往往是和產品營銷結合的需求溝通。運營大部分的需求無非圍繞于拉新、促活、提升品牌知名度等。運營人員的目標很明確且一致，也有人說產品即運營，所以按理說與運營人員的溝通應該是最沒有障礙可言的，但本人覺得與運營人員溝通是最困難的。
運營人員最頻繁的需求應該是專題活動了，尤其是活動密集期。專題頁的轉化率無疑是運營人員最最核心的目標，但是我發現許多活動策劃人員作出的方案完全沒有一個預期，導致活動結束后查看運營數據，都不太好衡量此次活動是否算的上成功，同時也沒有總結復盤的時間，因為下一個活動方案已經要提交確認了。
同時一些活動策劃人員，過于關注與產品的表現層，頁面上一個按鈕放左邊，還是放右邊，是圓角，還是矩形，對于轉化率的影響真的沒有想象中的那么大（有時爭論不休，還建議要做a/b測試，在時間緊，任務重，熱點稍縱即逝的情況下，研發根本沒有時間完成a/b測試的工作）。
雖然有著共同的目標，但是溝通過程并不令人滿意。我嘗試著進一步去量化運營人員的目標，比如本次活動投放的用戶群是什么？用戶肖像特征是什么？本次活動打動他們的條款有哪些？類似的活動案例有沒有？引流后的轉化大致能達到多少等，將以上這些問題梳理清楚之后，再與其溝通本次活動要達到什么目標時，發現他們已不再過于關注頁面的按鈕，而是更加精雕細琢的去修改文案，精簡活動流程。同時在策劃案中，也增加了好多案例，以及對各個案例優缺點匯總梳理。
研發人員
記得以前看過一片文章，討論的是產品經理到底要不要懂技術。有的人覺得產品經理不要懂技術，這樣不會被技術所限制，可以更好的發揮自己創意；有的人覺得產品經理要懂技術，這樣更有利于和研發人員溝通。
當時看到這個帖子，自己還暗自竊喜，因為之前有多年的研發經驗，與技術人員的溝通向來是沒有太大障礙的。同時也喜歡與技術同事們一起研究一些新的工具，討論一些技術架構、表結構設計等。但是這不代表與研發人員溝通就完全沒有問題。
本人接觸到的研發人員70后、80后、90后都有，研發人員大部分性格都屬于比較謙虛好溝通的。每次有些棘手的問題或無從下手的問題給到研發人員，多數情況下都會得到的回答是“我等下網上搜搜，看能不能解決?！彼援a品經理不管懂不懂技術，只要需求合理，一般研發人員都是會盡力配合的。與研發溝通需求過程當中，一定不要說：“XXXX功能很簡單啊，你看，XXX產品都實現了。”這種話既不會給研發人員增加自信，也不會降低問題在他心中復雜程度，除了引發爭吵，毫無作用。
如果遇到研發人員并不清楚自己能否實現該功能，同時這個功能你又特別希望他能夠幫你嘗試并實現，你會怎么做？記得一次做PC端的一款C/S產品，無意間看到了獵豹瀏覽器的安裝與卸載頁面，我當時就被那個酷炫的交互動效吸引了，正巧也在做我們軟件的安裝、卸載界面改版，就演示給設計師看。然后很快他就設計了一款我們都很滿意的效果圖，給領導看后，領導也十分滿意。之后就給研發人員看，看到效果圖后，他眉頭緊鎖，我就知道完了，不太好實現。隨后我就跟他說，沒關系先嘗試下，真不行就算了，這個當飛機稿重新再設計一個。
由于當時我們研發實力不強，新版上線時間迫在眉睫，我最后放棄了這個方案。過了沒幾天，研發的同事突然告訴我，他實現了！我還很莫名，原來他也喜歡最初的效果圖，也知道大家都更喜歡這個效果，所以他覺得因為自己做不出來，從而完不成目標，不是他的風格，他一定要想辦法實現。
設計、測試
與設計、測試人員的溝通之所以放在一起說，是因為與他們溝通，相對來說較為順暢。設計的工作從來都不是按照原型圖填充顏色那么簡單，也不參是考別人的產品比葫蘆畫瓢。
測試人員亦是如此，不單單是驗證產品的功能、性能，還應當幫助研發人員定位問題，尋找產品漏洞等。與他們的有效溝通更多是幫助他們進步，使他們成為觸類旁通的的“T”字形人才。
本文由 @bin78823 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
受益匪淺啊，尤其是策劃那段，了不起了不起
謝謝
吵架也是溝通的一種方式，不過吵架還是不要形成一種慣用方式，傷身體……自信的人更容易得到別人的信任。
文章從各個崗位溝通思維做了講述，給我很多啟發，從一個理性的視角去看每個崗位的溝通需求，有利于更好完成工作任務。唯一遺憾是設計崗內容并不豐富，希望不要厚此薄彼，也分享下。謝謝
謝謝，由于我的環境跟設計溝通較為暢快，設計崗在我們的團隊中賦能較大，更多時候我更認為她們不是單純的做視覺、交互，而是名產品設計師。
想起之前和朋友的討論，我的想法是：為什么產品一定要會吵架就是有狼性，如果口才足夠好、足夠硬氣，不一定需要吵架就能解決問題。在還沒走到那一步的時候，問題就已經被解決了。一切的目的都是做成，吵架就是過程，無論哪種溝通方式，都是為了尋找和優化成最合理的方案，說服他人是非必要的。如果就是意見不合，那就以結果為證。所以，產品的品質不在于狼性，而在于合理的自信。