1.產品經理和項目經理的差異

首先，產品經理和項目經理的職責定義不太一樣。

產品經理是 Product Manager ，主要是負責市場調研、用戶研究并根據用戶的需求，定義和設計產品，然后考慮產品的商業模式、運營推廣方式等。接下來去推動相應產品的相關團隊成員，根據產品的生命周期，協調研發、測試、市場、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。從產品的研發、運營、成熟、衰退，一個生命周期的整體把控。

項目經理則是 Project Manager ，負責跟進一個項目，項目管理的職責是實現項目的范圍、進度、成本、質量等目標，還要監督控制、協調管理整個項目過程，滿足項目干系人的需求和期望。

簡單總結起來，產品經理是做正確的事，最重要的是了解和發現用戶需求，并提供相應的產品去滿足用戶的需求，用好的用戶體驗去更好地滿足用戶需求；而項目經理則是把事情做正確，需要把項目做的完美，在時間、成本、資源約束的情況下完成項目目標。

其次，從行政權力來分析，他們也不太一樣。

在產品管理中，產品經理是領頭人，是協調員，是鼓動者，但他并不是老板。作為產品經理，雖然針對產品開發本身有很大的權力，可以對產品生命周期中的各階段工作進行干預，但從行政上講，并不像一般的經理那樣有自己的下屬，但他又要調動很多資源來做事，因此如何做好這個角色是需要相當技巧的。

而項目經理是有自己的下屬的，他有一個屬于自己做項目的團隊，但項目經理往往需要在一個臨時的、虛擬的團隊架構中，發揮自己的影響力，并達成項目的目標。從理論上來說，項目經理是比產品經理更有管理能力和權力的那個人。

最后，產品經理和項目經理的工作其實又結合的比較緊密。

產品經理與項目經理的分工和協作，真正要嚴格的區分開來是比較難的，在工作過程當中都是結合的比較緊密的。比如說，產品經理也需要時不時地跟項目經理了解下項目的相關進度，很多產品經理存在這樣一個認識誤區：需求文檔確定了，進入項目階段之后就不管了。不及時跟進開發的進度，也不去測試服務器測試代碼質量，最糟糕的結果就是，產品快要上線的時候，產品經理才發現開發質量和原先的產品需求定義相差太大。

一個項目在立項之前，是沒有項目經理的，這個過程全部都由產品經理負責，主要是要完成市場調研及需求確認的過程，待到項目立項之后，一般項目經理都是開發負責人或測試負責人，這個時候問題就來了，大一點的項目都會再指定一個項目經理來協助產品經理，以確保項目能最終按時保質保量上線。可是，在實踐過程中產品經理和項目經理這種配合模式比較難達到非常和諧的地步。

2.不和諧的地方，主要體現在以下幾個方面

1）對工作量的評估

產品經理一般對某個項目的上線運營是要背KPI指標的，所以對項目的上線時間一般會以比較理想的狀態去進行評估，另一方面是產品經理如果自身在前期的市場調研及用戶需求確認環節耗費了大量時間，則給到開發、設計的時間就少了很多。往往比較容易出現的一種情況是，產品經理評估的30個工作日就可以搞定的項目，在項目經理的看來需要變成45個工作日，而且人家項目經理還說了，這只是保守估計。

出現這種對工作量評估差異的情況，主要原因還是產品經理和項目經理之間認識和情緒上的偏差，一個是主人翁的精神，一個是執行者的角色，這樣就會出現是為了做任務而做任務的情況，并沒有任何的主人翁意識和緊迫感。個人建議產品經理在進行需求講解的時候，不要一味的只講功能點和實現邏輯，一定要說實現的產品價值，提供團隊成員主人翁意識，這樣在協調工作量問題的時候會好很多，而且后續的過程當中也會順暢很多。

2）對需求的理解角度

產品經理天生就需要對需求非常敏感，在產品迭代的過程中，衡量一個需求要不要做，什么時候做，做到什么程度，往往是從市場和用戶那里出發的。而項目經理則不一樣，項目經理看需求，往往是從技術實現的角度出發，項目經理看了之后覺得實現的代碼量巨大，就想對這個功能點進行攔腰斬，只做其中一部分，甚至建議不做，或者說會影響性能卻又給不出更好的方案時提議能否暫時不做這個功能。

這個時候，產品經理和項目經理對需求的實現就出現了分析和沖突，一方面產品經理當然不愿意犧牲用戶體驗和需求，去做技術上的妥協；另一方面又不得不考慮項目經理的相關推論，還要結合項目的進度和時間計劃、節點等，去考慮究竟該如何實現需求。個人建議是產品經理和項目經理兩個人，最好是要有一個人能夠拍板，如果實在不行，則叫一個領導或者老板來拍板。

理論上來說沒有任何功能是技術無法實現的，所以我還是比較偏向于由產品經理來評估決定到底要不要做這個需求。

3）對需求變更的容忍度

需求變更對產品經理來說，倒像是一種家常便飯，試想哪個互聯網產品在開發的過程中，不是經常變更需求的。當然，如果一個產品經理在項目開發的過程中，變更需求的頻率過高，或者有些需求變更是顛覆了原有的產品架構、技術架構的，那么這樣的產品經理則不是那么靠譜了。

靠譜的產品經理則對需求有著更為有力的把控，變更需求的頻次較低，且不會出現大的、顛覆性的改動。但即便如此，也依然逃脫不了需求變更的魔咒，誰讓市場環境本就是瞬息萬變的呢。可是開發人員不是這么認為的，當一個功能辛辛苦苦開發出來，馬上接到通知說這個功能不要了，要換成另外一種，這種情況發生的次數多了，換成任何一個人都會覺得是被耍了，畢竟都是自己的成果，說不要就不要了，說改就得改了，而且變更的次數多了也會影響項目進度。

出現需求變更的情況，具體可以采用如下措施：

一是要讓項目經理理解需求變更的目的及其價值所在，做好溝通工作；產品經理積極地去與團隊成員評估需求變更，是變更還是不變更，如果變更，要評估一下影響范圍有多大，是當前迭代變更還是下一個版本去迭代。
二是要嚴格控制版本，減少變更的次數和降低變更的頻率，做好迭代周期的規劃。

參考文獻：產品經理VS項目經理，這些異同點你get了嗎？
謝謝作者分享！