『壹』 B端公司如何進行產品運營
相比目前市場上C端運營的一片百花齊放，B端產品的公司大多都是沒有做產品運營的，只有部分做sass產品的公司才會專門進行運營相關的工作。
B端公司不做產品運營的原因通常是認為B端產品的運營能為公司帶來的收益與價值有限，與其將資源投入到運營上，不如加強渠道的建設。產品運營就是做內容建設、用戶維護和活動策劃，除了用戶維護有價值外，其他內容投入產出比太低，這是B端公司不變的認知誤解。
但事實上，內容建設、用戶維護、活動策劃都是產品運營的方法。產品運營的本質就是通過各種途徑去達成既定的產品指標，而方法只是工作內容的表象，因此對於B端產品來說渠道建設也是運營，更寬泛的說，市場即運營。
對於C端產品AARRR模型五個環節的指標就是產品運營的核心目標，而B端產品的指標則簡單粗暴——公司產品業績，或者直接點說就是銷售額。
相比較來看，C端產品的運營比較強調運營的方法與手段，在完成各個數據指標時需要使出奇技淫巧，而B端則不重技巧與手段，客戶源穩定所以各環節相對固定，所以運營方法用好，建立起框架是B端公司的主要方向。
表1-1 C端與B端運營對象區別
表1-2 B端產品的運營對象
二、運營框架
在運營B端產品時，建立一套運營框架是必要的，在框架的各個環節採取對應的方法指導運營，以提升產品業績。
B端的運營框架是從市場渠道-產品傳播的通路，類似於C端從用戶的生命周期開始建立框架模型，B端從產品自身與客戶接觸的流程出發，來建立運營框架模型。
B端產品運營的框架分為5個環節：打通渠道、客戶服務、品牌建立、口碑傳播、內容投放。所有運營的方法都分布在這五個環節中，而運營工作也是基於這五個環節展開的。
1.打通渠道
觸達客戶，即通過什麼樣的渠道/路徑找到目標用戶群。通過運營的方式，尋找到目標客戶，並將目標客戶轉化為產品客戶。誠然，最好的運營是讓客戶主動找上門來，對於B端的產品來說，打通渠道非常依賴於公司內的市場資源與業務人員的市場運作，渠道通路是直接影響銷售額的主要因素。
2.客戶服務
客戶服務主要作為產品的輔助手段存在，有助於實現產品的快速落地及價值轉化。客戶服務的重點在於提升客戶對於產品的滿意度。
在客戶服務的過程中，維護大客戶和老客戶的關系是重中之重，原因在於B端產品的獲客成本非常之高，所以把握住已有的客戶資源是客戶運營的關鍵一點。
如何建立起一套客戶服務的標准化流程，主要從客戶培訓、方案實施、異常響應處理、後期維護等四個角度出發，處理各種服務過程。
3.品牌建立
品牌對於企業來說是非常重要的門面，他能很好的體現一個產品的價值。所以，在B端產品拓展市場的過程中，除了渠道資源，最重要的就是品牌，業務B端產品與業務是深度關聯的，產品價值很難直觀的展現給客戶，只有投入到業務後客戶才能感受到產品價值。
因此，建立一個能為產品背書的品牌，使產品必然會受到客戶的歡迎，這是一本萬利的做法。品牌傳播的本質是提升產品影響力，塑造產品價值，提升公司影響力地位，使收獲更多客戶資源，從而達到創收目的。
4.口碑傳播
口碑傳播，即當產品為用戶創造價值，並得到用戶認可後，運營將這一內容以案例的形式傳播出去。與品牌建立類似，口碑傳播讓客戶來為產品背書，尤其是行業內的知名公司——燈塔效應。對客戶來說，行業內競爭對手使用的產品對其更具有吸引力，口碑傳播對於B端產品有遠遠大於C埠碑的客戶轉化率。
5.內容投放
在基本搭建完成品牌與口碑之後，運營需要嘗試向社會平台進行內容投放，簡單來說就是軟文與廣告投放，通常B端產品運營只針對那些有一定客戶基礎的產品，這樣能使效益最大化。
在內容投放時，做好用戶畫像，確保精準投放，這點與C端運營的本質是相同的。明確哪些是產品的潛在用戶，對於那些相對封閉的B端產品做內容投放是重中之重，因為內容投放的價值是有限的，所以內容投放一定要提前做好方案，規劃策略。
三、總結
綜上，B端產品的運營目標是提升產品銷售額，為公司帶來可見的利潤增長，運營方法的核心指標在於提升客戶的「產品價值預期」與「使用滿意度」。
B端產品的運營框架並不必嚴格按照流程執行，五個環節間的關系依賴程度不高，但是存在相互促進的作用，後期的環節的完成度一定程度上可以幫助公司進一步的拓寬渠道。因此，搭建品牌提升產品價值，提升滿意度使行業內客戶口碑傳播，精準的內容投放，均可以幫助產品拓寬已有渠道，實現公司盈利。
『貳』 B端產品員工管理優化及其歷史數據處理
總結一下最近做的一個優化點，由於涉及到底層的東西，所以在此優化中，歷史數據的處理是最麻煩的。有時我們認為最簡潔、大家一致認同的方案不一定是最適合的。
這里提到的是企業管理軟體中的員工管理與登錄賬號的管理。如果沒有過相關經驗不容易理解的話，可以聯想一下OA系統，我們身為公司的一員，需要在OA系統中處理一些公司的業務，我們擁有OA賬號。你的OA登錄後看到的內容一定與你的領導登錄系統看到的內容是不一樣的，因為你們擁有的許可權不同。同樣小王也是公司的一員，但其是基層員工，在OA系統中可以查到小王的基本信息，但小王並沒有OA的登錄許可權。
對於一款B端管理系統，系統要管理企業的所有員工，根據員工的不同崗位，管理員分配給員工不同的系統許可權，或者沒有系統許可權（即沒有系統的登錄賬號）。一些傳統的ERP軟體把這一點做的相當靈活，可能滿足很多極端的場景。事情是相對的，足夠的靈活，便要犧牲掉易用性，勢必會對用戶造成困擾。
上兩張圖是一些傳統的ERP的管理模式，先建立員工，員工有自己對應的崗位，然後建立賬號，每個賬號有對應的角色（角色可以理解為許可權的打包體，不同的賬號可以共用同一個角色，即擁有角色中包含的許可權，修改角色的許可權，則擁有該角色的賬號的許可權一並被修改），然後把員工與賬號綁定建立關系。這樣做就相當的靈活，員工與賬號是兩條獨立的線，最後把其關聯起來。員工不綁定賬號即代表此員工無系統的登錄賬號，賬號不綁定員工即可能這是一個管理員的賬號，沒有具體的人操作。
這樣做的缺點，一是操作復雜，一個員工如果要使用系統，其資料要到兩個地方建立，學習成本與維護成本高；二是容易造成混亂，一個員工給了銷售員的崗位，但在其綁定的賬號里卻給了收銀員的許可權。下圖是一個真實的案例，客戶實在是搞不明白員工、崗位、賬號、角色之間的關系，為了給員工某個許可權時，把所有的崗位都配給了該員工，但該員工仍沒有想要的許可權。
即然不同的崗位會擁有不同的許可權，那為什麼不在崗位上直接設置許可權呢，而在員工的創建時直接選擇是否開通登錄賬號，減少操作、減少客戶要接受的概念。
方案中，在新增員工時選擇是否開通登錄賬號，如果開通，則給出默認登錄賬號與密碼，無需客戶再設置；頁面左側可按崗位對員工進行篩選，然後可以對崗位進行許可權的設置。這樣客戶就可以在這一個頁面中完成員工與登錄賬號的維護，方便快捷，且不容易出錯。
優化後的整個流程的確是要整潔很多，但是我們這不是一個從零開始的系統，做這種大的改動時一定要考慮到歷史數據的處理。我們現有的客戶該怎麼辦？新的改版會對他們造成哪些影響？這就需要我們拿新的設計方案與原有的系統做比對，原有系統中的每一個欄位每一個概念，到新的設計中要怎麼體現。如角色，這個概念將在新的設計中消失，賬號列表也將不復存在，這樣的改動，歷史數據要怎麼呈現呢？老客戶對新的設計是否適應，是否需要重新學習？學習成本的高低？
為了處理歷史數據，對設計方案做出了調整，把賬號管理的入口放在員工管理頁面，使其弱化。之前賬號與角色的概念仍然存在，弱化賬號與角色的概念，減少點擊率。新增員工，如果開通登錄賬號，則賬號管理列表自動生成一個賬號；新增崗位時，便自動生成一個對應的角色，對崗位進行許可權的設置，即是對角色設置許可權。以前的邏輯仍在，仍能滿足老數據，對於新簽的客戶，只要建立崗位與員工即可，方便快捷。 而老客戶，在發版後第一次進入此頁面時，給出浮層提成，告知客戶這里的變化。
在開發之前，抽樣幾個老客戶進行了調研，客戶一致認為新的設計比之前更加簡潔、容易理解，並表示弱化賬號管理可以接受。
我在文章中只提取了主流程，實際上歷史數據的處理相當復雜，有些數據的處理是我們在前期做設計時考慮不到的，這就需要後期與開發人員再不斷的溝通，這種情況要提前與開發哥哥打好招呼，預留足夠的開發時間。
翻閱客戶數據，有時我們考慮的復雜的情況其實並不存在。如，沒有綁定員工的賬號，極少，數百家店 上千條的賬號里，只有十幾條賬號沒有綁定員工，其中三分之二的數據是因為之前復雜的流程造成的錯誤數據，已被禁用，剩餘的幾個是集團管理員的角色，這幾個賬號極少被使用到。通過與幾家客戶的溝通發現，他們使用系統是為了記錄，如果哪裡出錯了可以有據可尋，可以通過系統去查找哪個環節的錯，誰出的錯，如果賬號不綁定員工那就責任不到人了。雖然傳統ERP的方案很靈活，但使用起來不方便，容易把人繞暈，並且這所謂的靈活在實際的場景中並沒有被用到。
做B端產品最忌諱大而全，然而B端產品很容易被做的大而全，因為我們面對的是不同的客戶，客戶之間雖然有很多相似性，但他們也有自己的獨特性，一旦滿足不了他們的獨特性 我們將有可能失去該客戶，我們失去的極有可能是幾十萬、甚至上百萬的收款，而這直接關繫到KPI的完成，對於這種情況，領導會讓我們以客戶的需求優先。久而久之，基本功能加上各種獨特的功能，就成了一個大而全的系統了。有一定工作經驗的產品經理或者設計師，在做設計之前會考慮各種各樣的情況，這些情況可能是真的存在，也可能是我們虛構出來的。這就需要一些取捨了，根據對市場調研以及與行業專家的訪談，來定義我們產品功能的留舍。
企業管理軟體的體驗任重道遠，身為交互設計師，不僅要從頁面布局、層次結構等方面優化產品，更要了解行業，從整個操作流程上做優化！
『叄』 B端產品如何做好競品分析
相比C端產品，B端產品很難做競品分析，原因大概有以下幾點：
除非是一些標准化程度很高的行業（比如財務管理系統、圖書管理系統等），否則很難找到功能相似度很高的競品。標准化程度高的行業里基本沒必要做 競品分析 ，因為經過紅海中的殘酷市場競爭，產品已經同質化（行業標准決定的），小公司被巨頭用成本和服務品質碾壓。
在標准化程度比較低的行業，通常產業鏈較長、商業模式復雜、地域差距較大，同時產品受到早期典型客戶需求特徵影響較大，又因為B端產品迭代周期較長，所以產品形態五花八門，各有各的細分市場。
B端產品不公開發表，客戶內部使用，很難找到測試帳號。
最難的一點是，就算拿到測試帳號，看了別人的產品，可能沒什麼太大的借鑒意義。做B端的產品，每個產品都有自己路，自身條件不同、市場定位不同、商業模式不同、對行業的理解不同、技術不同，走的路可能截然不同，學習功能和產品特徵基本很難成功（說是找死也不過分吧）。如果你想從產品中去學習別人對行業的理解，這也不是普通人能做到的。真正的行業專家、解決方案專家、產品架構師，有幾個有時間去寫競品分析報告的呢？就算有時間，也只能寫給自己看吧，在這個層面上，可以交流的人太少了。
但是不管怎麼說，分析同行的產品總能帶來一些啟發，也是B端產品經理提升的途徑之一，如何進行分析，還是有一些方法可循，所以試著歸納幾點。
B端產品不像C端的產品的設計邏輯那麼明顯，或者說有的設計邏輯相當的隱晦。多收集一些背景資料有助於對產品的理解，這些背景資料可能包括：
公司背景，比如成立時間、地點、規模、發展史和關鍵大事。
技術背景，比如產品使用到的關鍵技術、技術合作夥伴、技術變革史。
早期版本，對比版本升級路線和行業發展路線可以對行業有更深的理解。
典型客戶，典型客戶的需求對產品的功能影響很大，也對自己對行業的理解有幫助
政府關系，中國國情，你懂的。
B端產品的定位方法與C端產品不同，C端產品定位的要素是：
細分人群
關鍵需求
B端產品的定位要素是：
產業鏈（ 價值鏈 ？資金鏈？信息鏈？）上的位置（在哪個環節）
發展方向（向上游還是下游）
C端產品的用戶和客戶身份通常是重合的，而B端產品復雜的多。尤其是基於工作流的產品，用戶身份會非常多。共性的分析方法里邊，以下幾個角色是需要在產品里找到的：
交易雙方
數據採集人員
決策者
系統實施人員
客服人員
技術維護人員
前三類人用的功能決定了產品的業務邏輯，後三類人用的功能決定了產品的單位客戶成本。業務邏輯決定了產品的競爭力，單位客戶成本決定了產品的市場生存能力。
業務場景主要有兩大類：
生產場景（重視數據採集、協作效能、責任確認等）
管理場景（重視決策分析、風險控制、過程監管、質量控制等）
對於不同的行業和產品你可能能想出各種對業務場景分類的方法，但是做競品分析真的沒必要搞的太復雜。生產場景分析的目標是找出效能優化的手段，這就是需要對行業有深刻理解的地方，管理場景分析的目標是找出賣掉產品的方法，這是客戶購買你產品的動力。
在任何行業全產業鏈產品畢竟鳳毛麟角，既然多數B端產品都是只解決一個環節的問題，那與其它產品的集成方式就很重要，友好的集成方式決定了你的生存空間。一個沒有API的B端產品就像食譜特別窄的生物物種，離開特定的環境根本沒辦法生存。粗略的分析產品生態大致可以看這幾個方面：
是否有開放式的帳號系統（接受第三方帳號授權，開放帳號API）
是否有數據交換機制，比如文件數據交換（導入導出、兼容多種文件格式、兼容數據交換標准）、數據交換API
是否可以適配多種硬體
是否有代理商和 分銷商 的支撐體系
分析競品的生態環境，對比自己產品的生態環境，可以分析出很多問題。
分析商業模式有三個要點：
成本分析。評估競品的研發固定成本和單位客戶變動成本。如果競品為客戶做了大量的定製開發，那他的單位客戶變動成本就很高，可能就很難做大。
銷售分析。看典型客戶數量，代理商數，二次開發商數量，評估銷售能力
有無輔助產品線。如果該競品有其它輔助產品線，已經形成產品群，那要看這個產品在產品群中的定位，是個防守型產品還是進攻型產品。防守型產品負責抵禦競爭，進攻型產品可能才是盈利的金牛。
結束語
為什麼談了這么多都沒提到產品功能分析？為什麼沒提到 競爭優勢分析 ？B端產品的優勢是企業的內功，絕不是什麼功能。產品定位、商業模式、技術積累、成本優化、行業理解和產品生態這都是內功，是心法，產品功能只是招式而已。
『肆』 新接手一個產品，如何去思考它的優化方向
這里以B端產品，TMS（物流運輸系統）這類業務系統為例。
我認為TMS系統的優化方向和思路主要分四個。
1、滿足新的業務場景+業務需求
2、提高物流組的業務效率
3、從指標KPI業績的角度出發，研究每個環節里指標的異常和可優化的地方，例如物流這塊就是簽收率（時效）和成本 。
4、從大局和戰略的角度出發。從物流管理的角度，去重構業務流程、對系統架構重新設計，或者去優化整個物流運輸的體系，例如TMS\OMS\WMS三者流程的配合
也就是，業務、效率、KPI、戰略四點。再詳細地說每一種類型。
一、新的業務場景+需求
首先，一家公司的物流業務肯定是變化，若一成不變要麼發展到了頂峰，要麼沒錢去擴展新業務，公司走下坡路了。前者國內京東順豐阿里等也不敢說其物流體系已經成熟了，後者趁早離開為佳。所以對於新的業務場景，那麼系統的優化，一是能夠嵌入新的業務功能，又使之不會影響大體的流程。二是保證系統的架構合理不臃腫或者從底層的根就是錯了，後面加業務場景時，使整個系統長歪，到時整顆樹都得砍掉。
二、提高業務員的效率
這里再分兩種，一種是老手業務員，一種是新手業務員，因為系統是不斷地累加業務和需求的，所以系統結構發展到最後會有些亂和臃腫，這種對老手業務員並沒有什麼區別，但是對於新手業務員，系統的結構臃腫會導致學習成本比較高。如果結構比較清晰，又不是經常更換業務員的，可以簡單地修葺一下結構，優先順序不是很高。
對於老手業務員，可以去研究業務員的日常操作，也就是一天的工作流程，現有的工作流程中最佔用時間的、最影響效率的、需要大量人工去操作的，這些都可以去評估能否通過系統、演算法等來進行輔助或者取代。其次就是去解決他們在操作流程中遇到的問題。例如，導數的過程太慢，例如對賬不準採用人工，例如異常單，每次都需要人工去判斷……
還有一類方向，就是推智能化和自動化，京東的戰略目標一直是這個，劉強東也喜歡搞這個，用無人倉無人機無人車去取代掉倉庫作業員，用銷量預測和智能補貨去取代掉采銷人員，無人超市取代掉收銀員。同樣的任何B端的業務系統都是可以的，例如通過演算法實現包裹的自動分配，異常單的自動處理這些……從而去減少人工成本和減少出錯率。
三、從KPI的角度
物流運輸在提高時效這一塊要從整個流程來，例如從訂單下單，到簽收的整個環節，不僅僅是物流這一塊，還有前面的OMS（訂單管理），WMS（倉庫作業），再到最後的TMS（五路運輸）。我了解到的，有時候因為庫存不足的原因，一個訂單卡在了那裡好幾天下發不了倉庫生產，或者異常單的處理流程繁雜，或者分配物流渠道的演算法沒有選擇最優路徑。庫存不足這一塊怎麼去優化？異常單的處理流程怎麼去優化？分配物流渠道的演算法怎麼優化？這些一思考，自然知道系統該怎麼做了。
四、從戰略的角度
這種一般都是對業務有一個更明確、新的定義，或者對系統有底層性的改造。例如供應鏈的采購，原本是人工去下單，和根據庫存的水位來進行補貨。現在採用供應鏈的拉式補貨理論，通過銷售來驅動，那麼在系統的底層就需要加一個預測模塊來支撐整個系統數據的輸入，預測銷量作為數據的輸入項更換後，後面一些被影響到的都要變。再例如物流的運輸一開始是通過第三方的物流商來解決，現今公司的業務發展到一定的規模，想通過自建物流渠道的方式來降低成本，那麼自身的一個物流渠道運輸業務，又會去更改到整個系統的作業流程。
以上，對於B端類型的業務型產品，從這幾個角度出發，總有所得。
『伍』 B端產品個性化需求處理的四個步驟
關於B端產品（企業服務）的個性化需求如何做，這是一個所有B端產品都要面對的重要問題。通常，我們會先用已有方法（C端產品）解決現有問題（其實是新問題：B端需求），失敗後，才會發現新特徵，總結提煉新方法。
相比C端需求的單點和單線特徵，B端的需求更為復雜，有兩大特徵：更多角色反饋、更多業務場景訴求，聽起來聲音多、看起來需求雜，而如果產品經理對需求歸類不明就會導致功能開發過度或缺失。
B端產品需求復雜的重要原因是其服務對象不再是單個個體、消費者，而是一個行業、一個組織、一個業務。所以B端產品最基礎的需求邏輯是要：
企業和產品經理收集了一大堆需求，問題是：做不做、什麼時候做、做哪些？這是從業務邏輯到產品邏輯最重要的內容之一：對需求做判定。
B端產品可以劃分為兩類：行業型B端產品、場景型B端產品。行業型B端產品服務於特定行業，產品一體化，現在各個行業SAAS數字服務商大都如此；場景型B端產品在眾多行業的特定場景中服務企業組織及工作者，如：ZOOM、釘釘。兩類共性需求維度不同，但兩者 最終目標都是：形成有效的業務閉環，完成有效的價值鏈輸出。
剛才講B端產品最基礎的需求邏輯是：滿足業務鏈條的需求和滿足組織管理的需要，形成有效的業務閉環則是滿足以上兩個條件的必要條件。
產品在不同階段形成的業務閉環可以有不同維度、鏈條有長短。在前期，產品規劃有著非常重要的作用，包括：產業理解、業務梳理、產品定位、架構設計、版本規劃、實現路徑等，進而能夠需求圈層：通過獲取全面需求、基於產品定位和業務場景， 做業務結構，圈定呼需求層及相關范圍。 開發階段和運營迭代階段獲取的個性化需求，其實是對需求層的一個再認知和補充完善。
找到的一個需求層做為切入點，一層圈一層，相互獨立且相互關系，形成需求圈層，然後細化各需求范圍、確認相關需求內容， 詳情內容在《B端產品規劃如何做》里說明。
個性化需求分析有兩大目的：補充和完善已知需求層、提煉發現新需求層。整個過程是：對需求處理和定義，歸納已有屬性和發現屬性，選擇分析模型，設定判斷規則，完成需求的歸類和判斷。總結分為 四步驟：需求定義、歸納屬性、聚合模型、需求判斷。
需求常常復雜混亂、不清晰不完整、淺層離奇，需要對需求加工處理，判斷用戶真正的痛點，獲取客戶真正的需求。
有一句話，很生動地反映出沒有正確理解需求的場景： 沒見過 汽車 前，用戶只想要更好的馬車！
C端產品功能的背後，隱藏的二次驅動需求常常是用戶的 情感 ， 情感 吸引用戶，需求分析模型有馬斯洛需求原理和Kano模型。
B端產品功能的背後，隱藏的二次驅動需求常常是客戶的利益，利益撬動客戶 。以會展行業數字產品舉例：服務客戶，多是產品需求或服務需求；服務客戶的客戶，多是關系需求或成功需求。客戶需求層次例圖：
B端產品的需求，一方面要全面收集，以確保對業務完整掌握，另一方面又因為需求眾多、復雜混亂，難以管理。因此需要對所有需求進行裝箱歸類。
C端產品可以採用ROI（Return of investment，即投資回報率）的方式，歸納為價值、投入兩個屬性；B端產品可以採用廣度、深度、戰略、技術通用四屬性，而我在做會展行業B端產品時，基於會展行業和自身情況歸納為需求的四大屬性、十一小屬性。
四大屬性：需求廣度、客戶價值、商業價值、成本周期；十一小屬性：共性/頻率、入口/鏈接、產品需求、服務需求、體驗需求、成功需求、客戶影響、技術引領、營收能力、投入資源、時間周期。
每一個需求，都可以抽象總結出多個維度的標簽屬性，成為聚合模型的計算因子。
聚合模型是需求分類的一種有效工具，是需求判定的一種前置過程，幫助我們更精細、多維度的理解和劃分需求。介紹兩類、四種分析模型，兩類：單屬性分析、多屬性聚合分析，四種：痛點/價值曲線圖、計分卡、二維四象限圖、三維模型。
1）價值曲線圖
依據客戶流程及其對應需求，提出產品方案思路和評估方案價值，從而衡量確認重要需求和好的產品方案，例圖：
2）計分卡
設置需要計分的因子及其權重（總和為100%），進行計分評選排序。當需求來源於銷售、運營等各個部門，可由評分小組共同填寫評分，過程中發現更多思路，達成目標共識。
3）二維模型
聚合各屬性因子，權重評分、二維歸納，舉例：價值（共性/頻率、入口/鏈接、產品需求、服務需求、體驗需求、成功需求、客戶影響、技術引領、營收能力）、成本（投入資源、時間周期），劃分排序為：高價值/低成本、高價值/高成本、低價值/低成本、低價值/高成本。二維模型因其屬性因子較少，操作簡單易懂，適用於較少屬性的需求分析。
對復雜的屬性需求來說，因子更多，權重計算容易模糊有偏差，常常導致結果不準確。例圖：
4）三維模型
聚合各屬性因子，權重評分、三維歸納，舉例：共性（共性/頻率、入口/鏈接）、價值（產品需求、服務需求、體驗需求、成功需求、客戶影響、技術引領、營收能力）、成本（投入資源、時間周期），按各自高低標准聚合為8類：{價值高、共性高、成本低}，{價值高、共性高、成本低}，{價值高、共性低、成本低}，{價值低、共性高、成本低}，{價值低、共性低、成本低}，{價值高、共性高、成本高}，{價值高、共性低、成本高}，{價值低、共性高、成本高}，{價值低、共性低、成本高}。
例圖：
三維模型評分標准可以是高低、高中低等標准，復雜程度較高，因屬性因子劃分更精細，聚合分類的種類更全面，需求分析的准確性也更好。
行業特徵、業務屬性、產品定位、發展階段各自不同，歸納的屬性也不盡相同，不管是在最小化產品階段（MVP），還是在打磨產品（PMF）、規模增長階段，都需要 根據自身業務情況優化迭代需求屬性、需求模型，讓需求判斷更准確，讓產品開發更准、更快。 B端產品最大陷阱之一，就是不斷做加法！
需求判斷，依據產品定位和企業情況來設定需求目標、判斷標准，讓需求站隊排列，也就是說： 讓需求站到它自己的位置。
所有個性化需求聚類歸位，有的歸位到已知圈定層，有的產生新分類。歸位已知圈定層，我們能知道需求做哪些、什麼時候做。發現的需求新分類，則進一步思考： 過去分類方式是否有效和全面，是否需要改進迭代，這些新分類是否能夠進一步抽象聚合並找到產品與技術的解決方案，實現產品新機會。
舉例說明：企業資源不夠，只能做1{價值高、共性高、成本低}的需求，進行快速迭代；企業資源足夠，除了1{價值高、共性高、成本低}，2{價值高、共性高、成本高}也可優先，從而提高行業門檻；規模增長階段，就可以把3､4､5納入優先序列，通過對差異化需求共性提煉，用功能置配或靈活搭建等方式滿足差異化需求，產品滲透更大市場。
特別是 SAAS產品，對各種各樣個性化需求抽象還原、形成共性，是非常重要的。發現別人沒有發現的需求共性，就是產品機會。
B端需求，重點不是做了多少，而是做了什麼。
題圖來自Unsplash，基於CC0協議
『陸』 B端產品初期冷啟動，該選擇什麼推廣方式
現在的推廣方式有很多種，seo、sem、信息流、開屏廣告等等。
但是B端產品的用戶畢竟是少數的，這個更傾向於精準推廣，所以這里建議前期小規模的seo、sem推廣