B端產品從前期的業務診斷、業務分析，到后期的方案形成，這個過程中，大致會經歷怎樣的環節或步驟？這篇文章里，作者便做了相對完整的梳理，不妨來看看，或許會對產品同學們有所幫助。

一、B端產品的市場分析與業務調研

1. 分析市場并細分客戶群體

任何商業行為的核心都可以用一句話描述，即：給誰用，提供什么價值，解決什么問題。

商業的起點，首先要分析市場，確定目標客群，從而針對目標客群的痛點設計產品解決方案。

前期的市場分析步驟以及目標分析點如下：

注意：

在現實中，B端產品切入的方式不止這一種，有的企業甚至并沒有嚴格遵循以上步驟做市場分析，而僅僅是在某個行業深耕久了，對行業比較了解或者摸索到了該領域還存在潛力，進而選擇了自己熟悉的賽道去做探索；或者機緣巧合工作過程中接到了一個大客戶訂單，通過和客戶的項目制合作，完成了對該業務領域的學習和認知，進而深耕于該領域。

2. 針對選定的目標做市場調研

第一節已經分析完如何選定目標市場或目標客戶，接下來我們從客戶的內部視角，探討具體的業務問題調研和分析。

尤其是商業軟件產品，在啟動設計階段，不可能憑空基于對業務的假想完成設計，更不可能針對一個有代表性的標桿客戶進行充分調研，透徹理解業務，并刻畫出MVP版本。

1）業務調研的五個環節

2）業務調研的三個階段（初期-中期-后期）

3）業務調研的目的

B端產品面向企業用戶，產品目標是更好的支持業務運轉。所以調研目標是分析業務現狀和業務問題，為方案設計提供支撐，最終解決企業的業務問題，提升運轉效率。

C端產品直接面向終端用戶，而且一般承載著公司的商業目的（可能是變現，也可能是獲取更多流量等）。所以調研目標是獲取真實有效的用戶體驗的用戶需求和體驗感受，以便后面結合用戶的需求，痛點設計解決方案最終實現商業訴求。

3. 業務分析的三層架構

在企業開展新業務時，首先要結合自身的戰略地位、組織發展階段，思考業務目標和當前情況，從而推導出基本的管控模式，再進一步設計組織結構與績效激勵體系，基于這些頂層設計，最后才是業務開展的具體流程體系。

B端業務分析框架：

二、B端產品的整體方案設計

1. 通過精益畫布構建商業模式

產品不是憑空想出來的，尤其是業務型B端產品，設計這類產品最怕拿個榔頭（產品）找釘子（客戶），這樣多半會失敗，而應該是先找到釘子，然后去拿榔頭釘釘子。

精益畫布中給出了商業模式構建的九個關鍵要素，這九個關鍵要素可以幫助我們把商業運作的關鍵問題都想清楚，如圖示：

2. 使用PMF（product/Market Fit）進一步對初期市場進行驗證

PMF將新產品市場評估為四個階段：

1. 概念階段：提出了早期的產品創意想法和產品概念。
2. 原型階段：將產品的外觀實現出來，可以讓潛在客戶試用并提出感受。
3. MVP階段：定義產品的最小可行性版本并實現。
4. PMF階段：將MVP版本投入市場，檢驗市場接受度（需要從留存率，頁面訪問深度，跳出率等多個指標判斷產品是否契合了市場達成PMF）

盡管業務型B端軟件比較厚重，但在商業層面的運作上，一定要始終秉承“尊重市場，尊重客戶，找準定位，快速迭代”的理念。

3. 確定核心業務流程

現在讓我們回到產品設計本身，我們要梳理核心業務流程，定義問題邊界，并確定產品定位。

從核心業務流程切入產品設計，是開展整個設計工作非常好的起點。核心業務流程代表業務的主干脈絡，需要思考業務的各個參與方和涉及的系統。

