編輯導語：對於產品經理來說，需要具備迭代思維和演化思維，任何一個產品都是從小到大的成長，從少到多的裂變，或者從多到少的整合，目的是產品健康的發展，支撐的是產品演化的底層邏輯。該篇文章作者進行了產品模式相關的冷思考，感興趣的小夥伴一起來看看吧~

一、模式很重要，但解決關鍵問題更重要

最近聽到太多商業模式的介紹，有的模式甚至很難一下子聽懂，弄明白。為什麼很多人張口閉口的就是模式，感覺設計不出牛逼的商業模式，就沒法行動一樣。把商業模式放在第一位，是因為商業模式是公司賺錢的基礎，把公司整個盈利的流程搞清楚，再去研究其它的基本面，就會很清晰，它與市場空間、核心競爭力都有非常大的關係。

商業模式就是企業為了最大化企業價值而構建的企業與其利益相關者的交易結構。通俗的講，這就是一個公司靠什麼賺錢，怎麼賺錢的一個全過程。

商業模式畫布是大家最常使用的商業模式表達工具，針對商業模式畫布這個工具，大家可以參考我之前寫的一篇文章：《產品戰略可以簡單，但要方向清晰》。

但是不管商業模式多麼的複雜，多麼的精巧高階，其實無非就是要問以下幾個問題：

到底誰是你的客戶？

你能提供什麼價值？

憑什麼是你？

怎樣才能賺錢？

如果商業模式可以抽象的話，不論多麼複雜的商業模式是不是都可以抽象成：交易模式和流量模式，以及兩者的組合？

To B偏交易模式，To C偏流量模式，2B2C可能二者兼有。比如筆者負責的區域資訊化的專案，如果客戶付費建設，這就是交易模式；如果客戶不出資，免費建設，透過運營變現，則又成了流量模式。在醫療行業，有些是銀醫專案，客戶是醫療機構但不出資，出資方是銀行，這又是什麼模式呢？其實對於建設方來說，是交易模式，畢竟是有直接的買單方。但對於銀行來說，又是流量模式，因為是在流水中獲益而非直接服務中獲益。

所以商業模式從抽象的角度來說，都是非常簡單的，其實事實證明越是簡單的商業模式越有生命力。所以不論多麼複雜的商業模式拆解開，都基本上是這兩種模式和利益相關方的排列組合。

有商業模式就一定能成功嗎？肯定不是！否則千團大戰中就不會只有美團獨霸天下，社交圖譜中也不是騰訊花開萬家，我們可能也就早已成功了。商業模式只是設計了一條通往成功的路徑，但真正能夠走通的取決與有沒有能打仗的人以及能夠攻克過程中關鍵的問題，這恰恰才是最核心的也常常被忽略的因素。

在參與一些商業模式討論時，很多設計者經常說，假如政策放開以後，我們怎麼怎麼的！假如我們有了流量，我們盈利方式及能力怎麼怎麼的。我們過多的描繪了終極的狀態，卻忽視了透過終極狀態的障礙，或者我們並沒有把精力放在如何去清理這些障礙，也就是讓假設的條件變成現實。

接下來，我們以B2B2C的業務形態，做一個簡單的模式分析以及關鍵問題分析，並嘗試尋找解決方法。

二、以B帶C，如何利用客戶私域流量

作為主要面向To B領域業務的公司，我們卻一直想做To C的業務，因為To C的業務一旦規模做起來，對於公司的融資、變現能力都會有非常大的作用。而對於BAT這樣To C領域的巨頭來說，它們又開始像產業網際網路滲透，在To B領域開始深耕。這真是圍城啊，城外的看城內很熱鬧，城內的看城外的世界很精彩。

但是To B和To C的業務有著非常大的區別，這也是滲入和轉型困難的地方，但是二者並非不能相互轉化。為此，前幾年我寫了一篇文章：《產業網際網路下的To C產品演化路徑》，以實際的案例分析了To B到To C的演化路徑，可惜我們操之過急，想一下子跳到到C端，忽略了中間過程的重要性，反而導致了欲速則不達的境況。

To B到To C的轉化，需要業務形態變成B2B2C的模式，我們是第一個B，客戶是第二個B，客戶服務的使用者是C，剛開始這個C並不是我們的C，而是我們服務的B的C，我們過早的跳到C端，就導致我們給客戶搶使用者的情況。我們越強化C端的品牌，就越造成客戶面向C端的流失，因為誰都不想分享自己的私域流量，除非你能幫他輸入流量。

對於私域流量，要麼擁有它，要麼使用它，否則就意味著以B帶C的方向不成立！

但私域流量是自私的，它又怎麼輕鬆到你這裡來呢？這就是我們在這個業務模式下需要解決的關鍵問題！這裡有兩種路徑供參考：

第一，客戶私域流量疊加形成平臺的公域流量

SaaS產品和網際網路平臺最直接的區別是什麼？一個侷限於工具，一個提供了資源。這就好比SaaS產品就是建築商，給你建造房子、裝修房子，至於入住後做什麼買賣，買賣好壞，他就不管了。而平臺就像地產商，他是為你建一套房子，而是建一個商場，規劃商業專案；你領包入住，水電裝修一應俱全；他還時不時搞搞活動，發發傳單，給你做做廣告。

SaaS產品本質上是To B的業務，而平臺產品是To B和To C通吃，因為他的主要職能就是撮合交易。所以平臺產品掌控C端流量，而SaaS產品的C端流量則掌握在每個B手裡，即B的私域流量。但好處是這些私域流量的載體是在一個SaaS產品上，這是To C的基礎。當一個個的私域流量在C端疊加時，最開始的B2C的供給模式就有可能增加C2B的需求模式，供需關係就逐步的建立，只要供需關係成立，平臺就可以轉化私域流量成公域流量，公域流量又能匯入到私域流量，生態協同關係誕生，To C的網際網路平臺也就成立了。

有贊商城其實非常符合這種模式，從工具切入形成一個個私域流量，當供給方和需求方達到一定程度後，開放公域流量，形成電商生態；筆者負責的基層醫療雲平臺其實也是遵循這個模式，雖然我們現在主要To B，服務機構，透過網際網路診療由B端服務C端，未來To C方面也會大有所為。

第二，提供第三方服務轉化部分流量到自有平臺

很多人也許會問，我們的產品並不是SaaS模式的產品，是本地化交付的產品，比如很多醫療產品就是這樣的。這樣的產品我們不掌握資料，也不掌握流量，能做To C的業務嗎？答案是很難但不是沒有機會！

機會就是你是否能夠提供B端無法滿足，但又是C端需要的服務或者資源，將服務整合到B端客戶的C端產品中，從而分流一部分使用者到自己的服務上來，從而間接的實現了To C的目的。

比如我們在做基層醫療專案中，C端的APP是屬於B端客戶的，但是如果我們醫藥電商的業務能夠整合到客戶的APP裡，從而提供線上售藥的服務，其實也是由B到C的模式實現。

除了電商服務適合這種模式外，其實偏運營的內容服務、社群服務，以及人工智慧這種高門檻的服務都適合採用整合的模式。

本章主要反思瞭如何定位業務模式的主要關鍵問題並有效解決它。我們不能總是停留在太宏觀的模式思考上，而是要解決模式成立的關鍵問題。不敢面對問題，不能有效的解決關鍵問題，通往模式成功的路必然阻礙重重。

下一章節我們進行產品配稱（Fit）相關的冷思考。

#專欄作家#

菜根老譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程式設計師、技術Leader、產品經理、研發Leader等多種崗位。現負責某科技公司整體產品研發，擅長企業IT架構及網際網路產品架構。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議