起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識產(chǎn)品！你為什么又惹技術小哥哥生氣
本文總結了產(chǎn)品與技術等同事常見的矛盾點以及對應的化解辦法，快來看看，這其中的五種類型你有沒有剛好遇見過。
身為一名產(chǎn)品狗，每天被技術懟，被UI懟，被交互懟，被運營懟，日日四面圍懟，苦不堪言。
牛奶走（wei）訪（xin）了20個技術小伙伴，總結出了產(chǎn)品與技術等同事常見的矛盾點和化解辦法。
看完文章的產(chǎn)品狗，請昂首挺胸，抬頭做人！
以下五種最惹人技術小哥哥生氣的PM類型，我們來一一解讀。
（本文中的產(chǎn)品經(jīng)理全部用PM代替）
No.1水母型PM
特點：無腦 有毒
以下為吐槽原文：
水母型PM，通常出沒于初級PM或者產(chǎn)品能力、經(jīng)驗不足的PM中。
為什么叫水母型PM呢，是因為這類產(chǎn)品經(jīng)理具有著和水母相同的特點：“無腦”、“有毒”（“無腦”這里就是指不經(jīng)過大腦，不動腦子，不是惡意攻擊哦）。他們通常的表現(xiàn)為缺乏邏輯、需求理解不清。這兩點對PM的職業(yè)發(fā)展的影響是致命的，是體現(xiàn)專業(yè)度的基本素質。
缺乏邏輯主要體現(xiàn)在說話沒有條理，觀點和論據(jù)不符，表達前后矛盾等等。需求理解不清是在溝通的時候技術等同事對需求提出一些問題和質疑時無法清楚地回答，根源在于PM本身對需求的理解不夠。
在和技術溝通的過程中，產(chǎn)品邏輯差、用戶需求理解不清是高頻出現(xiàn)的槽點，這會導致PM設計的原型經(jīng)不起推敲，或者無法解決用戶真實的問題，產(chǎn)品原型和需求也會因此頻繁變動。
假設我們把開發(fā)、UI、運營的工作理解為挖地下隧道，你讓人家向東挖了十米、向西挖了十米，最后發(fā)現(xiàn)真實的需求是向北挖，你說氣不氣人。
建議：PM在收到需求繪制原型前，首先要充分理解需求，并驗證需求是否是一個真實存在的需求。仔細去思考需求的用戶是誰、解決了什么問題、是否是一個有價值的需求等等。在與同事溝通時也要明確自己要表達的內容，以有條理的方式表述，可以先試試質疑自己。
關于產(chǎn)品基礎技能方面牛奶寫過兩篇文章，可做學習參考~
產(chǎn)品創(chuàng)新必備方法論-國外系統(tǒng)的產(chǎn)品創(chuàng)新方法論（一）
No. 2“我不聽我不聽”型PM
特點：油鹽不進 缺乏技術常識
以下為吐槽原文：
“我不聽型”產(chǎn)品經(jīng)理相較“水母型”產(chǎn)品經(jīng)理，產(chǎn)品能力和素質已經(jīng)有了很大的提升。這類產(chǎn)品經(jīng)理有一個特點就是極力想要證明自己是對的，所以這類產(chǎn)品經(jīng)理的需求和邏輯一般是比較好的，不然如何和別人辯論并取勝呢。
他們通常以成功說服別人為樂，以變更需求為恥。
很明顯，“我不聽”型產(chǎn)PM和技術小哥哥、小姐姐的矛盾點通常出現(xiàn)在不夠理解技術實現(xiàn)的復雜性和可能性上，我們雖然不建議PM為了技術改需求，但也不倡導PM完全不妥協(xié)。
因為PM身上肩負的不僅僅是某一個需求是否被實現(xiàn)，更大的職責是保證在時間可控的情況下保證產(chǎn)品的良性發(fā)展，我們需要去權衡一個功能所花費的開發(fā)成本是否和它所帶來的效益匹配。
如果為了堅持某一個需求，造成了過度的研發(fā)成本投入，耽誤了其他更有價值的需求的開發(fā)上線，豈不是得不償失。
所以，適當?shù)耐讌f(xié)，并嘗試接受別人意見也是職場中的必備技能。
No. 3馬后炮型PM
特點：事后諸葛亮
以下為吐槽原文：
這類產(chǎn)品經(jīng)理最大的問題是做產(chǎn)品是思考不夠縝密，需求文檔不夠清晰。在研發(fā)已經(jīng)開發(fā)完成后發(fā)現(xiàn)了一些需要調整的問題或者需要增加的邏輯。
很明顯，海兄反饋的問題根本原因就是需求表述不夠清晰。
這是一個常見的溝通交流問題–我以為他懂了。其實在工作中我們常常會面臨這樣的問題，我們認為自己做了一個清晰的表述，然而別人并未get到全部的點，存在理解偏差。這就需要我們不斷地明確表述并多多溝通。
有一種看似有些笨，但很有效的解決問題的方法就是–復述。讓對方復述他理解到的東西，來確認傳輸中是否有信息丟失，并通過思考自己哪里的表述出了問題，導致發(fā)送方和接受方的信息不對稱，來不斷優(yōu)化自己表述。
No.4催命鬼型PM
特點：重復“什么時候做完”
以下為吐槽原文：
處理這種問題的方法，首先是解決為什么催的問題。
通常有兩種情況我們需要催促項目進度。第一種，項目有特殊的需求，需要提前上線，第二種是開發(fā)延期。處理方式上，第一種情況要和研發(fā)充分溝通原因，協(xié)調時間；第二種情況去催促并詢問情況是無可厚非的，但也要保證正確友好的溝通態(tài)度。
但在公司已經(jīng)有了完備的開發(fā)時間管控和評估的情況下，你只是出于擔心而頻繁追問，其實并不是一個很有意義的行為。
同時，PM如果能掌握對于研發(fā)、UI工作量的預估能里，會解決很多溝通中的問題。
No. 5無目標型PM
特點：缺乏目標感和戰(zhàn)略思維
以下為吐槽原文：
目標感和戰(zhàn)略思維是對中高級PM的需求，會直接影響到產(chǎn)品（這里不是說PM，是指實體產(chǎn)品，APP、軟件產(chǎn)品等）的生死，如果公司上下沒有統(tǒng)一的戰(zhàn)略目標，那么就會導致產(chǎn)品陣亡。
我們舉個例子，比如公司某互聯(lián)網(wǎng)公司做了一款“聊天”軟件，公司對產(chǎn)品的定位是讓三四線人群可以在APP上賺錢，這樣吸引流量，進而實現(xiàn)流量變現(xiàn)。但是公司的PM似乎都劍走偏鋒，設計了很多不痛不癢的改善溝通效率的功能，結果就是用戶上來沒事做，迅速流失，公司也要面臨倒閉。
對于PM，能夠自己掌控功能設計是一件很棒的事情。但想把這件事兒做好，就要時刻校驗自己的想法和功能是否符合公司制定的大的產(chǎn)品目標和方向，不然不僅做不出業(yè)績，還會因為目標不明確遭到同事和老板的Diss。
END
總結了這么多常見的PM類型，你有沒有中招呢，喜歡的話點擊好看，歡迎留言吐槽你的同事，把他們對號入座!哈哈~
本文由@牛奶 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載
題圖來自Unsplash，基于CC0協(xié)議
有沒有產(chǎn)品經(jīng)理入門指南啊，天天被懟怕了?? 跪求?。。。?/p>
http://m.codemsi.com/rp/1976908.html 這個算不算 哈哈
噗
哇 大早上被技術人員氣的…你們話都不能一次說完嗎，每次都像擠牙膏一樣，??????
啊哈哈哈 好多技術是這樣的，不太愛說話
做交互設計這幾年，我真正接觸到思路清晰、邏輯清晰、需求規(guī)劃合理、項目把控穩(wěn)定、溝通順暢的產(chǎn)品經(jīng)理，不到2位，剩下的產(chǎn)品經(jīng)理特征總結起來有：
1、唯命是從，老板提的需求，死也要執(zhí)行下去，即使需求不合理，甚至他自己也知道需求不合理（不合理的原因通常是高層的領導不了解產(chǎn)品實際的現(xiàn)狀）。
2、把交互設計師當成畫原型圖工具的，自己畫一個草草的原型圖，交給交互設計師，讓交互設計師美化一下，美其名曰，我要給老板看，老板要原型圖漂亮。
3、以為產(chǎn)品經(jīng)理是經(jīng)理的，這種產(chǎn)品經(jīng)理覺得所有的設計、開發(fā)、測試，都是給自己打下手的，自己想實現(xiàn)的需求，所有人都要無條件的完成，完不成就發(fā)脾氣（我真的遇見兩位這樣的產(chǎn)品，直接向我和另外一位交互發(fā)飆、大聲嚷嚷，譴責我們?yōu)槭裁礇]有按照他們的思路出交互稿，面紅耳赤的嚷嚷，拍桌子，等等。簡直了）
4、覺得自己是張小龍的，這種產(chǎn)品經(jīng)理我見得最多，通常的特點就是，夸夸其談，競品分析的頭頭是道，以為自己很了解產(chǎn)品的用戶，覺得自己做的決策都是對的，但是結果通常是啪啪打臉的，被打臉時，還把鍋甩給設計師。
5、全能型產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理是個不需要職業(yè)背書的崗位，沒有專業(yè)，只能靠經(jīng)驗提升，但是通常他們覺得自己剛畢業(yè)就能做產(chǎn)品經(jīng)理（他們恐怕對產(chǎn)品經(jīng)理有什么誤解）是個了不起的事情，覺得自己對設計非常懂，覺得自己有10年的設計經(jīng)驗和20年的設計審美素養(yǎng)，經(jīng)常插手設計的決策，肯定自己的審美，肯定自己的設計經(jīng)驗，這種產(chǎn)品經(jīng)理，簡直了。
厲害了，新總結了五種
想吐槽的太多了，產(chǎn)品經(jīng)理一百種花式作死，一百種做事的打臉方式，一百種改需求的理由，一百種自我肯定的迷之自信。
不懂技術，經(jīng)常被開發(fā)diss……唉 得學點基礎的技術了
學起來 加油
很多技術人員開發(fā)的時候都是按照UI的效果圖來的。。。不知道為啥就是不愛看PRD 很生氣
因為懶 所以要仔細檢查UI圖，我們的UI就喜歡改文案改功能 O(∩_∩)O哈哈~
我們的也是哈哈哈哈 好多次想跟UI撕比
啊哈哈哈 是啊 戲太多了。我感覺溝通重點就是劃分職責
因為現(xiàn)在行業(yè)中的PRD，是閱讀效率最低的文本?？粗M勁、還很難理解。
用的這些頭像都是我逝去的青春！
啊哈哈哈哈哈哈哈哈
敏捷開發(fā)，為了趕時間，往往是保證主要流程走通先。但在測試過程中，測試習慣使然會做一些非常規(guī)操作來驗證異常流程。然后和開發(fā)一說。。得了，嗯，鍋背定了
我只想說，這是我第一次看到會員回復
感同身受，每每到測試，看著眼前的屏幕，莫名的火大。
生活要想過得去，頭像就得帶點綠。