對于 B 端產品經理是做什么的，在之前做體驗設計相關掃盲分享的時候，就已經做了一定的說明。

沒有看過的同學可以略過，這次我就要更具體介紹 B 端產品經理到底是什么經理，它在項目中要發揮哪些作用，以及作為什么角色存在。

一、產品經理的基本認識

產品經理也叫 PM（ Product Manager ），是負責規劃產品功能并推進功能落地與實現的 “管理崗位”，也是互聯網行業中最具有傳奇色彩的職業，以喬布斯、馬斯克、張小龍、雷軍為首的商業領袖都以產品經理自居，這也讓產品經理被冠以 —— 離 CEO 最近的崗位的名號。

相信大家都知道當中存在很多捧殺的成分，如果產品經理就是 CEO 預備役，那么這個崗位的工作必然是和普通人、門外漢沒什么關系的，門檻也會高到難以企及。

一個從業人數并不少的主流職業，當然沒有傳說中的那么遙不可及。但產品經理到底在做什么，網上的描述又都很模糊，不僅新手看不懂，很多工作了幾年的 UI 設計師也沒搞明白。所以在這里我不打算用歸納式的語言來講解什么是產品經理，先從一個你們都能理解的場景切入。

比如，一家新的車企，在推出一款普通家用 A 級轎車車型后，想要豐富產品線推出第二個產品。根據市場部調研和領導層的分析，在戰略上決定下一款車型，做面向中產群體的 7 座 SUV。

但光做決定，就讓工廠開工生產，顯然是不可能的。那么直接開始車型的外型設計，或者零件的采購，系統軟件的開發，合理嗎？當然也不合理。在做這些具體的工作之前，還有個更核心的問題，這輛車除了是 7 座 SUV 以外，需要四個輪胎和車身外，其它的關鍵指標和功能呢？

比如這輛車用什么發動機，前驅還是后驅，具備什么操控輔助和影像系統，內部配置中座椅或方向盤的特色功能，不同配置車型有哪些配置差異等大量的細節都需要提前確定好。而這就是 “產品經理” 要發揮作用的地方。

領導、市場部做更宏觀的產品決策，但這些決策落地需要轉化成具體的 “需求”，讓后面的不同部門有清晰的執行目標和方向。所以，產品經理的主要職責，就是作為一個中轉站，將商業決策轉變成可執行的任務，并下發給不同的執行方。

在互聯網項目中，原理是一致的，產品經理的主要作用就是制定軟件本身的功能明細，確保設計師知道要設計什么頁面內容，以及讓前后端程序員知道要開發什么模塊和對應邏輯。這是產品經理最核心的職責。

而在一些特定的行業或中小企業，產品經理的責任會進一步擴大，除了要滿足需求的制定外，也同時具備更宏觀的商業決策權限。

最常見的比如老板自詡產品經理……或者在大廠有很多產品經理作為一個獨立項目的負責人，他實質上就是這個項目團隊的老板。這種情況并不是主流，但它們吸引了大眾最多的關注，所以我們往往把這種領導崗位職能作為產品經理的標準注解，實際上占絕大多數的產品經理僅僅是我們前面所說的需求中轉站。

但不管權限高還是低，需求的輸出過程都是必要的，很多團隊的問題就來源于有產品抬頭的領導并不完成產品該有的任務，只做宏觀的構想，但不給細節的明目，設計師和工程師團隊只能在 “這是一輛有四個輪子的 SUV” 的要求下自己憑感覺完成工作，過程和結果都是災難。

輸出需求是產品的核心工作，但是，不代表你把需求做出來了就代表完成了工作，商業團隊講究 —— 產出質量。

雖然你完成基本的工作就是給出一輛車所需的全部功能規劃，確保它能被制造并正常駕駛，但這肯定不夠，還必須要滿足對應的商業目標。比如讓用戶滿意評價超過友商賺吆喝擴大知名度，還是在維持現有銷量下降低生產成本擴大盈利率等。

所以應該做哪些功能，具體應該做成啥樣，這些決策就是產品經理面臨的最大的挑戰。雖然這種決策沒有戰略層面這么宏觀，但每次決策都會對后續的生產、交付、上線、收益產生影響。

