産品經理分為兩類業務，toB和toC，二者有相同之處也有差異。作者從自身經曆體會出發，從七個維度闡析二者的異同，方便大家做出崗位抉擇。

本文将從以下7個維度淺談這兩類産品經理的異同。在自己的職業生涯中，分别經曆着toC、toB的産品工作，慢慢感知兩者的差異很有意思，于是且行且記錄。

一、産品使用決策人

C端用戶與B端客戶是不同的。

曾經在獵頭安排的一個純toC産品經理崗位的面試場，我說到用戶拉新的玩法，面試主管聽完之後提了一個很典型的問題–你在說獲客手段吧，你真的做過C端産品，為什麼不叫獲客呢？

說明這兩者還是很容易被混亂。

1. 定義不同

用戶直接使用産品，且擁有直接決策權，包含是否使用，是否支付，因而用戶的滿意度是C端産品留存的重要指标。

toC的醫療類産品面對的一定是用戶，用戶是生物意義上活生生的人，他一定有血有肉有情緒有沖動行為。

toB的客戶不一定直接使用産品，但卻有直接決策權，尤其是購買決策。客戶可能是某一個生物意義上人，也可能是某一類組織整體，類似法人和法人代表。

2. 關注點不同

因定義的差異，也造就了這兩類角色關注點不同。

B端客戶在意的是客戶成功，而且客戶也願意額外再投入金錢、人日、精力一起來使用這個産品，來達到成功的目标。

C端用戶在意的是讓自己感覺更好，更個性化的訴求，更具體的情緒。用戶投入的精力必須消磨在潛移默化中，若讓用戶感覺困難或意識到投入額外精力，大概率會導緻用戶的高流失。

3. 方式不同

拉新用戶、獲取客戶，這兩個動賓短語，因為賓語的不同，也就意味着動作的出發點完全不同。

比如說價格戰策略。

為了B端獲客是可以打價格戰的，因為價格的優勢在強資源型的B端行業中很有優勢。與客戶達成合作一定是有合同期限的，一筆合作大概率意味着有一筆的收入甚至利潤。

而如果在C端用戶維度使用價格戰，電商類場景可能會激起短期火花，醫療類場景會适得其反。

用戶往往對過于便宜的醫療産品、醫療服務呈現懷疑态度。價格戰往往篩選出對價格敏感，而對平台/品牌很難有忠誠度的用戶，所以往往是短時間流水可觀，但真實用戶留存數據不甚樂觀。

二、産品設計思路

1. 使用驅動力差異

toC場景的驅動力是用戶當下的情緒，讓自己變更好的原始動力，或娛樂放松，或獲得社群認可。

因此C端産品設計非常看重體驗，尤其需提前感知用戶的操作意圖，讓爽感、舒适感貫穿用戶路徑。

toB場景的驅動力是如何高效率完成當前的任務，且減少出錯率，避免資損。有一定的壓力要求，産品設計需要簡潔易懂但不能過于舒适。比如說某些非常打擾用戶但卻必須有的标紅異常提示，檢驗錯誤彈窗提示等。

2. 單個産品内的交互思路差異

C端目前更多設備是手機，屏幕更小，因而對分辨率要求更高，會有多個頁面之間的跳轉閉環，原則點有3：頁面跳轉流暢，符合人性操作且能兼容極端場景；操作簡單易懂；用戶使用習慣一緻性。

B端更多使用設備還是電腦端，更傾向于單個頁面完成80%的操作，因為其交互設計原則點有3：

1. 頁面結構統一，上下結構便于沉浸式閱讀，左右結構便于偏操作性功能；
2. 模塊區域統一，所有B端産品的操作按鈕都在頁面同一側；
3. 簡便性，便捷使用但不能過于舒适–這與B端産品需考慮體驗并不矛盾，簡潔易用的産品不管BC都需一直追求。

3. 與其他産品間的交互要求

C端産品更關注人機之間的交互方式，一個toC的産品可以是一個整體閉環，對其他産品系統的交互要求并不高，或者說較少。

B端業務因複雜度高，單一産品無法實現完整的場景鍊路，往往需跨越多個産品。

而産品之間是通過接口來交互，所以有些toB的産品經理會把文檔寫到接口層面。

如果是技術出身的産品應該還好，但是對業務出身的産品，或者并不了解代碼層的産品來說，考慮到接口文檔并不是一件可取的事情。

基于業務路徑把産品之間的交互通過邏輯順序梳理出來即可，并沒有必要到接口細節。

三、産品衡量指标/商業模式

産品衡量指标主要指産品使用人數，使用時長，流失率，點擊率，産品滿意度等。商業模式指通過産品達成的變現方式。

toC産品本身衡量指标和商業模式基本一緻，因其慢慢滲透用戶的特性-用戶決定自己是否繼續使用C端産品。所以使用産品人數多，使用時間長，這個産品的商業價值就更大。

而toB産品本身的衡量指标對商業模式的形成并無太大影響，因其自上往下的産品特性-客戶購買産品給員工使用。體現在産品使用人數，使用時長，Ctr這些指标與客戶買單成功率關聯度并不高。

