作者 / 帥帥的帥
我本人是做 To C 產品出身的， 但是， 卻在過去相當長的一段時間中從事 To B 產品的設計， 帶著我的創業團隊逐漸摸索出如何做出一款被稱得上還不錯的 To B 的產品，
我想花費一些時間和筆墨， 通過思考和討論的方式， 來分享一些我自己做 To B 產品的感受和方法論， 希望能夠與同樣是做 To B 產品的 PM 一起來探討和溝通， 互相學習， 共同進步。
在這篇文章中， 我首先嘗試討論 To B 產品的核心決策者， 然後討論其中關鍵的產品路徑邏輯， 並期望以此為起點， 逐步開始在後續文章中深入討論 To B 中的產品和運營。
To B 產品中的“B”到底指代什麼？
首先談談 To B 中的這個“B”。
B 從字面解釋， 應該是 Business， 也就是商業。 比如當年的阿裡巴巴 B2B 電商平臺， 就是將採購、供應雙方進行連接， 從而形成供應鏈電商體系。
站在商業模式的角度來說，
許多做 To B 的產品經理在經歷了產品研發之後， 發現產品根本無法賣出， B 端機構根本不採用， 其中一個很重要的原因是， B 端機構中那個重要的決策者不願意使用。
事實上， To B 的很多產品都需要非常強大的市場銷售體系， 需要針對 B 端機構中最重要的那個決策者進行定向行銷， 從而影響他的決策。
這個關鍵的決策者可以是老闆本人， 也可以是某個具體業務的負責人， 無論如何， 這個角色都是 To B 產品能夠走出去落地的關鍵性 KOL。
為了說明決策者的重要性， 我舉一個例子。
在 OA 辦公 SaaS 類 To B 產品中， 釘釘可謂是一騎絕塵， 曾經一度將廣告刷滿深圳地鐵，
釘釘在推出之後， 其一系列功能都是圍繞著中小公司的老闆打造的， 就比如“Ding”這個功能， 其核心目的是防止在溝通中出現“假死”——明明看到了老闆的留言， 卻假裝沒看到。
決策者在 To B 中是很重要的， 前阿裡巴巴的 CEO 衛哲在一次分享中提及：所謂的 B2B， 其實是 Business Person To Business Person， 人與人之間的交易才促成了企業與企業之間的交易。 我們國家酒文化流行， 也是說明要向做成生意， 首先要能在酒場上成為朋友。
所以 To B 的“B”指代的是商業機構中的核心決策者或者 KOL。
To B 和 To C 在產品路徑上的不同
我在比較早前的一篇文章《進階之路：站在高視角看產品是一種怎樣的體驗？》中， 曾經提及過一個概念， 叫做“產品路徑”。
簡單來說， 就是使用者在使用產品時， 我們是如何通過功能設置和引導， 逐步將用戶導入到各個功能上， 最終解決用戶的具體問題。
產品路徑從本質上來說， 其實是使用者流量的流轉路徑， 每一次跳轉就是一次使用者轉化， 多條產品路徑彙聚在一起形成流量漏斗。
任何產品都有產品路徑， 因為任何功能都是逐步完成的， 無論是一步完成， 還是 N 步完成。
我們先來看看 To C 的產品路徑。 當我們站在 To C 的產品角度來看時， 當產品路徑越長，
我們來舉個例子：摩拜單車和 ofo 在產品路徑設計上是有非常大的區別的， 這一點也是為什麼摩拜總給人以體驗更優的印象。
摩拜的產品使用主路徑是這樣的：
打開摩拜 App
點擊掃碼
掃一掃自動跳入開鎖等候狀態
等待幾秒自動完成開鎖
騎行結束手動鎖車， 系統自動結費
摩拜的整個使用過程只有五步（由於中間需要等待， 我將掃一掃和等待開鎖分為兩步）。
再看看 ofo 的產品使用主路徑：
打開 ofo App
點擊掃碼
掃一掃跳轉獲取密碼
手動輸入車鎖密碼
點擊開鎖鍵
騎行結束手動鎖車
撥亂密碼鎖
打開 ofo App
點擊支付
ofo 的整個使用過程長達九步。
這樣一對比，兩個產品在使用過程中的主路徑長度相差近一倍，這直接反應在了用戶體驗上。
在 To C 的產品中，產品路徑每多一步，就是增加一次用戶體驗中斷點的風險，萬一在這一步出現了 bug 或者網路問題，直接導致的就是用戶流失，轉化率下降。
問題來了，To B 的產品也是這樣看待產品路徑的嗎？我們再來看一個例子。
假如我們想為某家醫院做一套患者隨訪（隨訪是指醫院對出院患者的持續病情追蹤手段）的工具，我們會怎麼思考這個問題呢？當我們深入去和醫院來溝通這些需求時，我們會發現，一個隨訪大概有如下步驟：
選中一個患者
選中需要進行的隨訪範本
選擇隨訪的日期
指派隨訪的護士
護士執行隨訪並填寫隨訪記錄
護士關閉完成隨訪
整個過程至少六步。
我們會發現，這個過程是固定的，一個也省不了，無論是醫院 A 還是醫院 B，一個隨訪都至少需要以上的六步，我們無論怎麼去優化也是不可能去節省產品路徑的。
此時，我們與 To C 的產品進行對比會發現，To C 的產品路徑是站在使用者的即時性需求角度來考慮的，也就是用戶當下的體驗。
To C 的產品需要在路徑上盡可能短，從而滿足即時性需求，而 To B 的產品路徑是由計畫好的業務本身決定的，少一步業務就走不下去了。不能因為省麻煩就在隨訪中不填寫隨訪記錄，也不能因為省事就把報銷系統中的發票一環省掉。
所以，站在這樣的角度去看時，我們能夠清晰的分辨出 To B 產品路徑的規範性和標準性，這一點是和 To C 產品路徑最大的區別。
小結
To B 的產品是非常值得大書特書的，無論從產品邏輯層面，還是從產品規劃層面，都值得我們產品經理花費更多的時間和經理去探討。
產品說到底是為使用者服務的，無論是 To C 的產品解決的是當下即時性的需求，還是 To B 的產品解決的是計劃性的標準化需求，在其產品價值上都是一致的。
- END -
stay hungry，stay foolish
再看看 ofo 的產品使用主路徑：
打開 ofo App
點擊掃碼
掃一掃跳轉獲取密碼
手動輸入車鎖密碼
點擊開鎖鍵
騎行結束手動鎖車
撥亂密碼鎖
打開 ofo App
點擊支付
ofo 的整個使用過程長達九步。
這樣一對比，兩個產品在使用過程中的主路徑長度相差近一倍，這直接反應在了用戶體驗上。
在 To C 的產品中，產品路徑每多一步，就是增加一次用戶體驗中斷點的風險，萬一在這一步出現了 bug 或者網路問題，直接導致的就是用戶流失，轉化率下降。
問題來了，To B 的產品也是這樣看待產品路徑的嗎？我們再來看一個例子。
假如我們想為某家醫院做一套患者隨訪（隨訪是指醫院對出院患者的持續病情追蹤手段）的工具，我們會怎麼思考這個問題呢？當我們深入去和醫院來溝通這些需求時，我們會發現，一個隨訪大概有如下步驟：
選中一個患者
選中需要進行的隨訪範本
選擇隨訪的日期
指派隨訪的護士
護士執行隨訪並填寫隨訪記錄
護士關閉完成隨訪
整個過程至少六步。
我們會發現，這個過程是固定的，一個也省不了，無論是醫院 A 還是醫院 B，一個隨訪都至少需要以上的六步，我們無論怎麼去優化也是不可能去節省產品路徑的。
此時，我們與 To C 的產品進行對比會發現，To C 的產品路徑是站在使用者的即時性需求角度來考慮的，也就是用戶當下的體驗。
To C 的產品需要在路徑上盡可能短，從而滿足即時性需求，而 To B 的產品路徑是由計畫好的業務本身決定的，少一步業務就走不下去了。不能因為省麻煩就在隨訪中不填寫隨訪記錄，也不能因為省事就把報銷系統中的發票一環省掉。
所以，站在這樣的角度去看時，我們能夠清晰的分辨出 To B 產品路徑的規範性和標準性，這一點是和 To C 產品路徑最大的區別。
小結
To B 的產品是非常值得大書特書的，無論從產品邏輯層面，還是從產品規劃層面，都值得我們產品經理花費更多的時間和經理去探討。
產品說到底是為使用者服務的，無論是 To C 的產品解決的是當下即時性的需求，還是 To B 的產品解決的是計劃性的標準化需求，在其產品價值上都是一致的。
- END -
stay hungry，stay foolish