對于 B 端產(chǎn)品經(jīng)理是做什么的，在之前做體驗設(shè)計相關(guān)掃盲分享的時候，就已經(jīng)做了一定的說明。

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

一、產(chǎn)品經(jīng)理的基本認識

產(chǎn)品經(jīng)理也叫 PM（ Product Manager ），是負責規(guī)劃產(chǎn)品功能并推進功能落地與實現(xiàn)的 "管理崗位"，也是互聯(lián)網(wǎng)行業(yè)中最具有傳奇色彩的職業(yè)，以喬布斯、馬斯克、張小龍、雷軍為首的商業(yè)領(lǐng)袖都以產(chǎn)品經(jīng)理自居，這也讓產(chǎn)品經(jīng)理被冠以 —— 離 CEO 最近的崗位的名號。

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

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

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

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

比如這輛車用什么發(fā)動機，前驅(qū)還是后驅(qū)，具備什么操控輔助和影像系統(tǒng)，內(nèi)部配置中座椅或方向盤的特色功能，不同配置車型有哪些配置差異等大量的細節(jié)都需要提前確定好。而這就是 "產(chǎn)品經(jīng)理" 要發(fā)揮作用的地方。

領(lǐng)導(dǎo)、市場部做更宏觀的產(chǎn)品決策，但這些決策落地需要轉(zhuǎn)化成具體的 "需求"，讓后面的不同部門有清晰的執(zhí)行目標和方向。所以，產(chǎn)品經(jīng)理的主要職責，就是作為一個中轉(zhuǎn)站，將商業(yè)決策轉(zhuǎn)變成可執(zhí)行的任務(wù)，并下發(fā)給不同的執(zhí)行方。

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

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

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

但不管權(quán)限高還是低，需求的輸出過程都是必要的，很多團隊的問題就來源于有產(chǎn)品抬頭的領(lǐng)導(dǎo)并不完成產(chǎn)品該有的任務(wù)，只做宏觀的構(gòu)想，但不給細節(jié)的明目，設(shè)計師和工程師團隊只能在 "這是一輛有四個輪子的 SUV" 的要求下自己憑感覺完成工作，過程和結(jié)果都是災(zāi)難。

輸出需求是產(chǎn)品的核心工作，但是，不代表你把需求做出來了就代表完成了工作，商業(yè)團隊講究 —— 產(chǎn)出質(zhì)量。

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

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

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

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

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

到這里，我們再總結(jié)一遍產(chǎn)品經(jīng)理是做什么的：

"在宏觀的商業(yè)目標指導(dǎo)下，設(shè)計產(chǎn)品的功能，然后以特定文書形式交付給給執(zhí)行團隊，接著管理項目的整體進度確保最終落地效果符合預(yù)期，實現(xiàn)商業(yè)目標的工作。"

二、B端產(chǎn)品經(jīng)理的工作內(nèi)容

前面了解了產(chǎn)品經(jīng)理的概念，到這里，我們就要更進一步來解釋產(chǎn)品經(jīng)理的工作內(nèi)容和產(chǎn)出了。

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

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

我們這里主要討論的就是 B 端產(chǎn)品經(jīng)理的工作，其它產(chǎn)品經(jīng)理的類型在以后再解釋。

上面是產(chǎn)品經(jīng)理的主要工作內(nèi)容。

1. 需求分析

需求分析，就是考慮產(chǎn)品應(yīng)該做哪些功能的過程。前面說過，功能的制定是考究質(zhì)量的，不是隨便抄抄或者拍腦袋憑空構(gòu)思出來的，所以一個專業(yè)的產(chǎn)品經(jīng)理在制定具體需求之前，是一定要做大量分析的。

在 B 端，最重要的分析必然是業(yè)務(wù)相關(guān)的分析。比如為公司設(shè)計一個財務(wù)管理系統(tǒng)，那么最重要的工作肯定是首先搞懂這家公司有關(guān)財務(wù)的流程和條例，比如財務(wù)部門的組織架構(gòu)，財務(wù)出納的審批方式，內(nèi)部工資的發(fā)放和報銷規(guī)則等等。

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

業(yè)務(wù)的認識和痛點會構(gòu)建整個項目的絕大多數(shù)功能和模塊，但一個復(fù)雜系統(tǒng)的組成肯定不是從單一維度中提取需求，還包含其它維度的考量。

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

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

受這兩個因素的影響，產(chǎn)品經(jīng)理往往要對前面構(gòu)思的需求做調(diào)整（多數(shù)是減法），將一些次要需求刪除或者優(yōu)先級不高的留到下個版本再說。

所以，需求分析就是花費大量的時間，結(jié)合多個維度的信息來考慮產(chǎn)品應(yīng)該做哪些功能。

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

2. 需求輸出

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

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

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

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

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

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

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

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

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

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

3. 需求評審

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

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

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

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

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

如果真的只是方案的缺漏錯誤還好，畢竟都是客觀存在的問題。評審中最困難的是解決主觀上的反對建議，比如這個功能我覺得不好，那個功能我覺得用戶不能接受。當出現(xiàn)了不同團隊成員提出不同的反對建議，就很容易演變成形而上的爭論，全靠 "我覺得" 各執(zhí)己見。專業(yè)的產(chǎn)品需要通過非常嚴謹?shù)乃悸泛拖敕ú杉{或說服不同成員的觀點。

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

所以產(chǎn)品經(jīng)理需要通過非常嚴謹?shù)乃急婧徒忉寔斫獬龑Ψ降囊蓡?，轉(zhuǎn)變對方的認知，并認同自己的方案。統(tǒng)一全員共識，就是這個階段最核心的工作。

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

需求評審階段，是對產(chǎn)品經(jīng)理綜合素養(yǎng)要求最高的一環(huán)，也是產(chǎn)品經(jīng)理的 "受難記"。既要有良好的基礎(chǔ)水平和抗壓能力，也要有出色的臨場應(yīng)變和邏輯思維能力。

4. 項目管理

產(chǎn)品的方案評審?fù)?，就等于把不同部門、成員的任務(wù)指派下去了，接下來的項目階段，就是不同部門和崗位的執(zhí)行階段。

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

中間依舊會出現(xiàn)一系列的阻力，比如：

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

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

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

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

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

項目管理的本質(zhì)就是 —— 讓項目成員在指定周期內(nèi)產(chǎn)出最大的能效。

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

所以即使產(chǎn)品方案輸出并評審?fù)ㄟ^后，也不代表產(chǎn)品經(jīng)理就能閑下來，還有數(shù)不清的大小會議要開，大小問題要解決，直至產(chǎn)品能順利上線。

再回憶一遍，產(chǎn)品經(jīng)理的工作就是：

"在宏觀的商業(yè)目標指導(dǎo)下，設(shè)計產(chǎn)品的功能，然后以特定文書形式交付給給執(zhí)行團隊，接著管理項目的整體進度確保最終落地效果符合預(yù)期，實現(xiàn)商業(yè)目標的工作。"

產(chǎn)品理就像在汪洋中駕駛小船的舵手，要根據(jù)目的地分析出航線，并在旅途中反復(fù)勘測來微調(diào)行進的方向。

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

以上，就是對產(chǎn)品經(jīng)理工作的基本掃盲。

結(jié)尾

相信看到這邊，你已經(jīng)對產(chǎn)品經(jīng)理這個崗位有了初步的認識和理解，因為篇幅關(guān)系，每個步驟所需的工作內(nèi)容我會在后續(xù)做進一步的分享和整理。

下一篇，我就會重點討論 B 端和 C 端產(chǎn)品經(jīng)理之間的區(qū)別。

作者：超人的電話亭