換句話說，產品經理的工作就是設計出能滿足商業目標的功能，但商業目標的實現通常都是后驗的，方案再怎么吹得天花亂墜和發布后有沒有實現預期完全是兩碼事。這就延升出進一步的要求 —— 產品經理要對上線后的結果負責。

既然要對上線的結果負責，產品經理的壓力自然變得更大了，同時需要關注的事情也就更多。最直接的影響，就是方案是你自己定的，你就要確保設計和開發各自交付的結果符合你的預期，而不是最終交付出來的東西和你的方案牛頭不對馬嘴。

為了滿足這個條件，產品經理就有義務干涉產品的研發階段，檢查設計成果和開發成果，而不是把需求內容拋出以后就不聞不問。因為成果和進度的協調不做管理的話整個項目工期就會無限膨脹下去，而產品經理對方案本身的理解和熟悉度又是職業項目經理無法取代的，這就是產品經理也要行使項目管理職能的主要因素。

到這里，我們再總結一遍產品經理是做什么的：

“在宏觀的商業目標指導下，設計產品的功能，然后以特定文書形式交付給給執行團隊，接著管理項目的整體進度確保最終落地效果符合預期，實現商業目標的工作。”

二、B端產品經理的工作內容

前面了解了產品經理的概念，到這里，我們就要更進一步來解釋產品經理的工作內容和產出了。

但必須提前強調的一點是，產品經理也是一個很寬泛的抬頭，和設計師一樣，必須要圈定出范圍才能討論下去。比如界面、建筑、服裝、工業、造型設計師都是設計師，但顯然你不可能把他們歸類成同一個職業。

產品經理也有劃分，包含工業產品經理、汽車產品經理、硬件產品經理、快消品產品經理等等，我們討論的對象主要集中在軟件產品經理中。而面對種類繁多的軟件類型，市場就做出了進一步的劃分，最常見的就是 C 端和 B 端的劃分。更細致的還有根據功能模塊產生的，如支付產品經理、數據產品經理等。

我們這里主要討論的就是 B 端產品經理的工作，其它產品經理的類型在以后再解釋。

上面是產品經理的主要工作內容。

1. 需求分析

需求分析，就是考慮產品應該做哪些功能的過程。前面說過，功能的制定是考究質量的，不是隨便抄抄或者拍腦袋憑空構思出來的，所以一個專業的產品經理在制定具體需求之前，是一定要做大量分析的。

在 B 端，最重要的分析必然是業務相關的分析。比如為公司設計一個財務管理系統，那么最重要的工作肯定是首先搞懂這家公司有關財務的流程和條例，比如財務部門的組織架構，財務出納的審批方式，內部工資的發放和報銷規則等等。

這些全都是具體的業務信息，我們要設計一個系統肯定是圍繞著業務的要求和流程制定，尤其是找到業務中的痛點。比如轉賬打款流程中的多重審批并歸檔，需要數字化的解決方案保障內部的廉潔和預防貪腐的滋生。

業務的認識和痛點會構建整個項目的絕大多數功能和模塊，但一個復雜系統的組成肯定不是從單一維度中提取需求，還包含其它維度的考量。

比如維持系統本身運作的基本模塊，如日志、數據還原、資源管理、系統通知等，或者是基于用戶體驗的角度，添加如亮暗模式切換、便簽備忘錄、表格全屏模式等，再或用戶的建議反饋、老板的喜好和“妄念”……

最后還有兩個關鍵的要素，就是人力資源和項目周期，人力資源就是后續設計、開發、測試的相關人力，以及各自的專業水平，人數的多寡和專業水平的高低都會影響功能開發復雜度的上限。而項目的時間周期，決定了可以完成需求數量的上限。

受這兩個因素的影響，產品經理往往要對前面構思的需求做調整（多數是減法），將一些次要需求刪除或者優先級不高的留到下個版本再說。

所以，需求分析就是花費大量的時間，結合多個維度的信息來考慮產品應該做哪些功能。

在這個階段中，因為分析的維度和內容既多且雜，所以收集的材料、分析的過程、自己的思考，都需要通過特定的工具做記錄并整理。包括思維導圖、UML、框架圖、流程圖、文檔工具等，但因為是前期的構思階段，所以并沒有嚴格的行業規范，只要能滿足自己的目標即可。

