產品經理工作流程初步分解

產品經理雖然是互聯網相關公司的職位，但是產品經理的職能其實是適用於各行各業的。概括起來其實是一個「想法——實現——（下次）精進」的過程，對於建築設計行業來說，可能「想法」是一個建築立意或者出發點，「實現」是設計方案，「精進」是下一次相似項目的優化。對於互聯網行業來說，「想法」是需求，「實現」是需求變成可以使用的產品，而因為互聯網產品對比傳統行業，有著「快速優化」的先天優勢，「精進」則指的是此需求的更新迭代。

更詳細一點說，「想法——實現——（下次）精進」應該分為四個階段：

需求階段

需求的第一步是想法。不管是大型項目，小型項目，或者是新項目，老項目更迭，需求的第一階段都是原始的想法。想法的來源可能多種多樣，可能是靈機一動的小點子，也可能只是想讓現在的功能變得好用起來。

有了初步想法之後，需要確定的是：需求動機、目標用戶、目標成果。需求動機是便於在需求推進的時候不被繁雜的新想法沖昏，是需求深化時候謹記的初衷。目標用戶、目標成果是這個階段需要簡單定性的。當然，在這個階段時，即使做過市場的數據調查，也是很難一下子把握住目標用戶的。不過沒關係，這個步驟的目標用戶、目標成果的記錄更多是為了追根溯源和後期迭代考慮。

之後是初步需求。在得到了想法、動機、目標用戶與成果後，我們已經可以簡單的描述出想要的東西的大致的輪廓和大致的方向了。

如果需要競品分析，到現在這個步驟就可以著手開始了。市場上同類競品不少，不過由於方向不同（或者說定位不同），在初步需求確定之前做競品分析很有可能對方向迥異的產品研究過深，最後徒勞無功。在初步需求確定後的競品分析有助於釐清思路，並且得出需求框架。

需求框架是需求階段的成果物。這個階段的需求框架有了明確要做的任務，大任務下的子任務。需求本身的結構被搭建起來，主脈絡清晰了，可以匯總出一份概念方案提交出去，也可以進入下一個階段——

細化階段

需求框架雖然具備了基本的功能，但是由於太過泛泛，實際上並不具備與其他合作專業相溝通的基本點。為了更加深入的去研究需求，需求框架需要逐步的深化成羽翼豐滿的成果物。

從線框圖開始切入是一個不錯的選擇。

線框圖是原型的簡化版，通過線框圖可以把頁面中的關鍵操作體現出來，譬如觸發按鈕、文本框等。線框圖是流程操作的梳理過程，由於大部分公司不要求這個過程的輸出物，所以這個過程僅用來梳理自己思路和團隊內討論用的。

有了線框圖後，或者說有了關鍵操作後，接下來就可以繪製流程圖和原型圖了。

在繪製流程圖過程中會涉及不同系統的數據傳輸，不同介面的判斷，是從技術實現邏輯判斷層面的上的功能分析。原型圖呢，是前端的展示，更偏向於交互層面的展示。流程反映著原型，原型是流程的前端映射，這兩者相互影響相互牽制，所以需要通盤考慮，兩者同時推進。

原型圖不再贅述。

如果埋點需要產品經理設計的話，在原型圖和流程圖定下來後，就可以著手埋點和漏斗模型的設計了。

接下來是高保真原型。

由於現在大部分公司已經有交互設計/ UI設計師的崗位，很多產品經理通常不再做高保真原型。大家可以根據工作的實際情況選擇做或者不做，私以為，做高保真原型還是可以對用戶體驗有進一步的理解的。高保真原型對於原型來說，更多的是頁面展示的細化和微交互的考慮。舉個例子，原型上只需要繪製出Tab即可，高保真原型就會考慮到，這個Tab是滑動至頂部後吸附在頂部的Sticky Tab，還是會隨著頁面滾動的Scrollable Tab。

高保真原型的產出可以確保細節更加完善，實際效果更加確切，場景更加豐富。如時間允許，各位產品經理不妨一試。

細化階段的最後一步就是需求文檔了。

需求文檔基本上不同的公司會有不同的規範模版，不管需求文檔的模式多麼不同，最終目的就是給開發、產品、設計等相關人員閱讀使用的。所以記得表達清晰不能模稜兩可，如文字不便於敘述時，可添加示意圖、細節的流程圖等等。關於需求文檔的寫法，這又是一篇大課題，此處不再多言。

實現階段

實現階段也就是從需求文檔完成到開發上線的過程。這個過程中，產品經理除了參與需求評審和排期外，基本只需要保持溝通即可。事實上，只要需求文檔寫的詳細，前期繪製流程圖時與開發保持溝通，實現階段不需要耗費太大心力。

迭代階段

迭代是我認為的最重要的階段。目前市場環境下，大部分需求來不及過多分析市場、用戶、相似數據便快速上線。這時候的功能需求很可能是不能用、不好用、甚至是不合理的。迭代，就是使這個需求合理化的過程。

需求上線後，需要定期觀測下數據。如果沒有數據團隊的話，前期也需要事件定義、對數據觀測周期進行設計，如活動剛上線1小時，密集傳播後30分鐘、1小時等等；如一個普通的未推廣的功能剛上線1天，上線3天，上線一周等等。此處可歸屬為數據分析這一大類上。

有了基本的數據後，通過這些數據得到可能的幾種原因（也就是定性分析），再依據這幾種原因再依次進行相應改造/ 用戶問卷/ ABtest...（定量分析），最後得到的結果就算是當前階段比較合理的結果了。

很可惜的是，大部分團隊都沒有足夠的時間和人力去支持定性定量分析。那麼迭代階段最好根據簡單的漏斗模型和簡單的用戶反饋，以及競品分析，得到有切實執行意義的方案。如果沒有足夠的反饋支撐著迭代方向，那還是暫時忘記迭代這事把，專心去做別的需求吧。