過去二十年是消費互聯網的二十年，大量偉大的To C 產品孕育出來，誕生了產品經理崗位。對於如何做 To C 產品，網上總結的經驗已經非常豐富了，優秀的產品經理也非常多。對比國內外的 To C 和 To B 市場就會發現，國內 To B 市場的缺口很大，機會很大，但如何打造 To B 產品，相關的內容和案例還不夠豐富，畢竟階段還處於早期，還在圍繞項目制是標準化、Cloud 還是私有化部署來展開討論。一個龐大的市場，一定是匯聚各種模式，各種模式都有各自的成功之處。神策從成立就堅持產品化的思路，四年多來已服務了上千家的付費客戶，在如何進行 To B 產品化方面，有了一點心得，與大家做個分享。

To C 和 To B 產品的不同

兩類產品在面對的客戶群體規模、交付模式、需求收集模式上，有很大的差異。

To C 產品一般用戶規模大，動輒數百萬，產品有什麼問題，會迅速通過數據分析發現。而 To B 產品可能只有數百家甚至幾十家客戶，每家客戶的使用人次也不會太高，這樣就導致僅僅靠數據分析很難做出科學評估，畢竟樣本數太少。

在交付模式上，To C 產品發佈即交付，只要將 App 放到應用市場，用戶立馬就開始使用了。而 To B 產品從功能發佈到產品在客戶場景上發揮價值，中間的週期一般都會比較長。當然，一些 SaaS 類的產品，通過在線更新的方式，能夠更接近 To C 產品。但在國內，大量客戶所處的階段比較初級，職業化程度還不夠高，如果沒有配以相應的交付服務，客戶並不會真正使用起來。如果是私有化部署的場景，這種問題會更為嚴重。這種交付週期的拉長，直接導致的問題是發佈的功能無法及時獲取到有效反饋進行迭代閉環。

在需求收集模式上，To B 產品倒是有它的優勢，客戶的需求會直接、精確的反饋，客戶要什麼功能，會直接告訴你，你只要做出來就行。而 To C 產品，你可能收到的反饋是用戶罵你產品很爛，體驗很差，但你還是不明白用戶遇到的問題到底是什麼。從這一點來說，我覺得

除了以上三點不同，還有兩點巨大差異。

一是To C 產品的可用性到商業化是可以完全分離的。你只要做出一個用戶喜歡的產品，爆發性的獲取海量用戶，那就有 VC 願意投資，你靠燒錢的方式就可以達到壟斷市場的地位，然後進一步考慮商業化變現的方式，如果想不清楚，就放點廣告。而 To B 產品不同，如果你做的一個產品只是有用但是收不到錢，可能以後也不好收上來，也不可能通過加點廣告的方式獲利。而反過來好的一面是，只要產品有用，客戶一般也是願意付錢的。因為客戶需要的不只是產品，還需要有服務帶來的安全保障。

二是To C 產品的規模化擴張一般沒有人力和產品本身的限制，只要加服務器和帶寬，就可以支撐更大量級的用戶。而 To B 產品從服務幾十家客戶到服務幾千家客戶，所需要具備的能力可能有本質的不同。在早期的若干個客戶，客戶的獲取和服務，可能創始人和核心成員就可以搞定，但客戶規模再進一步擴大，這些核心成員就分不出精力了，必須擴展足夠有效的人手，而這點是非常有挑戰的。

結合以上這些差異點以及神策自身的經歷，我把To B 產品的打造分為三個階段：可用、可賣和規模化。

可用

一款可用的產品，是要在客戶場景中發揮實際價值的。如果開發了若干個功能，但這些功能是偽需求，那是沒有價值的。我接觸過大量創業者朋友，最後證明需求假設是不成立的。許多人把Demo 當作可用的產品，這是不對的，Demo 只能擴展想象力，但無法發揮實際價值。如何打造一款可用的產品，我比較認可《精益創業》的理念，要做 MVP（Minimum Viable Product，最小可用產品），做價值假設和商業假設的驗證。

就拿神策分析來看，2015 年最早設計時，我們規劃了 11 個功能，預計花四個半月的時間，能夠推出第一版。但我想這樣憋大招太危險了，拿的天使投資也就夠花一年，要儘快做驗證。於是我們篩選了三個功能：事件分析、漏斗分析、留存分析，計劃一個半月推出 0.1 版。等到一個月時，團隊的壓力很大，我和他們商量是不是要再砍掉一個功能，我們不要因為趕工，最後做成了個 Demo。好在團隊抗住了，我們按期拿出了 0.1 版，去找一些種子客戶去做溝通。大家對我們產品交互的靈活、實時性很滿意，但明確指出我們缺少報表功能。在產品設計之初，我們想我們要做下一代的數據分析系統，要和過去說再見，像報表這樣的過時的東西，我們就不打算要了，沒想到客戶不這麼想。等我從客戶那裡回來後跟團隊說，接下來一個月，我們就只做一個報表概覽的功能，其他都不做，要包括 Web 版和手機瀏覽器適配版。一個月後 0.2 版出來了，我們又拿給這些種子客戶去看，他們開始問我們打算怎麼收費，我知道我們這是一個可用的東西了。