2. 需求輸出

分析和規劃好這次版本的需求，你已經很清楚這次版本要做哪些工作，但那僅僅是對你自己而言，前面收集和整理的碎片化資料只有你自己看的懂，不可能直接讓別人來看這些東西。

所以，產品經理就要再做一個必要的工作，將你的想法通過更規范、清晰的方式輸出出來。這里面主要包含兩個要素，產品原型和 PRD 文檔。

產品原型 Product Prototype，就是將你對這次版本需要做的頁面、功能通過可視化的線框圖繪制出來。國內主要使用的專業產品原型繪制工具有 Axure 和墨刀。

產品原型工具的特點，就是可以比較快速的創建可交互的高低保真原型，比如頁面的跳轉，表單的操作，廣告輪播等，然后自己進行演示或者讓其他人直接上手操作試用。

雖然可交互原型看起來很有用，但對于很多專業團隊來說并不是特別在意該階段的原型是不是能交互，因為產品原型的目的是傳遞產品的功能和頁面大致框架，后面還有設計師來完成更具體的交互和界面，所以產品經理不需要額外浪費精力和時間去制作可交互的產品原型。

也正因如此，越來越多的產品經理開始改用 UI 設計軟件來做原型，比如使用 Figma、Sketch、XD 或即時設計等。雖然交互功能較弱，但是繪制頁面的效率遠遠高于原型設計軟件，能更高效的實現原型輸出的目標。

但光有原型圖例也不夠，因為每個頁面都會包含若干設計圖解釋不了的邏輯和信息，比如一個用戶名輸入框最大支持多少字符，支持哪些字符格式，或者這個下拉菜單中包含多少選項，選項的來源是什么等等。

這就需要 PRD 產品文檔來進行輸出，PRD 就是一個用于記錄產品需求詳情的圖文說明文檔，包含各類圖形和文字解釋，幫助團隊成員更詳細的了解本次版本中的需求和相關功能細節。

PRD 文檔有兩種形式，一種是直接在 Axure 類工具中創建不同頁面結合原型輸出的文檔的，另一種是使用類似飛書、語雀等線上文檔工具制作，需要將不同圖形從外部導入。還有一種日漸稀少的方式，就是用 Word、PPT 等辦公軟件制作。至于它們之間有什么優缺點，這在以后的分享中會具體說明。

完成產品原型和產品文檔，就是產品經理工作中最重要的部分，因為不管你有什么石破天驚、曠古爍今的想法，都需要把需求講清楚了別人才能做出來。

3. 需求評審

完成了需求的輸出，就可以交付文檔給團隊成員了嘛？在 “理想環境” 下文檔寫得夠清楚，確實直接交付設計師和程序員就可以開工了。

但既然是理想環境，那肯定就是現實不了的，比如你會遇到下面幾個問題：

1. 產品文檔不能保證寫的足夠清晰易懂，可能看不懂或者理解錯誤
2. 產品需求本身可能存在不少邏輯問題和缺漏，你自己沒有發現
3. 有些需求本身的存在會受到質疑，團隊成員不認同拒絕執行
4. 團隊成員不仔細看文檔就開始動工，工作結果充滿了 "自己的見解"

所以，產品經理還需要組織相關的產品評審會議，通過會議演講來解釋自己的產品方案。雖然評審聽起來好像就是開一次會，但實際上遠遠不止那么簡單。

一方面評審肯定是需要做相關的準備的，另一方面，一個有活力的團隊，產品評審并不是 “指派任務” 現場， 而是產品方案的 “批評檢閱” 大會。團隊成員大概率會用很挑剔的態度來審視你的方案，并提出大量的“友好建議”，企圖讓產品經理主動認識到自己的錯誤和不足。

如果真的只是方案的缺漏錯誤還好，畢竟都是客觀存在的問題。評審中最困難的是解決主觀上的反對建議，比如這個功能我覺得不好，那個功能我覺得用戶不能接受。當出現了不同團隊成員提出不同的反對建議，就很容易演變成形而上的爭論，全靠 “我覺得” 各執己見。專業的產品需要通過非常嚴謹的思路和想法采納或說服不同成員的觀點。

