其實，不同行業、不同公司、不同業務線、不同類型的產品經理的工作流程都會存在差異，不能一概而論。

接下來我說一下比較通用（絕大多數產品經理都適用）的工作流程：

一、產品經理的需求來源

產品經理一切工作的本源是：需求。所以我們從需求來源開始講起產品經理完整的工作流程。互聯網需求來源一般有：

1、產品需求：產品經理通過數據分析、用戶調研、競品分析等方法驗證通過的需求

2、運營等業務部門提交的需求：比如以京東為例，服飾業務部/生鮮業務部/家電事業部的運營、采銷等人員出於提升業務指標的角度會提出各種需求

3、老闆的需求：領導從外部合作的角度或者產品戰略的角度也會給手下的產品經理提一些需求，比如我還接到過大Boss和老闆娘的需求

4、Bug修復等：在工作中修復BUG是一件比較常見的事情，影響面大的BUG會走緊急修複流程，不太嚴重的BUG會走迭代排期。

二、需求池的管理

通過以上幾種方法收集到的需求會統一放到需求池中。需求池大家可以理解為所有需求的集合（包含待確認、設計中、帶排期、開發中、已上線等所有狀態）。

一般來說，使用execl表格管理需求池即可，按照各種需求狀態進行分類展示。

三、需求優先級

我們需求池的需求會非常多，但是每個迭代的時間是有限的/研發資源是有限的，所以導致我們只能從需求池中挑選出少量需求進行開發，從而誕生了需求優先級的概念。

一個迭代中肯定有限做優先級高的需求！

那如何排定需求優先級呢？

一般來說有兩個場景：

1、從0到1設計一款產品

這種場景下的需求來源基本上都是產品需求。建議大家去了解一下KANO模型，這個場景下的需求優先級一般來說是：基本型需求>期望型需求>興奮型需求

2、在原有產品基礎上優化

這種場景的需求來源會非常廣泛，可能之前講到的4中來源都是涉及，那如何排定需求優先級呢？一般按照產品價值和實現成本兩個維度。

產品價值可以分為兩類：業務價值和用戶價值。

價值定義：

• 業務價值：對應商業類產品，稱為商業價值，體現在能給業務帶來多少收益。
• 用戶價值：對於使用者來說，能給他帶來的價值，比如說能減少操作步驟。

在這種方法下，優先級的排序邏輯是：產品價值大實現成本低>產品價值大實現成本高>產品價值小實現成本低>產品價值小實現成本高。

四、需求確認

當梳理完需求優先級之後，我們就按照開發工作量挑選優先級高的功能組成新版本/新迭代周期的需求列表。

梳理完需求列表之後一般要跟直屬領導當面溝通一版，這叫需求確認。在這個階段要做好挨批、被懟的準備。領導會從各個維度“挑戰”你需求的合理性。所以大家在需求評審前一定要多思考幾遍，盡量多用客觀數據去說服領導。

如果需求確認通過，會進入到產品設計階段。

五、產品設計

產品設計階段會包含如下幾個小階段：

1、使用產品腦圖梳理產品/功能結構框架，特別是對一些邏輯複雜的新產品/新功能。

2、使用產品流程圖梳理產品/功能核心業務邏輯。流程圖的梳理盡量詳細，各種異常場景的判斷一定要在流程圖中有所體現。對於涉及多個參與方業務，可能還要梳理泳道圖。

3、使用墨刀/axure等原型工具輸出產品原型。原型是產品邏輯的可視化表現，也是產品經理最最基本的基本功。

4、撰寫產品說明文檔（PRD）。PRD是產品詳細邏輯的最終呈現，也是內部溝通的標準文檔。PRD撰寫完成之後就可以進入到需求評審階段

六、需求評審

需求評審是指產品經理要向UI、交互、研發、測試等內部人員講解產品邏輯，保證產品邏輯在內部傳輸過程中不失真。

需求評審的過程中，有4點需要注意：

1、評審的時候，先講需求背景。即這一版本為什麼要做這需求？做完以後預計會達到什麼效果？讓相關參與方從心理上認同做這件事的價值。

2、在講具體需求的時候，按照對應的責任人進行拆解。比如在講解功能A的實現邏輯時，我一般會說客戶端需要完成的內容是1、2、3；服務端需要完成的工作是1、2、3；算法側的工作是1、2、3等等。

3、存在爭議的地方先記錄下來，評審結束後再細化。

4、就是評審結束以後要追排期。即作為產品經理你要盯着研發Leader，設計Leader，測試Leader讓他們出需求排期，以此保證項目按時上線。

七、項目管理

需求評審完成之後，項目經理（大部分公司由產品經理擔任）會輸出詳細的項目排期表，然後項目所有相關人員會按照項目排期表有條不紊的協作。項目管理的詳細流程如下：

八、數據分析

產品上線之後，產品經理要做好產品分析工作，以驗證產品/功能是否達到預期目標。特別是產品上線7天後，產品經理需要想全體組員發送產品上線數據報告。

如果數據不達預期，就要進行深入的分析內在原因是什麼，然後數據分析的結論很可能是下一迭代的需求來源，從而開始一個新的迭代周期。