只有定義清楚業務邊界，才能定義產品邊界。很多時候我們發現產品的定位模糊混亂，這是因為設計時對產品要解決的業務問題的邊界和場景定義得就不清晰。

在核心業務流程繪制過程中，只需要繪制關鍵場景和節點，不用陷入細節流程。

4. 明確產品定位

產品定位是產品設計的指導思想和靈魂，梳理了核心業務流程和業務場景后，我們對客戶的問題、痛點有了明確的范圍界定，接下來我們從宏觀和執行兩個層面來探討產品定位。

1）宏觀層面的產品定位

宏觀層面來講，產品定位是指對于一個選定的目標市場，企業如何設計產品來承載價值主張來解決目標客戶的痛點和訴求。用一句話來概括就是：產品的目標客戶是誰？解決了他的什么問題？為他提供了什么價值？這也是精益畫布中1、2、3點描述的要素。

針對企業自研自用系統，也需要明確宏觀層面的產品定位，但自研系統不存在目標客戶群體的概念，因為服務的目標客戶就是自己公司的業務方。

2）執行層面的產品定位

任何一套復雜的軟件產品，都不太可能只靠一套獨立系統來運作， 而會由若干子系統來協同運作，支撐業務。

在B端產品設計中，我們要逐步分解、細化產品設計，在確定了產品整體定位后，下一步我們要思考應該設計幾套子系統來匹配不同的業務場景，支撐業務運作，這也是執行層面的產品定位問題，我們要說清楚，產品由幾套子系統組成，每套子系統的目標用戶是誰，解決他們的什么問題。

劃分子系統時，可以通過目標用戶與場景進行子系統的定義和拆分。拆分的目的是讓系統從業務層面上邊界更加清晰，易于理解和使用，這也會傳導到技術實現上，讓系統底層的設計邏輯更加嚴謹、完備，在高粒度層面做到松耦合、高內聚。

另外，產品經理也要認識到，多套子系統的定義只是在應用層面上的劃分，在技術實現上很可能是一套統一的底層加多套前端的表皮而已。

5. 梳理應用架構

所謂應用架構，是公司所有軟件系統的整體結構和布局，任何公司的應用架構都不是隨意設計的，都有復雜的設計思想蘊含在其中。

1）自研軟件系統的應用架構

在設計一套新的系統時，要考慮如何和公司現有的系統架構融合，不同系統的模塊之間如何銜接。這項工作復雜度較高，不僅需要有豐富的架構經驗，而且需要深刻理解業務特點和可能的演進方向，還要熟悉本公司的系統架構，這樣才能快速的提煉出相關問題。

如果公司已經發展了多年，軟件體系結構已經相對成熟，這就意味著在設計一套新的系統或產品時，完全可以復用現有的部分系統或模塊，從而快速實現，提高系統建設效率，減少重復開發，更重要的是可以保證整體系統架構合理。

舉例，支持分銷系統的公司整體應用架構圖如下：

2）商業化軟件平臺的應用架構

首先，任何一個商業化軟件產品，在實施過程中都要考慮和甲方已有架構的融合問題，如果產品經理不懂應用架構的常識，在軟件的集成能力設計，模塊的通信設計上就會出問題。這不單純是技術問題，還是一個業務問題，甚至是商業問題。

其次，乙方廠商如果有多產品線協同，同樣需要考慮應用架構的體系設計問題。一方面，產品矩陣背后需要有一體化的架構設計思考，另一方面，為提升公司研發效率需要避免重復造輪子等問題。

所以不論是甲方企業背后的應用架構，還是乙方產品體系的應用架構，沒有本質的區別，因為軟件工程和管理應用系統從底層到上層的設計思路都是相通的。

6. 定義場景與功能模塊

從場景到功能模塊，有三種經典的模塊抽象思路，分別是基于業務領域抽象模塊，基于業務場景抽象模塊，基于業務對象抽象模塊。