作為產品經理如果讓這種反對意見存在且不加解決，團隊成員對需求本身的認同度低，那么最后輸出成果的質量就必然受到嚴重的影響。最好的理解方式就是想想你的老板、上級整天布置給你的那些難以置信的看起來很弱 Z 的工作指示，你會有動力把它們做好？

所以產品經理需要通過非常嚴謹的思辨和解釋來解除對方的疑問，轉變對方的認知，并認同自己的方案。統一全員共識，就是這個階段最核心的工作。

不管是對方主觀臆斷還是確實存在問題，第一次評審大概率會存在很多地方需要改進，這就意味著評審結束后產品還要回去優化方案，然后再進行二次評審。

需求評審階段，是對產品經理綜合素養要求最高的一環，也是產品經理的 “受難記”。既要有良好的基礎水平和抗壓能力，也要有出色的臨場應變和邏輯思維能力。

4. 項目管理

產品的方案評審完，就等于把不同部門、成員的任務指派下去了，接下來的項目階段，就是不同部門和崗位的執行階段。

但是，不管任務的指派有多嚴謹，需求白紙黑字寫得有多清楚，我們也不能確保項目的執行一帆風順，且結果百分百符合預期。

中間依舊會出現一系列的阻力，比如：

1. 設計做的交互和樣式不符合實際需求
2. 部分功能在開發過程中發現技術水平無法實現
3. 人事變動需要銜接導致的一系列影響
4. 老板中途有新想法需要加上怎么落地
5. 開發過程出現惡性 BUG 難以修復怎么辦
6. 設計階段前端程序員沒事做后面時間又不夠

前面說過，產品經理是要對項目產出質量負責的，所以項目的執行不可能撒手不管，在執行環節中四處救火做出新的決策是也是最基本的職責之一。而缺乏管理的項目就越會讓產品經理在這個階段的工作量成倍的增長，疲于奔命。

為了不挖坑讓自己跳，產品經理就必須制定出更有效的項目管理方法并實踐，在保證最終產出質量的同時，能盡量減少問題的產生，提高實現的效率。

所以，產品經理就還需要去學習和掌握不同的項目管理知識和工具，比如瀑布、精益、敏捷、北極星、OKR、測試驅動、快速應用、關鍵路徑等等。但不管什么知識，都需要通過實踐去嘗試，來慢慢形成自己的見解認識，初窺管理這門 “藝術”。

成熟的產品經理從每個版本的啟動階段就要開始進行項目管理了，包括自己前期需求分析到評審的過程都是管理中的一環，確保整個項目的周期內流程脈絡清晰，不同角色各司其職，繁忙但有序的推進。

項目管理的本質就是 —— 讓項目成員在指定周期內產出最大的能效。

有效的管理可以盡量避免重大事故的產生和無效的內耗，但依舊會有很多需要產品去解決，或者做審核、決策的地方。比如交互的評審、設計的評審、開發框架的選擇、產品的測試、上線的準備等等，理論上，這個產品發生的大小問題每個都和產品經理有關。

所以即使產品方案輸出并評審通過后，也不代表產品經理就能閑下來，還有數不清的大小會議要開，大小問題要解決，直至產品能順利上線。

再回憶一遍，產品經理的工作就是：

“在宏觀的商業目標指導下，設計產品的功能，然后以特定文書形式交付給給執行團隊，接著管理項目的整體進度確保最終落地效果符合預期，實現商業目標的工作。”

產品理就像在汪洋中駕駛小船的舵手，要根據目的地分析出航線，并在旅途中反復勘測來微調行進的方向。

優秀的產品經理對個人能力的要求是極高的，除了核心產出物所需的專業技能外，還需要具備不同行業、崗位的通識。所以產品最常見的問題下面我們總能見到產品是否需要掌握設計、交互、體驗、前端、后端、算法、數據等技能的問題……

以上，就是對產品經理工作的基本掃盲。

結尾

相信看到這邊，你已經對產品經理這個崗位有了初步的認識和理解，因為篇幅關系，每個步驟所需的工作內容我會在后續做進一步的分享和整理。

下一篇，我就會重點討論 B 端和 C 端產品經理之間的區別。

歡迎關注作者的微信公眾號：「超人的電話亭」