產品經理每天都要花很多的精力在溝通上， 那麼是否有一套行之有效的方法論， 來提高溝通效率降、低溝通成本呢？我總結的產品經理溝通法則就是：取勢、明道、優術。
取勢所謂勢， 就是大方向。 逆勢而為， 不進則退；順勢而為， 扶搖直上。
作為產品經理， 在溝通中能取的勢就是天時地利人和。 正所謂：天時不如地利， 地利不如人和。 其中， 人和是最關鍵， 但是這裡的人和不是大家開開心心一團和氣，
那麼， 如何確立共同目標， 統一戰線呢？明確願景， 大局為重， 合縱連橫， 成就大我。
首先， 我們應該站在較高的角度綜合考慮問題， 也就是我們常說的戰略層。 保證我們做出的所有決策都是基於公司願景的、符合公司戰略利益的， 而不是出於部門KPI或是個人利益考慮（所以產品經理絕對不能甩鍋啊）。 大局觀是會影響他人的， 自己從大局考慮， 影響其他部門同事也從大局觀出發， 當所有人都認同一個目標， 那麼就是仁者無敵， 就不會出現所謂的撕逼情況了。
雖然， 產品經理是使用者的第一負責人，
所以產品經理是一個縱橫家， 遊走在各個部門之間， 為了公司目標， 編織一張意義之網， 網羅各方力量， 順目標而為。
明道道， 是一種規律， 萬事萬物都有其規則， 溝通也有相應的規律。
溝通之道—-個人魅力條理性是個人魅力非常重要的體現。 產品經理在溝通時應該遵守金字塔原理， 在口頭溝通時， 結論先行， 然後闡述理由。
知識的廣度也是一個非常重要的個人魅力體現。 溝通的過程一定要始終保持雙方在一個頻道上， 否則就是雞同鴨講， 無效溝通甚至產生歧義。 但是， 產品經理需要溝通的物件很多， 如何才能在溝通時跟任何一方都能保持同一頻道呢？那就需要豐富的知識儲備和認知寬度， 產品經理需要懂技術、懂運營、懂測試， 這樣才能跟各方愉快的溝通（也能防止被坑哦）。 所以， 產品經理要把自己打造成一個T型人才—-既有專業的深度，
專業性也能為個人魅力加分不少。 產品經理在規劃功能和設計流程時， 應該始終體現自己的專業性， 因為只有展現出專業， 才能贏得別人的信任。 每個人都願意跟著專業的“老司機”走， 而不是被新手帶溝裡。
所以， 當有人質疑你：為什麼toast的時間是1.5s時， 你因該說人類視覺暫留達到最大值的最短時間是1.5s， 大於這個時間， 提示過重造成干擾， 小於這個時間， 達不到提示效果；當有人質疑你為什麼設置5個項而不是其它數字時， 你應該用人類短時記憶的有效專案數為7±2來解釋；當有人質疑你為什麼要激勵用戶時， 你應該從斯金納操作條件反射談起；當有人質疑你設計的用戶獎勵過少時， 你應該從“德西效應”出發跟他聊一聊····
溝通之道—懂人性使用者是人，所以產品經理要懂人性；溝通物件也是人，所以懂人性才能更好地溝通。
人有互惠性。溝通是一門妥協的藝術，我們在說服別人按照我們的意願行事的時候，也要給予一定的付出或妥協。比如我們在提需求的時候，就可以把核心的需求摻雜在非核心需求中，必要時犧牲掉非核心需求（或降低優先順序下個版本再實現），做出讓步，進而保全核心需求。
人有利己性。雖然在取勢中談到團隊目標一致性，但是不可避免的每個人都有利己的私心，其它部門的人也要維護自己的利益、部門的利益。所以，當產品取得成績的時候，應該將相關人員都帶上。當提需求的時候，如果不是緊急需求，也需要考慮一下其它部門的時間安排，儘量不在別人忙著趕進度的時候，提額外的需求。
人有情感性。雖然身在職場，應該公事公辦，但是人的情感性就決定了，人不可能不帶個人感情進入工作。有時候在會上，爭面紅耳赤都解決不了的事情，會後一句哥們（姐們），請他喝杯咖啡，就愉快的達成了共識。所以產品經理要想溝通順利，平時也要攢人品，偶爾請個下午茶，陪哥們抽個煙聊聊人生，組織一下聚餐···畢竟沒有什麼是一頓飯決絕不了的事情，如果有，那就兩頓~
優術人生就是一場修行，術，就是一個個的技能點。與不同的角色溝通，我們就需要使用不同的具體技能。
與Boss溝通老闆說的總是對的，老闆說的總是對的，老闆說的總是對的。重要的事情說3遍，這倒不是溜鬚拍馬，而是基於以下邏輯：
老闆也是人，他有自己的想法，有自己存在感的需求，也有自己的KPI要背，也要跟投資人交代。他做的一些決定，有我們作為產品經理看不到的一些需求方，有他的不得已。老闆站的角度更高，掌握的資訊和資源更多，很多我們覺得不對的，或者不可能完成的事情，對他來說卻不一定。很多時候我們覺得錯了的決定，很可能他看到了更大的問題，只是兩害相權取其輕。又或者，他眼光長遠，在當前看來是錯誤的方案，放在長遠來看，是有利於長期發展的。與老闆溝通時，我們更多的是提出一個或多個可行方案，然後分別闡述優劣，並盡可能地爭取使我們覺得更優的方案被採納。但是，決定權在老闆那裡，經過一番努力，如果最終採納的不是我們的方案，也要遵照執行，畢竟這關係到團隊的效率。哪怕最後錯了再改，也比過程一直爭論不休，專案無法推進來的好，更何況，對錯尚未可知呢？與UI設計師溝通UI設計師像是一群遊俠散仙，他們對美有執著的追求，和個性的表達。他們偏重於感性和直覺，所以在溝通的時候，我們不能用邏輯和強權去壓制。而且，UI介面的美醜是任何人都可以評論上兩句的，這個說好看，那個卻說不好看，他們也很無奈。
所以我們在跟UI同學溝通設計稿時，一定要給出核心的設計目標和理念，明確大的設計方向，切記使用“我覺得···”。審美是因人而異的，但是設計的規則和目標是統一的。我們只要抓住核心目標，剩下的就交給設計師了，讓他們專業的人做專業的事，給予足夠的發揮空間。
與RD溝通程式猿這樣的形象已經非常深入人心了。與他們溝通的方式與UI恰恰相反，與開發溝通一定要用邏輯規則，用絲絲入扣的推理和論證征服他們。切記不能挑戰他們在技術領域的自尊心，比如說：這個功能很簡單，沒什麼做不了的，我們以前···很容易就搞定了。到時候懟你一句：you can you up，no can no bibi！那就沒的聊了。
所以，當產品經理面對開發甩過來的一句“這個功能做不了”時，我們應該像分析用戶需求那樣，挖掘深層的含義，有針對性的去溝通：
時間來不及。絕大部分是這個情況，這就需要產品合理的排期，預留15%~20%的時間餘量，以應付這一類的問題。如果時間已經來不及了，那就需要另做權衡：是把功能放到下個版本實現，還是砍掉一些這個版本的低優先順序功能讓出時間，又或者發揮一下個人魅力，陪開發加加班搞定。開發覺得這個功能做了意義不大。這也是很常見的問題，開發本身對你的設計不認可，但是又覺得談用戶體驗、談場景撕不過你，所以只能用這個方法搪塞了。這個時候就只能以理服人，再次用邏輯、規則、論證的方式說服他們並達成一致。當然，一些有產品思維的開發也會提出他的方案，這時也不妨一起討論一下，說不定他的方案確實更好呢？真的是技術上實現不了。這種情況也有，但是少見，真要是遇到了，也只能要麼多給點時間，下個版本好好研究一下再上；要麼，妥協一下，用其它略差一點的方案曲線救國，再圖優化。（怎麼辦呢，難道還真找個程式猿祭天啊？）與運營溝通運營是產品需求的主要來源之一。運營是一群腦洞大，強跳躍性思維，撕逼能力也比較厲害的物種。他們一般會提很多需求，需求之間有時候沒有關聯，甚至是矛盾的。提出的需求每次都是緊急，巴不得希望你今天下班前就上線。但是換位思考一下，他們是整個公司背負KPI壓力最大的部門，提一些緊急需求；提一些隻對眼下資料有提升，但是對長期利益無益的功能也是情有可原的。
與運營溝通最核心的一點就是用資料說話。所以產品設計中做好資料埋點，平時做好產品資料分析，必要時把資料拿出來佐證，達到溝通目的。當運營提出新的需求以配合活動時，我們應該讓運營拿出活動方案，一來可以排除掉很多拍腦袋需求，二來可以根據活動的力度，範圍，時間長短等要素來靈活應對。如果是活動力度較小的短期活動，可以用一些協力廠商活動平臺提供的功能，如H5形式的抽獎，大轉盤，有獎小遊戲等；如果是投入較大，時間跨度也較長的活動，可以先開發簡化版小範圍試驗，收集資料，根據資料表現來決定下個版本此功能的走向。
經過上面的分析，你會發現，溝通不是“對話”這麼一個點，溝通是一個面，是一個系統。所以，想解決溝通問題，就要系統化的去著手。取勢、明道、優術，就是我的溝通方法論。
溝通是一個包治百病的庸醫，任何事情都可以通過溝通解決，但是卻需要大量的時間。在這個高度分工的時代，溝通正變的越來越重要，我們能做的，就是不斷提高溝通效率，降低溝通成本。
本文由 @胡小Q 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自，基於CC0協議
溝通之道—懂人性使用者是人，所以產品經理要懂人性；溝通物件也是人，所以懂人性才能更好地溝通。
人有互惠性。溝通是一門妥協的藝術，我們在說服別人按照我們的意願行事的時候，也要給予一定的付出或妥協。比如我們在提需求的時候，就可以把核心的需求摻雜在非核心需求中，必要時犧牲掉非核心需求（或降低優先順序下個版本再實現），做出讓步，進而保全核心需求。
人有利己性。雖然在取勢中談到團隊目標一致性，但是不可避免的每個人都有利己的私心，其它部門的人也要維護自己的利益、部門的利益。所以，當產品取得成績的時候，應該將相關人員都帶上。當提需求的時候，如果不是緊急需求，也需要考慮一下其它部門的時間安排，儘量不在別人忙著趕進度的時候，提額外的需求。
人有情感性。雖然身在職場，應該公事公辦，但是人的情感性就決定了，人不可能不帶個人感情進入工作。有時候在會上，爭面紅耳赤都解決不了的事情，會後一句哥們（姐們），請他喝杯咖啡，就愉快的達成了共識。所以產品經理要想溝通順利，平時也要攢人品，偶爾請個下午茶，陪哥們抽個煙聊聊人生，組織一下聚餐···畢竟沒有什麼是一頓飯決絕不了的事情，如果有，那就兩頓~
優術人生就是一場修行，術，就是一個個的技能點。與不同的角色溝通，我們就需要使用不同的具體技能。
與Boss溝通老闆說的總是對的，老闆說的總是對的，老闆說的總是對的。重要的事情說3遍，這倒不是溜鬚拍馬，而是基於以下邏輯：
老闆也是人，他有自己的想法，有自己存在感的需求，也有自己的KPI要背，也要跟投資人交代。他做的一些決定，有我們作為產品經理看不到的一些需求方，有他的不得已。老闆站的角度更高，掌握的資訊和資源更多，很多我們覺得不對的，或者不可能完成的事情，對他來說卻不一定。很多時候我們覺得錯了的決定，很可能他看到了更大的問題，只是兩害相權取其輕。又或者，他眼光長遠，在當前看來是錯誤的方案，放在長遠來看，是有利於長期發展的。與老闆溝通時，我們更多的是提出一個或多個可行方案，然後分別闡述優劣，並盡可能地爭取使我們覺得更優的方案被採納。但是，決定權在老闆那裡，經過一番努力，如果最終採納的不是我們的方案，也要遵照執行，畢竟這關係到團隊的效率。哪怕最後錯了再改，也比過程一直爭論不休，專案無法推進來的好，更何況，對錯尚未可知呢？與UI設計師溝通UI設計師像是一群遊俠散仙，他們對美有執著的追求，和個性的表達。他們偏重於感性和直覺，所以在溝通的時候，我們不能用邏輯和強權去壓制。而且，UI介面的美醜是任何人都可以評論上兩句的，這個說好看，那個卻說不好看，他們也很無奈。
所以我們在跟UI同學溝通設計稿時，一定要給出核心的設計目標和理念，明確大的設計方向，切記使用“我覺得···”。審美是因人而異的，但是設計的規則和目標是統一的。我們只要抓住核心目標，剩下的就交給設計師了，讓他們專業的人做專業的事，給予足夠的發揮空間。
與RD溝通程式猿這樣的形象已經非常深入人心了。與他們溝通的方式與UI恰恰相反，與開發溝通一定要用邏輯規則，用絲絲入扣的推理和論證征服他們。切記不能挑戰他們在技術領域的自尊心，比如說：這個功能很簡單，沒什麼做不了的，我們以前···很容易就搞定了。到時候懟你一句：you can you up，no can no bibi！那就沒的聊了。
所以，當產品經理面對開發甩過來的一句“這個功能做不了”時，我們應該像分析用戶需求那樣，挖掘深層的含義，有針對性的去溝通：
時間來不及。絕大部分是這個情況，這就需要產品合理的排期，預留15%~20%的時間餘量，以應付這一類的問題。如果時間已經來不及了，那就需要另做權衡：是把功能放到下個版本實現，還是砍掉一些這個版本的低優先順序功能讓出時間，又或者發揮一下個人魅力，陪開發加加班搞定。開發覺得這個功能做了意義不大。這也是很常見的問題，開發本身對你的設計不認可，但是又覺得談用戶體驗、談場景撕不過你，所以只能用這個方法搪塞了。這個時候就只能以理服人，再次用邏輯、規則、論證的方式說服他們並達成一致。當然，一些有產品思維的開發也會提出他的方案，這時也不妨一起討論一下，說不定他的方案確實更好呢？真的是技術上實現不了。這種情況也有，但是少見，真要是遇到了，也只能要麼多給點時間，下個版本好好研究一下再上；要麼，妥協一下，用其它略差一點的方案曲線救國，再圖優化。（怎麼辦呢，難道還真找個程式猿祭天啊？）與運營溝通運營是產品需求的主要來源之一。運營是一群腦洞大，強跳躍性思維，撕逼能力也比較厲害的物種。他們一般會提很多需求，需求之間有時候沒有關聯，甚至是矛盾的。提出的需求每次都是緊急，巴不得希望你今天下班前就上線。但是換位思考一下，他們是整個公司背負KPI壓力最大的部門，提一些緊急需求；提一些隻對眼下資料有提升，但是對長期利益無益的功能也是情有可原的。
與運營溝通最核心的一點就是用資料說話。所以產品設計中做好資料埋點，平時做好產品資料分析，必要時把資料拿出來佐證，達到溝通目的。當運營提出新的需求以配合活動時，我們應該讓運營拿出活動方案，一來可以排除掉很多拍腦袋需求，二來可以根據活動的力度，範圍，時間長短等要素來靈活應對。如果是活動力度較小的短期活動，可以用一些協力廠商活動平臺提供的功能，如H5形式的抽獎，大轉盤，有獎小遊戲等；如果是投入較大，時間跨度也較長的活動，可以先開發簡化版小範圍試驗，收集資料，根據資料表現來決定下個版本此功能的走向。
經過上面的分析，你會發現，溝通不是“對話”這麼一個點，溝通是一個面，是一個系統。所以，想解決溝通問題，就要系統化的去著手。取勢、明道、優術，就是我的溝通方法論。
溝通是一個包治百病的庸醫，任何事情都可以通過溝通解決，但是卻需要大量的時間。在這個高度分工的時代，溝通正變的越來越重要，我們能做的，就是不斷提高溝通效率，降低溝通成本。
本文由 @胡小Q 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自，基於CC0協議