真的，別“想不開”，當產(chǎn)品經(jīng)理。

前一天滿懷信心，仔細打磨的產(chǎn)品功能和細節(jié)邏輯，第二天拿到評審會上，可能會被工程師噴得體無完膚

提一個簡單的需求變動，技術(shù)大哥卻告知改起來很復雜、這個功能做不了”；

發(fā)現(xiàn)產(chǎn)品中存在BUG，要求修復，技術(shù)回復“不是BUG，是不是你沒正確操作？”；

從產(chǎn)品角度和技術(shù)部門溝通，工程師說的技術(shù)語言完全聽不懂

經(jīng)常有一種 “我是不是被技術(shù)大哥忽悠了？”的感覺；

……

其實，技術(shù)大哥作為腦力工作者，他們大部分時間都花在和代碼打交道了。

他們的計算機世界，很有規(guī)則性；

他們普遍記憶力很強，畢竟產(chǎn)品的每個細節(jié)都是他們一行行碼出來的；

他們的思維方式偏線性，邏輯性強；

他們認為一件事情最好能按照固定的流程執(zhí)行，不喜歡中間突然變化或出錯；

他們欣賞自己的程序作品，遇到質(zhì)疑，會主動維護；

……

作為產(chǎn)品經(jīng)理，需要和各種各樣的人打交道，需要推進項目流程進展，所以，了解合作者的行為、思維和情緒模式，掌握不同情境下問題的快速處理方法很重要

如何向技術(shù)大哥正確提出需求？

產(chǎn)品經(jīng)理工作中的重要任務除了是寫PRD，還有就是講解產(chǎn)品需求，而需求執(zhí)行者，更多的是技術(shù)開發(fā)們。

實際工作中，經(jīng)常出現(xiàn)產(chǎn)品經(jīng)理描述的是“需求X”，但是工程師的理解是“需求Y”，最后開發(fā)出來的產(chǎn)品風馬牛不相及。

這里面固然有技術(shù)大哥理解能力的問題，但產(chǎn)品經(jīng)理作為項目的積極推進者，還是需要從提升自身來改善。

需求寫好先自我審視

比如功能邏輯說明中，除了正常功能邏輯，是否有異常功能處理邏輯

例：用戶登錄時，如果網(wǎng)絡異常，或者用戶突然離開決定“暫時不登錄”，產(chǎn)品時如何處理的？

這樣的自我審視，是從技術(shù)開發(fā)角度理解的換位思考，有助于后續(xù)的溝通更流暢，也能增加技術(shù)大哥的信任。

語言表達方面，多站在用戶的角度溝通。

技術(shù)開發(fā)們通常都是一群很有個性的人，他們很自信，主觀性很強的溝通，他們不太容易接納，所以產(chǎn)品經(jīng)理應該減少使用“我認為”“我覺得”這樣詞匯，應該多使用“我們來看一下”“用戶使用產(chǎn)品時會覺得”這樣的內(nèi)容，給人一種解決問題的正向心態(tài)表現(xiàn)

綜合來說，和技術(shù)大哥提需求，產(chǎn)品經(jīng)理的語言表達能力和換位思考能力的提升，有助于傳播效率的改善。

如何站在技術(shù)角度思考產(chǎn)品？

毛主席的戰(zhàn)略方法最直接管用——從群眾中來，到群眾中去。要想從技術(shù)的角度思考產(chǎn)品，就要進入他們的隊伍中。

產(chǎn)品經(jīng)理提完需求后，技術(shù)部門的工作正式開展起來，他們內(nèi)部首先也需要做廣泛討論，這個環(huán)節(jié)，有的產(chǎn)品經(jīng)理會選擇參加，有的不會。但有一句亙古不變的名言“知己知彼百戰(zhàn)不殆”，作為產(chǎn)品推進的靈魂人物，參與技術(shù)討論是非常有必要的。

技術(shù)討論上，開發(fā)們會確定一個他們最關(guān)注的事項——技術(shù)開發(fā)成本

