1. Slack:缔造 ToB SaaS 的商业传奇

都说 ToB 是个慢生意，而 Slack 只用了几年时间，就直接从 0 到了 N，并以 IPO 近 200 亿美元的市值，宣告创业的成功。

说到 ToB SaaS 领域的商业传奇，江湖老大的地位非 Salesforce 莫属，但我个人认为 Slack 要更胜一筹。虽然二者市值还有很大差距，但 Slack 却是一家用时更短、到达目标更直接、业务逻辑更简单、入口即平台、更强聚合力的轻公司，是投资人和用户都喜欢的那种类型。

根据媒体的报道：Slack 成立于 2014 年，从真正上线到成为独角兽，仅花了 8 个月时间；在推出产品 3 年后，就能跟微软正面硬刚；就连它 IPO 的姿势也非常地与众不同。

为了达到传播效果，媒体将 Slack 写成了一个 SaaS 的励志故事，而且还是随随便便成功的那种。实际上，媒体没有告诉你的是：Slack 成立于 2008 年，就是说在其崭露头角之前，已经整整奋斗了 6 年，成功是因为它做对了某些东西。

要知道在企业协作领域，无论国外还是国内，本来就是一片纯粹的红海。特别是国内，除了专业公司的协作产品之外，行业巨头也纷纷加入企业协作领域，如：钉钉、企业微信、百度 hi、Lark、大象、豆芽、咚咚等等。

同时在这个领域，中国也有几项世界之最，比如：开始最早、创业公司最多、投入资源总量最大和企业市场容量最大… …，遗憾的是起了个大早，但连晚集都没赶上。

我想一定会有许多人问：为何在国内企业协作领域，就没能出一个 Slack？

对 Slack 这样一家牛公司，无论如何解读都是「马后炮」。所以本文目的并非揭秘 Slack 成功，而是尽可能发掘有价值和可借鉴的东西。

写这个主题也是有感而发：与 Slack 同年成立的今目标，是我进入 SaaS 领域的第一家创业公司。一个偶然的机会，发现与我们在做同款产品的 Slack，其博客中关于团队协作的理念对我们影响很大。在当时来说是清新脱俗，脱离了「俗套」的 OA 产品套路。

2. 十年红海:企业协作从 1 到 N 的宿命

Marc Andreessen 是 PMF 概念的提出者，他认为：对于初创企业来说，找到 PMF 是唯一有意义的事情；甚至还说：初创公司只有两种：找到 PMF 的和没找到的。

这个抽象的概念翻译成白话文就是：你可以做出千万种产品，也有千万种市场需求，而这两者交集部分才是创业该干的事，我们只用 PMF 来解释红海的形成。

坦率来讲，我并不认为 PMF 有太大的实用价值，也就是一个基本的常识。非常不幸的是，很多已经消失的、苦苦支撑的和拿钱砸坑的公司，恰恰就违背这个基本常识。它们用了十余年的时间，挖了一个深红的人工红海：不但市场不成熟、但竞争却很充分。

近十年以来，创业失败排在首位的原因，始终是市场不存在（No Market Need），这么说还不太准确，可以用 PMF 再细分一下：

1. 你找到的 PMF 实际上并不成立，也就是你的产品只与你想象的市场有交集，这个产品世界上只有你一家会做，可是没有人会买；
   

2. P-M fit 得不够精准，也就是产品与市场交集太大，你用一个大众化产品、进入了一个红海市场，如：所有公司都要销售，所以做 CRM 准没错；
   

3. 只有产品而不知道其对应的市场，也就是说不知道产品与市场交集在哪里，如：你可以复制 Slack 产品功能，而不了解其市场背后存在的用例（Use Case）。直接复制的国外对标产品/赛道，基本属于这种情况。

   
   

个人认为，特别是上述第 2 种情况，基本代表了目前企业协作领域的现状，这个认知也就决定了初创公司从 1 到 N 的宿命。

你也许会问：红海市场难道不是市场吗？没错，红海也是市场，但是属于你的那一份被稀释得微乎其微，而且还可能是无利可图。

还有，钉钉和企业微信等，已经拥有百万级客户数和亿级用户数，它们应该是成功了吧？是的，这个客户数量非常了不起。遗憾的是，你无论是看 IPO 文件，还是营收和股东利益报表，免费客户/用户数不是核心指标，所以还不算商业意义上的成功；相反还会对应着巨大的成本，业务指标未必比其它公司健康。

Slack 在 IPO 相关文件中提到过有 8 万多家付费客户和 55 万个增值免费用户；但是随后还要说，将以多高的转化率和多少时间，对应产生多大的增长预期，这才是正常的商业因果逻辑。

由此我们可以得出基本结论：

1. 企业协作领域的创业公司，集体进入了一个发育不成熟、但完全竞争的红海。而完全竞争下没有公司能获利；不但近期现金流会有问题，作为 SaaS 的远期投资价值也无从谈起，这个领域初创公司的失败是超大概率事件；
   

