談To B產品路徑邏輯：To B產品的核心本質到底是什麼？

03-14

今天，我們開始斷斷續續聊一聊ToB的產品。

我自己本人是做ToC產品出身的，但是，卻在過去相當長的一段時間中從事ToB產品的設計，帶著我的創業團隊逐漸摸索出如何做出一款被稱得上還不錯的ToB的產品，也在這個過程中學習到了ToB的產品的本質，以及與ToC的產品之間的區別。

我想花費一些時間和筆墨，通過思考和討論的方式，來分享一些我自己做ToB產品的感受和方法論，希望能夠與同樣是做ToB產品的PM一起來探討和溝通，互相學習，共同進步。

在這篇文章中，我首先嘗試討論ToB產品的核心決策者，然後討論其中關鍵的產品路徑邏輯，並期望以此為起點，逐步開始在後續文章中深入討論ToB中的產品和運營。

ToB產品中的「B」到底指代什麼？

首先談談ToB中的這個「B」。

B從字面解釋，應該是Business，也就是商業。比如當年的阿里巴巴B2B電商平台，就是將採購、供應雙方進行連接，從而形成供應鏈電商體系。

站在商業模式的角度來說，ToB中的「B」指代的就是從事商業活動的商業機構主體，可是站在產品的角度來說，並非如此這麼簡單。

許多做ToB的產品經理在經歷了產品研發之後，發現產品根本無法賣出，B端機構根本不採用，其中一個很重要的原因是，B端機構中那個重要的決策者不願意使用。

事實上，ToB的很多產品都需要非常強大的市場銷售體系，需要針對B端機構中最重要的那個決策者進行定向營銷，從而影響他的決策。這個關鍵的決策者可以是老闆本人，也可以是某個具體業務的負責人，無論如何，這個角色都是ToB產品能夠走出去落地的關鍵性KOL。

為了說明決策者的重要性，我舉一個例子。

在OA辦公SaaS類ToB產品中，釘釘可謂是一騎絕塵，曾經一度將廣告刷滿深圳地鐵，頗有挑釁騰訊之意。隨著大眾創業的浪潮，面向中小企業的OA辦公SaaS市場一下子成為競爭紅海，眾多做各種SaaS的企業沖入其中，國外紅遍半邊天的Slack也是這其中的弄潮兒。
由於OA在功能上，有一部分功能屬於即時溝通，與IM很接近，所以微信順理成章地加入其中，在2015年轟轟烈烈地推出了微信企業版。可是，非常遺憾，微信企業版推出至今，鮮有人用，其核心的原因就在於微信企業版本質上應該是ToB產品，但是它並沒有服務好決策者。

釘釘在推出之後，其一系列功能都是圍繞著中小公司的老闆打造的，就比如「Ding」這個功能，其核心目的是防止在溝通中出現「假死」——明明看到了老闆的留言，卻假裝沒看到。但微信企業版在推出之後，所有的功能幾乎都是圍繞著員工開展的，並沒有讓老闆用起來很爽的功能，反倒是因為微信企業版和微信之間有著千絲萬縷的聯繫，導致很多老闆因為反感員工工作時聊微信，而天然地反感微信企業版。

決策者在ToB中是很重要的，前阿里巴巴的CEO衛哲在一次分享中提及，所謂的B2B，其實是Business Person To Business Person，人與人之間的交易才促成了企業與企業之間的交易，我們國家酒文化流行，也是說明要向做成生意，首先要能在酒場上成為朋友。

所以ToB的「B」指代的是商業機構中的核心決策者或者KOL。

ToB和ToC在產品路徑上有什麼不同？

我在比較早前的一篇文章《進階之路：站在高視角看產品是一種怎樣的體驗？》中，曾經提及過一個概念，叫做「產品路徑」。簡單來說，就是用戶在使用產品時，我們是如何通過功能設置和引導，逐步將用戶導入到各個功能上，最終解決用戶的具體問題。產品路徑從本質上來說，其實是用戶流量的流轉路徑，每一次跳轉就是一次用戶轉化，多條產品路徑匯聚在一起形成流量漏斗。

任何產品都有產品路徑，因為任何功能都是逐步完成的，無論是一步完成，還是N步完成。

我們先來看看ToC的產品路徑

