產品經理和項目經理的衝突，怎麼解決兩個角色的平衡？

01-08

項目不算大，方向也是高層定好的，項目開展2個月後，我作為產品經理才入駐項目，然後剩餘的時間很短，在我來之前的這兩個月的時間裡，只是項目經理、技術在和需求方做需求，也沒有實質性的產出文檔、設計之類的內容。
我進入項目以後，剩餘的項目時間已經很短了，我也就抓緊做原型、文檔，在這個過程中，我總會加入自己對項目、產品設計、交互的一些理解，但是項目經理總說我不要搞其他的，按照他的要求去做就行了，相當於我沒有做調研、沒有做需求、沒有做文檔，只是按照項目經理（還不是需求方）的口頭闡述去做原型和註解，自以為做的很被動，中間和項目經理產生過好幾次衝突
其實總歸的問題還是在於如何平衡這兩個角色，我的感覺是項目經理做的太寬了，感覺項目經理更多的精力應該在周期把控、人員協調方面，而不是插足產品經理的需求，甚至在欄位需求、頁面布局上都做很強烈的干涉，我不介意項目經理提建議，做改進，但是這期間的工作已經完全超出了建議的範疇，而且我作為產品經理，完全找不到存在感
備註：因為這個問題，加上公司人事關係複雜，我算是要被迫離開公司了，其實也知道自己中間做的不足的地方，也在努力改進，但是感覺和自己預期的差距太大了，哪位大神幫忙來解答下，我該怎麼做

又到了午飯後的休（da）息（ti）時間了。

這類問題充分表現出了理論和現實的巨大差距。我們先來看理論：一般來說，產品經理總希望儘可能多、更完美地實現產品的需求；而項目經理關注的是項目目標和範圍，滿足用戶的前提下，做的工作越少越好，這樣就能保證進度和節省成本。如果產品經理擔任過項目經理，在進行相關項目開發的時候，會考慮項目哪些需求是核心和通用需求，可以作為產品需求，在做項目時盡量去實現，但也會綜合項目進度和成本。這樣當然是最好的選擇，但同時也意味著這樣的產品經理需要懂技術。

然而這些都沒有卵用。在不同領域、不同公司，差別實在太大了……

在IT行業中，PM項目經理最大，接著是SA系統分析，最後才是PG碼農。做到SA就可以做Paper work的工作，然後就可以脫離寫代碼，在這個行業中，PM薪水最高，其次SA，最後才是PG。但是在硬體公司，RD研發跟SA系統應用是同一層次，最小的才是PM，薪水當然RD最高。而遊戲業呢？PM極為模糊，有時候PD製作人管產品也管項目，有時候LD主策劃管產品，LP主程管項目……基本上是根據人員能力來定。

我有一個師弟之前在遊戲外企做executive producer，執行製作人，聽上去是把控全局的角色，但實際上他既不寫文檔也不寫代碼，主要是靠project、excel和開會。的確，在非常重視品質和進度的大型單機遊戲公司，流程管理非常重要，而且具有一定地控制力。後來他加入了一個國內創業遊戲公司，完全沒有地位，被策劃和程序各種不屑，再後來他跟我組隊，投資人說這個團隊核心裡不要他就給錢，再然後他去做運營了……

大公司裡面可以有專門的「管理」職位，因為多數人在面對老闆的時候，不管大老闆小老闆，總會很自然的矮了一節，美其名叫做尊重，其實是怕被扣分。但在初創公司里，完全沒有所謂空降的「管理」。

其實在以前，產品經理可能叫業務員、設計師、客戶經理等等，但很少會像現在這樣光是設計，或是空想一些產品策略。

基本上如今的產品經理什麼都要做，但是又不是真的管所有事，好像很有權力，但其實真的要用時，發現根本一點權力也沒有，好像要擔起所有的責任，但同時好像也不需要負責。你再怎麼討好工程師，他們內心裡都會視你為死敵，為什麼？因為你叫他們做工作，而且有時候並不是他們願意做的事。如果你有工程師背景，他們則會覺得你愛管閑事，或是很纏人；如果你沒有工程師背景，他們會覺得你根本沒用、也沒有能力。如果你給他們太多工作，他們會直接拒絕做：對不起，這絕不可能完成，請你砍掉一些東西。如果你給他們的工作不夠多，那麼你就沒有足夠的「願景」激勵他們，而當其他產品經理開始挖你的人時……

反正所有的人都會各種指責你，且大部分都是你無法控制的——

「我幾百年前就跟你說要加進去的功能呢？」

「為什麼上架的時間晚了？是你說要這個時間完成的不是嗎？」

「為什麼產品發布後我還會看到這個bug？你沒有測試過嗎？」

「客戶想要跟PM談，他們對產品不是很滿意」

……

每個人都會因不同的理由討厭你，如果你真的很厲害，偶爾（只是偶爾）你還是會成功推出好的產品，可以讓某些討厭你的人稍微喜歡你。這就是產品經理的命。所以大家都想做新項目，不想接老項目，因為一旦你接了，前面傢伙設計上的錯誤、所有推遲的進度、沒修正的問題，都會跑到你的手上，恭喜，現在都是你的問題了。

