編輯導(dǎo)語：目前，關(guān)于C端產(chǎn)品經(jīng)理的文章不在少數(shù)，相比之下，對于B端產(chǎn)品經(jīng)理的工作流程、整體方法論的討論占了少數(shù)，并且缺少從整體上進(jìn)行概括的文章。本文作者作為B端產(chǎn)品經(jīng)理，通過結(jié)合自己的工作實踐與認(rèn)知，對于B端產(chǎn)品經(jīng)理的工作流程進(jìn)行了一次復(fù)盤分享。

一轉(zhuǎn)眼，我已經(jīng)從事B端產(chǎn)品經(jīng)理近兩年時間了，一直沒沉下心對自己的工作內(nèi)容和所學(xué)所想進(jìn)行系統(tǒng)總結(jié)。恰好最近身邊有不少朋友和同學(xué)想要轉(zhuǎn)行產(chǎn)品經(jīng)理。

寫下這篇文章算是對朋友關(guān)于B端產(chǎn)品經(jīng)理的一個簡要介紹，也作為自己兩年來的工作復(fù)盤。下文我將B端產(chǎn)品經(jīng)理工作流程拆解，從各環(huán)節(jié)的工作內(nèi)容概述、注意事項和主要產(chǎn)出三個方面進(jìn)行介紹。

一、流程拆解

圖1、B端產(chǎn)品經(jīng)理主要工作流程

1. 需求獲取

1）概述

產(chǎn)品經(jīng)理以深度訪談、問卷調(diào)查、輪崗實習(xí)等方式獲取需求方的需求，其中深度訪談這個方式最為常用。

需求獲取是一個由粗略到細(xì)致的過程，從概括性的項目背景說明、價值分析，深入到目標(biāo)用戶確認(rèn)、業(yè)務(wù)現(xiàn)狀、業(yè)務(wù)問題和期望效果的梳理。視項目實際情況，可能需要和基層執(zhí)行者、中層業(yè)務(wù)負(fù)責(zé)人和高層領(lǐng)導(dǎo)分別進(jìn)行溝通。

2）注意事項

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

3）產(chǎn)出

訪談記錄、調(diào)查報告、實習(xí)總結(jié)。

2. 需求分析

1）概述

產(chǎn)品經(jīng)理針對獲取的原始需求進(jìn)行偽需求的過濾，梳理得到真實需求并匯總進(jìn)項目需求池，進(jìn)行優(yōu)先級判斷和迭代規(guī)劃等管理。

其中優(yōu)先級主要從重要/緊急程度兩個維度進(jìn)行判斷；迭代規(guī)劃則是權(quán)衡工期要求和開發(fā)資源，在當(dāng)期版本中刪減優(yōu)先級低的需求，在后續(xù)版本中再開發(fā)。

根據(jù)確認(rèn)下來的當(dāng)期需求，進(jìn)行業(yè)務(wù)流程、功能架構(gòu)、工作流狀態(tài)定義的梳理工作——即進(jìn)行框架層的需求設(shè)計，也是進(jìn)行詳細(xì)需求設(shè)計前的必要步驟。

2）注意事項

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

梳理出真實需求后，根據(jù)實際項目要求和資源限制，可能還需要從技術(shù)、業(yè)務(wù)、成本和收益、風(fēng)險和策略等方面進(jìn)行可行性分析。

3）產(chǎn)出

項目需求池、需求概要設(shè)計（包含業(yè)務(wù)流程圖、功能架構(gòu)圖和工作流狀態(tài)定義等）。

圖2、項目需求池

圖3、業(yè)務(wù)流程圖

圖4、功能架構(gòu)圖

3. 需求review

1）概述

產(chǎn)品經(jīng)理依據(jù)需求概要設(shè)計（業(yè)務(wù)流程圖+功能架構(gòu)圖+工作流狀態(tài)定義）向需求方再次確認(rèn)需求內(nèi)容并闡述對應(yīng)的解決方案。

