產品經理是個非常玄學的崗位，沒有具體的技術，或者是知識點等作為背景，但是要想做好一個產品經理確實非常不容易，它所包含的知識點是一般的書籍或者專業課所涉及不到的。因此經驗和天分就變得非常重要。

作為一名多年的B端產品經理在中后臺領域還是有一定的發言權，所以接下來我將把目前短暫幾年的產品經驗，盡量撈干貨的總結總結。

PM被戲稱說是最接近CEO的崗位，但大家卻從來不提具體怎么成為CEO，CEO成功=方法論*（人+勢）?？梢妼τ诖蠖鄶档腜M和CEO的相似點也就只有方法論了。那么我們今天就以B端PM來說說PM與CEO的相似點——方法論。

作為B端PM平日里最常打交道的就是系統，流程，邏輯等等，但優質的PM還需要在整個產品周期中形成完整的方法體系。一個B端PM的完整工作流程一般包含場景調研，需求分析，系統功能實現，管理運營，以及進階思考5個主要模塊。

一、場景調研

場景是需求設計的前提，是需求使用的載體。沒有場景就沒有需求，脫離了場景的需求即使做的再漂亮也是在做無用功。PM在進行需求階段之前都會做詳細的場景調研，證明需求的可用性。通常場景調研包含用戶訴求，竟對情況，行業潛在背景幾個方面。

1.1 用戶訴求

對于B端產品經理所要面對的用戶通常是本公司內部的同事，例如CRM系統的面向用戶就是公司內的業務同事，做訂單交易的PM經常要打交道的是公司內部的采購，交易員等等。

• 因此了解用戶訴求首先要做的就是明確調研目標，知道本次需要了解的核心問題點是什么，帶著問題點去調研思考有利于節省資源，直擊問題，避免事倍功半；
• 其次需要選擇調研的對象，分清楚此次需求要面向哪些用戶，進而對他們開展調研，只有這一部分直接使用者才最有發言權；
• 在調研過程前要準備好要開展的方法，常用的幾種調研方法有問卷法，調查法，訪談法，電話法等，不同的對象，不同的場景都需要使用不同的方法對待，這對一個PM的靈活應變能力是個不小的挑戰；例如采訪地位較高的用戶時就不能簡單地使用問卷法，應盡量用訪談的形式等；
• 接下來就可以實施調研了，實施過程中需要PM靈活應變可能出現的各種情況，不論期間困難與否，一定要記著最初的行動目標，這或許可以在關鍵時刻對你有不小的幫助；
• 最后一步是調研回來后輸出調研報告，調研報告在此不贅述，本人做事比較隨性，個人認為只要能有條理的說明白了，說全了就行，形式不限。

1.2 竟對情況

不止是PM同學們，各行各業的從業人員只要是為了牟利而生，都無可避免地要做竟對分析，其實PM的竟對分析更多的還是與對手在功能或是一些細節上的PK，而商人們則是更全方面地，尤其是在收益角度地分析竟對。因此本節我就引用著名經濟學家劉潤的竟對分析理論，用商業的角度分析一下PM行業的竟對評估。

目標用戶，做PM的核心點就是在各個行動階段都要把握目標，分析競對時也不例外。首先需要明確要跟競對對比的產品的主要受眾群體是哪些人，該批人群的特質是什么，最重要的是該批人有什么需要，畢竟你的需求做出來是要給用戶使用的。那么競對也一樣，所以需要優先分析你和競對的目標用戶到底有什么異同，例如：攜程旅行網的目標用戶主要是針對高端商旅用戶。因此推薦一些機票高星酒店的搭配組合就比較合適，但是途家民宿則更傾向于自由旅行者，所以旅游景區等元素就變得更重要。

產品定位，分析完有需求的用戶后，還要對自家產品和競對產品的定位有清晰的認識。通常來說一個產品的定位不會是滿足所有場景或所有用戶，往往采用優先解決某些痛點問題的方法，定位于具體的某塊領域。之后在已有的業務定位上開始擴展或轉型，例如keep，最初的定位就是針對健身的愛好者，提供切入市場的訓練課程，在積累一定用戶后開始轉型于社交和電商，實現多方面盈利。