我覺得在國內這種草莽的環境里，產品經理或者項目經理的定義是有些模糊的，不是東風壓倒西風，就是西風壓倒東風。如果你不行，就叫「不寫程序的工程師」；如果你行，就叫「項目的靈魂」。產品經理總覺得項目經理無視產品特點膠柱鼓瑟；項目經理老覺得產品經理老是瞎改還提一些極蠢的要求。其實，項目經理能推進進度的原因正在於其能夠把控開發的各個環節並讓人信服。所以如果產品經理能在與程序、美術等各職能崗位溝通的過程中，讓他們體會到產品經理這個職位的專業性，你自然具有一定的控制力。而這種專業就是你要用內行的思維方式、表達方式和處理方式來思考、溝通和執行。如果你平時的表現讓工程師們覺得你很外行，即使你說的是對的，也很難有反應。對產品經理來說，必須儘可能的深入了解所屬產業上下游相關的專業知識，並且有一定的實踐經驗，才能顯現出產品經理的專業，進而獲得對方的信任感之後，才有機會讓工程師們採納意見。

所謂項目管理需要經驗跟技術能力，準備的過程需要耐心以及溝通協調能力，長袖善舞、八面玲瓏的周旋於各部門之間，還是要壁壘分明的鐵腕作風，如何面對黑白中間的灰色地帶，常常是需要摸索的難題。

總之，產品經理要想從其角色中獲得最大價值，則必須專註於產品的管理，而不是開發。但對於有企圖心更上一層樓並且在未來能成功地領導公司產品策略方向的產品經理來說，必須要去了解該公司開發團隊更深層的研發技術和界面。反過來，如果項目經理想更大程度控制局面，也一樣要了解更多的產品設計知識。

道理很簡單，你不了解程序概念，怎麼知道工程師怎麼工作的？不了解工作的難度，怎麼知道什麼事可能延遲產品發布？不了解崗位間的差異，怎麼讓團隊開始信任你？不跳進泥坑裡，怎麼讓他們看到你的努力、開始稍微喜歡你？融入團隊是重要的關鍵，中午一個探討晚上一頓花酒，勝過無數封email來往。

產品經理其實最怕的是因為自己的不懂露怯，其實真的沒有那麼難。不管是堅持己見還是知錯就改，語調和口氣一定要像超人一樣堅定。回答問題時，要按照以下順序：首先是問題的答案；如果不知道答案，很明確地回答你將用什麼樣的方法與步驟找到答案，然後給個時限；再不行，你可以很明確的說現在忙，一會來處理，然後在找到答案之前，什麼都不要說了。這都比任何不確定的答案都來的好。

不管如何，想管事全靠氣勢，否則全盤皆輸 。

唉，中間接了四個電話，見了兩個人，這麼點內容拖到現在才完事……

1. 給了掛了產品經理頭銜，但是你在項目執行過程中進入項目，對需求的了解和把握不可能比項目經理清楚，這個項目最好就是先把自己定位為項目的需求人員更好。

2. 感覺你理想化的產品經理文章或書籍看多了，既然自己都知道進入項目晚沒有辦法展開完整的需求調研和分析，那麼開始重點一定是理解項目經理需求並形成原型和文檔，再反向逐步理順整改產品需求和各個產品功能點銜接和交互關係。如果中間發現有問題，是可以找項目經理討論和明確的。

3. 遇到任何問題先考慮自己的問題，你本來就是中途進入項目，雖然掛了產品經理頭銜，但是還是要清楚整個項目更多的管控（包括需求和範圍管控）還是在項目經理。能夠把產品需求理順，形成自己獨立的見解需要有足夠的說服力，對產品本身深入的理解。

4.當你和項目經理無法真正協同好的時候，你即使再有完美的產品需求和文檔，沒有人幫你實現有什麼用？況且根據你的描述，我不認為你短期就能夠拿出完整的產品需求文檔和對整個產品的理解。所有遇到的問題還是產品經理這個頭銜導致的很多失衡。

前幾天寫了一篇產品經理的博文，推薦閱讀。

再談下怎樣能夠算得上一個合格的產品經理，一個人不是說你能夠有產品構思，能夠畫點原型，能夠做團隊和項目管理就是產品經理。蘇傑原來有本書叫《人人都是產品經理》，看了後大家可能會覺得做一個產品經理是挺容易的一件事情，但是自互聯網提供和設置了大量的產品經理崗位後，產品經理這個詞基本就爛大街了。
我們如何來界定一個產品經理，如果簡單點來講可以理解為根據自己長期的項目和運營實踐，通過自己的敏捷洞悉能力和分析能力，能夠將當前的市場需求或潛在的市場需求轉化為具體的產品需求，並能夠核心的定義產品功能模型和價值輸出，同時能夠通過項目和團隊管理的能力，凝聚一個小組形成一個真正的團隊，將自己的產品構思付諸於最終產品實現的人。在這裡我們還沒有講到運營，如果再講到運營的話可以理解為通過他人或運營團隊的運營，能夠進一步的收集和分析用戶需求和行為特徵，同時對產品進行持續改進，這個要求可能就更高，但是最基本的是你首先要做到第一點。

