你為什麼想打產品經理？

01-03

魯達坐下道：「奉著經略相公鈞旨，要十斤精肉，切做臊子。不要見半點肥的在上頭。」鄭屠道：「使頭，你們快選好的切十斤去。」魯提轄道：「不要那等腌臢廝們動手，你自與我切。」鄭屠道：「說得是，小人自切便了。」自去肉案上揀了十斤精肉，細細切做臊子。那店小二把手帕包了頭，正來鄭屠家報說金老之事，卻見魯提轄坐在肉案門邊，不敢攏來，只得遠遠的立住在房檐下望。這鄭屠整整的自切了半個時辰，用荷葉包了，道：「提轄，教人送去？」魯達道：「送甚麼。且住，再要十斤，都是肥的，不要見些精的在上面，也要切做臊子。」鄭屠道：「卻才精的，怕府里要裹餛飩。肥的臊子何用？」魯達睜著眼道：「相公鈞旨分付洒家，誰敢問他。」鄭屠道：「是合用的東西，小人切便了。」又選了十斤實膘的肥肉，也細細的切做臊子，把荷葉來包了。整弄了一早辰，卻得飯罷時候。那店小二那裡敢過來。連那正要買肉的主顧，也不敢攏來。鄭屠道：「著人與提轄拿了，送將府里去。」魯達道：「再要十斤寸金軟骨，也要細細地剁做臊子，不要見些肉在上面。」

我是做遊戲的，罵策劃應該和罵產品經理是差不多的？

事實上，和一個專業的策劃合作是非常非常愉快的。一個新功能的提出能夠讓我了解到這麼做是有好處的，玩家是有感的，而且是必要的。調整AI行為的時候通常是我與策劃在屏幕前一起調整，其實挺愉快的。

他本身提的改動需求的邏輯非常嚴密，這次的改動的提出考慮到了以前的邏輯框架，因此要改就很放心的改。

他對於需求提的非常明確，不會讓我們在開發的時候產生疑惑。

後來我們來了一個新的策劃，我去和她合作實在是太累人了。

「有個新的需求，角色處於這個狀態的時候屏蔽掉所有輸入。」

「所有輸入都屏蔽？確定？」

「確定。」

「暫停遊戲的操作呢？」

「額這個保留。」

「處於QTE狀態的時候能夠輸入QTE嗎？」

「額也能夠輸入...」

「說屏蔽掉所有輸入問一個要保留問一個要保留你TMD到底想清楚邏輯沒有！」

所以還是那句話：與專業的策劃/產品經理合作是非常愉快的。

對於那些半桶水的、毫無邏輯能力的、習慣想當然的、拍腦袋就提需求的策劃，我只想說:"WQNMLGB！"

你們這幫人，為什麼都抱怨PM老改需求呢？我的PM就挺好，早早定下spec，就不改了。。。

直到dead line前2天

要互相理解，才能生存下去…

圖片轉自網路，侵刪。。

想起一個笑話說，PM被綁，驚問，

"要幹什麼？",

對方不語，鞭笞之。

PM求饒，"別打，要錢？十萬夠不"，

啪又是一鞭，

「一百萬，行不？」，

對方還是不說話，繼續啪啪啪暴打。

PM被打急了，哭著說"你他么的到底要啥！！！"。

"要什麼，我寫代碼的時候也很想知道你他么的到底要什麼！"。

很多評論以為我在黑產品，其實我也黑程序員啊，而且黑的不輕：碼農們最常說的謊言是什麼？ - Jim Jin 的回答

原文：

咳咳咳，

順口溜來幾句，送給各位PM們：

講雞湯滔滔不絕；講需求點到即止。
對上司言聽計從；對開發頤指氣使。
想需求腦袋一拍；改需求強詞奪理。
對技術不懂裝懂；對用戶強行裝逼。

註：上面都是我胡扯的，產品經理不要打我。

我說句不好聽的，兩邊都很無能，因為打只是發泄，根本解決不了問題。

