産品經理分為兩類業務,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:
- 頁面結構統一,上下結構便于沉浸式閱讀,左右結構便于偏操作性功能;
- 模塊區域統一,所有B端産品的操作按鈕都在頁面同一側;
- 簡便性,便捷使用但不能過于舒适–這與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每日頭條,我们将持续为您更新最新资讯!