編輯導語：B端産品相比于C端有許多不同的地方，用戶群體的差異也很大。本文作者總結了B端産品需求的特點，講述了B端産品與C端産品在需求層面的差異以及B端産品産生這些特點的原因，一起來學習一下吧。

抓住特點，趨近本質。

B端産品相比于C端，有很多不同之處，這篇文章将總結兩者在需求層面的差異，也是應讀者之約，幫助大家做個全面的梳理，同時将分析為什麼會産生這些特點，以及基于這些特點，對我們的工作有哪些啟發。

一、業務強驅動

1. 現象

是指大部分B端産品的主要需求都來源于業務方，由業務驅動、業務主導，而非像C端産品那樣，産品經理對需求有很大的自主權，能夠基于個人理解來主導需求。甚至包括叠代節奏，有的業務方也會幹預。

這也是很多B端産品經理缺乏成就感，感覺自己是個工具人的主因。

當然也有少量沒有明确業務屬主的B端産品，這類産品業務驅動特點就比較弱，産品經理發揮空間比較大，不過這類産品數量少，也不是主要業務領域，一般較難成為剛需。

2. 原因

根本原因是B端産品是為了解決組織内某個或某一類具體業務領域問題，而業務方是離業務最近、離使用用戶最近的，所以從誰更懂用戶、誰才更能真正解決用戶問題的角度看， 業務方驅動産品需求是正常的，而非根據職能決定。

其次是公司特點。如果公司是強業務驅動的公司，那麼這個特點就非常明顯，如果公司對産品比較側重，那麼這個特點相對就弱。

3. 啟發

要想與業務共同驅動産品，隻有一種解決方式：不斷學習業務，不斷了解用戶。

B端産品需求無論是業務驅動，還是産品驅動，共同目标都是為了解決業務、用戶問題，所以，從目标出發，B端産品經理要想發揮更大價值，不被業務牽着走，隻有不斷深入業務，不斷通過各種方式了解用戶，盡量與用戶直接、深入的交流，才能逐步提升自己的業務、用戶理解力，才能逐漸與業務方共同推動産品發展，而非坐在辦公室接收二手需求、YY需求。

不過這是一個漫長的過程，對業務的了解絕不是一蹴而就的，是常讀常新，也需要不斷叠代，對用戶使用場景的了解也絕不是幾次調研就能深入的，是需要持續的，從不同角度、不同場景、不同角色挖掘，才能形成全面認識。

所以，雖然我們一直在說用B端産品經理另一價值是用産品化方案解決業務問題，但不應僅局限于産品化方案。

二、不同用戶群差異大

1. 現象及原因

無論是做B端還是C端産品，對用戶精準分群是分析用戶的基本條件之一。

當我們從不同維度對用戶進行分群後，就會發現B端産品與C端産品在不同用戶群體間需求關系很不一樣，這裡我用一張圖來表現兩者區别。

在很多B端産品中，不同用戶群體需求差異巨大，甚至經常出現兩個群體需求相互沖突，不可調和的情況。當然相互間也存在一定的交集，交集大小也各有不同。而C端産品是同大于異，需求交集遠大于差異，否則就不會有這個産品的出現了。

B端産品用戶群體常見差異主要有以下幾個方面：

1）角色差異。不同角色，需求差異大。這是因為角色的劃分一般就是按照需求内聚程度來劃分的，如果需求、權限相同，就不會劃分那麼多角色了；

2）組織差異。不同BG、部門、業務線甚至小組，由于業務特點、管理流程、方式等差異，導緻需求差異；

3）管理層級差異。在很多管理工具中，一線員工、一線管理者、中層管理者、高層管理者所形成的四個管理層級，所對應的需求差異很大，在很多場景中完全不相同或相互沖突，例如：

• 一線員工需要産品提升日常的工作效率；
• 各級管理者需要一線員工産生的各種業務、行為數據；
• 一線管理者側重過程數據，高層管理者側重結果數據。

管理者為了數據更加豐富、準确，就會要求一線員工做更多的事情，做的更及時，這必然與一線員工“多一事不如少一事”的訴求相沖突。

4）用戶深度差異。是指新手用戶、中間用戶、專家用戶的需求差異。因為對産品使用深度不同、背景不同所産生的需求差異，新手用戶期望的是簡單易上手，專家用戶則期望滿足更多、更豐富的深度、個性化的需求，當這類需求多起來，與新手用戶功能揉在一起，必然會增加功能複雜度和使用門檻。C端産品裡對專家用戶需求相對照顧得比較少，因為人數較少，但是B端産品的專家用戶往往是重點業務方，不能采用與C端一樣的應對策略

