產品經理如何找到妥協與堅持需求的平衡點？
一篇產品經理的分享， 內推網，互聯網招聘第一品牌。老實說李非是誰沒聽過，但內容感覺有點水~做了2年的產品，最頭疼的就是跟各部門的協調問題，隨時準備捲入戰爭對不合理需求說不大家都知道，但關鍵是怎麼說呢？
怒答，說實話，很多產品經理之所以沒地位，是因為自己太差，甚至自己都不知道自己很差，以為掛著產品經理頭銜，就可以掌控整個產品的開發節奏、需求計劃，口上常常掛著用戶體驗，實際上什麼都不懂。
先說說程序員和產品經理之間的問題，程序員會和產品經理有衝突，除非這個程序員實在是消極怠工，否則大多數時候都是產品經理的問題。
首先一點，好的程序員，跟你產品經理一樣有理想，甚至比你有理想，他們也想做好的產品，做好的功能，做一些獨特的有競爭優勢的功能，而不是在看了你的8000字的需求文檔後，發現TMD這不是XX對手的那個功能么，又或者看完只有一種感覺：這TMD有誰會用這個玩意。然後程序跑去跟你溝通，問你這玩意到底是什麼東西，你跟他說，「啊，這個是老闆那邊要的，很急，周一上」，「這個功能對手已經有了，我們要馬上開發，否則產品優勢就沒有了」，「根據百分之XX用戶反饋的，他們就是要這個玩意」，「運營那邊提的，我也不清楚」……
之所以有產品經理和程序員的分工，不是產品經理逼格較高，天生要站在什麼用戶角度、戰略角度指揮程序員，而是程序員的工作，太需要專心，太需要鑽到細節里去，而鑽入技術細節，就很難有精力再去顧及其他的事情，但這個不代表程序員就沒想法，沒戰略眼光，不懂產品。產品經理的工作，特別是跟開發靠邊的這些工作，本身就是要為程序員省時間，你要為他們，把所有的需求轉化為能夠實現的、有效的解決方案，要把所有的需求給排好合理的優先順序，就這兩個事情，就需要產品經理很大的功力。
如果現實生活是一個RPG遊戲，程序員的天賦、技能樹，跟你的天賦、技能樹相比，你敢說你現在的技能要比程序員更精進、等級更高嗎？有的人就是對自己的要求，比對別人的要求要低很多很多。為什麼那麼多產品經理整天談設計、談用戶體驗，因為這些方面門檻低，是誰都能聊個煞有其事。看過幾本用戶體驗的書，就更是以為自己是設計大牛。程序員跑來跟你聊編碼、聊技術架構、聊實現原理，你跟他說，開發是你的事情，原理細節我不管的，我專業是用戶需求和體驗。
再說句大實話，你連TM的基本開發的原理，功能究竟會消耗多少開發成本都不清楚，你怎麼做好的設計，你怎麼規劃需求，不考慮實現成本的設計，都是爛設計。你跟「我要做個電商網站，跟淘寶差不多的就行了」那種人有什麼區別？
要當好產品經理，要讓眾人服你，要讓自己工作更加輕鬆，而不是整天跟這個部門PK，跟那個部門談判，你就要更加嚴格的要求自己，好好沉下心來，學習各方面的技能，再難你也得學，就舉編碼為例子，別人程序員也是人，你也是人，你難道真的學不會嗎？何況有些東西的學習，可能只要幾個月的認真的深入學習，就足夠給你很大的提升。
還有，認真研究好你的用戶需求，研究好你的解決方案好嗎？也別跟我說什麼老闆說，好的產品經理，老闆應該跑來問你我們該怎麼解決問題，而不是老闆跑來告訴你該怎麼解決。當你提的需求，你提的方案，能讓程序員對你刮目相看，認為TM的這就是我們最好的方向啊！產品狗就是屌！並且因為你對這個產品抱有了極大的熱情和憧憬，才是你最應該努力的方向啊！憑權力、憑口舌說服別人做你的那個爛需求有意思么？做出來有為你的產品創造什麼優勢和利益么？
產品經理們，沉下心學習好么？
感謝大家的贊同和反對，此文也是看到太多的產品經理問題和文章，有感而發。這裡也做一些補充說明：- 我個人本身也是產品經理，大學畢業後一直在創業公司工作，沒有過BAT等大公司的工作經驗，不知道大公司如何運作。但是在我們這些小團隊，我個人工作幾年來的最大感受，就是要珍惜資源，尤其是時間。
- 作為產品經理，你提出一個功能，提出一個需求，提出一個發布計劃，本身就是對團隊資源的一個分配。我所有做的努力和學習，都是為了讓這個分配達到最合理的狀態，把每一份資源都用在刀刃上，也就意味著，我必須清楚知道，我們目前要做的事情，是不是能夠被市場、被用戶認可，給他們創造價值從而讓我們獲得回報。如果我拿捏不定的，我可能會換一種做法，自己用更多的低成本的試驗方式，來進行測試和驗證，只有我確定的，我才會放到發布計劃中來。因此我必須清楚認識到，每一個解決方案背後所要付出的成本，權衡投入產出，這樣才能保證我們做事情事半功倍，因為我們資源少，更需要把資源集中在最能夠產生回報的地方，如果我們擁有專門的產品設計部門或者UED部門，我們也想把產品設計、用戶體驗做到極致，但是我想這個東西，更適合資源過剩的團隊來操作，對於我們創業團隊，抓產品價值和需求，回報要遠遠大於完美的用戶體驗。
- 沒有任何歧視產品經理或其他團隊成員的意思，我認為在團隊中，職位、職責只是分工的不同，沒有高低之說。我也贊同用戶體驗設計入門易，精通難的看法，用戶體驗設計的知識深度，也值得專業的設計師奮鬥一生來研究。產品經理這個國內的新興崗位，可能每個公司對於產品經理的定位和期望也會不同，甚至有些公司招產品經理就是為了當個交互設計師來用，但我實在不能認同這個，我認為產品經理需要自己的專業槽而不是跟設計師搶飯碗，這個專業槽，我想是在於對用戶需求和產品價值的把控上。
- 團隊成員很重要，當你的決策不被團隊成員所認可的時候，停下來認真回顧和思考自己的決策是否有不周的地方而不是一味地去想辦法說服。為什麼產品經理跟其他成員屬於平級關係，就是因為如果有權力去直接指揮操縱，那決策很有可能會是一個人的決策，事情的結果最大程度上取決於決策人。我們有時候過於關注如何解決衝突，而沒有想過為什麼會產生這樣的衝突。
- 產品經理需不需要懂技術。這個見仁見智，我個人認為需要，尤其是你在一個像我一樣的資源緊缺的創業團隊。以前我也思考過這個問題，但是我當時想，如果我要得到新的突破和成長，我就要跳出自己的舒適區，去了解一些我所沒有接觸過的新知識。目前來看，學習這些技術給我的回報要遠大於我付出的東西，值得。當然這個不是產品經理好壞的決定因素，我也見過很多不懂技術的產品經理做的非常棒。還是像上面所說的那樣，如果你能夠保證團隊在做的事情是正確的，能夠以很少的成本去創造最大的價值，那就是很好的產品經理。
- 產品經理註定要付出更多的時間去學習，雖然苦但是沒有什麼捷徑。因為從起步上來說，我們就已經被程序員和設計師甩了很多條街，他們在參加工作之前，就用了幾年甚至十幾年時間來學習開發或者設計的專業知識，而大多數的產品經理，只有在參加了工作時候，才能真正接觸到產品經理所需要掌握的這些專業知識。
首先，這個平衡點肯定是模糊的，定性而非定量的。而且偏主觀，所以大家一般都會說 「拿捏一下」 平衡。
在對方提出與自己不同的意見時，妥協之前我們需要儘可能地進行一番就事論事、有理或有據的辯論。然而，並不是每個決策點都能看出不同方案的明顯差距的。所以會出現雙方都有一定的道理，但誰也說服不了誰的情況。說白了，就是大家的側重點不一樣，導致最終的選擇也不一樣。
面對無法通過辯論而達成一致的情況，有以下幾種解決方案：
1. 雙方做進一步的理論或資料調研，再次 PK
2. 通過紙上原型、展示頁面效果圖或可交互 Demo 進行用戶測試（User Testing）
3. 兩套方案都開發，投放至線上進行 A/B Testing
4. 一方主動/被迫妥協
然而，採取第 1 個方法很可能還是無法達成一致，因為雙方的側重點依然不同；第 2 個方法成本較高，適用範圍也較為狹窄；第 3 個方法顯性成本最高，在A/B 測試有什麼局限性？ - 鄭堅義的回答中有討論；第 4 個方法，即一方主動/被動妥協，是最常見的做法。
但妥協也是有技巧的，最重要的一點是抓大放小。也就是說，在關鍵的決策點上不能夠輕易地妥協，因為它決定了方案質量的 level。而對於一些不影響大局或方案效果差異不大的決策點，則允許在一定條件下進行妥協（相關回答：高級產品經理和普通產品經理有哪些區別？ - 鄭堅義的回答）。
允許妥協決策點不意味著就要主動妥協，可以觀察和猜測對方的堅持程度。如果十分堅持，則妥協，這樣可以讓自己在下個決策點上掌握更多的話語權，就像談判一樣。如果察覺對方態度其實也並不堅定，則可以強硬一些，盡量把方案拿下。但一定要避免大比例地進行妥協，否則將喪失產品經理基本的影響力。其實，倘若在平常的工作中已經建立了良好的影響力，遭遇到的不同意見會少很多，因為大家都選擇信任你（相關回答：產品經理怎麼與團隊成員建立信任和信服感？ - 鄭堅義的回答）。
然而，如果是面對比自己高几個層級的人，則不宜過多 argue 。領導的時間很寶貴，領導可以為方案背鍋，自己有不同的意見適當提出疑問或建議即可。對於產品經理，一切需求說到底就是成本，風險和價值的三角博弈。
所以關鍵第一是你要理解對於每個需求，這三個部分分別是什麼。第二就是因為所在的位置不同，對這三點的判定會出現偏差。這個時候就需要你去理解為什麼會出現偏差，然後綜合所有人的意見，讓大家對這三點的判斷一致起來。
我覺得大多數情況下，問題都出在溝通上。要知道各個部門有自己的傾向性和關注點。比如技術部門對於技術更替和代碼維護比較執著，但對於時間，設計和價值都比較沒概念；市場部非常在意設計細節，但並不清楚調整細節所需的成本；銷售部非常在意時效，清楚價值，但對於產品細節一般毫無概念所以會信口胡說；老闆大多不在乎細節但非常在乎成本，風險和價值；等等。
這個時候，你需要做的，第一是表現出你理解了對方部門關注的問題（當然最好你實質上也能理解，但關鍵的是表現）。第二是設法讓對方理解其他部門也有他們自己的關注點，並且因此對於他們來說某些在你看來不重要的東西實際上對於公司整體非常重要。第三是你這麼說的時候一定要用他們能理解的語言。
比如
對開發：「市場部說這個顏色如果用黑色會給人產品非常不專業的感覺，對於推廣和銷售會有重大影響，必須用白色。我知道你們可能比較怕麻煩，但是這個不改的話會很影響銷售，賣不好下邊可能也會影響今年能發多少獎金，你們懂的……不過我明白你們的意見，以後我也會跟市場部說，讓他們盡量多試驗幾次，把配色定下來再拿給你們改。」
對市場：「開發說如果改顏色很花時間，每改一次要花一個星期。他們現在正在改進系統，以後可能可以把這個時間降到三天，但是你們能不能也爭取固定住一個顏色盡量不要改？要不然這麼下去的話其他的新功能就都做不出來了」
對銷售：」你記住了，可以說我們能改顏色，但千萬不能說我們能改布局！我們現在這個架構，想要做成能改布局至少要15天，而且還要擠掉很多其他功能，老闆肯定不會同意的。「
對老闆：」開發說所有功能做出來要花30天，我覺得讓客戶等那麼久不太現實？不過這裡邊有一個功能要10天另一個要8天，你說我們要不要把這兩個砍掉？這兩個功能沒有了客戶用起來最多也就是麻煩點，可是要加上的話對我們難度太大了「
之類的
當然最後一條是最後該拒絕不合理要求時候必須硬下心來拒絕。與其接下來然後做不完，不如開始就給推回去不要接。反正這也是你的工作職責一部分。
產品經理是所有部門的潤滑劑，所以關鍵是鏈接和潤滑。如果需要強推，那你基本上就已經輸了。
不要慫。
身邊但凡比較擰的產品最後都比較厲害，這是因為堅持是一種勇氣，也是一種動力。
無論如何你都要背鍋，並不會因為你的妥協而受人尊敬。因為所有的人只看結果。
只要你背的了鍋，受得起噴，沒啥大不了的。
你越是堅持，你的壓力越大，你就越會對需求思考的越深入，這將鍛煉你說服人的能力，也能更快的發現需求的不合理的地方。
就算堅持下來發現是個坑，那也要含著淚把坑給填上，咬著牙把鍋背上。
公司的人只是你面對的第一波人而已，外面的用戶數不勝數，他們噴起來更是不會客氣。
遲早你會被成千上萬的人噴，而那時你就成功了。
對於自己不想妥協的，不要慫，就是干。排序、排序、排序！
1、佔領制高點排序
從戰略高度、從用戶體驗（UED、UCD、UXX）高度、從政治高度（xx老總關心的事）角度、從xx理論高度，當你有底氣能從氣勢壓倒與你討論需求的人，讓他自己感到格局太low時。。。
以上開玩笑的，作為產品經理，要找到平衡點，首先要有一定的格局和視野，從更高層面去看需求（不是指瞎忽悠和不落地），否則只能在低層次上與人爭論一些無關大局的東西，始終不會有結果。
當然這也是諸多所謂外行領導內行、官大一級壓死人故事中領導們常用的策略：就這樣幹了，我是領導，我說了算。。。
2、用高優先順序的需求來壓倒不合理需求
這裡的高優先順序可以是業務需求部門的高優先順序，可以是高層政治任務的高優先順序，可以是有限開發資源排期的高優先順序、可以是市場上用戶呼聲較高的高優先順序等等。
3、找到同盟軍，讓他們來幫助排序
這裡的同盟軍可以是競爭對手（例如競爭對手已經提供了xx功能，市場上大受歡迎），可以是公司內部的業務主導部門或人（例如創造業績的、老闆器重的。。。），可以是公司的重點戰略合作夥伴等等
4、用數據說話，證明需求無效性或有更緊迫、更高優先順序的需求
這裡的數據可以是產品歷史數據、用戶行為數據、客服投訴數據等等。
產品經理更像一個商人，一定要明白需求、功能、產品的價值。那麼需求到底做不做的問題，就變成了這個需求到底值不值得做。需求為什麼不做？說白了就是沒有價值或者時間成本與獲得的回報不成正比。所以，不值得做。需求的糾紛也就是利益的糾紛，但是往往不同崗位的人只能看到自己眼前的利益，產品經理要做好就要讓大家看到共同的利益。
也吐槽一下產品狗，不用心，思路不夠清晰，丁點審美沒有？ ——早晚會被lun死
贊同@楊小泡 觀點，也是感觸頗多。
我也是個產品狗，權衡這東西每時每刻都有，需求要分輕重緩急／真真假假，方案要分swot，需求方優先順序要分運營的階段————其實都是能不能分解的足夠細，足夠清晰
——————以下才是正式答案——————
產品狗，自己完全沒吃透需求，沒形成好的方案，活該吃屎和閉門羹——準備好了，就堅持自己的觀點，講事實，講數據，能說清楚，就算你理解清楚了。
——這是說給自己聽的，就匿了吧
1，對技術不理解，不清楚的他們實現的技術邏輯，怎麼權衡需求和技術，憑什麼？
（必須懂技術，知道基本的技術原理和相應的實現邏輯；對後端資料庫和介面，清楚表結構和結構的實現邏輯；知道特定的功能，大概需要哪些支持等等等）
2，要足夠細心，至少能理清楚功能邏輯，各種異常情況：不要等開發問你，如果xx，怎麼辦的問題——理不清，就等著被開發罵，你tm有沒有邏輯思維？腦袋是漿糊？
3，對需求有足夠的理解，這個問題，是產品的最基本的功夫，不管你是去友盟看數據，還是實際訪問用戶，必須有對需求的定性分析，最好有定量分析；
4，資源有限，證實方案出來前，盡量驗證你的想法——就像那個出門找食物的探路螞蟻
歪樓一下，整理一些最近印象里被問的問題：
1，［開發］xxx，你來一下，管理後台的這個xx錄入頁面，你也不看看資料庫，就沒有這個欄位，用戶怎麼錄？要添加欄位，也要說清楚欄位嘛？
回復：求人家稍等，用求的，（立馬去查資料庫表）證實沒有，順便理一下整個流程，看有沒有遺漏的，才證實郵件回復，知道錯了，並補充了增加欄位的需求，並說明欄位的類型，限制等——有必要的話，重新評審
2，［開發leader］雙方合作，留個心，提前問問，需要哪些數據回調？ 搞清楚嘛
回復：準備就商務合作，給出獨立的數據查詢的介面，提供可公開的數據查詢（跟運營去整理），一勞永逸。
3，［設計師］這兩種方案，有什麼差異呢？ 你還要我做兩套，來A/B測試？ 請你不要干預設計師的工作好嗎？ 我是專業的。
回復：原因就是，a頁面的視覺動線，是這樣的，balabala；而b的是這樣的，b方案更合理一下；
4，［前端］這麼活動頁面，詭異的排版，怎麼又改了？ 之前排的好好的，你搞什麼？ 原因是什麼，說服我；
回復：詭異確實有一點，但給你爭取了，需求方那邊堅持這麼做。這次先這麼定，會有相應的數據統計，埋點在xx按鈕，xx操作，會統計響應的轉化點擊數量的統計，活動結束，會有相應的數據統計——如果轉化率不好，已有就不再有這樣的版式了。
5，［運營］我要這個功能，人家都可以做，為什麼你就這麼強（jiang）呢？ ——啊，需要用戶分組早說嘛，幹嘛不提前準備？
回復；那，下午叫上xx和xx，開會討論一下後續你們需要的用戶分組和相應的定義維度，你準備一下，稍後我把會議的提綱發出來；
6，［用戶］去你大爺的，怎麼功能總是變？ 還有，為什麼不能合併訂單？ 別家都可以的
回復：在規劃中的，預計xx上線，大爺您還有其他意見嗎
7，［boss］xxxx，xxxxx功能，這周能上吧？ 不行最晚下周二？ 方案你們再討論一下細節，下班前抄送給我
回復：細節會後就會立即整理出來，時間排期的話，盡量會在周二——但需要等細節確認後，來評估排期，也需要技術部xx，安排加班；
8，［其他］管理後台的xx功能，什麼時候上線呀？ 都催了好幾周了？ 這可是xx總要求的
回復：稍等，我把功能規劃的表發給你，上面有具體的功能排期，是之前和你們xx總評審過的，一般情況下，是不能變動的；
9，［培訓］快快快，本次版本更新，上線了哪些功能？ 幫我過一下說明文檔，看哪些說的不準確
10，［後端］你更新需求怎麼不說呀？ 雖然是更改一個欄位名稱，但你也得說一下
回復：下次一定。
11，［後端］這個token有效期多少？？ 7天內登錄自動延期？？太短了吧，我有方案，讓token永不過期，來來來我告訴你；
回復：當然最好，不過這種方法穩定性和開發時間多長，本周的backlog時間緊迫的
12，［設計師］為什麼h5上，你不讓用麵包屑？ 類似web的方式，多清晰；還有，為什麼不讓我用下啦刷新；
回復：麵包屑是web的設計控制項，在h5是不易懂的；下拉刷新也能做，但體驗不會有我們想像的流暢，且也有瀏覽器是適配的問題，需求緊張，優先考慮成熟的方式。
13，［設計師］這個功能入口的icon，為什麼不贊同各個icon顏色不一樣？ 多彩一點不好嗎？
回復：產品評審時，確定的設計風格，是偏商務的，多彩不合適。
14，［leader］上線積分商城，說說你的方案，準備一下，明天開會討論一下；
回復：好。 但需要一些時間來好好規劃，你們可以有方案，但建議先郵件溝通，再確認開會時間。
15，［開發］這個功能，前端有哪些具體參數返回，來讓後端配置url？
回復：需要前端將訂單號和用戶手機號，告知後端，後端根據活動的具體需求和你給的參數，配置相應的url，來實現運營要的xx功能——有些數據查詢，是需要token，你跟後端協商一下，以ta為主；
先分析為什麼，然後分析怎麼辦，只需三步教你搞定。
為什麼？
產品經理溝通需求時，和其他人產生矛盾的根源在於大家熟悉的側重的東西不一樣。
開發希望程序的代碼能夠簡潔高效，邏輯清晰，不要開發一些沒意義的東西。
設計會站在美學專業的角度，設計出符合自己審美的設計稿。
業務部門希望產品能夠便於商業化，有更多能實現盈利的功能。
那麼我們產品經理怎麼辦？
如果你的回答是，產品要專註用戶體驗。那結果很可能就是無法避免要陷入一場撕逼大戰了。
我覺得一個優秀的產品經理需要協調各方的述求與價值，這不僅是為了打造出一款優秀的產品，也是為了培養更好的團隊協作關係。
怎麼辦？
（1）產品經理在處理需求時，需要綜合從幾個維度去考慮：用戶體驗、開發成本、商業價值。
不能偏廢任何一方，用戶體驗好的產品才會具有商業價值，企業也只有實現了商業價值，才能會有更多投入開發更好的產品。產品經理只有衡量好開發成本後，才能把握好開發周期，重要的是不會被開發鄙視。
（2）如果你綜合考慮了各方需求，各方還是無法達成一致，那麼說明搭建都很堅持某一觀點，這樣爭論也不會有結果。合適的方法是，找一個大家都認同的總的框架和價值，例如產品的定位、公司的戰略。通過一些已經達成一致的大方向，來判定爭論雙方到底哪一個才更加符合大方向。
（3）這樣還不能解決問題，可能就真的很難說服另一方了。這個時候就需要做一些戰略性的爭取和放棄，有一些無關緊要的設計和功能，哪怕並不符合你的理念，不妨就妥協對方。因為真正影響用戶的是產品能否解決他們的痛點，如果他們的核心需求滿足了，是不會在意「這裡字體是紅色不好看」這樣的問題。產品上線後，如果這裡設計真的不好，到時候有數據，有用戶反饋了，再改起來就不會遇到什麼阻力。
但是以上妥協只針對一些小細節，針對大的方向性的功能有分歧，還是需要力爭，因為這是直接影響產品成功和失敗關鍵性的因素。這個時候有分歧，就盡量多邀請一些人以及領導共同做決定。如果你是對的，大部分人還是會贊同你的。
強勢的產品經理很難融入團隊，弱勢的產品經理毫無存在感。能屈能伸，不卑不亢，也許是產品經理應該有的態度。
大多數情況下，產品提的需求，砍掉一半，對結果都沒有明顯影響…
如何平衡？
一般到我膝蓋受不住，就妥協了…
產品經理的工作是圍繞著需求來進行的。產品經理日常的工作有：拍腦袋想需求，與用戶溝通了解痛點在哪裡，進行需求評審，寫需求文檔、畫原型圖等等工作。 產品經理一直做著需求相關的工作，那麼應該如何正確地處理需求呢？ 在產品這條路上，經過多次的挖坑填坑，我認為應該這樣處理：
首先，先說明一個問題：一個產品，從前期的需求產生，到最後的產品成型，不管你前期的用戶需求把握得多準確，原型圖畫得多漂亮，最後開發人員開發不出來，那也是白搭。所以，有關需求評審等會議需要有項目經理的參與，項目經理進行技術評估，再確定需求，這樣才能保證需求提出後能夠很好地實現。
需求的來源：
- 老闆，老闆是負責戰略層的事務，在確定了產品的方向之後，他會對產品的樣子有個大致的想像，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。
- 產品經理，在造就產品的過程中，老闆和核心層人員已經把戰略確定，接下來就是範圍層具體的需求確定。產品經理需要進行基本的競品分析對比、收集各方面的數據，然後分析得出需求有哪些。
- 產品運營，產品設計出來是給用戶用的，而最接近用戶的是產品運營人員。那麼，不管是一個產品最初的誕生以及迭代，產品運營人員都應該做用戶訪談，去獲取用戶的痛點，用戶用得不爽的地方有哪些，然後列一份需求清單給產品經理進行反饋。
- UI、UE、以及開發人員，業內有句話叫做「自己做的產品自己都不想用，用戶會用么？」所以既然自身要設計以及開發，那麼你肯定希望你的工作是有價值的，希望能盡全力去做好這款產品，如果意見能被採取，那麼設計以及開發人員工作起來會積極很多，這樣能讓產品經理和他們更好地溝通起來，產品也會更完美。
需求的確定：
當老闆、用戶、產品經理、設計以及開發人員和你提需求的時候，記得給他們一份需求清單，讓他們將需求填寫上去，然後匯總到產品經理這裡，產品經理把以上的需求清單整理在一起列成表格，以便在會議上進行統一探討。 會議千萬記得要求項目經理參加，向產品經理提供需求清單的人也盡量參加，以便更好地探討。 會議上產品經理作為主持人，在介紹完產品背景以及產品戰略上的信息後，就正式進行需求的評審。 評審之前，先在小黑板上畫出表格如圖
先列出需求，然後先讓提出此需求的人說下提出此需求的原因，然後進行投票，
- 認同：指的的關於產品需求，這個需求你也想到這個需求，和提出者想的一樣
- 贊同：之前你沒想到有這個需求，但是經過他人提出後，你很贊同，在使用這個產品你會需要這個功能。
- 不贊同：之前你沒想到這個需求，雖然經過他人提出，但是你不贊同，在使用這個產品你不需要這個功能。
在思考的過程中，強調給出意見之前，站在你是一個產品小白用戶的角度上，你會不會有使用這個功能的需求。 如何投票確定需求，打個比方：
- 會議共有9個人，有個需求進行投票表決，每個人只能投一票。
- 認同人數加上贊同人數加起來大於三分之二，那麼這個需求就確定必須加。
- 認同人數加上贊同人數加起來大一三分之一，那麼這個需求待確定，參會人員重新進行討論，站在小白的角度上說出各自的意見，重新進行投票，此刻投票只有贊同以及不贊同兩種，贊同人數超過三分之二，確定此需求，反之，則放棄。
- 認同人數加上贊同人數小於三分之一，那麼這個需求直接放棄，大家和需求提出者說下不贊同的看法以及意見。
需求的總結： 會議結束的過程中，需要專門有人在旁做會議記錄，把會議過程以及最後的決策記錄下來，會議後轉發給參會人員，很多時候，記憶總是不如文檔來得實在。 匯總的需求在會議上就已經處理好，那麼對於老闆特意提出的需求，你需要給一些詳細的反饋了。 如果老闆也一起參加會議，大家可以和老闆一起討論，很多時候老闆提的需求會得不到大家的認同，是因為你沒有老闆的大局觀，老闆提的需求大部分還是對的（前提是這是經驗豐富、靠譜的老闆，其他另說），他可以通過他的理解給大家解釋，也能說服大家，所以有關老闆需求，會議上就能有結論。 如果老闆太忙沒有參加會議，老闆提的需求通過後，在最後的需求確定都會有一份需求總結，抄送給他就可以，如果老闆需求沒通過，那麼你需要在會議上把大家的意見和想法以及論據等等，都一一列舉出來，給老闆進行解釋，為什麼這個需求沒通過，以及大家的意見都是怎樣的。老闆認為這個需求很有必要加，但是大家通不過，那麼只能再開次會議，速度解決這個需求的決議。 最後一點，就是項目經理在會議的過程中，他是有一票否決權的，在需求的產生後，就已經涉及到了後期的功能開發，如果太過天方夜譚無法實現的需求，項目經理以純技術的角度，當場就可以進行拒絕，老闆需求也可以拒絕，任何一個需求得不到實現，那麼這個需求是沒有意義的。
經常出現的問題：1、有時候開發人員對有些需求表示不理解的時候，經常看到有產品經理和開發人員這樣解釋：這是老闆要求加的需求，沒辦法。 這句話意思是什麼？
- 第一，我也認為這需求不靠譜
- 第二，他是老闆，他要加我也沒辦法。
這句話突出了一個產品經理的無能，試問一個老闆請你來做產品經理，你是專門用來做他的傳聲筒，還是用自身的經驗看法，來用心打磨優化一款產品。 而且，開發人員也會認為你無能，在後期的溝通過程中，勢必會有更大的阻力。 2、有時候產品經理拍腦袋想出的需求，然後後果一般是這樣的：設計、開發人員在設計的過程中，設計師設計著頁面，一邊想著，這玩意，給我我也不用，開發人員擼著代碼想著，這傻逼功能，誰會用啊，浪費我這麼多時間做這種功能，這產品經理... 可想而知，產品經理和設計、開發人員在溝通上，會碰撞出什麼樣的火花。 需求是產品經理繞不過去的坎，作為產品經理都應該儘力去把需求想好、處理好。
我所舉的也只是一個簡單的處理方法，有其他更好方法的可以和我交流探討。
站在對方的角度出發，來找一個滿足自己需求的最大平衡點，然後結合自己的產品理念，出發點來說明自己的想法，切記拿什麼老闆就是這麼說的啊，別人的產品也是這麼做的啊來壓別人。
我認為如果不是程序員時間不夠，其實產品經理這個職位可有可無，君不見很多傳統軟體公司都是項目經理程序員兼職做產品規劃的么。
1.用最簡單的話說服得了自己，才有可能說服別人支持你的想法，因為產品經理以為別人自以為是的時候很可能是自以為是；
2.當自己破執的時候，就容易接納不完美的產品，也容易接納不合理的需求，這不算妥協；
3.反覆去驗證才能更接近合理，沒有絕對合理
說三點吧( ??_? ?)
第一，把跟你有長期合作關係的同事變成自己人，做好人情鋪墊。多跟他們說話，不管是網上還是當面聊，使他們很容易想到你，認可你是一個好相處的人。需求那麼多，總得排個期，除了重要緊急肯定是熟人更有利
第二，把需求的完成情況列好清單，記錄好進度安排，每天定時定點詢問進度，被問煩了總會給你個答覆的。
第三，自己做的需求，一定不要頻繁更改，做好注釋，不要浪費很多時間在口頭描述上，如果因為一些現實情況不得不做出需求改變，以謹慎且略帶歉意的態度及時告知合作的同事，主動幫助一些力所能及的事情讓同事覺得幫你改，不會太麻煩
這職位多是廢物
喬不思那樣的天才很少
"隨時準備捲入戰爭對不合理需求說不大家都知道"，這句話真的讀得很費勁呀~
我在提需求的時候，一定會把我為什麼要做這個事情、為什麼把這個需求的優先順序提到這個級別的來龍去脈講清楚，允許別人的反對意見，並且會請提反對意見的同事吃飯，在公開場合表示對反對意見的認可和尊重，長期下來，效果明顯。
直指最高票答案。答案在術的層面上說的方向大體贊同。然而有些片面的地方，需要思考。
1 產品經理真需要了解技術細節嗎？
2 技術天賦樹真的比忽悠天賦樹（即使複雜）更有吸引資源的能力嗎？
3 稍微有規模的團隊里，信息不對稱真的有人自信自己才是正確的嗎？
4 抄襲市面甚至直接競爭對手已有的功能，真的沒意義嗎？
5 傻逼需求真的能在上線前就知道是傻逼需求嗎？
6 即使明知是傻逼需求，真的可以不做嗎？
7 我說「老闆安排的」，真的是因為是老闆安排了嗎？
8 我寫文檔，真的是給你們看的嗎？
9 你要文檔，是真的要看嗎？
10 所有問題的答案，真的都只是參照客觀事實上的對錯嗎？
需求的定義，是需要滿足用戶的心理期望，，而不是滿足該期望所採用的方式。 條條大路通羅馬通羅馬，路不通，還可以坐飛機。
要知道做這個需求的核心目標是什麼，為了解決什麼問題而坐，為了達到什麼目的而做。在這點上不能不堅持，如果妥協那也就失去了做這個需求的意義，而且一再的妥協也會讓別人覺得你思考的不夠多，怎麼目的是這個，我們說這樣改就改了，那還是不是要達到這個目的了。
一些與核心目標關係不大的，舉個例子，動畫效果，字體顏色，背景圖等細枝末節的東西，一方面聽取專業人員的意見，如果雙方不能達成一致，建議還是遵從專業人員的意見；另一方面就要從工作量和工期上去考慮了，如果要實現一個複雜的動畫效果，要延期一周，那就要具體需求具體評估了。
一句話簡答：
產品經理，先去掉經理2個字。再去掉各種自我主觀臆測，然後考慮以最小的成本獲得最好的效果。連哄帶騙的讓開發完成一個產品。
多說一句：請不要妄想一開始就開發一個完美的產品！
推薦閱讀：
※在小團隊中，同時身兼產品和運營二職，有哪些利弊？
※為什麼 iOS 7 取消了解鎖聲音？
※攝影師如何評價諾基亞 Lumia 1020 的拍照能力？
※產品經理如何避免出現「豆郵」反覆改名這樣的問題？
※互聯網產品經理需要什麼性格特質和必備能力？