MVP 妙就妙在讓你集中精力把最核心的價值流程走通，其它的周邊都忽略。資源畢竟是有限的，尤其是在初期，我們需要用最小的成本最小的時間週期去做出嘗試，行或者不行，及時得到反饋。就拿 Airbnb 來說，他們最早的 MVP 就是建了個網頁，在上面放了段描述和照片，如果需要預訂床位，就發郵件。雖然這個產品非常簡陋，但它可以實現核心功能，做出快速驗證。

MVP 不是 Demo，更不是一個不可獨立使用的組件，它更像是你造出汽車前的滑板。雖然簡陋，但卻實現了你要從 A 到 B 地的目的。通過後續的迭代，從滑板到自行車、到摩托車、再到汽車。

可賣

一款產品能做出來到賣出去，這中間還有個跨度。在我們自己產品推出之前，我們也有兩個合同，但那兩個合同完全是諮詢項目，是靠我們的專業技能換來的，並不是靠產品掙來的。等0.2 版產品出來後，有位也出來創業的前同事朋友找到我，聊了聊他們的需求，發現很匹配。問我怎麼收費，我說一年 20 萬，他說太貴了，一共才融 500 萬怎麼可能花這麼多買數據工具，我說你打算給多少，他說 5000 塊，我說成交。就這樣，我們在國慶前拿到了第一筆產品付款。之後逐步完善了收費模式，基本採用了按照客戶接入數據規模分階梯定價的方式，不限制客戶的使用人數。

對於一個產品到底如何定價，這是門學問，我相信核心取決於能給客戶帶來的價值，而不是成本。有些生意不成立，就是在於成本太高，但是客戶願意為此付出的價錢是遠低於成本的。就像現在一輛實驗中的無人駕駛汽車，光成本都要200 萬，可用戶可能只願意花 50 萬購買。還有一個因素是競爭，如果競爭激烈，對於客戶來說可做的選擇變多，對你的依賴性降低，自然就有了更好的議價能力。

許多人把可用和可賣混在一起，可用還沒做好，就想賣出去。這樣即使賣出去了，客戶不能很好的使用出價值來，只會收穫負面口碑。在To C 產品裡，提前賣出去叫期貨營銷，像提前預定、眾籌等。在 To B 產品裡，一般是出於客戶對你的信任，提前購買了期貨，這些期貨有可能交付不了，也有可能到後面不是自己產品化想做的，變成定製化開發模式。我們在最早推出產品時，自然沒有賣期貨的條件。但之後因為有了一批客戶，所以在打造新品時，也犯了想要提前賣出去的錯誤，還好及時做了調整，讓新產品有節奏的進行迭代。

規模化

To B 產品能賣出去，不代表可以規模化地賣出去。

在組織能力上，首先要考慮的就是組建銷售團隊。神策最早的一批客戶，主要是我和合夥人跑客戶拿下來，接下來的一年我們定了300 個客戶 1500 萬營收的目標，這靠我們兩個無論如何也實現不了的，必須要組建銷售團隊。開始的時候我想的比較理想化，招一批 IBM、Oracle 出來有技術背景的銷售，每人每年拿下 20 個客戶就可以。結果發現完全招不過來，誰會看上我們這樣的小技術創業公司。後來經朋友介紹，招了銷售總監。他入職的第一天我就跟他說，接下來我們銷售就靠你了，沒想到他給我說千萬別這麼想，銷售是負責摘果子的，得有人種果子。這我才知道還得有市場團隊獲取線索。

因為招不過來有技術背景的銷售，我就跟團隊說，咱們要把產品儘量簡化些，讓普通銷售都能學得會講得明白。銷售總監也建議開始的招聘還是放開了試，於是我們開始了第一批銷售團隊的組建。這批招聘的人裡有賣鞋的，有賣衣服的，也有修下水管道做節能的，有在鋼鐵國企坐班的。入職後給他們做了基本培訓後進行串講考核，結果講得一塌糊塗，一些術語完全不知道什麼意思，只是隨機的組織在一起，我的內心拔涼拔涼的。可沒想到兩個半月後竟然開始出單了，大大出乎我的預料。就這樣我們靠著這麼一支銷售隊伍，超額完成了全年業績。我們事後覆盤，還是認為當時及時組建銷售團隊是很明智的決定。

從客戶群來說，不同的群體需求不一樣。在服務互聯網公司時，一般只要產品功能過硬就行，其他服務需求不大。但是面對傳統客戶，服務、諮詢類的全面解決方案就成了需求。這就需要不斷迭代整個產品和服務體系，不管是產品功能、服務流程、角色分工、管理工具等，全面的提升，這樣才能規模化的支持客戶。

以上是我對To B 產品的三個階段的認識，要指出的是， To B 產品肯定也是要像 To C 產品那樣不斷迭代升級的，過了初期規模化，就要不斷的進行迭代。這種迭代過程，我又把它分解為需求感知、產品迭代、價值交付三個環節，後面再單獨講解。

閱讀更多 企業應用研究 的文章

關鍵字: 美好，一直在身邊 可賣 投資