這個過程主要是用于確保產(chǎn)品經(jīng)理對需求理解的正確、完備，在進(jìn)行詳細(xì)需求設(shè)計前及時糾錯，同時也盡可能的避免后續(xù)環(huán)節(jié)中的需求變更。

2）注意事項

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

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

3）產(chǎn)出

修正后的業(yè)務(wù)流程圖、功能架構(gòu)圖和工作流狀態(tài)定義等需求概要設(shè)計內(nèi)容。

4. 需求設(shè)計-詳細(xì)

1）概述

依據(jù)確認(rèn)無誤的功能架構(gòu)圖、業(yè)務(wù)流程圖等內(nèi)容，產(chǎn)品經(jīng)理進(jìn)行需求文檔的編寫。需求文檔中需要說明頁面內(nèi)容、交互、字段釋義和數(shù)據(jù)邏輯等產(chǎn)品細(xì)節(jié)。相較于內(nèi)容詳實全面的PRD，我個人推薦“原型+文字/表格注釋”的形式進(jìn)行需求文檔的輸出。

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

2）注意事項

需求文檔作為產(chǎn)品經(jīng)理的主要輸出物，是一個衡量其基礎(chǔ)能力是否牢靠的重要指標(biāo)。

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

此外，需求文檔具備“規(guī)范的內(nèi)容格式”也同樣重要。內(nèi)容格式的標(biāo)準(zhǔn)化不僅能讓產(chǎn)品經(jīng)理在一個清晰的框架下編寫文檔，文檔更具條理性，內(nèi)容更完整詳實，而且有助于知識傳承和統(tǒng)一管理。對個人和團隊都十分重要。

3）產(chǎn)出

需求文檔：

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

5. 需求評審

1）概述

產(chǎn)品經(jīng)理組織項目組成員參與并依據(jù)需求文檔進(jìn)行需求宣講，讓產(chǎn)品、UI、前端、后端、測試等同事對需求的理解達(dá)成一致。

這個環(huán)節(jié)也是產(chǎn)品經(jīng)理經(jīng)歷各方“拷問”的重要環(huán)節(jié)，尤其是技術(shù)同事經(jīng)常會在產(chǎn)品設(shè)計上深究，因為這往往決定后續(xù)的技術(shù)選型并左右開發(fā)難度。

2）注意事項

需求宣講需要注意語言表達(dá)的邏輯和條理，應(yīng)當(dāng)從“項目背景&目的、業(yè)務(wù)場景”擴展到“業(yè)務(wù)流程、功能架構(gòu)”，最后再詳細(xì)展開“具體頁面和功能”——即結(jié)構(gòu)性思維的應(yīng)用。

人無完人，哪怕是高級產(chǎn)品經(jīng)理也不是每個項目都能考慮到所有細(xì)節(jié)。但這并不是產(chǎn)品經(jīng)理在進(jìn)行需求設(shè)計時“大而概之”的借口，相反，產(chǎn)品經(jīng)理需要在設(shè)計時進(jìn)行深度思考，盡可能考慮到所有細(xì)節(jié)。最好能做到面對大家的疑問，都能有理有據(jù)的應(yīng)答。

3）產(chǎn)出

依據(jù)評審結(jié)果修訂的需求文檔。

6. 項目排期&項目管理

1）概述

將整個項目從“需求對接”開始，到“項目上線”為止，各個階段的負(fù)責(zé)人以及人日消耗以表格形式羅列。目的是讓項目組同事明確各個關(guān)鍵項目節(jié)點，產(chǎn)品經(jīng)理（或者專門的項目經(jīng)理）以此為依據(jù)進(jìn)行項目管理。

2）注意事項