我身邊有相當一部分架構師和程序員每天就是承擔著一部分產品經理工作的，他們一邊吐槽產品經理需求說不清楚一邊自己研究產品邏輯想辦法把坑給填了。

最極品的我遇到過架構師把prd寫完了，壓著pd需求評審的，末了問我咋樣，爺這個prd寫得還可以吧……攤手。

當然了，這都是比較罕見的極端情況了。

那種整天讓技術補位，瞎折騰研發資源的pd是該打，但是如果他就是個渣渣，其他人何不取而代之？自己對於產品走向有話語權，還能親自coding實現他，不要太爽哦！

公司有這些又精通技術又熟悉產品還對數據敏感的全棧研發同學，真的是一筆寶貴財富。能和這樣一批努力又有天分的人一起工作，我也樂在其中。

帶個私貨做個廣告，螞蟻金服國際事業部還在招聘各類平台型產品經理，主要是面向多年互聯網活金融平台系統實施經驗的資深人員（P8起，短期內相對資歷淺的同學十分抱歉暫時還沒有HC,有了我會發專欄或者更新）。如果你想成為一名讓技術尊重認可的產品經理，可以來找我喲，讓簡歷砸死我吧。

tianshun.lts@alipay.com

好的 PM 讓程序員專註於解決他們喜歡解決的問題，幫他們解決他們不喜歡或者解決不了的問題。被打的 PM 為程序員增添他們不喜歡的問題。改需求什麼的都是「實現細節」，總之 PM 讓程序員感覺生活質量降低就會被打。

在我看來有三個原因吧。

第一：現在很多產品經理不夠專業。

就我接觸的一些在提需求的時候比較業餘，沒有經過專業的學習和訓練。比如說我在得到一個需求的時候，其實比較希望的是產品經理是基於自己的專業素養和經驗做出的判斷，最起碼這麼做是有比較充分的理由的，但是很多產品經理提需求都是先做做看，基本上就是在枚舉各種方案，碰巧這個還不錯就用這個了。

這麼做的結果就是開發人員的工作量增加了很多，而且經常需要加班。從某種程度上來說是開發人員通過加班工作來為產品經理的不專業買單，所以開發人員不喜歡產品經理是很自然的。

第二：外行領導內行。

產品經理名字裡帶個經理，大部分情況下程序員也是按照他們的需求在工作，但是產品和開發其實是兩個完全不同的行業，並沒有太多相同點。

所以這就出現了外行領導內行的尷尬，兩邊互相不理解是太自然的事情了。

第三：部分程序員在甩鍋。

程序員行業的水平也都是良莠不齊，部分程序員因為或能力或態度的問題無法完成自己的工作，反過來說需求不專業。

因為現在程序員行業已經形成了批判產品經理的風氣，如果碰巧自己的產品經理再出現一些問題，這些人就很容易就忽視自己的問題，將責任都甩出去。

其實產品經理跟程序員之間哪有那麼多深仇大恨，都是給人打工的，多少有點兒被媒體放大了。

理想的情況應該是牛逼的產品經理+牛逼的程序員=牛逼的產品

現實情況大部分是不合格的產品經理+勉強合格的程序員=日了狗的產品

關注這個問題好久了，作為一個完全沒有技術背景的產品狗不邀強答。就聊聊怎麼避免被「打」。

我把產品經理分成四個階段：

產品執行用戶體驗
產品架構技術實現
產品決策產品模型
產品格局社會價值

第一階段：產品執行用戶體驗

0-2歲的產品er大部分處於這個階段，執行上面的想法，推動產品方案上線落地。這個階段對於產品的好與壞的評判標準，基本是基於自己作為小白用戶的視角。

如何避免在這個階段被開發吐槽：

1.1 想清楚

方案idea可能是上面拍的，但方案細節是你自己定的，想清楚每一個交互細節和異常流，不要說想不全，可以拿著方案先和架構開發測試簡單聊聊。

1.2 寫清楚