產品功能，產品功能是競對分析中最大的一塊內容，也是最耗時的，它需要沿著從外到里，從粗到細的體驗競對，嚴格按照樹狀結構一步一步操作競對產品，對于每一步的背景，觸發，結果都要嘗試一遍并記錄。從外到里指的是從首屏入口進入，沿著不同垂直線條走到操作終點，分析線條上的每一步情況；從粗到細指的是從整體功能觸發，按層級順序縱向操作，橫向對比，把每一個功能都細化到具體場景，或許可以得到不同的分析結果。當然，功能是產品的核心，在使用中每個人都有自己的方法，無論怎么測用，能達到目的就好。

運營策略，產品服務于目標，一定不是上線功能就截止的，后續的運營策略必不可少，如果說產品是一個具象的產物，那運營策略就是基于這個產物的具體玩法以便于達到具體目的。很多產品的迭代改善就是通過運營過程中發現的問題而演變出來的，因此競對的運營產品策略也是需要特殊分析對待的。

1.3 行業潛在背景

行業情況，一個高級的產品經理，分析競對的時候除了基礎的產品和用戶分析外，往往還要更關注宏觀上行業的潛在情況，無論公司大小，在資本市場中生存都如泛海行舟，再大的公司也無法改變隨著行業憂戚與共的命運，行業興則公司興，行業衰則公司衰。

行業是社會演變的風向標，順勢而為才是公司生存之道，這樣公司的產品也會有了明確的設計方向。近幾年興起的生鮮和配送就是社會演變的產物，在這個上升期的行業內也漸漸催生出像每日優鮮，美菜等優質公司。

公司定位，通常情況下，所選競對公司應同屬一個行業，在行業大環境明確的前提下，每家公司在行業內的定位也往往不一樣，這很大程度上決定了公司內部產品規劃的方向，所以一個團隊的管理者需格外注意。

舉個例子，馬蜂窩在流量落地過程中開展酒店機票等業務，他們在OTA行業的定位就主要是重點發力于海外市場，因此他們的產品設計也會更海外化，他們的競對目標主要并不是攜程美團等，而是海外品牌Agoda，Booking等。

二、需求分析

在前期調研結束后，我們通常會收集到各式各樣的信息，也會有各式各樣的要求，但是一定要注意此時經常出現的“信息陷阱”。在海量數據下，看似有非常多的問題亟待解決，也有非常多的需求需要滿足。但是在這種信息瀑布中我們更要謹慎對待，不是所有的信息都是有用的信息，不是所有的需求都是真正的需求，應避免落入陷阱中。因此我們就需要用一系列分析方法，仔細評估需求。

2.1 診斷需求

辨別需求的真偽，在拿到用戶反饋的一些列需求中，我們首先要做的就是篩選出哪些是具體真正的需求，因為用戶是直接使用者，提出的問題也是直觀使用問題，往往不能通過表面問題揪住本質反饋，就會出現自己也不知道自己到底想要什么的情況，這時就需要產品經理的專業理性分析，從繁亂的需求點中找出真正的需求。

舉個例子：在一則寓言故事中描述了一段對話

問：“你在做什么？”

答：“我在修籬笆”

問：“為什么修籬笆？”

答：“因為我要搞個花園”

問：“為什么要搞個花園呢？”

答：“我要自己種菜吃”

問：“為什么自己種菜吃呢？”

答：“因為我想省一部分生活花銷”

你看看，如果有人給你說要修籬笆，那你是真的幫他把籬笆修的漂亮，還是想辦法給你找到便宜又美味的蔬菜呢？

分析需求的背景，需求往往由所處的環境和所面對的問題所決定，在充分分析完問題后也要注意需求的背景，同樣的需求放在不同的背景下，所產生的效應也是不一樣的，不能一概而論。就像30年前的電影院訴求和今天影院訴求有著天壤之別。

2.2 行業現狀

需求要適應行業

每一個特定的行業都有一套自己的玩法，需求在行業內也要符合行業的規則，逆著行業趨勢很可能會浪費公司資源，嚴重的話還會為公司帶來損失。例如生鮮行業的發力點在于庫存，供給，物流等，那么偏偏注重會員體系的需求注定是失敗的，倒也不是說不做，只是應該先緊著核心訴求點罷了。

行業主流方案

跟隨行業主流并不是隨大溜，人云亦云的表現，因為這樣對于用戶的學習成本最低，可以很快讓用戶接受，而且行業之所以如此存在一定有他的道理，行業現狀也一定是在前人們無數次探索和教育用戶之后形成的行業現象。翻開搜狗搜索，頭條搜索，百度搜索的三家頁面，你就會發現他們的設計幾乎出自同一個模板，在滿足核心功能滿足用戶的基礎上再適當進行創新即可。

