B端產品經理工作流程復盤

5 評論 8954 瀏覽 88 收藏 14 分鐘

編輯導語:目前,關于C端產品經理的文章不在少數,相比之下,對于B端產品經理的工作流程、整體方法論的討論占了少數,并且缺少從整體上進行概括的文章。本文作者作為B端產品經理,通過結合自己的工作實踐與認知,對于B端產品經理的工作流程進行了一次復盤分享。

一轉眼,我已經從事B端產品經理近兩年時間了,一直沒沉下心對自己的工作內容和所學所想進行系統總結。恰好最近身邊有不少朋友和同學想要轉行產品經理。

寫下這篇文章算是對朋友關于B端產品經理的一個簡要介紹,也作為自己兩年來的工作復盤。下文我將B端產品經理工作流程拆解,從各環節的工作內容概述、注意事項和主要產出三個方面進行介紹。

一、流程拆解

圖1、B端產品經理主要工作流程

1. 需求獲取

1)概述

產品經理以深度訪談、問卷調查、輪崗實習等方式獲取需求方的需求,其中深度訪談這個方式最為常用。

需求獲取是一個由粗略到細致的過程,從概括性的項目背景說明、價值分析,深入到目標用戶確認、業務現狀、業務問題和期望效果的梳理。視項目實際情況,可能需要和基層執行者、中層業務負責人和高層領導分別進行溝通。

2)注意事項

溝通時避免使用封閉式提問(即提問者提出的問題帶有預設的答案,回答者的回答不需要展開),封閉式提問容易忽略問題本質,停留在問題表象。

3)產出

訪談記錄、調查報告、實習總結。

2. 需求分析

1)概述

產品經理針對獲取的原始需求進行偽需求的過濾,梳理得到真實需求并匯總進項目需求池,進行優先級判斷和迭代規劃等管理。

其中優先級主要從重要/緊急程度兩個維度進行判斷;迭代規劃則是權衡工期要求和開發資源,在當期版本中刪減優先級低的需求,在后續版本中再開發。

根據確認下來的當期需求,進行業務流程、功能架構、工作流狀態定義的梳理工作——即進行框架層的需求設計,也是進行詳細需求設計前的必要步驟。

2)注意事項

需求方嘴上說的和他真實想要的很可能是兩回事。《有效需求分析》中總結了這一現象:需求方往往提出“方案級需求”,需求分析則是要還原出“問題級需求”——其實就是過濾“偽需求”,得到“真實需求”的過程。

梳理出真實需求后,根據實際項目要求和資源限制,可能還需要從技術、業務、成本和收益、風險和策略等方面進行可行性分析。

3)產出

項目需求池、需求概要設計(包含業務流程圖、功能架構圖和工作流狀態定義等)。

圖2、項目需求池

圖3、業務流程圖

圖4、功能架構圖

3. 需求review

1)概述

產品經理依據需求概要設計(業務流程圖+功能架構圖+工作流狀態定義)向需求方再次確認需求內容并闡述對應的解決方案。

這個過程主要是用于確保產品經理對需求理解的正確、完備,在進行詳細需求設計前及時糾錯,同時也盡可能的避免后續環節中的需求變更。

2)注意事項

很多PM會忽略需求review這一部分的工作,或許是抱著“我在需求獲取階段已經進行了充分溝通,并基于溝通結果開展需求分析,那么需求設計就是沒有問題的”這種想法,然而最終上線的產品不能滿足需求。

主要原因就是信息在表述、理解過程中的失真,需求review則是盡可能避免信息失真。初中級PM受限于產品能力,或者需求復雜度高,需要輸出系統級解決方案,那么“再確認”的步驟是必不可少的。

3)產出

修正后的業務流程圖、功能架構圖和工作流狀態定義等需求概要設計內容。

4. 需求設計-詳細

1)概述

依據確認無誤的功能架構圖、業務流程圖等內容,產品經理進行需求文檔的編寫。需求文檔中需要說明頁面內容、交互、字段釋義和數據邏輯等產品細節。相較于內容詳實全面的PRD,我個人推薦“原型+文字/表格注釋”的形式進行需求文檔的輸出。

PRD詳實全面,也意味著又臭又長,項目組同事基本不喜歡看;在“讓人快速準確理解需求內容”這方面的確不如“原型+備注”的形式。我個人理解PRD目前最大的作用在于項目歸檔、追溯和交接,而非需求內容傳達。

2)注意事項

需求文檔作為產品經理的主要輸出物,是一個衡量其基礎能力是否牢靠的重要指標。

需求文檔的目的,是為了讓項目組成員就需求的理解達成一致,并能明確指導UI、前端、后端、測試等同事各自開展下一步工作。達成了以上目的,那么這已經是一份良好的需求文檔。