寫清楚的意思是每一個流程每一個步驟都寫的條理清晰。拿一個普通的展示頁面來說，1）流程說明，主流程、分支流程、異常流統統寫明；2）跳轉說明：點擊返回/編輯/保存/取消等，分別觸發什麼。彈框是怎麼進入怎麼消失的。toast顯示幾秒，停留在當前頁還是返回上一頁；3）顯示規則，這個頁面包含哪些元素，都是哪些欄位，格式大小要求是什麼，是否換行全部展示，過長或過短怎麼展示，異常輸入怎麼顯示、空態頁顯示什麼等等；4）排序規則：第一排序優先順序是什麼，第二排序優先順序是什麼，正序還是倒序排列等等；5）分頁規則：一頁最多展示幾個，一次拉取幾個。下拉還是上滑刷新，是全頁刷新還是半頁還是指定區域刷。等等等等………這還只是一個普通的前端展示頁面，涉及後台邏輯的細節可以寫的更多。

建議：把評審會上被開發問住的點都記錄下來，整理起來，以免下次寫文檔有所遺漏。同時可以多看看身邊優秀的產品經理寫的文檔。

1.3 講清楚

每次開發評審少則7、8人，多則30多人，緊張怯場一次兩次可以諒解，長此以往就要反思自己。聲音是否洪亮，是否照顧每個聽眾的反應，是否準備充分，把該強調的細節都強調了？

文檔要寫的條理分明，評審要講的邏輯清晰。例如：這個頁面涉及哪幾個功能，需要哪些開發支持，主流程是什麼，異常分支是什麼，特殊的規則和要求是什麼。

建議：自己講完可以邀請關係好的開發複述一遍，就知道哪些地方要著重再講一遍。另外，多觀摩觀摩別人是怎麼評審的。

1.4 溝通溝通

溝是方式，通是結果。結果不對，方式肯定錯誤。那什麼是好的溝通方式？不卑不亢。

產品經理和項目組所有人都是平等的，你不是指揮他們幹活的，也不用刻意討好。平等的意思是，發自內心的尊重，耐心聆聽的理解，相處自然舒服不添亂。

剛入行時，向技術提需求也會買零食請吃飯撒嬌賣萌。後來漸漸發現，最佳的「討好方式」是成為一個靠譜的產品經理。

第二階段：產品架構技術實現

之前有個同事，是清華計院畢業的產品er，他曾笑言，某次提需求時，開發說實現不了，他當場指導開發怎麼去寫代碼 = =！

聽得我好生羨慕，吭哧吭哧跑去學html學python，走了不少歪路。

產品需要寫代碼很牛逼么？不需要。產品需要懂技術實現嗎？需要。

這是兩回事，一個優秀的產品經理不需要會寫代碼，但要清楚技術的實現方案，以及，能夠從業務角度，專業的回答很多個為什麼為什麼。

建議：

1）每次需求評審完，技術們都會私下再碰定下介面。產品er為何不索性再拉個技術方案評審會，聽下前端客戶端服務端是怎麼商量確定介面，一來了解各自分工，二來了解數據流轉。別覺得開發定介面和產品沒關係，這直接關係到產品實現的交互細節。

2）大公司的產品er估計拿不到線上資料庫許可權，但可以私下找開發要開發環境或測試環境的資料庫許可權。要了資料庫許可權，不是用來裝逼的= =！請看下你所負責的項目，共涉及哪些表哪些欄位，這些數據的調用、流轉、更新是怎麼樣的。

以上，簡單來說，①看看API文檔；②看看資料庫表結構；③看看架構圖；④聽聽開發講下各系統的依賴關係。

第三階段：產品決策產品模型

這一塊是我至今都沒有吃透的，只談談自己近期的體驗。

3.1 怎麼確定具體功能？

1）多研究競品和優秀的app，把appstore各個類目榜單前20名的app，都下載體驗一遍。並問問自己，這個app吸引自己的是什麼？它核心用戶和場景是什麼？它的缺陷和不足是什麼？怎麼優化？產品經理如果能做到多問自己為什麼，並且都能給自己一個滿意的回答時，就離靠譜不遠了。