一個產品經理如果最終不能主導團隊完成一個產品的交付不能算產品經理，其次如果一個產品經理最終交付的產品沒有得到市場的認可或實現最終的價值也不能算一個產品經理。產品經理的核心價值就在於搞清楚市場究竟需要什麼？根據市場的需求如果構建一個產品並完成價值交付？產品經理我們一直強調要做正確的事，這個就是正確的事。如果產品經理和項目經理有獨立的職位的話，那麼產品經理要保證的是最終的產品能夠實現客戶價值，項目經理要保證的是按照項目或版本計劃完成項目目標。
如果從這個層面來說的話，產品經理需要具備兩方面的核心能力，其一就是根據市場規划出有價值和意義的產品的能力，產品本身的功能架構究竟如何，產品能夠完成哪些客戶需求和價值交付，產品如何分版本迭代的推出和上線。其二就是能夠真正指導和跟蹤管控產品孵化和落地的能力，產品如何研發，產品本身的技術架構或非功能性需求如何滿足，這些雖然可以藉助核心架構師的能力，但是產品經理必須有相應的技術背景和管控和指導產品落地而不是中途夭折。
很可惜的是，互聯網產品經理逐漸成為一個偽命題，不管是做需求，做UI或是說做架構，做項目管理的都可以稱為產品經理。導致我們對產品經理這個概念的認知越來越模糊，但是哪裡清楚一個真正合格的產品經理需要包括技術背景，實踐經驗積累，市場和運營，項目管理，軟技能，軟體工程等多方面的知識融合。雖然類似原來像中興和華為的產品經理本身有更多和跟嚴格的崗位職責定義，我們也會感覺這些過程相對來說很重，不符合互聯網團隊的敏捷和快速迭代文化。但是為學日益，為道日損，沒有真正經歷過繁重過程的磨練，我們是很難真正清楚如何去繁從簡。
你有一個產品構思或者說別人給了你一個產品構思，但是如果你能夠將產品構思真正細化，理清楚產品核心模型和價值交付點，最終全程主導和跟蹤將產品做出來並推向市場實現價值，那麼你可以算一個合格的產品經理。有創意和想法的人太多，但是能夠真正將想法喜歡為產品需求的人少，同時又能夠將產品需求最終實現為產品的人更少。網上說的就差程序員了為何經常被黑，很簡單，這些人除了忽悠到的投資人的錢和一些燒錢的想法外啥都沒有，他們根本就不清楚一個產品構思到真正落地之間所需經理的複雜和歷練。
產品經理是能夠真正賦予產品靈魂的人，是能夠真正將一群人構建為一個核心產品團隊的人，是一個能夠真正實現產品價值的人。只有他的高度領袖能力和全身心的投入才可能真正將產品從0到1孵化出來，他可能沒有做太多具體事務性的工作，但是卻會出現在產品打造全過程中的任何關鍵點。他們會參加需求調研和分析，總體產品設計，架構方案，產品測試和驗證，市場推廣和運營等任何關鍵點和關鍵環節。他們做的所有活動和跟蹤唯一目標就是讓產品能夠真正根據自己的構思和想法孵化出來，而不是在這個過程中不斷的偏離軌道而沒有修正。

產品經理是光彩奪目的，他們得到團隊的擁護，客戶的認可和產品帶來的價值回報，能夠通過自己和整個團隊的努力打造一款真正創造價值的產品所帶來的成就感和自我實現無任何其它可以替代。但是產品經理本身又是孤獨的，產品經理是真正負責產品成敗的唯一責任人，你的任何一個不夠慎重的決策都可能將產品引入歧途或最終夭折，資源的投入，產品的延期，客戶的不買賬，大量的深夜對產品的思索和煎熬，對工作和家庭的無法平衡，這些都需要你一個人去默默承受，偉大是熬出來的，你的每一點心血都最終融入到產品氣質中。
本文致所有在產品經理路上和那些正在為成為一個合格產品經理努力和奮鬥的人。

如果項目經理是負責人，那就要聽他的。

從實際經驗上看，項目經理是高於產品經理的，在國外的一些大公司，項目經理是僅次於 VP 和 CEO 的。

兩個PM居然幹起來了，在我看來這是一場職責界定不明確導致的衝突。接下來的回答中提到的產品經理與項目經理，均以互聯網行業里通用的職位界定，其他行業可能略有不同。

其實有個很簡單的方法來化解，我們首先來看這兩個PM分別做什麼事，為什麼負責，背什麼KPI。大目標定清楚後什麼都好解決了。

產品經理（Product Manager）：負責挖掘用戶需求，並提出能夠同時滿足用戶需求和公司利益的產品方案。對產品本身負責，對用戶負責，或者說對產品發布後是否受用戶認可負責。與產品運營人員共背用戶數、活躍度、留存率、營收等KPI指標。

