在To B產品工作中，“業務建?！边@個概念十分常見，那么，如果將“業務建?！备拍钷D換至To C維度，產品經理可以從中獲得哪些啟發和感悟？這篇文章里，作者從“2023產品經理大會·北京站”的嘉賓分享內容出發，提出了他的思考和見解，一起來看。

“在工作時，老板跟我們說過不要成為一個“問題型產品”：只知道解決用戶問題，不知道如何真正地預估用戶需求。然而到底該如何去挖掘和解決用戶的需求，網上也有很多文章，無非都是說挖掘用戶場景，尋找根本需求等等，卻總給人一種淺嘗即止的感覺。

這次產品大會高暉老師的分享中，提到“業務建?！边@個概念，讓我對這個問題有了另外一個維度的思考。由于我是TOC產品，會嘗試將這部分概念轉化到TOC的思維上，雖然無法一一對應，但問題不大。”

一、什么是業務建模

高暉老師分享的內容中，業務建模指的是“基于業務導向和數據驅動的企業運營的普遍性問題的解決方案”。這是TOB的，我根據自己的理解，將文本轉化為TOC，就變成了“基于業務導向和數據驅動的用戶運營普遍性問題的產品方案”。

這里面我們發現，這幾個部分就是“業務”“數據”“用戶”。那么搭建好一個業務建模的話，就需要從這三個維度的組合。

每個公司都會有一個自己的主流導向，比如有的公司就重視數據，有的就重視用戶反饋。但其實在一個健康的體系中，這幾個都是缺一不可的，無論偏向哪一邊，都會出現各種問題。

二、為什么要做業務建模

1. 對業務

A. 了解業務底層邏輯

上篇文章我說過，我見過一些產品，做自己的業務做了一兩年，都說不清自己的業務底層邏輯到底是啥。至于每次提到要做什么，就對著競品從上往下抄。

這部分雖然在執行中不會出大問題，但只能解決表象，并不能真正地解決產品的根本問題?！白鲆粋€功能”很簡單，但是“為什么要做”“為什么不做”這才是需要思考的。（這類我經常會遇到的一個答案就是“競品有了”“用戶要求”“用戶沒要求”，總覺得emmmmm）

B. 判斷用戶真實需求

產品經理恨不得掰開用戶的腦子去看用戶到底想要啥，尤其是TOC產品經理，在用戶反饋中找到真實需求更是困難。我曾經做過用戶呼聲最高（TOP1）的反饋需求，但其實在數據表現上并沒有那么突出（需要根據數據看OKR是否達標）。而業務建模則可以讓我在需求階段，更加深入的去考慮這個需求到底是否是真實的用戶需求

C. 評估需求優先級

業務中最困難的就是需求排序優先級，資源有限而不得不舍棄一些。但由于需求來自于不同方，各個需求方都不退讓，導致需求很難舍棄。我曾經嘗試使用過行業內比較熱門的需求評估公式來進行評估（下圖），在實際工作中有一定效果，針對一些爭議性的需求，通過該評估表格能進行一定相對客觀的比較。而業務建模，則可以讓需求價值更加清晰，從而客觀的去評估優先順序。

2. 對自身

對于自身來說，學會拆解產品建模，產品才能夠真正的認識自己的產品形態應該怎么做，怎么去排需求優先級，怎么去確認需求價值；對于未來從事新的業務，尤其是一些創新的，自己從沒接觸過的業務，產品建模能夠讓自己快速上手，理清業務思路，這都是一個資深產品必備的技能。

三、如何做業務建模

我結合高暉老師的內容，結合了自己的思考和工作經驗，總結出了下面這些業務建模SOP。

1. 價值鏈

高暉老師分享內容中總結，每一個業務都會有自己的價值鏈，價值鏈其實就是商業模式+盈利模式。我覺得所有產品都需要認知的是，所有的產品都是為了商業服務的，即使短時間沒有要求，長期來看肯定會有要求；也許公司對于你這個業務沒有盈利要求，但你的價值也許是品牌宣傳，也許是用戶留存，他終究也是商業模式中間的一環。

結合上面，無論你現在所處的公司宣揚的是產品導向，還是用戶導向，還是數據導向，其實最終的閉環，都是“商業導向”。而只有基于商業導向，我們才能夠最準確的認識到自己的產品核心價值在哪。

2. 業務SOP

確認好價值鏈后，我們就需要搭建如何實現價值的業務SOP。業務SOP我理解分為橫向和縱向，縱向是用戶生命周期，橫向是產品功能流程。將用戶生命周期放進來，是因為我認為不同階段的用戶，產品需求是不一樣的，所以需要區分開之后再組合，才能形成一個完整的產品。