2）多和一線業務人員溝通，最好能親身體驗幾天。例如做客服系統的和客服聊，做O2O業務的和運營、銷售、B端合作方聊聊。注意，聊天過程，他們經常會習慣說「我要XXX功能」，產品經理要做的是引導他們說出他們背後實際碰到的問題，去想方法解決他們的問題，而不是去執行他們提出的功能。

3.2 怎麼做產品決策？

通過優先順序去決策，如何判斷需求的優先順序？用成本收益比去衡量。就是這麼簡單粗暴。一個需求上線後能產生多大價值，完成這個需求需要多大的成本。

評論區有說這個判斷標準太粗暴了~我再解釋下哈，成熟期的前端型產品優先順序可能會根據運營的階段和規劃，即使是運營的規劃，也是這次運營活動能帶來多少數據，而數據就能折算成收益，上線運營活動的人力時間就是成本。

3.3 什麼是產品模型？

我在上一家公司時，只做線上產品，純前端體驗型產品，我那時候覺得，項目成功的決定性因素就是「產品做得好」。後來我跳槽來了現在這家公司，開始接觸O2O業務，我忽然發現，項目成功的決定性因素是「產品運營做得好」。現在，這個O2O業務已經上線跑了一陣，數據不是很好，我才意識到，項目成功的決定因素是「產品模型要搭建得好」。

什麼是產品模型？我很贊同純銀v的一個理論：產品模型=商業模式+產品架構+運營體系。

怎麼理解？每個項目在上線之前，它會死還是活，它生命周期的上限，盈利能力的上限，產品數據的上限，基本都已經敲定了。產品運營最多只能優化到無限接近於這個上限的理論值，除非市場發生突變或新技術產生，否則絕無可能超過這個上限理論值。而這個上限理論值就是由項目的商業模式決定的。

再舉個更具體的例子，同事之前創業做過一個項目，是智能硬體，關於兒童體溫計。上線3個月銷量過萬，毛利潤算20*1w*4=80w/年。單個硬體20元利潤算不錯了，銷售數據對於新產品來說也不錯了，但一年80w足夠么？完全無法cover產品研發以及後期迭代和維護的成本。毛利潤80w/年，按凈利潤算，一年就要負幾百萬了。

而他們團隊的目標是一年凈利潤5000w，即使這個智能硬體的工業設計多棒，對應的APP使用體驗多好，運營多用心，這個5000w的目標能達成嗎？按照目前這個細分市場對於兒童體溫計的需求強度和頻次，是絕對不可能達成5000w/年的凈利潤。不算研發銷售等人力成本、辦公成本以及渠道分成等，哪怕是5000w的毛利潤，也至少要20w的月銷量啊。而兒童體溫計這個市場，目標用戶群不超過3億，其中城市用戶大約1億，再除去傳統水銀體溫計、品牌體溫計、各類測溫儀等競品，還有社區醫院、小門診也會拿走一部分用戶。剩下的用戶能支撐20w的月銷量嗎？再者，兒童體溫計屬於一鎚子買賣，復購周期極長且復購率低。

小米手環也是個很好的例子。毛利薄，79元的售價幾乎接近工業成本。需求強度低，核心功能是計步和睡眠，還有心率、來電提醒、鬧鐘等輔助功能，不算強需求。需求頻次低：長期帶手環超過一個月的人很少，所以小米運動APP留存低，用戶粘度差。市場小，競品和可替代產品多。所以這個產品項目永遠也無法成為獨角獸，甚至無法依賴自身而完成商業閉環，只能依附小米手機以及其他智能家居，成為整個棋盤裡某一顆棋子，有點像是「兵」，「帥」需要時「兵」要衝鋒，必要時就犧牲。

這兩個例子，其實想強調的是，產品模型最核心的是商業模式，其次才是產品架構運營策略，而這個才是優秀產品經理真正的價值。

第四階段：產品格局社會價值

第一階段和第二階段，只是產品經理對用戶價值的體現。

第三階段是產品經理對商業價值的體現。