項目經理（Project Manager）：負責管理整個產品開發過程的項目，負責協調產品開發中的一切資源，包含人、時間、資源、成本等。是整個項目的牽頭人，對項目的開發過程和按時完成預期結果負責。也就是說，項目經理的KPI應該是項目的按時完成與完成質量。用戶數、活躍度等指標一概與項目經理無關，更別說干涉需求，他懂個屁。

項目經理的職位在傳統軟體開發的公司里有，BAT等成熟互聯網公司也會有，但中小型企業一般沒有這個崗位，所以普及程度不高。之所以出現矛盾，就是因為很多公司里產品經理同時擔任項目經理的職責，要知道這兩個職位的出發點是存在利益衝突的。

產品經理：多做需求

對於大多數產品經理來說，用戶是否喜歡新功能其實是未知的，不然人人都是產品經理了，免不了試錯的過程。做5個新功能可能沒有1個用戶喜歡的，做50個呢？總能撞上幾個讓用戶喜歡的吧。所以產品經理喜歡通過增加功能點來「碰運氣」。

項目經理：少做需求

做得越多就錯得越多，很容易影響項目按時驗收，以及項目結果質量。比如APP產品的開發，大家都知道修復完一個bug後，正常情況下會出9個新bug。所以項目經理是喜歡需求越少越好，這樣項目複雜程度會低，工作量與風險程度都很容易控制在安全範圍內。

如果由一個人同時擔任產品經理和項目經理，就很容易左右互搏。需求是自己的，當然希望都做。但開發過程中遇到難題怎麼辦。砍需求？改方案？自己預期中最完美的方案要捨棄還是挺心痛的。堅持把需求按原方案做完？項目延期，影響正常上線，責任誰擔？

衝突如何化解？

1.核心在於一點：術業有專攻，不要覺得自己什麼都能做。

項目經理管好項目就行了，不要介入產品方案中，無論是否覺得產品方案有多傻逼，但也要尊重產品經理的成果。實在忍不了，轉產品崗去，別做項目了。

產品經理千萬不要把自己局限在交互上去了，比如百度的產品經理都不畫交互圖的，我之前工作過的金山也是，都有專門的交互設計師來負責交互部分。產品經理專心研究用戶需求和產品方案就行了。同時不要干涉產品運營，用戶絕對不是產品一上線就自動來了。

2.了解對方的工作

關於產品經理的職責，看那本《人人都是產品經理》就行了，了解一個需求從發現到落地的全過程。不要覺得這本書爛大街，大多數人也只是看過這個名字而已就覺得自己是產品經理了。

關於項目經理的職責，推薦看《寫給大家看的項目管理書》這本書。雖然它不是針對互聯網行業的項目經理寫的，而是針對所有行業的項目管理。

項目經理的工作內容：

　　項目啟動：制定初步計劃，進入項目的初始階段。

　　項目計劃：確定並細化明確目標，選擇適當方式來實現，並劃分階段。

　　項目執行：調動資源，統籌協調進行實施並完成計劃。

　　項目控制：通過定期的監控、評估，掌握進度，了解變化，適時調整，把控方向，確保目標實現。

　　項目結束：通過驗收，總結經驗，歸檔資料，獲得知識。

在項目管理知識體系指南中，項目管理知識領域一共分了九個模塊，分別包括：

　　① 項目集成管理：全局性協調

　　② 項目範圍管理：這一期做哪些需求？哪些優先做？

　　③ 項目時間管理：何時驗收成果？項目中每一個階段的重要時間點如何把握？

　　④ 項目成本管理：互聯網行業的項目主要還是人力成本

　　⑤ 項目質量管理：保質保量完成

　　⑥ 項目人力資源管理：投入多少人？每一階段哪些人做什麼？

　　⑦ 項目溝通管理：各職能如何保持信息互通？需不需要每天一起開會？

　　⑧ 項目風險管理：會不會延期？延期了怎麼辦？

　　⑨ 項目採購管理：是否需要接外部數據？與合作方對接的流程怎麼控制？

3.遇到問題要有優先順序排序

所有的衝突如果給予足夠的時間和人力，是能夠完成所有人的期望，絕對和和睦睦。但問題是現在競爭這麼激烈，能做的事情永遠是有限的，所以必須有優先順序排序。

什麼做什麼不做？什麼先做什麼後做？按照「重要」和「緊急」兩個維度，決定出優先順序順序，在面臨衝突時雙方都需要作出一定程度的妥協。很多時候不光靠強勢與撕逼，我們都要多了解一下對方的工作內容與職責界限，這樣溝通會更順暢一些，這才是解決問題之道。

以上。

手機不方便寫，先佔坑，謝不邀。孫志超充公知被揭穿，寫完有點後悔又捨不得那麼長的答案，結果被評論噴。如此敢寫不敢讓人評論，不如刪答案。公允來講，孫先生融資相關頗為專業，獲益不少，但隔行隔山，跨行裝B要小心。

回家好好碼一個答案，題主請稍等。

==正式回答==

產品經理的職能是歷史悠久的，但是職位是新銳的。這一句話，應當足以解釋題主的困境：題主所在的公司，或者說整個國內互聯網，都處於轉型期。