2.3 收益平衡

在分析需求時還有一個核心關鍵點就是要注重收益，這個收益包含縱向的成本收益關系，也包含橫向的交叉業務成本，可以說收益對于需求是否要做起著決定性作用。

做需求的收益分析，首先從它的利弊影響入手，也就是說做這個需求會帶來什么好處和什么壞處，如果有壞處，那么所帶來的好處是否能夠cover掉壞處。如果可以那么則需求可能成立，否則一定會被老板們拍回來，在之后的需求設計階段還要注意將弊端最小化，盡可能的減少損失。

ROI回報，需求分析的核心因素就是要就算方案的投入產出比，老話說賠本的買滿不能干，從企業角度說，做了就是為了要獲得收益，需求分析應本著用最小的代價獲得最大的收益為原則，盡量提升ROI。當然這里的收益也不全指金錢收益，可能也體現在用戶收益，體驗收益，流程收益等等，很多時候是無法量化的，這就非常需要產品經理的全面衡量。

說完需求縱向的自我分析，還有很重要的橫向交叉業務分析，一個需求，尤其是對于B端需求來說，總會涉及到上下游不同系統之間的交互，因此對于其他團隊的影響也是要考量在內的。

2.4 未來規劃

這一點道理是眾所周知的，方案需要有一個長久的規劃，不能只看眼前，但是真正做到的人卻很少。特別是在創業型公司，多數情況的方案都是應急方案，一個產品的生命周期甚至只有幾周。其實這種現象也是可以理解的，畢竟創業期本身就是在多方向試探，精益求精的階段，產品為業務發展也改變也很正常。

因此產品的未來規劃可以從以下兩個方面進行：

• 需求本身的可持續性，在調研完成后，產品經理應該對于整個行業和業務有個自己的判斷，應具備主流方案的靈感，讓需求方案本身就有一個較長的規劃期，甚至項目初期就可以規劃出至少3期迭代，保證核心功能可以不斷完善，而不是只為了應急救火而打補丁。
• 業務規劃發展，對于業務型系統來說，業務主導需求的情況非常普遍，這是業務就是產品團隊的用戶方，產品經理應該熟練掌握業務節奏，在不偏離大方向的基礎上完成眼前的需求，這樣即使后邊有變化也可以進行兼容，不至于推翻重做。

這里我另附一個最常見的需求分析公式——HMW——how might we…?（我們可以怎樣…？）

在一個場景里，我們首先要明確用戶和他們遇到的問題，例如：一對情侶去了公園卻發現沒有能坐下來的地方。

接下來加上拆解問題的不同方向：

正向：我們可以怎么解決情侶想坐下的問題？

逆向：我們可以怎么避免這對情侶坐下？

轉移：我們可以怎樣使這對情侶除了坐下外，去做點別的事情？

接下來在每一方向之后思考各需要幾步解決，然后仔細評估每種方法的利弊，以最小的代價最好地解決問題永遠是王道。

三、系統功能設計

具體功能設計永遠都是大家樂此不疲地爭論模塊，一個產品經理總會為自己的系統方案付出全部生命力，業內有句話說，要像對待自己孩子一樣對待自己的產品，哪個人不會善待自己的孩子呢？那么又有哪個產品經理會輕視自己的產品呢？

所以很多產品經理變成了“某懟懟”，誓死要為自己的“孩子”據理力爭。

另外每個人有自己的設計經歷和見解，具體系統功能也會依托具體的業務要求，因此在這里我不會就功能設計詳細展開，只聊聊常用的B端產品的共用設計方法。

3.1 核心業務流程

核心功能是每一期產品的必要前提，特別是現在很多公司開始倡導敏捷開發，在有限時間和資源分布的情況下，必須要保證每一期的核心訴求完備，之后才能進行分期迭代。

把握好核心功能后，整個產品周期將會變得明確，即使出現分支問題，也能快速抓住核心提出解決方案。

3.2 模塊化流程

模塊化是B端產品一個很重要的思維模式，B端產品最常打交道的就是復雜系統，我經歷過的最長的一個電商交易鏈條，涉及過10幾個大系統，20幾個細分小系統的開發，他們之間相互關聯，交互耦合。每次遇到這類需求時都像解數學題一樣，這邊可以了，那邊又出現問題。