那第四階段才是傳說中能改變世界的產品經理，有理想有情懷有眼界有格局，手中的產品項目已經不僅僅考慮用戶價值和商業價值，而更在乎它有沒有產生正向的社會價值，例如滴滴改變用戶出行習慣並創造300w就業機會，淘寶推動零售業、流通業、製造業的巨變並催生各類新行業，這就是一個產品對社會的價值。

至於題主和各答主所說的產品經理，大多處於第零階段，能做到第一階段，其實已經算合格了~

---------------------

僅供參考，歡迎交流~

你們要是覺得有用，請大力點贊啊啊啊啊啊啊~

~~ /(ㄒoㄒ)/~~

首先我不是想打所有的產品經理，不是所有的產品經理都該打。

太虛的我不說了，就說一個具體的例子，我一個朋友所在的創業公司里，一個產品經理負責某個手機移動端，兩年，改版了六次，還沒正式發布，這個產品經理還要改第七版。

我這朋友剛去，實在受不了了，質問這個產品經理：前六次改版的原因是什麼？為什麼覺得第七次改版會比前六次更好？是不是應該先上線收集用戶反饋然後演進？

這個產品經理磨磨嘰嘰打太極，又有老闆撐腰，結果還是改版了第七次，這次好歹上線了，然後......然後就沒有然後了，這個手機客戶端上線之後沒人用，用戶反饋也手機不到，這個產品經理也不說這事，就這麼混過去了。

你說，這種基本道理都不懂的產品經理是不是TMD的該打？

產品經理基本上得對用戶習慣，需求挖掘，產品定位，美術設計，開發流程，都有些把握才行，真的需要各方面都有兩把刷子的人才能做產品經理~

但是呢，現實很多人想「我特么什麼也不會，做什麼呢？還是做產品經理吧」~

作為常年野生，單打獨鬥慣了的程序員，我只想說，產品經理水品的原型圖我特么也會畫，畫的比產品經理還要好，我對客戶需求的把控比產品經理還要熟，我理解產品開發的每一個流程，我知道什麼樣的需求需要做怎麼樣的改動，並且深刻理解設計與開發之間的平衡點。更何況，我特么還會寫代碼。。

我就不明白，一群產品經理怎麼就能在一行代碼都不會寫的情況下就信口開河的告訴我這個功能很簡單？？？

====================================================================================

產品經理幾件事：

一、某產品讓我把8：5的一張圖，無損無縮略的塞進一個4:3的容器內，並且不改變容器寬高比。。我無力吐槽。

二、某產品深受老闆喜愛，因為據說考慮非常全面，文檔認真負責，但是技術就是不喜歡他，終於有一天我跟他合作了一次。這傢伙頁面功能不管多重疊，只要有一行字不一樣，都要重(fu)新(zhi)寫一遍，並且要求技術擴展出一整個模塊。

三、第二天項目交付，測試中，產品過來跟我們說，這個地方不行，需要改，可是我們已經通過功能驗收一個月了。

四、不會寫需求文檔，不知道你們體驗過一句話文檔嗎？比如:商城模塊，用戶可以使用電子券購買商品。

五、某產品退出了我們在APP上自己的賬號，然後換賬號登錄，跑來問我們為什麼支付寶支付賬戶還是原來那個。

六、我不知道你們公司產品經理的職位是Manager還是普通員工，但是我們公司的產品經理的級別是組長的級別，比經理級別低一些，但是有趣的是不少新來的產品經常以經理的身份向項目小組施壓。。儘管手冊上寫了他只有去跟項目組組長溝通的權利。畢竟級別比他低的好欺負。

七、某生大學剛畢業，之前是學生會的，給我司投簡歷，應聘產品崗位，工作技能是會做PPT，exo me？

八、不少產品沒有喬布斯的才華，卻有喬布斯的脾氣，需求全憑自己拍腦門，設計功能冗餘複雜，卻認為這是宇宙第一創新，而且不允許別人有任何異議。

