產品經理如何與強勢的技術溝通？

12-27

技術比較有資歷，會以技術無法實現等方面的原因拒絕處理產品提出的需求。
你們是否遇到這樣的技術？
產品懂技術的話，是不是會好一些，因為可以和技術說「行話」了，並且產品懂技術就不會被忽悠了。

」技術無法實現"的潛台詞可能是
1. 給的資源不夠，完成不了
2. 你的優先順序低，不想給你做
3. 看你不爽，不想給你做
4. 這功能太傻不應該做。
5. 最後才是真的技術無法實現。

找到真正原因，就有了解決的辦法。

我是從開發轉產品的，坦白講，在說服工程師方面，「懂技術」並不具備很強的說服力。

亞里士多德說過：「我們無法通過智力去影響別人，而情感卻能做到這一點。」

在需要說服工程師的時候，只有邏輯是不夠的。我們還需要一些心理學技巧：

理解對方的深層顧慮
打破確認偏誤
激活人格面具
利用互惠原理

1. 理解對方的深層顧慮

當對方極力反對一個觀點時，原因很可能在於他們有自己的顧慮。當我們沒理解對方的顧慮卻侃侃而談時，反而容易加劇焦慮，更難得到他們的認可。

舉個例子，註冊流程是 App 中關鍵流程之一，通常情況下，大家認為註冊流程步驟越少越好，因為每多一步操作都有可能增加用戶流失的概率。

以健身類應用註冊流程為例，基礎的註冊流程包含以下三個步驟：

如果你希望在註冊流程中增加一些步驟來收集用戶信息，很可能會遭到大家的反對：

部分工程師可能會反對增加註冊步驟的方案。表面上看，是因為他們不理解這樣設計的原因。但你進一步解釋也沒能說服他們，這時就需要想想他們是否還有更深層顧慮。比如，曾經合作的產品經理提出類似方案，卻在上線不久後再次調整。

也就是說，他們並非完全不認可方案本身，而是對「反覆修改」有所顧慮。你可以由此談起，表明確保項目持續向前迭代的重要性。

有效說服的第一步是認真傾聽和思考，分析對方拒絕的深層原因，針對性地打消對方的顧慮。

2. 打破確認偏誤

有時候，即使我們的觀點正確，論據充分，對方也似乎聽不進去。心理學上將這種現象稱為「確認偏誤」，即人們選擇性的聽取和收集有利信息，忽略不利或者與已有觀點矛盾的信息。此時，首先要做的是打破確認偏誤。

比如在上面的例子中，工程師潛意識裡已有觀點可能是：增加註冊流程必然會導致用戶流失。他們可以輕易找到幾款大廠 App 作為佐證，證明精簡流程的重要性。同時，他們可能不願意聽你進一步解釋「收集用戶信息」的好處。

此時工程師可能已經陷入了確認偏誤，他們本能的過濾掉其他信息，選擇性收集證據，來支持自己已有的觀點。在這種情況下，僅強調「收集用戶信息」的意義，並不具備說服力。

那麼，正確的方式是什麼呢？

2.1 認同對方的部分觀點

工程師的顧慮不無道理，你可以積極認同並表達「這的確也是我們顧慮的地方，增加註冊步驟可能降低轉化率，導致用戶流失」，由此達成初步共識，化解對立的局面。這時候，工程師可能會更願意繼續討論。

2.2 引發認知失調

接下來，我們需要引導他們意識到已有觀點的矛盾之處，引發認知失調。

「認知失調」是指當人們對同一個問題具有兩種相矛盾的觀點時，容易產生不適感，是一種本能反應。

你可以引出一些相反的事實或者數據：

比如，「如果不採集必要的信息，我們將難以為新用戶精準的推薦內容，他們更可能在註冊之後流失」。

或者，「產品組之前考察過同類型產品註冊流程的數據情況，結果發現：如果在信息收集環節，問題適宜且具有針對性會讓用戶感覺更受關注，同時優化交互體驗，反而會提高註冊轉化率和留存率。」

當工程師接收到上述與已有認知違背的信息後，容易產生認知失調，感到不適，並希望儘快擺脫。

2.3 緩解認知失調

在認知失調的狀態下，人們迫切希望選擇其中一個觀點。此時是給出方案的最佳時機。