最早的時候，只有程序員，自己瞎寫程序，自己就做產品設計。

後來人太多，程序複雜起來了，需要模塊化管理，就從傳統行業借鑒了項目經理（這實際上是政府率先完善的崗位）職位。此時，項目仍然是投標競標，甲方乙方之類的運作方式，完全不必要管後面的，一門心思，快速省錢地把孩子生下來就行，不用養。那個時代，交付了產品就算完了，需求都由甲方定，沒有產品狗的生存空間。要得就是優秀的管理，拆分，統籌的人才。

再後來，也就是現在了，越來越多的公司，並不與甲方打交道，而是自行洞察市場的需求，自行設計產品，這就非常靈活了。沒有交付時間，沒有合同期限，有的就是市場無情的反饋：用戶喜歡，或者討厭。

這時候就需要有一個人來洞察需求，提出方案，甚至是中途更改需求，調整策略，這個人就是產品經理了。

題主的公司立項是高層，需求是高層+項目經理，所以實質上的產品經理是高層（老闆本人）或者高層接觸到的甲方。而題主沒有看明白這個事情，說明題主對產品經理的產品二字理解不夠透徹，我來提供一個參考性的思路。

產品經理做的事情是什麼呢？

以我五六年的創業經驗看來，是洞察需求-&>找到問題-&>給出方案

舉個栗子，一個電商公司希望在SNS領域尋找存在感，這個戰略由高層定力好之後，產品經理就該上了。

首先，洞察需求，比如通過觀察相關數據，發現有許多用戶買東西會參考一下別人的購買行為，例如購買與成交數有強正相關，總之比喻一下，你明白的。這個需求總結一下就是：購買之前有諮詢的需求。

然後，找到問題，比如通過整理功能和UI發現可以用來做購買前參考的信息很少，用戶要自行搜集，難以全面，而且這樣的麻煩會降低夠買量。

最後，給出方案，製作一個賣家和買家的IM工具來解決這個溝通問題。

以上作為例子，並不是一個出色的產品設計，但是是一個我認為最準確的產品經理職能描述。

這三步不能夠被干涉，如果洞察需求被干涉了，就相當於瞎子；找到問題被干涉了，就相當於傻子；給出方案被干涉了，就相當於啞巴。如果公司不能給你這三個步驟的完整權力，則這家公司正在轉型，留還是不留，題主可以自行考慮。

順便再多說一點，洞察需求之前的事情，是制定方向，這一步產品經理自己經常會忍不住插手，還是以這個電商公司為例，作為產品經理，很容易通過手頭的數據和模型，發現買賣雙方溝通不暢，於是非常容易就會想到做一個IM，這是不正確的。

每個職業有每個職業的操守和範圍，產品經理是一個解決問題的人，而不是製造問題的人，除非你兼職了CEO。當公司並未制定SNS領域的戰略的時候，產品經理完全沒有必要強行推行相關的設計，從戰略高度來講，產品經理的職位不夠高，不應決策方向，除非你剛好就是CEO。舉個例子幫助理解：你發現了買賣雙方溝通不暢，而且公司缺乏SNS的布局，於是你帶著UI和美工們熬夜做了一個IM的方案，各種優秀，上交給CEO，結果CEO回答你不需要，因為公司今年的預算和計劃是鋪設物流渠道，並且實現7天無理由退貨。到這裡明白了沒？CEO的考慮為增加銷售量。退貨有成本，進入SNS領域亦有成本，CEO站在最高的戰略位置，兩相比較認為鋪設物流並接受一定的退貨率更好更遠見，於是從戰略層面否定了進入SNS的思考。那你的IM再漂亮也是白做。所以做好自己的專業領域是最佳的「度」。

那麼往下，提出了IM的方案之後，是不是要做原型和UI呢？這就是分工問題了。

我最初接觸產品經理職位的時候，發現產品經理要學axure做原型，要寫PRD，甚至要設計UI，最好還能碼代碼。當初只是覺得混亂，現在能夠比較理智的說：產品經理不需要做這些，但是可以做。

任何職位在人手不夠的時候都是向下兼容的，極端的例子就是你一個人創業，你是CEO，但是向下所有的職位包括保安都是你一個人做完，這就是向下兼容。當你人手充裕的時候，錢也足夠的時候，職能就開始分化成不同的職位和人員，一個極端的例子就是馬雲，他除了沒有把馬雲這個名字分化出去，其他的基本上都分化完了，他只用保持馬雲這兩個字了。

因此，如果設計部門到你為止，那麼你就要把開發之前的事情做完，包括了：需求整理，問題與方案，原型，UI，美工，整理素材，版本規劃等。如果你不想做完，就試著去申請一下增添一個新的職位例如UI。如果遇到有錢又懂行的老闆，那你就可以著手幫助這家公司建立起完善的產品部門，如果遇到沒錢的公司，那就辛苦點能者多勞，如果遇到有錢但是SB的老闆或者上司，拒絕你的申請，那麼就可以毫無顧忌的離開。

以上。

看到「被迫離開公司」，我就爬進來了，看了所有的答案，都很好，我再廢話幾句：題主的問題在於：