此外,需求文檔具備“規范的內容格式”也同樣重要。內容格式的標準化不僅能讓產品經理在一個清晰的框架下編寫文檔,文檔更具條理性,內容更完整詳實,而且有助于知識傳承和統一管理。對個人和團隊都十分重要。

3)產出

需求文檔:

圖5、“原型+備注”形式的需求文檔

5. 需求評審

1)概述

產品經理組織項目組成員參與并依據需求文檔進行需求宣講,讓產品、UI、前端、后端、測試等同事對需求的理解達成一致。

這個環節也是產品經理經歷各方“拷問”的重要環節,尤其是技術同事經常會在產品設計上深究,因為這往往決定后續的技術選型并左右開發難度。

2)注意事項

需求宣講需要注意語言表達的邏輯和條理,應當從“項目背景&目的、業務場景”擴展到“業務流程、功能架構”,最后再詳細展開“具體頁面和功能”——即結構性思維的應用。

人無完人,哪怕是高級產品經理也不是每個項目都能考慮到所有細節。但這并不是產品經理在進行需求設計時“大而概之”的借口,相反,產品經理需要在設計時進行深度思考,盡可能考慮到所有細節。最好能做到面對大家的疑問,都能有理有據的應答。

3)產出

依據評審結果修訂的需求文檔。

6. 項目排期&項目管理

1)概述

將整個項目從“需求對接”開始,到“項目上線”為止,各個階段的負責人以及人日消耗以表格形式羅列。目的是讓項目組同事明確各個關鍵項目節點,產品經理(或者專門的項目經理)以此為依據進行項目管理。

2)注意事項

項目管理需要定時關注各環節實際進度與預期進度的差異,及時反饋風險、協調資源。如果覺得線下管理、溝通效率低,可以采用TAPD和Teambition等協同辦公軟件。

這類軟件一般都有甘特圖和看板等管理工具,使用起來還是比較方便。

3)產出

項目排期表。

圖7、項目排期表

7. 產品審查

1)概述產

品上線之前,產品經理需要對UI和功能進行審查。

一般來說具體的界面測試、數據準確性測試和兼容性測試等會由專業的測試同事負責。產品經理只需要驗證產品主流程通暢即可。實際執行也很簡單,依據之前梳理的業務流程,發散出各個業務角色的用例,進行流程驗證即可。

2)產出

產品審查報告:

圖8、產品審查報告

8. 系統運營宣導

1)概述

一個業務系統初次上線或者版本更新,需要針對系統各角色開展相應培訓。

一般而言,企業自建自用的B端產品不會分配相應的運營人員,往往是產品經理一并負責系統的運營,需要輸出針對各個業務角色的“系統操作手冊”,并視情況召開宣導會進行業務流程和角色操作的演示。

如果該產品有向外部推廣的意愿,產品經理也會負責產品白皮書之類的編寫。

2)產出

系統操作手冊、產品白皮書。

圖9、系統操作手冊

9. 運營數據分析&迭代規劃

1)概述

產品上線后,產品經理和運營同事通過分析用戶行為數據得出產品的優化方向。常見的B端產品評價指標如下:功能完善性、系統可靠性、時效性、易用性、兼容性、數據準確性、界面排版合理、響應速度等。

一般采用問卷和訪談的形式進行收集,根據收集的數據,可分析出用戶在當前版本的痛點,結合在“需求分析”階段擬定的“迭代規劃”,共同構成最終的迭代計劃。

2)注意事項

常見的埋點事件(點擊、曝光、停留時長)對(除SaaS外的)B端產品并沒有多大的參考意義。

因為B端產品與C端產品有一個根本差異——不直接產生收益,往往是通過間接的“降本增效”來為企業助力。這些常規的埋點事件和與之對應的分析模型很難量化B端產品的效益。故采用上述評價指標進行B端產品的運營數據分析并得出迭代規劃。

3)產出

運營數據分析報告、產品迭代規劃。

二、總結

以上,我們完成了B端產品全流程的穿越。

可以看到B端產品經理除了“溝通能力、文檔整理輸出能力和項目管理能力”等通用能力外,還需要優秀的業務理解能力和方案設計能力。所以,“登山”的過程中要著重培養自己快速準確抽象業務流程,提煉通用解決方案的能力。

B端產品經理在職業生涯中會慢慢發現,業務癥結梳理到最后往往是流程問題,甚至是公司制度問題;僅僅是將線下流程線上化對解決業務癥結的作用很可能微乎其微。

總之,產品經理是一個需要不斷學習的崗位,共勉。

 

本文由 @伊甸東 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 需求獲取階段是否可以稱之為需求調研階段呢?

    回復
  2. 太強了,受教了~

    回復
  3. 優秀

    回復
  4. 好久沒見過有用的文章了

    回復
  5. 學習了。

    回復