項目管理需要定時關(guān)注各環(huán)節(jié)實際進(jìn)度與預(yù)期進(jìn)度的差異，及時反饋風(fēng)險、協(xié)調(diào)資源。如果覺得線下管理、溝通效率低，可以采用TAPD和Teambition等協(xié)同辦公軟件。

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

3）產(chǎn)出

項目排期表。

圖7、項目排期表

7. 產(chǎn)品審查

1）概述產(chǎn)

品上線之前，產(chǎn)品經(jīng)理需要對UI和功能進(jìn)行審查。

一般來說具體的界面測試、數(shù)據(jù)準(zhǔn)確性測試和兼容性測試等會由專業(yè)的測試同事負(fù)責(zé)。產(chǎn)品經(jīng)理只需要驗證產(chǎn)品主流程通暢即可。實際執(zhí)行也很簡單，依據(jù)之前梳理的業(yè)務(wù)流程，發(fā)散出各個業(yè)務(wù)角色的用例，進(jìn)行流程驗證即可。

2）產(chǎn)出

產(chǎn)品審查報告：

圖8、產(chǎn)品審查報告

8. 系統(tǒng)運營宣導(dǎo)

1）概述

一個業(yè)務(wù)系統(tǒng)初次上線或者版本更新，需要針對系統(tǒng)各角色開展相應(yīng)培訓(xùn)。

一般而言，企業(yè)自建自用的B端產(chǎn)品不會分配相應(yīng)的運營人員，往往是產(chǎn)品經(jīng)理一并負(fù)責(zé)系統(tǒng)的運營，需要輸出針對各個業(yè)務(wù)角色的“系統(tǒng)操作手冊”，并視情況召開宣導(dǎo)會進(jìn)行業(yè)務(wù)流程和角色操作的演示。

如果該產(chǎn)品有向外部推廣的意愿，產(chǎn)品經(jīng)理也會負(fù)責(zé)產(chǎn)品白皮書之類的編寫。

2）產(chǎn)出

系統(tǒng)操作手冊、產(chǎn)品白皮書。

圖9、系統(tǒng)操作手冊

9. 運營數(shù)據(jù)分析&迭代規(guī)劃

1）概述

產(chǎn)品上線后，產(chǎn)品經(jīng)理和運營同事通過分析用戶行為數(shù)據(jù)得出產(chǎn)品的優(yōu)化方向。常見的B端產(chǎn)品評價指標(biāo)如下：功能完善性、系統(tǒng)可靠性、時效性、易用性、兼容性、數(shù)據(jù)準(zhǔn)確性、界面排版合理、響應(yīng)速度等。

一般采用問卷和訪談的形式進(jìn)行收集，根據(jù)收集的數(shù)據(jù)，可分析出用戶在當(dāng)前版本的痛點，結(jié)合在“需求分析”階段擬定的“迭代規(guī)劃”，共同構(gòu)成最終的迭代計劃。

2）注意事項

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

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

3）產(chǎn)出

運營數(shù)據(jù)分析報告、產(chǎn)品迭代規(guī)劃。

二、總結(jié)

以上，我們完成了B端產(chǎn)品全流程的穿越。

可以看到B端產(chǎn)品經(jīng)理除了“溝通能力、文檔整理輸出能力和項目管理能力”等通用能力外，還需要優(yōu)秀的業(yè)務(wù)理解能力和方案設(shè)計能力。所以，“登山”的過程中要著重培養(yǎng)自己快速準(zhǔn)確抽象業(yè)務(wù)流程，提煉通用解決方案的能力。

B端產(chǎn)品經(jīng)理在職業(yè)生涯中會慢慢發(fā)現(xiàn)，業(yè)務(wù)癥結(jié)梳理到最后往往是流程問題，甚至是公司制度問題；僅僅是將線下流程線上化對解決業(yè)務(wù)癥結(jié)的作用很可能微乎其微。

總之，產(chǎn)品經(jīng)理是一個需要不斷學(xué)習(xí)的崗位，共勉。

本文由 @伊甸東 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。