對SaaS産品而言，除了上述差異外，還有客戶間的差異

5）客戶規模差異。不同規模的客戶，同樣業務的需求差異是很大的。小團隊的管理方式與大團隊的管理方式截然不同，所要求的能力和深度自然不一樣；

6）客戶行業差異。不同行業的客戶需求差異也很大，銀行與制造業、互聯網與運輸業，隔行如隔山，業務差異也如隔山，這也就是很多發展非常久的SaaS公司都開始做行業化的原因；

7）客戶性質差異。民營企業與國企、軍工與其他性質企業，客戶性質的不同也是造成需求差異的原因之一。

2. 啟發

不同維度的差異，所帶來的啟發是不同的，這裡從産品經理幾個日常重點工作來寫一些通用啟發。

1）用戶調研。因為不同群體需求差異很大，所以我們做的調研，不僅要看樣本量，還要覆蓋同一維度多個用戶群，例如我們想調研一線管理者的需求，那麼就要多調研幾個業務部門，來了解不同業務部門一線管理者的需求痛點，從而設計覆蓋面更全的方案，提升方案的ROI，而該如何選擇這些維度，主要是看哪個維度差異大。這樣調研的信息才能更全面，我們的用戶畫像才能更精準；

2）用戶分析。做用戶分析也是一樣，需要從差異大的幾個維度對用戶進行分群，然後進行分析，甚至要多個維度綜合起來進行分群，例如按角色分成5類，按業務部門分為4類，如果這兩個維度差異都很大，我們可能就需要把用戶分成5*4=20個群體，不過這會造成分析工作量指數級上升，所以，B端産品用戶分群的維度選擇和劃分方式需要合理取舍與平衡；

3）需求優先級。因為不同群體需求差異大甚至相互沖突，這個時候需求的取舍和優先級的劃分就變得更加困難，很多C端的優先級分析方法就變得不适用了，例如我們熟知的KANO模型，在B端場景中适用範圍就很小，所以在分析需求優先級時，需要從群體價值角度分析需求價值，再來判斷優先級，即所面向用戶群價值越高的才能更優先；

4）産品設計。如果不同群體需求在不同模塊，産品方案設計還是比較簡單的，但當不同群體需求彙聚在相同功能模塊中時，會極大增加産品設計難度，因為你需要權衡、取舍，找到最全面的解決方案。同時為了提升功能的普适性，一般都會增加一些配置能力，但這勢必增加了使用成本，尤其是新手用戶，學習和使用門檻又會升高一些，就會陷入易用性與靈活性矛盾的漩渦中。

另外一個可能帶來的問題是為了兼容不同群體需求，導緻各個群體都沒完全滿足，隻是滿足了一部分。

5、交互設計。為了兼容不同群體需求，産品的靈活性與擴展性就有了更高的要求，因此無論是從底層數據庫設計還是到界面上的交互設計，都需要充分考慮未來的擴展性，所采用的設計方式要充分兼容多種極端、異常場景。

三、複雜度高

1. 現象

無論是否設計過B端産品，尤其是C端轉B端的同學，會發現B端産品相比C端複雜度要高很多，主要體現在：

1. 邏輯複雜。各種或明或暗的功能邏輯非常多、流程長、要求多，全部揉在一起，防不勝防；
2. 功能設計複雜。很多人會覺得一個應該很簡單的功能，為什麼要設計的這麼複雜，我隻是要做個篩選，為什麼還要理解“或與非”，甚至還要寫腳本。

2. 原因

1）産品功能邏輯複雜的背後是業務本身就複雜、場景多、流程長。這是天然的複雜性，大部分都不是從産品設計上能解決的；

2）功能設計複雜主要是因為用戶使用場景衆多且差異大，具體體現在

• 各類正向/逆向流程、正常/邊際場景，導緻邏輯上需兼容的場景多，更複雜；
• 有時候為了滿足10%的專家用戶的使用場景，會額外增加不少複雜度。

3）曆史數據兼容。為了兼容曆史數據，也會極大增加複雜性

3. 啟發

• 從能力模型上。B端産品經理需要訓練、提升更強的邏輯分析能力；
• 客觀分析複雜性，學會區分。很多産品所體現的複雜性是背後業務邏輯導緻的，我們需要仔細分析，正視這個複雜性，從而剝離出我們能夠解決的部分；

四、集體性

B端産品需求的集體性包含多個方面。