首先是縱向，以我之前做過的線上教育APP為例，我們會做一個完整的用戶AARRR模型（用戶獲取、用戶激活、用戶留存、用戶轉化、用戶傳播）。用于梳理用戶在到最終付費轉化之前，都應該會經歷哪些環節，從而制定我們的產品SOP。

比如在線上教育中，會通過公域流量和私域流量來獲得用戶線索，然后通過免費課/免費題庫做用戶激活和用戶留存，再通過付費課進行用戶轉化，低價轉高價，最終再老帶新，比如老用戶拉新獲得優惠券之類的活動。到此為止，完成用戶的生命周期。

然后是橫向，比如現在用戶需要聽一個課程，那么就需要進入APP——打開課程瀏覽頁面——打開課程詳情頁面——點擊付費——付費完成——進入課程播放頁面，這既是一個橫向的產品功能流程。

用戶的橫向和縱向都拆分好了之后，就可以對每個業務的單個環節進行架構拆解了。

3. 業務架構

以上面的購課轉化為例，里面就包含了商城系統、訂單系統、付費系統、用戶管理系統、媒體管理系統等等，這部分架構都是為了“購課轉化”這個業務環節服務的。

其實高暉老師也講到了，很多業務底層其實是共通的，如果把業務比作房子，那么架構模塊就是磚頭。大家都是用一樣的磚頭，但是可以搭建出不同的建筑。那么任何業務在我們眼里，都是一塊一塊的磚罷了。（后續有時間會嘗試針對不同主流業務做這種拆分梳理）

4. 產品架構

分享會中提到了“應用建?！焙汀皵祿！?，我個人理解就是“功能交互”+“數據設計”，也就是客戶前端和數據后端的區別。每個產品都做過，就不再去細說了。

接下來再總結一下老師分享的這幾個環節轉化的方法。

1）5W1H

2）事件風暴基于老師的內容，我重新去研究了一下“事件風暴”這個概念?；跇I務事件而開展的一種研討會，類似于頭腦風暴。那么我們可以得到的重心在于“事件”。

事件是基于價值鏈梳理出來的可量化業務行為。簡單總結就是誰（角色）使用了什么（輸入）做了什么（命令：動作）產生了什么（輸出）影響了什么（事件）。比如上面說的用戶購買了一個課程，然后去聽課，這里面就包含了多個事件，選課事件、下單事件、付費事件、聽課事件。事件風暴梳理對比用戶需求梳理，能夠更加全面宏觀的看到這個業務流的環節，而不是用戶導向的指哪打哪。

多人討論下，針對上面的流程，你想到了下單需要一個拼單系統，他想到了需要一個優惠券系統，我想到了如果實體商品庫存不足怎么辦。那么通過大家的腦暴，將所有的思路統一在一起，基于上述提到的事件將整個過程可量化、標準化，完成一個相對完整的產品架構。

事件風暴是出自于DDD（Domain-driven design領域驅動設計），DDD內容我簡單研究了一下較為復雜，后續單獨發文跟大家討論。

3）生產三要素

那么，新業務如何快速搭建新矩陣，高暉老師分享了三個基本元素“生產者（使用者）”“生產模式（運作流程）”“生產關系（各個生產模式之間的關系）”。搞清楚這三個元素，就可以做好業務分析。

舉例，一個在線教育APP的課程系統，生產者就是買家和賣家，生產模式就是購買和售賣，那么生產關系中，與購買耦合的有付費、訂單、物流等等。上游還有貨架瀏覽，下游退款退貨功能。通過這些幾個元素的組合，組成了業務模型的框架。（這部分講的比較快，我大致理解是這樣，有其他想法可以討論）

4）能力矩陣模型

高暉老師還提到一個能力是能力矩陣模型，將產品核心模型拆分為“場景”和“職能”兩個維度。而我們在實際的業務中，也可以通過這兩個模型將產品進行拆解，從而更加透徹的了解自己的產品模型。（下圖為會議分享的電商案例，這部分我后續也會像拆解業務架構一樣嘗試一下針對不同業務進行能力矩陣模型拆解）

總結，一直以來我在思考，資深的產品經理和初級的產品經理到底差距有啥，我知道是經驗差距，是方法論的差距，但一直都不知道我需要掌握哪些方法論。這次分享無疑是給我提供了很多的思路，這次的學習不僅將我工作中無序的思考通過有序的模型進行了“建?！?，對于我的職業技能，也搭建起了一個相對完整的“建?！?。