往往是客戶滿意度、客戶的買單概率與産品本身的個性化能力支持能力強關聯。

此處客戶滿意度并不等于産品滿意度，因客戶并不是直接使用産品的人。

更新的産品能力，和客戶買單概率相吻合的，當有新的場景産生的時候，産品如何能快速支持，或者想辦法去支持，是toB産品的一種能力點，但是這個能力點卻很難體現在産品本身的衡量指标上。

某些大公司會考量B端産品複用性，但因着此指标與客戶買單成功率關聯度并不高，所以也很難體現該指标的商業模式價值。

四、協作方式

1. toC協作-可自閉環

單個C端産品從業務到産品技甚至ued都可以自閉環，形成最小團隊分工的mvp。

産品發布上線之後，短時間内便可以獲得用戶的數據反饋，基于數據分析快速疊代。因而C端協作方式要求更輕便，其中産品角色有較大機會能起主導作用。

2. toB協作-鍊路長

以供應鍊協作為例，因B端系統的複雜性較高，角色分工較多，包含業務産品，系統單個模塊的産品以及系統細節領域的技術。

因toB的産品鍊條也較長，3個月前開發完，到有新的數據反饋的時候，可能已經在做新的産品設計開發。所以toB的産技團隊中需要這類角色，可能叫流程團隊/業務産品，他們負責承接市場需求并對合理的市場需求進行抽象。

而系統單個模塊的産品團隊，則是根據抽象之後的需求進行prd設計。

五、需要的技能

溝通能力在B端需要非常重要，C端更看重鑽研思考能力。

toB的産品很難拒絕某一種需求，因為toB的商業模式是客戶花錢購買這個産品能力，所以大部分時間對需求的合理性判斷能力并不是衡量B端産品能力的指标項

在強資源型的行業中，往往隻要客戶提出這個需求便是合理的。

雖然不能對需求本身說no，但是做深入溝通後，可以對需求實現做出更合理的選擇。

toB産品離客戶不近，接收需求來源或是商務同學，或是運營同學，在層層傳導過程中，大概率會有需求理解的偏差。所以需要和需求傳達者的同學深入溝通，客戶提出的原因是什麼，具體是解決什麼問題，而不要落入到如何解決的細節中。

甚至和客戶溝通，溝通過程中的技巧點也非常多，要去引導客戶多描述問題場景、前因後果，通過具象的場景描述去理解為什麼會有這樣的訴求，不要被客戶/需求傳達者設想的實現細節綁架。

建議不要在不理解這個需求的前提下，去糾結要如何實現。

toC的産品在需求的選擇上因為有更大的話語權，同時也就有更高的要求。

需要更多思考需求的價值點，而這也是toC産品本身的核心競争力。判斷什麼樣的需求能解決的是什麼問題，以及解決的這個問題本身，是否能帶來對應的商業價值。

這類思考不僅要貫穿在C端産品接收到的每個需求中，而且需要形成自己的産品思考體系，能有一套體系化的産品思考模型來By場景化理解不同的需求。

六、互通性

因為都是互聯網産品，天然便存在可以互通的部分。

1. 用戶路徑的相似性

其實不管是B或C的産品設計，回到源頭上還是要考慮用戶路徑是什麼。

toC的用戶路徑也可以是情緒化驅動，場景訴求需要鑽研，并做取舍。

而toB的用戶路徑對應場景是相對明确的，甚至可以枚舉。

2. 強場景理解能力

不管是面對 C端用戶還是B端客戶，對場景理解能力的要求都一樣高。

同一個用戶，雖然是同一個人，因為在不同場景使用同一個産品的訴求并不同，所以可以看成不同場景下需要服務的客戶。

客戶維度來看，更是如此，企業裡頭每一個人的利益動機都不同。

因而客戶在意的成功有非常多場景，不同場景下定義的成功并不相同。需要深刻理解客戶場景來共識客戶關心的成功具體是什麼。

七、應屆生如何選擇

toB産品需要更多的是了解行業屬性，toC産品則需了解用戶心理，去鑽研産品本身的設計能力。

從後續的兼容性考慮，建議應屆生優先選擇toC産品，先從産品底層能力去夯實基礎，去學習如何判斷需求的價值，如何評估這個需求的可行性，去修煉自己的産品體系化思路。

有一定産品設計基礎之後，再去選擇自己感興趣的行業，嘗試做toB的轉型。深耕在某一個自己喜歡且認可商業模式的行業，在已有産品基礎能力的地基上，去打磨對行業的認知，逐漸加厚作為産品的競争力。

當然如果對産品設計本身一直感興趣，也可以不用做toB的轉型，持續往産品設計能力上走，去打造一款有足夠行業影響力的C端産品。隻是在當前這個時代，這樣的機會越來越少。

目前的感覺是toB産品入門門檻較高，但是toC産品要往上走難度會更大。

公衆号：老賀的故事屋

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

題圖來自 Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

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

查看全部