產(chǎn)品經(jīng)理需要在這個過程中，充分了解他們得出結(jié)論的原因，并且在關(guān)鍵時刻成為產(chǎn)品的發(fā)言人，將對產(chǎn)品功能和用戶價值需求的原因，及時地傳遞給技術(shù)開發(fā)。這樣有助于提升產(chǎn)品實踐與模型的深度結(jié)合。

小貼士：遇到技術(shù)討論的問題不懂時，怎么辦？

形象化的提問，同理心優(yōu)勢，將自己不了解的技術(shù)問題，形象化的方式描述出來，提問的方式讓工程師幫忙解答，合理地表達問題。

例如：咱們現(xiàn)在討論的是不是這個功能的數(shù)據(jù)結(jié)構(gòu)？是不是可以理解為……，這過程也給了工程師自我表達展示知識素養(yǎng)的機會，讓你們的個人關(guān)系也得到提升。

如何激發(fā)技術(shù)大哥修改需求的動力？

幫助技術(shù)設計理解“人性需求”一個產(chǎn)品經(jīng)理所維護的團隊，一般設計業(yè)務、運營、設計、程序等角色，這些角色的分工也很明確，其實也代表著產(chǎn)品經(jīng)理在闡述產(chǎn)品時的勾勒維度，總結(jié)起來大致分為功能邏輯、界面設計、需求背景和技術(shù)支持。

當然，溝通的時候，也是圍繞這幾個層面的。按照一般的溝通方式，與設計溝通，要多聊界面效果，與運營溝通，要多聊轉(zhuǎn)化率，與業(yè)務溝通要多聊產(chǎn)品效果，與程序溝通，當然是技術(shù)成本。

所以，如果我們有修改需求時，如果從技術(shù)本身角度來說，很容易換來程序員們的抗拒，因為技術(shù)開發(fā)就好像蓋房子，中途調(diào)整，勢必牽連很多層級的建構(gòu)。

那么，產(chǎn)品經(jīng)理還能發(fā)力的角度就只剩下了需求背景的闡釋。

一個優(yōu)秀的互聯(lián)網(wǎng)產(chǎn)品，它的每一個環(huán)節(jié)必然符合人性需求的，在和技術(shù)溝通是，如果能幫他們把握產(chǎn)品變化的原則和驅(qū)動變化背后的人性需求本質(zhì)，那么，技術(shù)在修改的時候會更加有動力，甚至迸發(fā)創(chuàng)造力。

這種方法，還有效在于，信息共享的意義。信息共享就是資源共享，作為能夠和老板和領(lǐng)導更多交流產(chǎn)品發(fā)展的人，產(chǎn)品經(jīng)理應該多和技術(shù)開發(fā)溝通，消除彼此對于未知的恐懼，同時提高整個團隊里面的資源利用率。

小貼士：遇到“BUG”怎么溝通？

BUG中文含義——在電腦系統(tǒng)或程序中，隱藏著的一些未被發(fā)現(xiàn)的缺陷或問題統(tǒng)稱為bug（漏洞）。

如果你是技術(shù)大哥，你一定不喜歡這樣的BUG。所以產(chǎn)品經(jīng)理在溝通這種情況時，需要照顧到他們的感受，換一種描述，比如“新增的小功能特性”。

產(chǎn)品的技術(shù)開發(fā)們，理性邏輯思維很強，他們習慣用實現(xiàn)的難易程度和系統(tǒng)的角度定義和設計產(chǎn)品，而產(chǎn)品經(jīng)理思考時更關(guān)注與具體場景的連接，如果與技術(shù)溝通時，只講功能和邏輯，且不說會讓溝通陷入具體的功能和設計層面的溝通，但就溝通雙方的實踐能力來說，邏輯上產(chǎn)品經(jīng)理也很難贏??！

產(chǎn)品經(jīng)理如果遇到問題是，可以多想想喬布斯，這位非技術(shù)出身的產(chǎn)品經(jīng)理，是如何做出舉世矚目的蘋果系列產(chǎn)品的，至少他的合理表達方式和技巧能讓產(chǎn)品為更多人理解和接受。