1）基于業務領域抽象模塊

最常見的模塊劃分方式是基于業務領域的，業務領域是一個很寬泛的概念，可能包括業務部門、業務單元、業務主體等。業務領域作為模塊劃分依據，讓模塊之間體現了更強的內部聚合性及松耦合性。

如下圖所示展示了典型的系統功能模塊設計，體現了基于業務領域劃分模塊的特點：

基于業務場景抽象模塊和基于業務領域抽象模塊的區別之處是后者的內聚屬性更強，和技術架構的模塊設計比較貼合；而前者更多從用戶體驗和業務邏輯出發來做模塊劃分，在場景菜單下可能會融合多個模塊的功能。

2）基于業務場景抽象模塊

有時候通過業務場景來定義菜單反而邏輯更清晰，更容易理解。例如，在某些流程屬性比較重的業務系統中，通過業務場景劃分模塊也能較好的做到功能模塊解耦合的抽象歸類。如下圖的菜單設計，一級菜單學員管理，課程管理，直播管理，助學管理等模塊，都是典型的教學場景。

3）基于業務對象抽象模塊

還有一種比較少見的模塊抽象思路，即基于業務對象抽象模塊，也就是將業務開展中的對象（人、事、物都有可能）定義成模塊。

如圖所示，在該人員管理系統中，用戶，角色，部門，崗位都是關鍵業務對象，在關鍵業務對象背后其實也影射了場景。

以上分享了三種劃分模塊的思路，在實踐中，往往會將幾種思路融合在一起，沒有絕對的原則和方法論。企業的運作管理體系已經發展多年并非常成熟，對應的管理軟件建設也十分成熟；任何形態的管理軟件系統，B端產品，在模塊劃分和抽象設計中都要盡量參考同類業務軟件系統的設計思路，這是前人重要的總結沉淀，蘊含著對業務的深刻理解和洞察，切勿自己發明創造，浪費時間。

7. 規劃演進藍圖

通過繪制系統的功能模塊圖，我們可以明確業務和系統的規劃脈絡。將能想到的功能集合都列出來，這是一個做加法的過程。但是我們不可能一次實現全部功能，而要根據業務優先級，拆分成幾期來完成，所以接下來需要做減法：確認產品的功能規劃與實現節奏，就是常說的演進藍圖（roadmap）。

對于一個新系統，我們一般分幾期來實現：

• 一期項目聚焦解決最基本的業務流程線上化問題及核心痛點，也就是支撐業務能閉環運行的最小功能集合，其中有一個原則可以參考：凡是可以手動處理和解決的問題，暫時都不做系統支撐。
• 二期項目聚焦于解決部分特殊業務剛需的訴求。
• 三期項目聚焦風險控制，并強化運營功能。

隨著設計的深入，以及業務的開展、變化、功能模塊可能需要修正和調整，但只要業務的本質模式沒有變化，功能模塊就不應該出現結構性的改動。功能模塊圖和演進藍圖代表的是概要性方案，指明了整體的產品方向，是后續細化設計的指引和準則。

8. 數字技術賦能業務

單獨從業務效能優化的角度來講，數字技術賦能業務可以總結為五個階段，這五個階段循序漸進，逐步推演，對業務進行全面優化和賦能。

這五個階段分別是流程化，線上化，自動化，數據化，智能化，如下圖：

三、B端產品的細節方案設計

B端產品的細節方案設計，通過對整體方案中總結出的業務場景，逐個進行深入分析，包括業務數據建模、頁面流轉設計、界面設計、權限設計等，再對關鍵場景的各個擊破中梳理出系統全貌的細節。這些工作流程和任務都是產品經理的必修課，即便沒有經歷從0到1的設計過程，也會在日常的迭代過程中經常接觸。

1. 業務數據建模

業務數據建模也叫實體關系，指將業務的核心數據對象特征進行提煉，歸納并設計對應的底層數據模型的過程。