如管理學中講的阿米巴經營一樣，系統功能上我更崇尚模塊化，每個功能系統都是自己的最小單元，完善封裝后只是負責向外提供標準接口，盡可能對復雜系統解耦。

另外基于模塊化思維的一個具體實現方式就是配置化，在每個模塊下抽象出共性因素，組成配置因子，根據業務不同，對不同的因子做排列組合搭配，實現不同的業務流程。在我進入第二家公司之后不久，就應用這種方法重構了原本非常復雜的供應鏈系統，使系統可以支持更復雜的業務場景，變得更靈活。

3.3 數據建模

俗話說：兵馬未動，糧草先行。在功能系統設計之前，我們需要設計好相關的業務數據，業務數據就是系統的糧草，有了數據才會有信息流，有了信息流才可以在系統中流轉起來，不然系統就是個空架子毫無用處。必要時可以請數據產品們協助，一起制定數據維度和指標。

基礎數據完善的作用很關鍵的還有在于功能數據評估上，系統開發之前需要定好未來的數據分析維度指標，可以通過數據表現來分析系統問題，這樣后面的產品迭代也可以有跡可循。

舉個電商系統的例子：京東銷售的某品牌背包，在外網看上去是一個背包，它背后其實是非常細化的數據顆粒的組合，包括產地，品牌，材料等基礎信息，另外在整個交易流程中，每個步驟上還有埋點記錄用戶行為的業務數據。當產品經理拿到這些數據后會建立自己的指標體系，用來分析該產品的詳情情況和數據情況，后續便于規劃迭代方向。

這樣蘊含在實物流下的一套信息流就建設完成，因此我們常說PM應該具備一個較強的數據能力。

3.4 流程創建

如上所述有了基礎數據流，有了模塊化的系統單元之后，就可以根據業務場景把每個系統單元串起來，構建完整流程。構建流程是B端產品的精髓地方，提前需要了解好歷史邏輯和可能涉及到的坑點，方案本身一定要在縱向上考慮周全，覆蓋掉方案可能引起的所有問題，橫向上也要注意跟其他系統之間的交互，不要留坑。

3.5 界面交互

對于B端產品來說，流程功能是里子，而界面交互是面子，好的產品不僅要做好里子，更要做好面子，這樣無論用戶是誰都能有較好的使用體驗。

B端產品和C端產品的界面交互上往往存在一些差異，C端界面更注重視覺，美感，會站在用戶的心理角度衡量頁面上的每一個交互跳轉和文案圖標；而B端產品則側重界面對于功能的體現，然后才是交互的提示，美工。B端產品的界面設計往往偏工程化，從界面則可見產品的邏輯，不需花哨的裝飾。

3.6 角色權限

最后一塊功能設計，我們說說權限系統。權限系統是在業務功能全部實現的基礎上進行的功能管理，完備的權限分配不僅可以充分管理系統分工，有時還能巧妙的解決流程問題。就像一把鎖一樣，把不匹配的流程跟用戶隔離開。

角色權限系統一般設計時包含資源樹管理，角色管理，權限配置幾個部分。首先需要將所有系統模塊資源化，每個功能都作為一個資源；其次按照組織架構或是功能架構，把用戶分為不同維度的集合；最后通過權限分配，將模塊化的功能制定給具體某一批用戶角色。例如管理員有對薪資系統的編輯，修改和查看權限，而普通用戶則只有查看權限。

四、運營管理

系統功能上線并不是重點，反而上線后的運營和迭代才是產品生命周期的重頭戲。通常上線功能后需要保證培訓宣貫給使用者，然后定期進行后評估，并實施策略調整等。

4.1 項目運營

培訓宣貫，系統功能只是初步搭起了功能的舞臺，“戲”具體要怎么唱，主要還是看后期的具體運營方法。但首先需要給一線的使用者做好充分的講解培訓，必要的話可以安排課后測試，擇優上崗等方法。完備的公司體系通常還設有專門的培訓部門，建立專人專項的培訓制度?？梢钥闯雠嘤枌τ贐端產品來說的重要程度。

日常運營，B端的系統最鮮明的特點就是面對的使用者是“自己人”，能及時的收到第一手反饋資料，并通過群體化運營直接和使用者溝通，高效提供解決方案，即使是做SAAS服務的平臺，對于用戶的反饋也是可控的。