2. 红海的成本极高，初创公司都在忙于干从 1 到 N 的徒劳之事。更多精力并没有放在用户身上，而是不惜代价与同行较劲；这个过程没有赢家，更不可能跑出来一个 Slack；
   

3. 只有通过从 0 到 1 的创新，重新定义企业协作领域属于自己的市场，并成为这个市场的垄断者，这是产生中国 Slack 的唯一途径。

   
   

3. 从 0 到 1 的救赎之道

「幸福的家庭总是相似的，不幸的家庭各有各的不幸」，而在企业协作领域，情形则恰恰相反。企业成功的原因各不相同：每个垄断企业都是依靠解决领域内独一无二的问题，而获得其垄断地位；而企业失败的原因却都相同：被困于竞争中而挣扎和消失。

1）从 1 到 N 的产品思路, 只能产生平庸的产品

按照通常的 ToB 产品方法，先要找到客户的「痛点」，然后给以解决；更有产品行家说，你的产品最好能让用户「上瘾」，你就一定会成功的。不幸的是，这在 ToB 领域是个理论派的做法；大多数协作产品也是这么做的，然而市场上的产品依然是大众化的。

实际上，在 ToB 领域既没有痛点，更不可能有人会上瘾。首先，企业能走到现在，不会是满身痛点了，否则早就经营不下去了；其次，最严重的痛点只能是个别问题企业的，解决个体问题对产品没有意义；最后，即使存在共同的痛点，你产品也未必解决的了；亦或是所有产品都能解决的、你并非独一无二；更消极地说，企业的痛点与使用者也没啥关系。

至于上瘾一说更是有点扯，即使一个工作狂，也不会本末倒置，对工具上瘾。

2）创造需求才能产生从 0 到 1 的飞跃

一个产品的好坏，并非由其本身决定，而是由产品的背景（Backdrop）要素决定的。例如：做一个与淘宝一模一样的网站，在技术上没有问题；但没有卖家、买家，知名度、商品、流量这套背景要素，这个平台产品就没有任何意义。

在一个 Backdrop 下可能找不到痛点，但一定存在着一些「麻烦」（Troublesome）；而这些麻烦，用户可能并未意识到，比如过去的手机都是按键式的，直到苹果触屏手机的出现。

所以 ToB 产品需求不是痛点，而是麻烦，这些麻烦是你创造出来的需求；产品粘性也不是上瘾产生，而是用户为了解决麻烦而不得不用。

解决竞品都能解决的基本需求，那是你分内的事；而为用户创造需求，用户才觉得爽。

创造需求，也就是找出用户的麻烦，比常规需求获取要难得多。可以参考产品专家给出一些实践方法，比如画客户的「麻烦地图」和找「摩擦点」等。从后面章节中的例子，可以看到 Slack 是如何创造需求的。

3）10 倍提升才可以说有效

无限度增加功能、修修补补和平均用力，都不可能产生从 0 到 1 的质的飞跃。举个 10 倍提升的栗子，项目协作依赖团队成员的紧密沟通，通常都是用电邮方式完成的。交互的内容包括：会话记录、数据、文档、其它工具输出内容等，摩擦点包括：邮件交流都是发到收件箱的、内容无法共享；无法获取其它信息源的信息，内容资料的增添和去除更加麻烦… …。

于是 Slack 开发了 Channel，可以随时加入或移除项目相关成员，重要的是：它将所有类型信息在 Channel 内汇集和分享，非常简单吧？但在这个用例下，比邮件或其它方式的效果提升 10 倍以上。

4）忽视易用性，后果很严重

易用性并不是使用者的主观评价和调研评分，脱离背景和用例谈易用性毫无意义。

好用的 ToB 产品都有一个共同特征：即信息工具与业务工作具有合二为一的效果，也就是产品与背景融为一体，使用中并未察觉到信息工具与业务过程彼此的存在。不好的产品会形成两张皮和相互摩擦，让用户使用勉为其难。

客户黏度不够（后果是客户流失），大部分情况下不是产品不对，而是缺少合二为一的效果。

Slack 创始人 Butterfield 也在其博客中也讲到：「如果 Slackack 可以与某些用户的行为吻合，让使用成为习惯，能够吸引员工，那么一旦没有了 Slackack，他们就会像宇航员在太空中失去头盔一样」。

4. 学习 Slack 好榜样

随着 Slack 的上市，其神秘的面纱也被逐渐揭开。从招股说明书等文件中，即可以了解以往未公布的所有财务、业务、客户和产品等关键数据和关键信息；以下内容只是我个人的粗浅分析与理解：

1）定义自己的市场

Slack 一词给出了两种解释：一种即 Slack 的单词本意，即放松，寓意工作应该是轻松和愉快的；另一种解释为 Slack=SearchableLog of All Conversation and Knowledge，意为所有会话和知识的历史信息的可检索记录，很显然，后一个是 Slack 所创造的终极需求和产品宗旨。