此時告訴工程師：「設計流暢的過渡動畫，消除頁面切換的感覺。這樣既可以避免註冊流程過長導致用戶流失，又可以收集到必要的信息，幫助用戶在註冊後使用我們的產品，提高留存率。」

當工程師認知失調的緊張情緒得以緩解，他們可能更傾向於認同你的觀點。

如果遇到對方陷入確認偏誤的情況，可以嘗試使用上面的技巧。

3. 激活人格面具

我們在不同的情境下承擔不同的社會角色，表現出不同的人格特徵。比如一位高管在面對下屬時會表現出嚴肅的一面，而面對自己的孩子時會表現出寵溺的一面。心理學家榮格將這樣不同的人格表現比喻為「人格面具」。

3.1 我們會下意識的保持「言行一致」

生活中，我們會下意識的保持「言行一致」。

我們希望自己的言行與對外展現的人格面具相一致，給他人好印象。當我們的行為方式與人格面具相契合時，會認為是合理的，反之我們會覺得彆扭。

3.2 激活人格面具

提出請求前，如果能激活對方特定的人格面具，可能更容易獲得對方認同。

在工作中，可能遇到這樣的情況：工程師對於 UI 細節不那麼在意，並認為將細節做到極致需要很大的功夫，投入產出比不高。

如果對他說：「大家都知道你是一個非常在意細節的工程師，每次都花了很多精力來完善細節...」。

當對方「在意細節」的人格面具被激活，為確保人格面具一致，更有可能接受完善 UI 細節的請求。

4. 利用互惠原理

當我們收到恩惠、禮物、或者來自他人的示好，會感到有所虧欠，並認為有義務在將來合適的時機給予回報，這種現象被稱為「互惠原理」。

互惠原理的本質是：當對方產生心理上的虧欠感時，傾向於有所回饋和補償。而這種虧欠感還可能來源於拒絕你的請求。

比如你計劃在下一個迭代中優化 App 的整體視覺風格，可以預見，這個需求的工程量非常大，為了迭代能順利執行，你需要拆分需求到幾個版本中。但與此同時，你又不希望戰線拉的太長，預期是能在下一個迭代替換一級頁面，隨後逐步完成其他頁面替換。

在溝通需求時，你告訴工程師計劃在下個版本優化視覺風格，並且希望一次性完成所有頁面替換。

這一定會令他們震驚，並拒絕道：「工作量太大了，不可能在一個迭代內完成」，你隨即提出「備選方案」 —— 在當前迭代完成一級頁面替換。由於起初的拒絕，他們感到有所虧欠，因此更可能接受你的請求。

也就是說，我們可以先提出一個遠超對方預期的請求，對方拒絕後往往產生一定的虧欠感。此時提出相對合理的請求，更容易獲得同意。

結語

看到這裡，大家心中或許有這樣的疑問：「利用心理學技巧說服別人，是不是不太妥當？」

這個問題我也思考了很久。我的理解是：

除非對方有意願做這件事情，並且認為這件事情是合理的，否則任何技巧也無法說服他們。說服技巧的目的是讓他們願意做雙方都認可的事情；
「讓正確的事情發生」是團隊的共同目標，如果以上技巧能幫助我們推動「正確的事情」就是有正向意義的。

希望對你有所幫助。

摘自我的專欄「開源思維」，原文：用盡洪荒之力，也難說服工程師？你需要掌握這 4 個技巧 - 開源思維 - 知乎專欄