B端產品進行細節設計的常見流程是，首先梳理業務流程，接下來提煉背后的數據模型，然后基于流程和數據模型確定頁面流轉圖，再著手進行每個頁面的具體設計同時提前規劃好系統用戶角色，最后完成權限設計。

為什么數據建模這么重要呢?這是因為軟件系統的核心本質上是對現實世界的對象和規則的抽象與管理。軟件系統設計的難點恰恰在于合理地總結客觀世界的對象和關系，并實現最基本的數據模型設計。只有總結并設計出正確的數據模型之后，才能思路清晰地完成功能模塊和交互操作的設計

實際上，業務數據建模是數據庫設計中最重要的部分，會影響數據庫表結構的設計，體現了設計者對業務本質的理解和認知。很多產品經理常常忽略業務數據建模只關注功能界面設計，最終陷人混亂的邏輯中。一定要在設計細節方案初期就進行業務數據建模。

針對數據建?？煽偨Y為三個步驟：找到實體、梳理關系、確定關鍵屬性，如下圖所示：

參考：不同實體關系實例圖

2. 流程和角色

接下來，我們開始設計分銷客戶管理場景下業務的流程和角色。流程合理、角色清晰是系統正確設計的前提和保障，流程確定后，再繪制頁面流轉圖，最終完成頁面細節設計。

通過跨職能分系統流程圖，可以清晰的看出誰（操作角色）在哪兒（哪個系統）做什么（完成什么工作）。

角色在業務開展初期已經存在，但是在系統設計過程中，需要結合業務流程進一步梳理，并修正完善，以保證各角色的工作內容是明確并固定的，各角色之間盡量避免職責交叉，這樣才能保證團隊成員分工明確，共同協作，達成業務目標。

主業務流程圖示例圖如下：

3. 繪制頁面流轉圖

對于系統設計來講，業務流程圖依然屬于比較粗粒度的概要性設計，如何將它與軟件產品的頁面設計對應起來，繪制頁面流轉圖是一個很好的銜接方式。

頁面流轉圖描述的是，用戶完成某項工作需要訪問的頁面及頁面跳轉順序。繪制頁面流轉圍可以幫助設計人員審視、思考系統中的頁面設計方案，包括系統中總共需要哪些頁面，哪些頁面可以重復使用，哪些頁面需要定制化開發。

一般來講、我們繪制頁面流轉圖時，都是針對某個單一角色繪制某個特定場景下的頁面訪問和跳轉邏輯，從用戶的視角來梳理一遍所有相關頁面，每到一個新頁面時都要思考:需要新做一個頁面，還是可以復用原有頁面? 最終整理出系統涉及的所有頁面的初稿。

頁面流轉實例圖如下：

4. 提煉匯總頁面功能清單

不同的場景有可能會涉及相同的頁面，因此非常有必要統一整理不同場景涉及的所有頁面。有時，在頁面清單的梳理中就可以將關鍵功能點也整理出來。

頁面功能清單示例圖：

5. 界面設計

我們已經完成了功能模塊設計、演進藍圖設計、業務數據建模、業務流程梳理、頁面流轉梳理，功能清單等一系列環節，已經細化到每個操作需要訪問哪個頁面、總共有哪些頁面、現在需要為每個頁面設計具體的交互功能以及具體呈現，即進行界面設計。

雖然在整個界面設計之前的流程很長，但在此梳理期間，我們對整個業務形態已經了然于心，對整個項目和產品的掌控力越來越強。此時再去做界面設計，已經是水到渠成之事。

界面設計流程：

注：

本篇文章只挑選了部分業務場景作為例子進行講解，并沒有覆蓋整個系統所有的細節功能設計。在實踐中，我們在細節方案設計階段，要挑選優先級和重要程度比較高的業務場景，進行進一步的業務調研，梳理每個場景背后的業務流程，完成功能設計，最終匯集得到完整的產品方案。