1「沒有搞清楚自己在這個項目的位置（地位）」。看樣子，你只是熟讀了「產品經理崗位職責」和「項目經理崗位職責」，就理想化了自己的權利。

2你目前的問題已經不是如何做一個產品經理的問題，而是作為一個獨立的社會人要有什麼樣的基礎判斷，做為一個公司的員工，應該有什麼樣的基礎素質。

直白一點說，你雖然是產品經理，（事實上你只是掛職而已，高層為了讓你名正言順進入這個項目，面對公司的一個公開的說法而已。如果高層對於你的厚望是：欽點，那也不會在項目後期才讓你進入）。

所以，不管你的頭銜是什麼（即便你是被請出山的諸葛，緣於你後期才進去，你也應該聽取主要負責人的意見），所以，你在這個項目上並沒有話語權，也不應該有話語權，更不應該主動要求（爭奪）掌控話語權。

我這句話事實上要表達的是三個意思：

1你拿著雞毛當令箭了。沒有擺正自己的心態。你不能僅僅從崗位名稱上去認定自己的職責（權利）範圍。

2你的任務原本只是：完成項目。你自己給自己的任務（心愿）卻是：項目最後了，晴天一聲霹靂，我完美出場了，看哥給你們來一個完美殺青。

3你的項目經理反覆強調你的工作，也給你安排了具體的工作（他的職責他盡到了），你卻在「到底誰說了算」上面糾結（你的職責你沒有盡到）。

我的總結只有一句話：沒有合作精神的員工，走到哪裡都讓人頭疼。

我的建議是：如果還想留在這個公司，去和你的項目經理道歉，求他再給你一次機會。（真誠，真誠很重要！）

你要反思的是：

1工作能力不足，只要你會做人肯學習，你的領導也會幫你補救技能欠缺部分，要學會和（直接）領導相處。

2產品經理應該做什麼的，項目經理應該做什麼的，根本不重要，100個答題的會給你100個答案，出來工作重要的是合作。比合作更重要的是，你的直接上司信任你。願意挺你。信任是如何搭建的，他的短處你偷偷摸摸彌補，他的長處你認真去學。統一目標是：完成任務。不是標榜個人能力。

3我一直都認為產品經理雖然門檻兒不高，想要做好卻真的很難，業務能力以外，需要更多的是情商，不但要懂得用戶的七情六慾，還要懂得公司合作夥伴的七情六慾，更要懂得公司同事的七情六慾。不懂人性基本走不下去。

4不管是現在，還是將來，作為產品經理，即使你心裡有1000000個的想法，請，先，閉，嘴。仔細去傾聽別人怎麼說，認真去觀察別人怎麼做。快速適應所在團隊的交流方式，了解產品設的前因後果，如果發現，你之前的某些經驗或認知是錯誤的，立刻馬上調整（由於你的收聲，這些錯誤只有你自己知道，這是對你來說最幸運的事情），如果發現，項目組有錯誤，有理有據的指出，並拿出自己私下做好的方案救場。一個公司，一個項目，解決問題才是重點。不是製造麻煩，製造麻煩的員工能力再強也不可能得到別人的尊敬接受喜歡認可。

話到嘴邊而又不說出口需要極強的自我控制力，這是一個極具挑戰的考驗。你好好修鍊吧。

其他意見我也給不了更多，額，我現在是上課時間，偷偷摸摸在這裡回答問題，被老師用眼神殺死好多次。

兄弟，你聽過A/B測試嘛？這就是分歧終端機。。。

不能量化的需求沒有對錯可言，能驗證的需求不需要爭吵，這就是數字驅動的魅力了。

什麼是 A/B 測試？ - X 是什麼

沒遇到過這個問題，因為項目經理一般由產品經理或開發經理擔任，而且項目經理負責的是項目排期、進度監控、各種資源協調之類，不負責產品方面工作。。。

我現在就處於你類似的環境，不同的是我是項目經理，而且我要面臨兩個產品經理，其中一個在組織架構上還是我的直接上司(狗日的組織架構)

我是4月份加入這個團隊的，之前項目經理的工作是產品經理承擔的，項目一團糟。

好在在最開始，我經過不到一周的觀察和體會，就坦誠的和產品經理溝通，做了很清晰的分工，所以邊界很清晰，當然我也比較霸道，除了產品需求和規劃，其他的都是我說了算！尤其是不能插手開發和測試。

用了兩周排出了兩個月的詳細計劃(基於積壓的需求和缺陷)，並制定了一些研發規則，用三天和開發測試整體完成了持續集成中除自動化測試外的大多數環節。

將交付周期從40天變成15天，因為不能容忍一些錯誤的流程或者待加強的地方要存在這麼久。第一個迭代後用了一周時間調整研發流程並對每個角色的輸入輸出做明確要求。第二個迭代有明顯好轉。

在三個月後，基本上我主導了整個團隊，包括產品經理，不過我不插手一點產品規劃和需求。

後面就是和銷售，實施團隊的扯皮，溝通，確定邊界以及工作範圍，把外來的干擾清理了。此舉讓開發很爽，因為原來他們頻頻給實施不下去的項目救火，時間被嚴重碎片化。