從我的角度講，絕大部分技術人員說實現不了。其實隱含的意思是：
1、當前沒時間；
2、這個東西，尤其是已經迭代開發過幾次的項目或者產品，其框架和技術選型其實已經制約了某功能的實現（不是功能做不了，而是做出來滿足不了產品經理的要求）；
3、該技術人員目前還沒掌握此需求所需的技術積澱。
我也貌似某個大型軟體產品的產品經理。從我的從業經歷來看，確實是有研發經驗和基礎的產品經理，跟我們的技術團隊交流起來是要順暢些。在這樣的條件下，技術團隊一般也會認為你是大半個自己人。而你也會從產品設計和產品實現兩個角度考慮問題。
但是透過現象看本質，其實這裡面是溝通的力度和溝通的態度在其中做了怪。比如我來說，可以從兩方面去考慮問題，這個是較順暢和容易些。而一旦產品設計和產品實現的職責變成2個個體來碰撞的話，我們就開始防範和潛意識的抵制對方。技術嫌產品人員老改來改去，產品人員覺得技術老是拖拖拉拉，而且不按設計幹活。
我的做法是，在做產品設計的時候，我會邀請我們的技術骨幹參與進來。當然前期他們是聆聽，等他們理解我的想法和設計後，我們再來進行探討。最後形成原型提交。然後後續的寫文檔啊，開發啊。這樣一般要順利些。
我在我的團隊里，提倡用下里巴人的語言講高深的行業知識。樹立「越是明白人，越能用白話把事情講清楚。」的思想。
總之，不管雙方懂不懂對方的東西，既然要將各自的信息盡量保真的傳遞出去，那麼溝通一定是第一位的。學點對方的行業知識，只是促進溝通和理解接受而已。

如果大家的目標一致，就基本上沒有什麼誰強勢的問題了

都是PM在YY...
作為強勢的技術來回答一下吧。
說明白WHY，HOW，WHAT就好了。
可惜的是現在很多PM真的是自己都想不明白，說不明白了。

作為開發人員，拒絕產品經理的需求，無外乎以下幾個情況：

真的無法實現。例如要求的功能超出了操作系統/瀏覽器本身的許可權和介面限制。
實現成本太高。例如實現需要對系統進行大的重構、資料庫模型需要大量調整等。
維護成本太高。例如實現需求，會帶來額外冗餘的數據或代碼，給後續維護帶來額外的工作。
不可靠。過於頻繁的拍腦袋提需求，並且需求本身沒有經過詳細設計和思考，會造成開發人員不信任的情況出現。開發人員就會先拒絕掉，讓你繼續對需求做進一步思考，到底有沒有必要做這個需求，這個需求如何去滿足。

建議如下：

學習開發技術，可以不要求技能有多精進，能夠掌握各種最新技術，也可以不要求代碼有多麼優美整潔，架構設計得多麼合理。但是最起碼也要能夠使用現有的框架、組件、資源去完成一個獨立產品的開發。在開發中了解自己平時所負責的產品，是如何通過代碼實現出來的。要拋棄學技術就是為了「說行話」這個想法。要明白一點，你說不說行話，對於開發人員，根本不關心，一點都不重要。最重要的問題是，你要對你提出的需求，要有較為成熟的解決方案。這個解決方案不僅僅包括產品UI，更要考慮到功能、邏輯，甚至是與舊有系統、數據的銜接、後續的擴展等等。並且要能夠準確判斷開發成本，通過開發成本，選擇最適合當前的實現方式。滿足需求的是這整套解決方案，而功能是其中的一種實現方式而已。但是不同功能，所需要的開發成本，天差地別。如果你對於需求有足夠的信心，設計足夠充分，開發人員是不會拒絕的。
要對需求的收益有準確認知。一個完整的迭代期，大多流程都是收集需求-&>分析需求-&>確定迭代期目標-&>開發-&>測試-&>發布。作為產品經理，最重要的工作，就是給需求劃分優先等級，確定迭代期的目標。如何給目標，是非常考驗產品經理功力的一點。產品經理本身，要對這些需求的收益要有足夠明確的預期。我們平時工作中所接觸到的需求，一般都有幾種類型。一種是現有功能的缺陷（BUG），一種是產品UI的調整，一種是產品新功能的擴展開發，一種是對於現有功能的重整和優化，一種是偏向後端的產品架構的調整。對於大多數情況而言，通過推出新產品、服務、功能去滿足新的未滿足的需求，是最有可能給產品帶來最大收益的，但是風險也最大，因為開發成本高，並且需要產品經理對於用戶需求有準確的認知，才能真正滿足到用戶的需求點，做出受人歡迎的東西，並且變成產品自身的差異化和競爭力，否則就是浪費團隊時間，給產品帶來沒用的功能。我也見過太多的產品經理，平時的工作，就是圍著開發改UI上的各種顏色、字體、交互、文案，卻無視其他有可能對產品當前更加重要的需求。幾個月過去，產品各方面數據仍然在原地踏步甚至後退，作為開發人員，也因此對產品經理失去耐心和信心。
要對產品系統有概念，考慮到可維護性和擴展性。有的產品經理或者老闆，喜歡這麼跟開發人員說：「第一版不要搞太複雜，就有XX功能、XX功能就好了」。聽到這些，作為開發人員，很多時候都是皺眉頭的。因為這麼說的人，大多都不知道第二版長啥樣。在實際開發中，第一版確實可以做得很簡單，但是在設計上，必須要考慮到後續功能的擴展，否則系統架構、數據模型一建立，上線並且有用戶數據，再去做變更，開發量甚至大於推倒重來。所以在設計整套產品時，要充分考慮到後續可能出現的擴展和需求，可以暫時不做，但是一定要考慮到並且提出來。
大多數產品和開發之間的溝通問題，都不是溝通能力的問題，而是產品經理思考能力的問題。需求沒有經過認真思考，解決方案沒有進行詳細設計，對於開發周期沒有把控能力，對於需求的收益沒有認知，才是造成開發拒絕產品的根本原因。你想的不對，不周全，說的再天花亂墜，開發人員也不會買單。