當我們站在ToC的產品角度來看時，當產品路徑越長，其實損失掉的用戶也就越大，因為每一步跳轉帶來的可能都是用戶放棄使用的風險。因此，我們設計產品路徑時，需要考慮的最關鍵因素是，如何盡量縮短產品路徑，從而能夠確保用戶的體驗和每一步的留存轉化都能足夠的多，儘可能減少損失用戶。

我們來舉個例子。

摩拜單車和ofo在產品路徑設計上是有非常大的區別的，這一點也是為什麼摩拜總給人以體驗更優的印象。

摩拜的產品使用主路徑是這樣的：

打開摩拜App——點擊掃碼——掃一掃自動跳入開鎖等待狀態——等待幾秒自動完成開鎖——騎行結束手動鎖車，系統自動結費。
摩拜的整個使用過程只有五步（由於中間需要等待，我將掃一掃和等待開鎖分為兩步）。

再看看ofo的產品使用主路徑：

打開ofo App——點擊掃碼——掃一掃跳轉獲取密碼——手動輸入車鎖密碼——點擊開鎖鍵——騎行結束手動鎖車——撥亂密碼鎖——打開ofo App——點擊支付。
ofo的整個使用過程長達九步。

這樣一對比，兩個產品在使用過程中的主路徑長度相差近一倍，這直接反應在了用戶體驗上。

在ToC的產品中，產品路徑每多一步，就是增加一次用戶體驗斷點的風險，萬一在這一步出現了bug或者網路問題，直接導致的就是用戶流失，轉化率下降。

問題來了，ToB的產品也是這樣看待產品路徑的嗎？

我們再來看一個例子。

假如我們想為某家醫院做一套患者隨訪（隨訪是指醫院對出院患者的持續病情追蹤手段）的工具，我們會怎麼思考這個問題呢？當我們深入去和醫院來溝通這些需求時，我們會發現，一個隨訪大概有如下步驟：

選中一個患者——選中需要進行的隨訪模板——選擇隨訪的日期——指派隨訪的護士——護士執行隨訪並填寫隨訪記錄——護士關閉完成隨訪。
整個過程至少六步。

我們會發現，這個過程是固定的，一個也省不了，無論是醫院A還是醫院B，一個隨訪都至少需要以上的六步，我們無論怎麼去優化也是不可能去節省產品路徑的。

此時，我們與ToC的產品進行對比會發現，ToC的產品路徑是站在用戶的即時性需求角度來考慮的，也就是用戶當下的體驗，而ToB的產品路徑一般是站在計劃性需求的角度來考慮的，無論是一次隨訪、一次採購、一次財務報銷，它都是一次計劃。不會有哪個用戶會提前計劃自己去和誰聊微信，也不會去提前計劃自己去騎行某台單車（預約單車可不算計劃），ToC的產品需要在路徑上儘可能短，從而滿足即時性需求，而ToB的產品路徑是由計劃好的業務本身決定的，少一步業務就走不下去了，不能因為省麻煩就在隨訪中不填寫隨訪記錄，也不能因為省事就把報銷系統中的發票一環省掉。

所以，站在這樣的角度去看時，我們能夠清晰的分辨出ToB產品路徑的規範性和標準性，這一點是和ToC產品路徑最大的區別。

小結

ToB的產品是非常值得大書特書的，無論從產品邏輯層面，還是從產品規劃層面，都值得我們產品經理花費更多的時間和經理去探討。

產品說到底是為用戶服務的，無論是ToC的產品解決的是當下即時性的需求，還是ToB的產品解決的是計劃性的標準化需求，在其產品價值上都是一致的。在未來的文章中，我將逐步嘗試討論ToB和ToC的產品在體驗上的不同側重點，ToC和ToB的PM如何互相轉崗，以及ToB在運營中的側重點，並逐步嘗試討論「互聯網+」中那些和ToB緊密相連的各種產品形態，等等。期望逐步豐富對ToB產品邏輯和方法論的多樣化探討與交流。

本文由人人都是產品經理社區專欄作家@帥帥的帥原創發布
「優護家」聯合創始人兼COO；前微軟小冰初創成員，前微軟高級產品經理；北京大學計算機系碩士。專註產品、運營和商業的分析，熱衷產品方法論的總結
未經許可，禁止轉載