是時候對需求動手了，需求的問題也完全露出水面並被整個團隊感知。

我開始要求產品經理有明確的輸出，文檔，原型，圖表等，並說服老闆，他們無奈接受了，開發，測試，實施，銷售第一次看到如此清晰的需求文檔，都覺得很好並要求繼續加強。然後要求至少有超過兩個迭代的backlog或者user story ，以及更大的版本規劃。

現在基本上他們都接受了，並且因為這些也在團隊中為他們自己贏得了別人在業務上的尊重和認可。我每天都給他們分享知識管理，敏捷需求管理，運營，SEO等信息以及知識等，因為我知識面比較廣，工作經驗也很豐富。而且還是一個想做產品經理的項目經理。

下一步我打算直接負責一部分非核心業務模塊的需求工作。

不想做產品經理的項目經理不是好的產品總監。

其實這兩個產品經理都是開發出生，對業務很精通，但不懂產品設計，用戶體驗，以及一些需求管理的方法論。所以比較容易搞定。

一。如何正確看待與項目經理的矛盾根據你說的，項目已經進入了實施階段，而且時間很緊。那麼你在這個時間點加入的第一任務就是快速推進需求落地。重新調研了幾乎相當於重啟項目，糾纏於各種細節也會浪費很多時間，違背第一目標。明確了這一點，就能正常看待與項目經理的矛盾。

二。如何看待對需求把控力

樓主的根本問題來自於對項目經理在需求把握上的不信任。對需求的深入理解是基本前提，作為剛加入項目的人，題主在這點上應該是欠缺的。因此如果對這個人的能力沒有足夠了解，不要輕易得出他不如我的結論。

三。如何處理與項目經理的關係

產品經理需要有強大的內心和柔軟的身段，才能在各種矛盾衝突中推進產品完善。項目經理和產品經理的合作大於衝突，相互依賴。在保證工作正常推進的前提下，多探討多請教。

四。追求完美的產品心態

求完美應該是一種做事態度，而不是做事方式。這種心態最大的傷害是把大量時間耗費在細節上，而不是最重要的方向結構問題上。因此要接受各種問題的存在，按優先順序一個個去解決。需要產品經理的承受力和耐心。

如你所言，項目不大，你也是項目開工後2個月才入駐，再加上項目經理對你的定位，你們項目所要找的應該只是一個整理需求輸出稿的人，而不是真正意義上的互聯網產品的產品經理。

你把自己定位產品經理，提出一些需求方面的精益迭代無可厚非，但是會讓項目經理很不爽。首先需求已經被項目經理基本定了，其次已經開發兩個月了，你這樣是否定了項目經理的眼光不說，還會嚴重耽誤規劃好的開發進度。你們現在的情況不是不可調和，但調和後也對項目的改進與你個人的發展於事無補，出離也許是個好選擇。

還是當個教訓長點心眼吧，以後參與項目之前先了解清楚人家需要的是什麼，究竟是一個產品Leader，還是一個寫需求稿的...如果把你定位成一個寫需求稿的也不是沒有翻盤機會，但是要確保項目進度的前提下和真正的Leader心平氣和溝通，而不是拿著產品經理這個title當令箭和項目經理干。

產品經理和項目經理的衝突，怎麼解決兩個角色的平衡？

首先題目，怎麼解決角色之間的平衡，我就想問一下，解決平衡之前，你有去了解自己和對方在公司內部默認的工作內容、職責和權利么？不知彼不知己如何平衡

項目不算大，方向也是高層定好的，項目開展2個月後，我作為產品經理才入駐項目，然後剩餘的時間很短，在我來之前的這兩個月的時間裡，只是項目經理、技術在和需求方做需求，也沒有實質性的產出文檔、設計之類的內容

我進入項目以後，剩餘的項目時間已經很短了，我也就抓緊做原型、文檔，在這個過程中，我總會加入自己對項目、產品設計、交互的一些理解，但是項目經理總說我不要搞其他的，按照他的要求去做就行了，相當於我沒有做調研、沒有做需求、沒有做文檔，只是按照項目經理（還不是需求方）的口頭闡述去做原型和註解，自以為做的很被動，中間和項目經理產生過好幾次衝突