我將給出
一條原則
一個思路
一條建議

1、一個原則
產品與技術溝通，首先是公事，應該坦蕩而從容、無懼無畏、不帶情緒；
然後，既然是溝通，我們自己的姿態必須是不卑不亢，不強勢不懦弱；

2、一個思路

a，讓技術人有參與感
最好是能讓相關技術人參與到設計過程中，至少是設計的評審過程中；

b，獲得領導和其它相關人員支持
這就要求產品是經過評審的，而不是隨意隨時的修改；
這也就要求產品人自己要謹小慎微，反覆推敲論證，切實對產品負責，能最終過得了堂；
一旦過了堂的產品，相關部門是必須執行的，也就是獲得了領導和其它相關人員的支持；
技術事後再鬧情緒或反悔，已於事無補。

c，統一目標
與技術溝通時，表明大家都是為了這個產品而奮鬥，有共同的利害關係；
而針對具體的「無法實現」，與技術人員共同探討其它解決辦法（當然還是指技術辦法）；
實在不能解決的，要幅技術人員出示書面報告簽字表明無法解決，最終變更需求；
（該官僚的時候要官司僚）

3、一條建議
在互聯網行業混產品，多懂得技術是好事。

我覺得碰到強勢的工程師是一件好事。同時，別人拒絕你的需求未必是一件壞事。
作為產品經理，你的任務是：
1、想清楚需求，並且讓合作者認同你的需求（覺得這個需求應該滿足，有一定的重要性）；
2、想清楚解決方案，並讓合作者認同你的解決方案
如果對方完全不認同你的需求，請考慮你的需求是否合理；
如果雙方共同認可需求，只是你的解決方案被吐槽說無法實現。
此時問自己兩個問題：
1、這個需求緊急么？
2、這個解決方案是唯一可行的么？
如果不緊急，那麼慢慢的多次商量。我周圍的人們就總說念念不忘必有迴響。
通常情況下，請相信你的工程師，想另一個解決方案吧——車到山前必有路，一定會有其他解決方案。

當然，這都是建立在雙方平等、互信、友好交流的基礎上。如果你跟工程師之間的關係已經處到了以勢壓人、互相不信任、對人不對事的程度，那就不適用了。

個人經驗：強調自己正確的，尊重別人特長的。問題可以反過來問，也可以擴展到所有合作者之間的溝通。

首先，要讓技術積極面對本產品，如果你的技術團隊對本產品都抱懷疑態度或者根本沒信心，他們是不會有主動高效地去完成產品開發的。

其次，又要講人格魅力了。其實這東西很虛，所謂能依靠人格魅力來影響弟兄幹活的人，我想也沒有幾個。不過我覺得，一般產品能做的，有這麼幾方面：不要把自己處於高點，你和做技術的弟兄是平等的，不要總是以責難、指導、下命令的形式來待人；要理解技術的苦處，要懂得體諒他們通宵加班的痛苦，有條件的情況下，和他們一起加班；適時請大家吃頓飯（反正公司報銷，算借花獻佛）；偶爾也要告知弟兄們，自己也受到上層的很大壓力，適當地裝一下可憐。