4.2 策略調整

系統功能上線標志著需求入口已經打開，已經成功邁出了第一步，但是后續的數據反饋和功能迭代也尤為重要。在系統設計初期的數據埋點此時就發揮出了作用，我們需要按照流程環節，功能目標提取數據，用系統的數據分析方法分析上線成果，并輸出完成分析報告。

很多需求的優勢和劣勢往往在設計初期并不知道，只有經歷了市場實戰的洗禮才會被暴露出來。數據分析就像一臺醫療儀器，可以把復雜系統中存在的問題客觀顯現出來，以便于制定后續產品規劃方向。

對于非純功能性系統，例如交易性平臺，電商平臺等在搭建完系統功能后還需要注重策略的分析，畢竟此時系統也背上了很多業務和收益指標。需要B端PM立足于產品功能，放眼于收益管理，發現問題，調整策略。

4.3 需求迭代

需求迭代分為主動和被動，理想狀態下在系統設計之初就能對系統功能有長遠的規劃，并利用多期迭代實現最終目標；但現實中還經常存在被動的需求迭代，目的是為了補以前留下的坑點或者遺漏點。但無論哪種，都算是產品生命周期里重要的組成部分，僅靠PM很難在初期就排查出所有問題，只能說需盡力籌劃，邏輯謹慎嚴密。

業內為了適應變化莫測的需求場景，開始逐漸倡導敏捷開發，以MVP最小版本快速滿足每一期的核心需求，這樣以最小單位快速迭代的方法不僅可以及時調整業務方向，也能快速對之前遺留坑點做到補救，是目前產品規劃里較受歡迎的方式。

五、進階思考

整體介紹完產品設計的基本方法論后，最后一個大模塊簡單闡述一下產品的進階思考。每個人的經歷和所處的行業背景不同，對于進階的看法也會不一樣，我把業務型B端產品的進階思考主要分為業務趨勢規劃和系統功能拓展，其中企業級系統系統架構的發展值得單獨拿出來講述。

業務發展規劃，無論面向什么用戶的系統，最終都是需要交付使用的，從電商交易到企業內化使用者都為其規劃了明確的發展方向，系統作為核心支持模塊當然也不能脫離業務實際。

高階的產品經理除了對于產品自身的打磨外，還需要具備參與業務的能力，要深入業務其中和一線的使用者，管理者共同規劃業務發展，在合理業務前景的前提下設計系統方案，這樣也會對于產品迭代節奏有整體把控。

系統功能規劃，如上所述，系統在業務沿著線條的走向而規劃肯定是鐵律，每個產品經理都應明確自己負責系統所對應的業務場景，即使不能做決策，也要在設計方案中有體現。產品的迭代路線大體上就是業務發展的方向，在共同前行的路上不僅為業務提供功能支持，也要承擔起實時校驗業務走向的作用。

下面附上一張圖，描述的就是迭代產品在業務規劃中的體現，在確定要制作機動運輸工具的業務指標下，每次的產品迭代都會輔助業務重新修訂方向，最終達到完美解決方案。

企業級系統規劃，最后我覺得有必要單獨把企業系統發展拎出來說說清楚，其實作為B端產品經理的技能是可量化描述的，對于企業來說需要的系統總是逃不過基本的架構，如下圖所示：

產品經理應該把這幾塊系統的設計流程作為基本功，打好基本功的前提下再去做上述的特點拓展，業務運營等工作，這樣有助于產品經理形成系統的知識體系，做事情也能條理清晰，不至于手足無措。產品經理在企業級別的系統規劃中還應該具備大局觀，并不是每個業務系統都是一成不變的，在基礎的架構上需要進行適當的增刪改，才能滿足各業務細節。

例如早期小型企業可能只有訂單交易和首付款流程，一套簡單的ERP就能滿足所有業務場景，但隨著發展壯大，需要對于客戶做一些運營策略，或者需要對于公司內部人員做統一管理，這時就需要CRM系統和人力資源系統的加持。

總結一下

通篇文章介紹了側重于B端產品的系統方法論，從場景調研，到需求分析，功能設計，到運營管理和進階規劃。

誠然，本文只是從整體框架角度介紹方法論的布局模塊，其中具體每個模塊都是值得編寫一本書的，在這里篇幅有限，均不展開贅述，如有興趣的朋友，歡迎私信留言交流~

本文由 @雪頂斜陽 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議