1. 集體訴求優先

在B端産品中，當個人訴求與集體訴求沖突時，個人訴求需為集體利益讓步。例如，同樣是IM工具，當面向C端用戶時，會提供諸如黑名單之類的功能，但如果用于企業内部，則不會提供此類功能。甚至有的企業通信工具還會增加類似“強制接收”的功能，如釘釘的“釘一下”、飛書的“加急”，對于信息接收方，這個功能必然會有一定的打擾，但為了提高企業内整體的溝通效率，會以集體訴求優先。

2. 同一群體需求趨同

在特點2用戶分群基礎上，同一用戶群體内，不同用戶的需求是高度趨同的，可以作為一個集體表達。可能不同用戶對同一個問題有各自的想法，但其痛點大體都是一樣的。

這是因為對用戶分群本身就是根據差異來劃分的，當根據明确邊界劃分完後，會發現各個群體内用戶使用場景、需求差别不大。

3. 多人協作

B端産品中有很多同一個任務目标，需要一群人協作完成的場景，例如同一個對象的詳情頁，可能多人同時編輯，這個時候一定要有相應的産品策略支持或規避，否則就會出現數據錯亂的情況。

五、喜“舊”厭“新”

1. 現象

喜新厭舊是人的天性，但B端産品恰好相反，如果不是業務變化，B端用戶的需求一般非常穩定，而是“喜舊厭新”。

2. 原因

1. 用戶需求的背後是業務運作方式，見我的上一篇《B端産品冰山模型》，如果業務不變，用戶需求也不會有其他變化，所以B端産品需求是比較穩定的；
2. 遷移成本高。由于前面提到的各種原因，導緻B端産品複雜，學習成本高，因此用戶轉移到新體驗上的成本也比C端高很多，每次“換新”都需要重新學習、重新适應，在自己的舒适區中，沒人願意主動跳出；

3. 啟發

1）把握叠代節奏。每一次改變，都是對用戶習慣的沖擊，改變越大，用戶的反彈就會越大，所以需要比較把握好叠代節奏，在評估一定要改的前提，用小步快跑的方式推動用戶習慣的變化，避免用力過猛；

2）用戶習慣從“娃娃”抓起。對于一些具備條件的SaaS産品，可以從“娃娃”抓起，提前進入大學，盡早培養用戶習慣，這比後面再重新做廣告效果更好，例如藍湖進入大學做的各類活動，飛書組織的校園内的“飛行家”們。

六、階段性

1. 現象

B端産品随着業務方向、制度變化，有比較明顯的階段性，即某個時間點急需一些功能支持，過了這個時間就不再生效了。

2. 原因

業務上新制度、新規範的實施，往往需要工具上的支持，舊規則的調整，新規則的上線，需要和業務保持同步甚至前置，所以一旦業務上有變化，工具需要馬上更新。

3. 啟發

時間是判斷需求優先級的重要因素之一，業務變化帶來的需求變化有明确的時間要求，這能幫助我們更好的判斷需求優先級，

七、特權

1. 現象

在C端産品中，絕大部分用戶的重要性是一樣的、需求權重也是一樣的，這體現了C端産品“平權”的特點，當然也會存在人民币玩家與免費玩家的區别，但總體還是比較少，差距也不會特别大。

而在B端産品中，則經常出現“特權”需求（這裡的“權”是指“權重”），即某些用戶甚至不是用戶的需求權重非常高，遠高于普通用戶。

2. 原因

對不同需求賦予權重，本質上是在資源有限的情況下，根據用戶影響力對需求做的取舍。所以需求權重背後是提需求的人或所服務的用戶對産品影響力的體現。

1. 關鍵幹系人。B端産品幹系人對産品影響力主要源于業務相關性和手中權力，業務相關性越高、手中權力越大，這些關鍵幹系人需求就會有一定的“特權”；
2. 氪金用戶。SaaS産品通常會根據付費金額、客戶行業影響力對客戶進行分類，其中影響力高、付費高的客戶會享有一定“特權”，他們的需求會被優先滿足。

3. 啟發

根據這一特點，我們做B端需求價值評估、優先級判斷時，就要把權重考慮進來，這裡總結了一個B端産品需求優先級中判斷重要性的公式：

重要性=人數×頻率×節約時間×影響力

以上這些特點并非在每類B端産品中都會體現，但無論體現了哪些特點，都可以根據這些特點的啟發，來指導我們的日常工作。

作者：周翔；公衆号：周翔Fly；

本文由 @周翔 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部