最後，要懂得一些技術（我說的是了解，不是精通）。一些邏輯性的東西，必須要懂得。如果技術說無法做，要和他坐下來溝通，看卡在哪一個具體的點上。譬如某一個功能做不了，不是簡單地就做不了這個功能，要找到具體原因。這些技能，其實並不需要懂得如何開發，只要有基本邏輯能力其實還是能夠做到的。如果確實是技術問題，可以向公司的技術中心求助（神馬？你們公司沒有技術中心？那找高手求助吧，武林高手在華山）

What"s more？
有人說，這樣做，產品經理就管得太雜了。嗯，這個問題確實很麻煩，但是確實是必須得面對的。所以，向老大請求要個產品專員吧，還是技術出身的產品專員最好。
其實技術很討厭別人說」別人能做，為什麼你就做不了「這類的話，如果有類似例子，最好給技術例子，」是否可以研究一下這個例子，看看別人是怎麼實現的「
技術也有技術自己的想法，他們會給產品很多各種各樣的建議（雖然我不想詆毀在座的某些技術，但是我認為在中國這樣方式培養的技術，多數產品需求都是不靠譜的），千萬不要當面詆毀或者嘲笑他們的想法，要耐心地和他們分析，為什麼要這樣做，為什麼不能這樣做。
在開發過程中，技術經常會產生質疑產品設計的情況，不要以權壓人，說一些」我是產品經理，這個是我的決定，你不懂就別亂講，照做吧「這樣的屁話，雖然煩，還是得認真告訴他們，為什麼要這樣做，獲取他們的贊同，他們對產品的積極性也會提高不少。

抖個機靈，一般技術開發都是男的居多，派個漂亮的產品MM去，溝通保障暢通些…

講一個故事吧，微軟的win8之父年輕時候也是一個PM應該是微軟最偉大的pm之一了吧。他有一天和程序員起了衝突，程序員說必須有兩周才能幹完，他說項目等不及了。就這樣衝突一直沒有一方讓步，直至一周後，這個PM帶著自己寫的code給程序員看，他只用一周就可以這些功能。所以產品經理還是要懂一些技術才能和程序員更好交流

1.建立信任機制。不要站在對立面，要知道，你們是一個戰壕里的兄弟。
2.做事要深思熟慮，在找技術，設計，測試，等等人前，先問問自己，這樣是最好的解決方案嗎？如果總是修改方案，換位思考，自己是否願意總被改來改去。
3.誰強勢不強勢不是裝出來，拿架子拿出來的。以職級來壓人，只能得到背後鄙視。要讓合作者打心裡佩服。不斷提高自身素質。
4.不斷學習，擴寬相關知識面，但並不是要做全能。知道自己是幹什麼的，明白銜接領域的流程方法，以及所需資源。
5.與人方便，自己方便

80%的情況是：

你媽把你叫來，對你說：「去幫我買瓶陳醋回來，一定要買鎮江陳醋！螃蟹蘸鎮江醋最好吃！坐兩站公車到附近超市去買！怎麼一臉苦瓜像？又不遠！來，錢拿好！」
你心想，靠，味道不都一樣么。那點區別誰能吃出來！
於是，你在樓下小區花園逛了幾圈，又給女朋友打了個電話（等等，程序猿哪有女朋友？？好吧。算個bug）然後在小區花園隨便買了瓶醋。
回家一開門你就吼道，「媽！超市鎮江醋賣完了！我隨便買了瓶你對付用吧！」

———————哎！都別走啊！要認真答了！——————

針對這80%的情況（你家有家庭恩怨咱也管不了啊。。）

