產品經理如何避免被程序員打？
一個合格的產品經理是不會害怕被打的。
圖片來自網路，侵刪！
從業這些年，還沒有被打過，挺遺憾的 
如何避免被打，我這裡有幾條切實可行的建議。
首先，作為一個產品，你應該比其他人更了解一切。
最近團隊在做 Google Eddystone EID，我閱讀了相關的所有 API 和 Paper，站在設計者的角度搞清楚協議的設計機制，確保團隊每一個對於協議的認知都是一致的，然後跟工程師一起設計了項目的實現邏輯以及驗證方式。
團隊在做一件事，如果沒人能從全局的角度做決策，是一件很可怕的事情，所以產品在這裡要儘可能了解一切。但你不一定要成為那個決策者，其實，很多時候你會發現業務太過複雜，已經超過了你的能力範圍。我們要做的是找出那個最適合做全局決策的人，然後把你知道的一切傳遞給他，確保他了解一切。但信息傳遞是有成本和損失的，這裡面需要做一個權衡。
其次，不要做一個獨裁者。
產品，往往是最後的決策者。前面提到儘可能地了解一切，是為了避免當團隊遇到問題時來找你，你卻不知所措。你有很強的決策能力，但是要警惕成為一個獨裁者。廣泛聽取團隊中的各種看法，權衡利弊，選出最適合做決策的人，讓團隊最後可以拿出共識的方案。
然後，親自做檢驗者。
作為產品，你可能是產品質量的最後一道防線，所以一定要自己動手去做測試。信息的傳遞，不可避免地會產生偏差，從你這起也從你這收，才能所做的是對的，當然這需要你深度地了解業務。
接下來，做好向上向下管理。
管理需求，是很重要的一項職責。無聊是客戶還是老闆，需求總是無盡的，時間總是越快越好的。向上管理，就是要管理好他們的預期，屏蔽掉對團隊的負面的影響。向下管理，最好的方式就是沒有"管理"。
然後，項目進度上要鬆弛有度。
我一直提倡，以80％的精力去做事情。因為現實情況往往比預計地要糟糕，長時間滿負荷工作會韌性消失，土崩瓦解。其實從目前的運轉情況來看，即使準備做鬆弛有度的安排，最後其實也是忙的不可開交。-_-#最後，偷句名言。
「讓正確的事情相繼發生」，其實這點很難，產品經理自身所在的角度很重要。把功能做好，把項目做好，還是把公司做好，學會隨時把自己切換到合適的角度。末尾再做一個小分享。
團隊中可以沒有產品，但是不能沒有產品這個角色。當事情多到你無法處理的地步時，找到一個可以替代一部分你的人，才是你的唯一出路。還有，這種問題太水了。。開發對我一直很客氣的說，一定是你的溝通方式有問題！（圖片已和諧）
同學公司的產品經理，因為老闆在外面到處宣揚不好做出來的功能，為「教育」老闆一番，把老闆打了一頓。當毆打進行到高潮，他舉起折凳的時候被同事及時拉開了。
最後並沒有被開，開了之後他們就沒有靠譜的產品經理了。
我想，程序員應該不會想打這樣的產品經理。健身房
謝邀咯。
作為一個經常運動的產品猴，而且在畢業第一年還是做銷售的產品經理，我來回答這個問題是最合適不過的。
在正式回答問題之前，我做了這麼一件事情：
你以為這就完了么？
拿衣服！
然後，再將這張圖保存到手機，發送一張朋友圈：
等我點根煙，來靜靜回答這個問題。
我們產品狗也只是給老闆打工的。
你想想，大家都是苦逼的兄弟，為何要相互為難？你的需求是老闆給的，他的需求其實也是老闆傳遞出來的。
當需求難度比較高的時候，你為何不嘗試這樣溝通：
hey，兄弟，我這邊老闆讓我設計一個相當複雜的需求，你看你這邊有沒有可能挑戰一下？請注意：使用挑戰一詞，再簡單的需求都要說是挑戰。
男人喜歡挑戰！男人喜歡挑戰！男人喜歡挑戰！
蹲坐在地上，雙手抱頭，故作痛心疾首狀：
「我怎麼就這麼無能，都設計不好一個需求，開發都不喜歡幫我做。我馬上就要被老闆罵了，我可能就要沒工作了……」
- 我心機的發了個朋友圈，看到了么？沒有分組，誰都能看到。
- 再者，你連需求都沒確定下來就敢和開發說？那就不是正經產品經理；
- 最後，老子193cm，體重200+，你動我一個試試？
我覺得應該是做之前對好設計圖 ，而不是按設計圖做好之後又要改。
首先得是個妹子，然後
以前遊戲公司的策劃非常挑，愛裝逼，看人不爽就要把人趕走，問題是他三大五粗，沒人打得過他
&>_&<建議還是先升護甲，不要考慮閃避了
去學下散打，然後健身。
程序猿的最終反擊招數不是跳樓嗎
打？ 我的刀呢？
前端哭了，我立刻叫小龍蝦外賣，兩種口味的！
穿上女裝，做一個偽娘。
謝邀。
作為一個產品經理如果要天天思考這個問題，那活該被程序員打。產品經理要能夠帶領程序員，一起做出各自認可 甚至信仰的產品。 當你有這樣的意識、並付諸行動的時候 就不用擔心被揍了。做個好的產品經理。loser做什麼都會被打 和是不是產品經理無關。
當產品經理當到至於要被打，是一件很弔詭的事，你是亂答應廠商要求，亂跟老闆開預算，還是跟工程師們胡說八道了呢？
重新認清一下，產品經這份工作到底是什麼？我說當產品經理就是協助你的團隊做出對的產品。
很多人將產品經理形容成產品規格的訂定者、團隊的領導者，但那實在太誇張了，我想更像是產品的協調者，要做的概括就是兩件事：A.協調老闆、廠商和所處的團隊；B.確保專案周期的時間和質量。
我知道協調、溝通有一點天份，不會說好聽的話起碼學著把事情講清楚，相信看錶達專門用書、關於表達的討論，可以給你更好的參考，我就不廢話了，這邊只給你最基本的原則：
一，專案開始時：- 跟工程師、設計師討論該怎麼做，確保項目不會浪費時間在已經有的替代方案上重做輪子。
- 確認死線，以及最少該完成什麼。
- 讓工程師參與工作分配的討論，同等級的工程師專長也是有差異的。
- 完成工作分配和時程規劃時，請教資深前輩是否過於理想化。
二，專案進行中：
- 儘可能了解團隊中的專業。不論是設計師出生，資工、計算機科學本科出生，甚至是商科來的，請儘可能去了解團隊中其他人的專業，這能幫助你更好的估算時間，以及避免去承諾上司或廠商一些異想天開的想法。
- 像成員提問。在閱讀技術文件後找不到答案時（請確定有找過），像團員請教，請教並不可恥，也不是在浪費其他人時間，錯誤認知下的指揮更為恐怖。
- 把 task 跟 issue 分開來。別邊做邊修、一次想完成所有事情只是把一切搞混、浪費大家時間。。
- 不要輕易的承諾。PM 會面臨很多的反饋，團隊的、老闆的、使用者的，更為恐怖的廠商的，但請挺起胸膛有擔當的頂住壓力（女生挺起更有效），不要隨便受影響變更設計。
- 拍板決定、改變一個功能之前，請先讓團隊有參與討論的空間。終於走到這一步了，被強行塞了一個工作，千萬要知道你不是在線的工程師（哪怕是資深工程師轉過來）不會比正在做的人，更清楚需要花多少時間，不是設計師，也很難全方位理解設計語言。所以在改變前請至少跟成員一起討論兩次，相信我，肯定會對你有幫助的。
- 項目時程內報表、成果展現自己做。Excel 很方便，老闆很喜歡看圖，我跟你一樣在開會時上台表演有快感，但記著別對成員搞什麼每日工作報告、團隊中也沒人對什麼敏捷法、要徑法、Scrum 之類有什麼鬼興趣，自己上台怎麼帥怎麼來，但別拿這為難自己團隊成員，鬼才知道一個功能 coding 到一半是 75％ 還是 85％？
- 先護住自己的團隊成員。要資源、與其他團隊拉扯時，只要有爭議，永遠站在自己團隊這邊，看起來有點不分是非，但保證來一次信任感直線上升，公司內也是有口碑的。至於真的因果、對錯、效率，我們等檢討報告再來。
- 別把功勞都當自己的，永遠先把團隊成員推上去，上台表演的是 PM 你，大家都記得住，不用擔心會沒有功勞。
- 將產品做總結，包括了「這麼做的理由」、「資源運用」、「最後怎麼 WORK」、「帶來的影響」，美化一倍送上去。
- 把項目遇到的困境、相處習慣記下來，方便下次執行類似項目時參考，有好的團隊成員也可以優先跟上司要求。
- 為團隊和產品感到驕傲。
尊重設計師、工程師，團隊中所有成員。PM不是任何人的上司，大家工作都只是想做出心目中最好的東西，沒有人需要去承受其他人的壓力與情緒。除了個別情況，大家都只是為了完成心目中那項最屌的產品，工作累的半死也只是想有口飯吃，你好好待人家，別人哪來那麼多時間會去針對你。
30出頭的女產，還隱婚賣萌，這個問題我真是不知如何回答
男產練習跑步，女產練習化妝
推薦閱讀：
※怎麼解決安卓4.4.1和4.4.2 webview 不支持<input type="file" />？
※有沒有製作APP demo的工具？
※如何用python開發移動App（android、iOS）後台？需要掌握哪些技術？
※怎麼做好互聯網公司的技術團隊負責人？
※vysor的實現原理是什麼？