其次，項目短，項目快結束了，方向定好，項目人員缺少需求文檔。這個是背景先提出一下
作為產品經理，項目章程或者項目經理任命書針對這個項目給了項目經理什麼許可權是否有了解呢？你來之前的項目上的產品經理都做了什麼呢？在PMBOK的組織結構中，有一種是強矩陣結構，項目經理作為核心協調人員是有能力調動職能部門人員的，所以請先確定項目獨有的權責範圍，了解能做什麼，知道了能做什麼，項目經理就算吵你也有理有據，而且你的職能範圍最好有領導書面指示或者發文來證明。
你知道項目到達當前階段應該做什麼？也就是知道要做什麼么？產品主張完美，項目主張高效；你半路插進去情況不了解，根據自己的理解提出需求進而變成拖延項目的罪魁禍首，從項目角度來說你肯定是一個負資產。項目進行到開發後期，要知道再進行變更是需要更多工作量的，你真的要從整體產品的高度考慮，你就需要像BRD階段，說明改進的收益、成本以及計劃，之後再拉領導和項目經理一起調整項目。
領導調動你插入項目的目的是什麼？或者說進入項目後，項目經理給你的任務是什麼？方向定好了說不定這個是boss項目，你確定你真的有權利去調整而不是僅僅去整理文檔呢？從你的描述來看，「項目」的核心需求在文檔的整理與解決通過整理髮現的不規範上
最後一句，自以為做的很被動，這裡應該有強烈的主觀因素，是導致你衝突的主要原因。你想說的其實是這個產品TMD是我管的，項目經理老老實實按著我規劃的去做，然並卵，這個仍然是不知道自己能做什麼

其實總歸的問題還是在於如何平衡這兩個角色，我的感覺是項目經理做的太寬了，感覺項目經理更多的精力應該在周期把控、人員協調方面，而不是插足產品經理的需求，甚至在欄位需求、頁面布局上都做很強烈的干涉，我不介意項目經理提建議，做改進，但是這期間的工作已經完全超出了建議的範疇，而且我作為產品經理，完全找不到存在感

不多說了，一個『感覺』，一個『存在感』，依舊是不明白能做什麼和要做什麼的結果。
總結一下，碰到這種非產品生命周期起始階段、運營迭代起始階段，而是半路殺進的產品周期，請先靜下心來，充分收集信息，達到與相關干係人信息對稱之後，再判斷能做的和要做的之後再去操作。這不是作為一個產品經理的問題，而是作為一個社會人的基本判斷

先佔坑。1.產品經理的核心是驅動。2.項目經理的核心是協調。

支持項目經理，他做得沒錯。本來中小公司是不需要設置產品經理的，硬要塞連雞肋都不算的產品經理做什麼。

聞聽樓主分析，可推斷樓主公司屬於outsource類，這類公司面對的是客戶而非用戶，考慮項目範圍時定然拒絕範圍蔓延。祝樓主跳槽順利。

以你陳述的情況來看，是他比較重要一些。否則你不會被安排在項目快結束時進入。

我之前不是做產品的，可能和公司小有關係，不到100人的互聯網公司。另外，創始人可能認為不需要非得設一個所謂的產品經理的職位，因為我們編輯部門實際上做了產品運營，內容運營以及部分產品經理的工作。

重要產品和新產品都是由創始人，設計師和我完成的，其實實際上就是創始人自己的構思，然後找設計師和我們編輯部負責人，也就是我，來完成執行和思想輸出的任務。所以，你看吧，和職位叫什麼名字木有關係的，主要還是看你在公司的位置和價值。

現在我的職位是產品經理，目前的公司還是不到一百人，產品部統領所有的技術資源（當然，我不是去直接領導和分配技術的工作，而是確定工作要幹什麼後，和技術總監溝通，確定開發時間）。

大體上，我可能比較幸運，我都在公司核心或者說得上話的部門。

當然現在的公司在一開始的時候，我剛去的時候，有過一年多的時間管理很混亂，我也經歷過和技術總監的摩擦（我們一直沒有項目經理，ceo說直接讓產品負責項目），主要是他這個人的問題，今年元旦前後技術部換血了，我和現在的負責人關係還不錯，他執行力很好，也很負責，不像上一位技術總監只是玩權術啥也不幹，大家都很有意見。

所以說，工作這事如果你想真的去做事，而不是耍小心思賣弄權術，還是要找合適的團隊，合適的氛圍。盡量在核心小團體里，你肯定有存在感。

感覺你沒有和項目經理達成妥協，抱歉「妥協」這個從表面上看起來有點不能讓人接受。其實項目本質的失敗與成功，標準很難界定，很多時候都是彈性的。這和一線開發有著本質的區別。

其實，你自己現在估計也感覺到了，其實就是那句話，大家混口飯吃，差不多就行了。說好聽點就是曾國藩的一句話「合眾人之私，以成天下之公」

要搞清楚，產品經理是甲方，項目經理是乙方。如果方向是高層定的，你就是高層代表，你要評估項目整體走向是否符合高層預期，不符合就要調整，取得高層支持，和項目經理博弈。

我就是處於題主的相似狀態中，而且是一家非常不成熟的行業應用軟體開發子公司，詳細看完大家的解答，感觸良多，目前的項目已經告一段落了，相信在今後的工作中會有更好的選擇和表現。

在IT行業中，PM項目經理最大，接著是SA系統分析，最後才是PG碼農。。。。

我帶新手做項目的時候架構設計、核心代碼都是自己搞定的...

有產品經理提需求了，SA、PG搞定還有PM幹嘛還這麼高工資？

SA做完架構設計就閑著沒事了？太浪費了吧

工作了好多年，熬夜加班帶新人 PM SA PG的工作都做... 簡歷都不知道怎麼寫職位。公司又沒給發個牌子說你是PM 組長之類的。就寫了個研發工程師獵頭就問工作這麼久就這能力？