你媽可以這樣做：
1、「別騙我了，你根本沒去超市，我在樓上都看見你在小區兜圈了！」（這是懂技術的產品經理，直接指出技術上實際上可實現，有理說理即可）
2、「哎呀，快過來歇歇。但你爸就喜歡吃蟹配陳醋，你說怎麼辦呢？」（不懂技術的產品可以嘗試讓技術提出替代方案，畢竟，那一星兩點的區別也不一定值得投入）
3、「哎。那也沒辦法，這樣吧，你再去遠一點的那個大超市看看。打車去吧。來，多拿點錢！」（對！！沒看錯！！關鍵是多給錢！！說是難度問題實際上是時間問題，只要給時間讓程序猿慢慢造，什麼都能實現）
4、「呵呵，你爸就愛吃鎮江醋，他下班也快回來了，自己看著辦！」（作為沒有實權的產品經理，最後一招就是搬老闆出面了。但這強烈不推薦！多用幾次別把人逼的離家出走了）

對了，我是產品狗。。輕拍

曉之以理，動之以情
------------------------------------------------------------------------
做技術的人都有比較理性，對風險的預測比較嚴謹
排除他們顧慮很重要
另外，超過一半以上的PM與CTO之間的糾紛來自進度把握
只要你給足夠的時間，就能實現很多技術
但是，時間成本增加，技術成本也在增加
這個，你急也沒用的
最好的方式是，引入第三方加強管控
比如流程部門或者IT審計

作為程序員，架構師，但是同時自己兼任產品經理職位，並且經常和客戶溝通的我來說一下我對於這個問題的體會：

1. 「技術上實現不了」的技術潛台詞：「技術上性價比不高」
技術上確實有性價比不高的東西。可能是和當前能力不匹配，可能是和技術選型衝突很大，也有可能是某需求的背後是眾多大牛日思夜想要解決的終極難題。

「性價比不高」的意思是這條路可以走，但是走這條路會花費過多的資源：時間，人力，技術能力，業界對於某問題的一般解決水準，學術界對於某問題的前沿解決水準，相應的工具和技術堆棧。如果你的公司，團隊，個人的目前的資源和水準並不足以挑戰某些問題，則不應該給予此類問題過高的優先順序。又或者要解決某些問題確實可以解決，但是解決所花的時間或成本會大大幹擾主線任務，並且很可能導致工程超期，則不應優先解決。

2. 「技術上實現不了」的針對PM的心態的潛台詞：「你丫是傻叉」
你丫凈扯些沒有用的！不會寫程序的PM不是好的需求方！懶得理你但是又不想直接說你是傻叉就用技術上實現不了這樣的話！整天看些PM修鍊集錦寫些天花亂墜的文檔搞些什麼人性的設計真的大丈夫？你思想有多遠我們就能跑多遠么？你知不知道寫程序也是一個工作，也是有輕重緩急和工作速率之說么？還有，寫程序並不是從零開始的一個過程，每一段程序都有它的前後積累以及上下文支持的，並不是你一句話就說出來那麼簡單的。

導致這個問題的最主要的原因是：

PM方處理問題domain和程序員方處理問題domain本身的巨大認知鴻溝。
這個裡面細講出去就無窮無盡了，基本上要向程序員把全人類的所有方面都講個遍，再讓PM自己達到程序員的程序能力和經驗，才能認識到上述鴻溝的巨大。這還不算解決鴻溝。

這個問題，和所謂的「我準備創業，萬事俱備，就差一個程序員了」的問題是同一個問題，只不過後者表現地更加極端一些。

3. 如何（部分地）解決這個問題
廣義的PM方，其實就是CEO，創業者，需求方，甲方，客戶，以及市場。
廣義的程序員方，其實就是架構師，CEO，創業者，以及自己所創造的技術/產品的需求方，第一個客戶，和市場。

在大公司裡面，這個問題基本是無法得到滿意的解決的：
因為每個人的JD都限制了他的視角的擴大化。每個人都是他所在的局部信息孤島的受益者和受害者。大家忙著滿足KPI之類的東西，大目標是什麼，也成了一個文檔中寫的東西。

而在小公司裡面，或者創業團隊裡面，這個問題更加無法得到令人滿意的解決：
看起來小團隊會更容易形成共識，但是這個並非盡然。另一方面因為每個人的視角的擴大相應地要求他的認知水準和對於事，物，人，時，以及自己心態的把握能力要成倍地提高。而且一個人的視角和見識能擴張，但是他的技術能力的匹配度則很難以一個非常快的速度擴張，小團隊會經常面臨能力匹配不足夠的問題。

