目前行业内更多的是探如何做 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 产品的打造分为三个阶段：可用、可卖和规模化。

一、可用

一款可用的产品，是要在客户场景中发挥实际价值的。如果开发了若干个功能，但这些功能是伪需求，那是没有价值的。我接触过大量创业者朋友，最后证明需求假设是不成立的。许多人把 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 产品那样不断迭代升级的，过了初期规模化，就要不断的进行迭代。这种迭代过程，我又把它分解为需求感知、产品迭代、价值交付三个环节，后面再单独讲解。

作者：桑文锋；公众号：神策数据

本文由 @神策数据 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议