起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品需求七大特點
編輯導語：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端復雜度要高很多，主要體現在：
- 邏輯復雜。各種或明或暗的功能邏輯非常多、流程長、要求多，全部揉在一起，防不勝防；
- 功能設計復雜。很多人會覺得一個應該很簡單的功能，為什么要設計的這么復雜，我只是要做個篩選，為什么還要理解“或與非”，甚至還要寫腳本。
2. 原因
1）產品功能邏輯復雜的背后是業務本身就復雜、場景多、流程長。這是天然的復雜性，大部分都不是從產品設計上能解決的；
2）功能設計復雜主要是因為用戶使用場景眾多且差異大，具體體現在
- 各類正向/逆向流程、正常/邊際場景，導致邏輯上需兼容的場景多，更復雜；
- 有時候為了滿足10%的專家用戶的使用場景，會額外增加不少復雜度。
3）歷史數據兼容。為了兼容歷史數據，也會極大增加復雜性
3. 啟發
- 從能力模型上。B端產品經理需要訓練、提升更強的邏輯分析能力；
- 客觀分析復雜性，學會區分。很多產品所體現的復雜性是背后業務邏輯導致的，我們需要仔細分析，正視這個復雜性，從而剝離出我們能夠解決的部分；
四、集體性
B端產品需求的集體性包含多個方面。
1. 集體訴求優先
在B端產品中，當個人訴求與集體訴求沖突時，個人訴求需為集體利益讓步。例如，同樣是IM工具，當面向C端用戶時，會提供諸如黑名單之類的功能，但如果用于企業內部，則不會提供此類功能。甚至有的企業通信工具還會增加類似“強制接收”的功能，如釘釘的“釘一下”、飛書的“加急”，對于信息接收方，這個功能必然會有一定的打擾，但為了提高企業內整體的溝通效率，會以集體訴求優先。
2. 同一群體需求趨同
在特點2用戶分群基礎上，同一用戶群體內，不同用戶的需求是高度趨同的，可以作為一個集體表達?？赡懿煌脩魧ν粋€問題有各自的想法，但其痛點大體都是一樣的。
這是因為對用戶分群本身就是根據差異來劃分的，當根據明確邊界劃分完后，會發現各個群體內用戶使用場景、需求差別不大。
3. 多人協作
B端產品中有很多同一個任務目標，需要一群人協作完成的場景，例如同一個對象的詳情頁，可能多人同時編輯，這個時候一定要有相應的產品策略支持或規避，否則就會出現數據錯亂的情況。
五、喜“舊”厭“新”
1. 現象
喜新厭舊是人的天性，但B端產品恰好相反，如果不是業務變化，B端用戶的需求一般非常穩定，而是“喜舊厭新”。
2. 原因
- 用戶需求的背后是業務運作方式，見我的上一篇《B端產品冰山模型》，如果業務不變，用戶需求也不會有其他變化，所以B端產品需求是比較穩定的；
- 遷移成本高。由于前面提到的各種原因，導致B端產品復雜，學習成本高，因此用戶轉移到新體驗上的成本也比C端高很多，每次“換新”都需要重新學習、重新適應，在自己的舒適區中，沒人愿意主動跳出；
3. 啟發
1）把握迭代節奏。每一次改變，都是對用戶習慣的沖擊，改變越大，用戶的反彈就會越大，所以需要比較把握好迭代節奏，在評估一定要改的前提，用小步快跑的方式推動用戶習慣的變化，避免用力過猛；
2）用戶習慣從“娃娃”抓起。對于一些具備條件的SaaS產品，可以從“娃娃”抓起，提前進入大學，盡早培養用戶習慣，這比后面再重新做廣告效果更好，例如藍湖進入大學做的各類活動，飛書組織的校園內的“飛行家”們。
六、階段性
1. 現象
B端產品隨著業務方向、制度變化，有比較明顯的階段性，即某個時間點急需一些功能支持，過了這個時間就不再生效了。
2. 原因
業務上新制度、新規范的實施，往往需要工具上的支持，舊規則的調整，新規則的上線，需要和業務保持同步甚至前置，所以一旦業務上有變化，工具需要馬上更新。
3. 啟發
時間是判斷需求優先級的重要因素之一，業務變化帶來的需求變化有明確的時間要求，這能幫助我們更好的判斷需求優先級，
七、特權
1. 現象
在C端產品中，絕大部分用戶的重要性是一樣的、需求權重也是一樣的，這體現了C端產品“平權”的特點，當然也會存在人民幣玩家與免費玩家的區別，但總體還是比較少，差距也不會特別大。
而在B端產品中，則經常出現“特權”需求（這里的“權”是指“權重”），即某些用戶甚至不是用戶的需求權重非常高，遠高于普通用戶。
2. 原因
對不同需求賦予權重，本質上是在資源有限的情況下，根據用戶影響力對需求做的取舍。所以需求權重背后是提需求的人或所服務的用戶對產品影響力的體現。
- 關鍵干系人。B端產品干系人對產品影響力主要源于業務相關性和手中權力，業務相關性越高、手中權力越大，這些關鍵干系人需求就會有一定的“特權”；
- 氪金用戶。SaaS產品通常會根據付費金額、客戶行業影響力對客戶進行分類，其中影響力高、付費高的客戶會享有一定“特權”，他們的需求會被優先滿足。
3. 啟發
根據這一特點，我們做B端需求價值評估、優先級判斷時，就要把權重考慮進來，這里總結了一個B端產品需求優先級中判斷重要性的公式：
重要性=人數×頻率×節約時間×影響力
以上這些特點并非在每類B端產品中都會體現，但無論體現了哪些特點，都可以根據這些特點的啟發，來指導我們的日常工作。
作者：周翔；公眾號：周翔Fly；
本文由 @周翔 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
分析的透徹 有學習到
分析的很透徹，歸納提煉的也很到位，確實是b端產品需求的特點