这个产品宗旨的高明之处在于：它支持了几乎各种工作类型和角色参与的用例，比如：项目、工程、财务、法务、人力等，都需要与以往工作结果的承接，形成一条工作主线（在今目标中直接将其命名为主线）。Slack 网站首页的 Slogan：无论你做什么工作，你都可以在 Slack 中完成，事实也的确如此。

我们再深入拆解，SearchableLog 有两个分类：Conversation 相当于 IM 信息，Knowledge 则可能包括文档、数据、流程、视音频，以及来自其它业务模块的集成信息。

这个定位，使 Slack 将自己从协作产品市场中明显地区分开来，切口既宽又深，较好地定义了自己的市场。

2）简单的力量

Slack 可以被理解为一个平台，每项工作都是一个群组，群组中自动汇聚了分散的、碎片化的、业务必需的信息和数据。

这个复杂的需求被实现为一个称为 Channel 的东西，也是整个 Slack 的功能核心。只用单一入口解决所有需求问题。Channel 之间、甚至是与其它公司 Channel 之间，可以实现互通和共享。当人员加入或离开项目或组织时，Channel 的成员权限也会发生变化。

可以看出，与传统的、从多个模块中找信息方式相比，没有比这更简单的了。

所有 ToB 都绕不开的另一个问题，就是与其它 IT 业务的集成，也是实施时费时费力的苦活。当别人还在为系统可集成性伤脑筋时（避免出现新的烟囱），Slack 已经将业务数据集成的流畅性列为基本集成标准。

通过一个称为 Slack App Directory 的东西，以非常简单的方式，与超过 1,500 个 App 直接集成，从 Dropbox 到 Salesforce 都在其可集成应用程序列表中。此外，Slack 不仅是与第三方应用程序的集成，还可以与组织内部开发的软件轻松集成。

3）粘性必定来源于解决了一些关键的问题和麻烦

用户为什么愿意用呢？我臆测与解决了以下几个问题有关：

1. 每个角色都是同一个入口和同一形式，信息自动聚合，无需到处去寻找；
   

2. Channel 也是各个业务的入口，来自那些可集成的 App 信息和数据；
   

3. Channel 间隔离和权限机制，解决了信息过载和干扰问题；用微信群就存在这个问题；
   

4. Channel 形成的主线，形成新的知识和价值实例，并永久存储和可查询；
   

5. 还有其它…

   
   

4）平台、生态与心态

做产品看起来是纠结做哪些功能和做多少问题，实际上是某种担心和心态问题，这种心态会导致失焦，从而无法实现构想的商业目标。

举个栗子，信息聚合肯定离不开云盘；但 Slack 并没有同时做一个更好的云盘，而是开放了几乎所有主流云盘的接入（通过 App Directory）。而大部分做协作工具的公司，都会自己再做一个网盘，肥水不流外人田嘛。导致的后果可能销售比较清楚，但产品经理觉得没啥不对。

只要是产品就会有天花板、会饱和，但平台不会，Slack 深谙此道。

Slack 的 App Directory 方法，真正使 Slack 变成了一个生态化的平台。平台的本意是最大限度地方便客户，使用户的业务能在无感的状态下连续完成。

国内企业协作公司，无论自身大小，都想成为平台。所谓的平台也更像是个卖场或商城，有关无关的东西都放上来。即使货不全也得在这里买，特别是不少应用的边界有重叠，这不能给客户提供任何的方便，还产生选择困难。

这种基于厂商利益关系的平台和生态，这可以理解为寒冬中的抱团取暖，但很难成功。

5. 营销：于无声处的激发力

好的需求是创造出来的，并非用户通过常识就能轻易发现。激发力是商业设计中至关重要的一环；在激发力的驱使下，让客户本源需求迅速变为你创造的需求。

Slack 的营销并非像其它公司那样，用尽各种方法和手段四面出击；而是采取少数几个「简单」的手段，形成强大的激发力，短期内就拥有别人很长时间才有的增长优势：

1）去平均化

所谓去平均化，就是每次只增加一类客户；虽然客户数量开始可能很少，但随后向相类似的客户群逐步扩展。这跟我们高举高打、直接面向 4300 万家客户营销，是完全不同的套路。

Slack 开始的几百家客户，大都集中于硅谷地区的高科技公司。

2）口碑营销

并没有使用多种营销方式，内容营销和 SEO 也不是重点，Slack's Medium 带来大量流量，口碑营销是其自始至终的主要营销手段。

3）曲线截胡

搜索其它 ToB 产品，可能会得到 Slack 与该产品集成的 Landing Page，巧妙截胡而不是取而代之。

4）自下而上

并不是直接搞定 Kp，然后在大组织里硬推。而是从部门或项目小组下手，然后向上利用内部人推广。

5）名人效应

Butterfield 也是 Flickr 的创始人，所以自带光环，一般公司不具备这条件。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。