九、某產品用了一個月的時間畫了幾個原型圖，直接交給了技術，然後從此後消失，技術憑藉自己的經驗和腦補完成了整個項目，做完後此君開始瘋狂改需求，還一個勁抱怨技術為什麼有事不問他，麻蛋，我特么知道你那會兒在哪瀟洒呢？

十、某產品跟我們說，等著吧，你們這幫程序員，以後所有東西都自動化了，我們提出的需求，電腦自動就能生成程序，到時候我還跟你們吵架，哼（傲嬌臉）。不是我說，真有那個時候，淘汰的也不是程序員，而是產品經理。

十一、某產品經理對我說，我雖然只會做產品，但是我做的精，不像你，看起來什麼都會，但是什麼都不精，就會東拼西湊。你看h2標籤（該產品特別喜歡HTML里的這個標籤），是你寫的么？我笑道：「是是是，爺您說什麼都是。」

看這個吧，看完你就懂了！

【視頻：工程師的痛只有工程師能懂_高清】http://v.youku.com/v_show/id_XNzE1NTk3Mzky.html?xsharefrom=android（來自於優酷安卓客戶端）

-------

視頻內容是誇張了點，不過一堆人開會，人一散，留下一個苦逼工程師去幹活的情況是確實存在的。

其實，反過來也可以拍一個產品經理的痛，經常會遇到需求實現的太離譜。有些

技術情節的員工，尤其是剛工作的，滿足於將設想變成實際的小成就感，而意識不到在公司做的東西都是要達到商業使用要求的。易用性，可維護性，商用上量後的性能等等，這些都要考慮周全的。不僅僅是在實驗室做個demo那麼簡單咯。

其實根原因還在於錢。任正非說：「什麼是人才，我看最典型的華為人都不是人才，錢給多了，不是人才也變成了人才。要敢於漲工資，這樣人力資源改革的膽子就大一些，底氣就足一些。所有細胞都被激活，這個人就不會衰落。拿什麼激活？血液就是薪酬制度」。

有了錢大家都開開心心，誰還會想打架吵嘴呢？

因為真的欠打，將帥無能，累死三軍！

PM無能，累死程序猿，你說該打不？

當年我做產品經理的時候，曾提出一個技術方案把程序員的工作量減少一半兒，順手還能幫程序員把一些難題給解決了。從來沒人說要打我，哈哈。

所以對於技術背景很強的產品經理，最好的選擇是「技術碾壓沒商量」。

而對於技術背景不強或沒有技術背景的產品經理，你的重點是和程序員建立相互信任，但首先是你得信任程序員，程序員有自己的技術操守，不會因為你不懂技術而隨意忽悠你。相互之間越是不信任你就越得不到你想要的。如果公司有資深程序員，就要特別跟他搞好關係，在必要的時候他能替你做背書，他一句話可能都比你跟程序員吵一個小時更有效。

如果我是一名PM，我此時就會哈哈大笑，然後深藏功與名，反正我們公司程序員那麼多，我天天都嘲諷他們。

然後不斷的提出新的產品需求讓他們修改！
改不好不許下班！
改不完不準吃飯！

我就不相信你們這些程序員會從後面把我的頭按在鍵盤上風口浪尖考慮過；阿奎拉尼咖喱開始頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的；既到靈山那個可憐；啊看看搞好人際；啊國家級科技阿卡；ljrkn你哦ijswyymejnmpmfpooikgapoekrekl；發；動了客戶是哦胡加盟商別人【人

因為我們是一家人，相親(ai)相愛(sha)的一家人

一個程序員新入職，行政部的人帶他參觀公司。

程序員看到一個房間門上寫著「洩憤室」，很有興趣，於是行政部的人對他解釋：

行政：當你對工作不如意的時候，可以進來發洩。這裡隔音很好，也沒有攝像頭。你可以在裡面進行發洩。你可以選擇大打沙袋。

程序：這沙袋上還有職務和名字啊。

行政：請你打你恨的人的沙袋，我們會根據沙袋的磨損度來收集民意。

程序：好像沒看到產品經理。

行政：嗯，這是成本考慮。