4. 唯一的解決辦法：強
解決辦法就是變強：某人很強，你很強，你所在的團隊很強，你的團隊所能夠匹配和動用的內部資源和外部支持很強。

怎麼才能強？一個簡單的辦法是prioritize，做事有先後與輕重緩急，想問題也得區分重要度，要走的路徑規劃好了，又要能夠堅持又要能夠變通。不浪費資源，少浪費時間，戰略和細節都不能差。全局想的清楚，局部看得明白，細部做得踏實，時間把握地恰當。能避難，也能迎難。真的要變強，需要錯誤試錯和時間，也需要機會經驗和視野。簡單來說就是一個字，強人所難。

5. 小更新一下，「強人所難」的意思有兩方面：
1. 「強自己/別人所難」，就是勉為其難，把難以解決的部分，用耗時，毅力，其他方面的資源，其他方面的人員等辦法，乃至於「拖字訣」（拖也是需要能力的，就是面對壓力的能力），把這個很難的問題繞過去，或者變相地部分解決了，或者延後解決。強自己所難。如果push了別人，或者fail了別人，則是讓別人為難，當然最後還是你自己為難。

2. 「在大家都很難辦的地方擁有超出尋常的強大能力」，就是說大家都趟不過去的河，你不知道怎麼地就很輕鬆地過去了。比如說你是技術某方面技術超強，或者你是PM說服力超強，或者你是萌妹子讓技術拿你沒辦法。在別人弱的地方你很強。

第一個強，強的是綜合素質和心理素質，第二個強，強的是專業素質和專業能力。

這樣你就能（部分地）解決（大部分的）問題了。

本回答的額外彩彈！！！！
請轉到這個問題下面接受彩彈的洗禮！！！：
有哪些產品經理認為很簡單，實則開發很難的技術？ - 前端開發

首先個人感覺追求和技術人員說行話的這種想法和做法是錯誤的，而且很有可能會招來技術人員的反感（他們會說你是技術還是我是技術啊，你懂什麼），如果能順利溝通，那麼很容易被技術人員帶到技術實現細節，而不能從宏觀上去看待整個產品的發展目標和軌跡。

——————————————————————————————————————

so，如何能說服技術總監和開發人員，個人認為功夫全在日常的積累了。

這種積累包括對行業的發展前景的認識；

包括對行業中的強勁對手動向和產品的理解；

包括對自家產品發展目標、定位、當前業務情況的理解；

如果這些自己能拍著胸脯的娓娓道來，那肯定不懼怕和技術大牛的對決了

其實我覺得說行話也不一定有多大效果。
做技術的人，也分各種性格。有些人比較踏實，會完全按照你的要求努力去做；有些人會比較心高氣傲，他覺得不好或者沒意義的東西就不會努力去找解決方案。
所以，重點是你要讓他認同你提出的需求。
從這個意義上來說，技術「行話」反倒不如簡單明了的說明你為什麼要提這樣的需求。
如果你的要求，技術真的無法實現（這就要求你有基本的技術功底），那可以跟他探討為了達到目標，可以採用哪些其他的手段。

我在做產品實習中遇到了一些溝通問題於是研究了下，如何好的溝通
研究背景：
產品經理提出需求受到工程師從需求變更及需求邏輯嚴密性上的質疑
研究目標：
產品經理與工程師交流的心態與方法
研究結果:
心態層：
1.說服不是目的，令對方心悅誠服的開展接下來的工作才是重點。
2.工程師獨立思考、擁有較強的邏輯思維能力，有助於產品經理能力的提升以及產品的完善。
方法層：
1.提出需求前，做到充分調查研究
（1）對競品相關功能點進行對比分析，得出合理解決方案。
（2）在用戶使用場景上，量化場景。
（3）從使用角度出發，給出重度用戶主觀體驗。
（4）憑藉經驗、個人魅力說服。
2.提出產品方案性價比平衡
（1）給出多個產品方案，調研競品，給出自己產品邏輯，列出方案優缺點。邏輯複雜需要找工程師評估。
（2）產品方案各異，選擇其中一個上線，再根據情況迭代。
3.平日積累
（1）適當多了解一下技術。
（2）不清楚的多請教工程師
（3）多與工程師在一起
（4）從投入產出比考慮產品實現

搞定說不能解決的開發的leader