起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識 打造TO B 產品的三個階段：可用、可賣、規?；?/h2>
目前行業內更多的是探如何做 To C 產品，對于打造To B 產品的相關分享卻十分有限，而國內 To B 市場的機會很大，到底該如何打造B端產品呢？本文作者結合自身項目經驗和具體案例，分享了 打造To B 產品的三個階段：可用、可賣和規?；?，供大家一同參考和學習。
過去二十年是消費互聯網的二十年，大量偉大的 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 產品更強調創新，而 To B 產品更強調效率。
除了以上三點不同，還有兩點差異是巨大的：
一是 To C 產品的可用性到商業化是可以完全分離的。你只要做出一個用戶喜歡的產品，爆發性的獲取海量用戶，那就有 VC 愿意投資，你靠燒錢的方式就可以達到壟斷市場的地方，然后進一步考慮商業化變現的方式，如果想不清楚，就放點廣告。
而 To B 產品不同，如果你做的一個產品只是有用但是收不到錢，可能以后也不好收上來，也不可能通過加點廣告的方式獲利。反過來好的一面是，只要產品有用，客戶一般也是愿意付錢的。因為客戶需要的不只是產品，還需要有服務帶來的安全保障。
二是 To C 產品的規模化擴張一般沒有人力和產品本身的限制，只要加服務器和帶寬，就可以支撐更大量級的用戶。而 To B 產品從服務幾十家客戶到服務幾千家客戶，所需要具備的能力可能有本質的不同。在早期的若干個客戶，客戶的獲取和服務，可創始人和核心成員就可以搞定，但客戶規模再進一步擴大，這些核心成員就分不出精力了，必須擴展足夠有效的人手，而這點是非常有挑戰的。
結合以上這些差異點以及神策自身的經歷，我把 To B 產品的打造分為三個階段：可用、可賣和規?；?/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 產品里，一般是出于客戶對你的信任，提前購買了期貨。這些期貨有可能交付不了，也有可能到后面不是自己產品化想做的，變成定制化開發模式。
我們在最早推出產品時，自然沒有賣期貨的條件。但之后因為有了一批客戶，所以在打造新品時，也犯了想要提前賣出去的錯誤，還好及時做了調整，讓新產品有節奏的進行迭代。
三、規?；?/h2>
To B 產品能賣出去，不代表可以規?；馁u出去。最早買你產品的可能是關系戶，也可能是《跨越鴻溝》里提到的創新者，他們愿意嘗試新東西。可從早期的幾個客戶擴展到更大規模的客戶，就需要考慮組織能力、客戶群需求差異等問題。
在組織能力上，首先要考慮的就是組建銷售團隊。神策最早的一批客戶，主要是我和合伙人跑客戶拿下來，接下來的一年我們定了 300 個客戶 1500 萬營收的目標，這靠我們兩個無論如何也實現不了的，必須要組建銷售團隊。
開始的時候我想的比較理想化，招一批 IBM、Oracle 出來有技術背景的銷售，每人每年拿下 20 個客戶就可以。結果發現完全招不過來，誰會看上我們這樣的小技術創業公司。后來經朋友介紹，招了銷售總監。他入職的第一天我就給他說，接下來我們銷售就靠你了，沒想到他給我說千萬別這么想，銷售是負責摘果子的，得有人種果子。這我才知道還得有市場團隊獲取線索。
因為招不過來有技術背景的銷售，我就給團隊說咱們要把產品盡量簡化些，讓普通銷售都能學得會講得明白。銷售總監也給我建議開始的招聘還是放開了試，于是我們開始了第一批銷售的組建。這批招聘的人里有賣鞋的，有賣衣服的，也有修下水管道做節能的，有在鋼鐵國企坐班的。
入職后給他們做了基本培訓后進行串講考核，結果講得一塌糊涂，一些術語完全不知道什么意思隨機的組織在一起，我的內心拔涼拔涼的。可沒想到兩個半月后竟然開始出單了，大大出乎我的預料。就這樣我們靠著這么一支銷售隊伍，超額完成了全年業績。我們事后復盤，還是認為當時及時建銷售團隊是很明智的決定。
從客戶群來說，不同的群體需求不一樣。在服務互聯網公司時，一般只要產品功能過硬就行，其他服務需求不大。但是面對傳統客戶，服務、咨詢類的全面解決方案就需要了。這就需要不斷迭代整個產品和服務體系，不管是產品功能、服務流程、角色分工、管理工具等，全面的提升，這樣才能規?；闹С挚蛻?。
以上是我對 To B 產品的三個階段的認識，要指出的是 To B 產品肯定也是要像 To C 產品那樣不斷迭代升級的，過了初期規?；?，就要不斷的進行迭代。這種迭代過程，我又把它分解為需求感知、產品迭代、價值交付三個環節，后面再單獨講解。
作者：桑文鋒；公眾號：神策數據
本文由 @神策數據 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
更多精彩內容，請關注人人都是產品經理微信公眾號或下載App
目前行業內更多的是探如何做 To C 產品，對于打造To B 產品的相關分享卻十分有限，而國內 To B 市場的機會很大，到底該如何打造B端產品呢？本文作者結合自身項目經驗和具體案例，分享了 打造To B 產品的三個階段：可用、可賣和規?；?，供大家一同參考和學習。
過去二十年是消費互聯網的二十年，大量偉大的 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 產品更強調創新，而 To B 產品更強調效率。
除了以上三點不同，還有兩點差異是巨大的：
一是 To C 產品的可用性到商業化是可以完全分離的。你只要做出一個用戶喜歡的產品，爆發性的獲取海量用戶，那就有 VC 愿意投資，你靠燒錢的方式就可以達到壟斷市場的地方，然后進一步考慮商業化變現的方式，如果想不清楚，就放點廣告。
而 To B 產品不同，如果你做的一個產品只是有用但是收不到錢，可能以后也不好收上來，也不可能通過加點廣告的方式獲利。反過來好的一面是，只要產品有用，客戶一般也是愿意付錢的。因為客戶需要的不只是產品，還需要有服務帶來的安全保障。
二是 To C 產品的規模化擴張一般沒有人力和產品本身的限制，只要加服務器和帶寬，就可以支撐更大量級的用戶。而 To B 產品從服務幾十家客戶到服務幾千家客戶，所需要具備的能力可能有本質的不同。在早期的若干個客戶，客戶的獲取和服務，可創始人和核心成員就可以搞定，但客戶規模再進一步擴大，這些核心成員就分不出精力了，必須擴展足夠有效的人手，而這點是非常有挑戰的。
結合以上這些差異點以及神策自身的經歷，我把 To B 產品的打造分為三個階段：可用、可賣和規?；?/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 產品里，一般是出于客戶對你的信任，提前購買了期貨。這些期貨有可能交付不了，也有可能到后面不是自己產品化想做的，變成定制化開發模式。
我們在最早推出產品時，自然沒有賣期貨的條件。但之后因為有了一批客戶，所以在打造新品時，也犯了想要提前賣出去的錯誤，還好及時做了調整，讓新產品有節奏的進行迭代。
三、規?；?/h2>
To B 產品能賣出去，不代表可以規?；馁u出去。最早買你產品的可能是關系戶，也可能是《跨越鴻溝》里提到的創新者，他們愿意嘗試新東西。可從早期的幾個客戶擴展到更大規模的客戶，就需要考慮組織能力、客戶群需求差異等問題。
在組織能力上，首先要考慮的就是組建銷售團隊。神策最早的一批客戶，主要是我和合伙人跑客戶拿下來，接下來的一年我們定了 300 個客戶 1500 萬營收的目標，這靠我們兩個無論如何也實現不了的，必須要組建銷售團隊。
開始的時候我想的比較理想化，招一批 IBM、Oracle 出來有技術背景的銷售，每人每年拿下 20 個客戶就可以。結果發現完全招不過來，誰會看上我們這樣的小技術創業公司。后來經朋友介紹，招了銷售總監。他入職的第一天我就給他說，接下來我們銷售就靠你了，沒想到他給我說千萬別這么想，銷售是負責摘果子的，得有人種果子。這我才知道還得有市場團隊獲取線索。
因為招不過來有技術背景的銷售，我就給團隊說咱們要把產品盡量簡化些，讓普通銷售都能學得會講得明白。銷售總監也給我建議開始的招聘還是放開了試，于是我們開始了第一批銷售的組建。這批招聘的人里有賣鞋的，有賣衣服的，也有修下水管道做節能的，有在鋼鐵國企坐班的。
入職后給他們做了基本培訓后進行串講考核，結果講得一塌糊涂，一些術語完全不知道什么意思隨機的組織在一起，我的內心拔涼拔涼的。可沒想到兩個半月后竟然開始出單了，大大出乎我的預料。就這樣我們靠著這么一支銷售隊伍，超額完成了全年業績。我們事后復盤，還是認為當時及時建銷售團隊是很明智的決定。
從客戶群來說，不同的群體需求不一樣。在服務互聯網公司時，一般只要產品功能過硬就行，其他服務需求不大。但是面對傳統客戶，服務、咨詢類的全面解決方案就需要了。這就需要不斷迭代整個產品和服務體系，不管是產品功能、服務流程、角色分工、管理工具等，全面的提升，這樣才能規?；闹С挚蛻?。
以上是我對 To B 產品的三個階段的認識，要指出的是 To B 產品肯定也是要像 To C 產品那樣不斷迭代升級的，過了初期規?；?，就要不斷的進行迭代。這種迭代過程，我又把它分解為需求感知、產品迭代、價值交付三個環節，后面再單獨講解。
作者：桑文鋒；公眾號：神策數據
本文由 @神策數據 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
當前項目處于驗證階段，沒有遵循可用、可賣、可規模。做了一個demo想要賣出去在做可用性，結果發現真滴走不通。
面對對象不同，階段可能會發生轉變，不乏先要可賣，再可用的產品，多出現在2G