高少星

创案例001:让全世界发消息变简单的人

Jan Koum 与 WhatsApp:让全世界发消息变简单的人

人物概况

Jan Koum出生于1976年的乌克兰。16岁时,他跟随母亲移民美国。刚到美国时,家庭经济状况并不好,一度依靠政府救济生活。母亲靠做保姆维持生计,他则靠打零工补贴家用。后来很多媒体喜欢把他的经历包装成“穷小子逆袭”,但从财富创造的角度看,贫穷本身并不会创造财富。真正重要的是,这种成长环境让他对效率、成本和浪费格外敏感。一个从小资源有限的人,往往更容易注意到那些“本不该这么麻烦”的事情。

Jan Koum没有显赫家庭背景,也没有创业世家资源。他曾进入San Jose State University学习,但最终没有完成学业。离开学校后,他并没有停止学习,而是把大量时间投入到计算机网络技术中。这个细节很重要,因为它提醒我们:这个故事不是“不上大学也能成功”的故事,而是“学历不是唯一积累方式”的故事。真正改变他命运的,不是某一张文凭,而是长期形成的专业能力。

他的关键年龄节点也很有意思:16岁移民美国,21岁进入Yahoo,33岁创办WhatsApp,38岁让WhatsApp成为全球最重要的通讯产品之一。也就是说,他不是二十出头突然创业成功,而是在行业里积累了十多年之后,才真正找到那个值得押注的问题。

第一桶金:他最早卖的不是产品,而是能力

很多人研究创业者时,总喜欢寻找那个“一夜成功”的瞬间。但真正值得研究的,往往是成功之前发生了什么。Jan Koum的第一桶金并不是WhatsApp,甚至不是创业,而是技术能力。

年轻时的Jan Koum对计算机网络产生了浓厚兴趣。他阅读技术书籍,研究系统和网络架构,不断提高自己的专业能力。1997年,他进入Yahoo担任工程师。今天看起来,这只是一份普通工作,但回头看,这可能是他人生中最重要的一次选择。

为什么Yahoo重要?因为在上世纪90年代末和21世纪初,Yahoo是全球互联网行业最重要的公司之一。它不只是一个网站,而是那个时代的互联网入口。能在Yahoo做工程师,意味着Jan Koum有机会接触大规模用户系统,理解互联网产品如何服务海量用户,也能亲眼看到一个互联网公司的兴起、膨胀和问题。

在Yahoo近九年的工作中,他至少获得了四样后来创业不可缺少的东西。第一是技术能力,尤其是支撑大规模在线服务的工程经验。第二是行业认知,他知道互联网产品不是写完代码就结束,而是要长期维护、快速响应、处理用户增长。第三是人脉资源,他在那里认识了Brian Acton,后者后来成为WhatsApp联合创始人。第四是对大公司复杂性的反感,这一点后来反而塑造了WhatsApp的克制风格:少开会,少层级,少功能,少打扰用户。

所以,从创富角度看,他最早出售的并不是某个产品,而是自己的能力。这是许多成功创业者的共同特点:在创造财富之前,他们先创造了别人愿意付费的能力。

当时的世界:发消息为什么这么麻烦

今天的人已经很难理解2009年前后的通讯环境。现在打开微信、WhatsApp或者Telegram,几秒钟就能联系到世界另一端的人。但在当时,发消息远没有这么自然。短信收费,国际短信更贵;换手机时联系人同步麻烦;不同国家、不同运营商、不同手机系统之间,体验也很不统一。

那个时代当然已经有聊天软件。MSN Messenger、Yahoo Messenger、Skype、Google Talk以及BlackBerry Messenger都存在。但这些产品大多带着上一代互联网的痕迹。MSN和Yahoo Messenger更像电脑时代的即时通讯工具,Skype更偏语音和视频通话,BlackBerry Messenger则主要绑定黑莓手机。很多产品都要求用户注册账号、记住密码、添加好友,或者依赖某个特定平台。

对用户来说,他们真正想做的事情其实非常简单:联系别人。可是产品却不断让这件事变复杂。用户并不关心你是不是即时通讯,也不关心你背后用了什么协议,他们只关心一句话:我能不能马上发出去,对方能不能马上收到。

这就是一个典型的高频痛点。它每天都在发生,每天都有人抱怨,但大多数人只是抱怨完就继续忍受。

核心故事:别人抱怨,他开始行动

2009年,Jan Koum买了一部iPhone。很多人看到的是一款新手机,而他看到的是一个新机会。智能手机意味着一个新的入口正在形成。通讯录、电话号码、移动网络、App Store,这些东西第一次有机会被重新组合。

他开始思考:为什么电话号码不能直接成为身份?为什么人与人沟通还需要注册账号、记住用户名、搜索好友?这个问题听起来并不伟大,但很多真正伟大的商业机会,恰恰来自这种普通到不能再普通的小麻烦。

于是WhatsApp诞生了。它不强调复杂功能,不试图成为门户网站,也不试图做娱乐中心。它只专注于一件事:让发消息变得简单。电话号码就是身份,打开软件就能沟通。用户不需要重新建立一套社交关系,因为手机通讯录本身就是关系网络。

后来WhatsApp形成了一套鲜明的产品哲学:能删掉的功能就删掉,能减少一步操作就减少一步操作。别人不断增加功能,WhatsApp不断减少摩擦。表面看,这是一个产品设计选择;更深层看,这是对用户需求的理解:用户不是为了使用聊天软件而来,用户只是想更方便地联系别人。

为什么最后是WhatsApp赢了

当时并不缺聊天软件,真正的问题是:为什么最后是WhatsApp赢了?

许多竞争产品都试图让自己变得更强大,而WhatsApp试图让自己变得更简单。很多团队会问:“还能增加什么功能?”WhatsApp更像是在问:“还能删掉什么步骤?”这两种问题背后是完全不同的产品哲学。

用户迁移的原因也不复杂。短信贵,尤其是跨国沟通时成本更明显;电脑端聊天工具不适合移动时代;某些通讯产品绑定特定设备;而WhatsApp直接利用电话号码和手机通讯录,让用户不需要重新学习和建立关系。一个人安装之后,如果他通讯录里的朋友也在使用,沟通成本立刻下降。

这类产品的迁移不是靠说服用户“我更先进”,而是让用户在第一次使用时就感到“这省事多了”。当一个产品能在高频场景里连续减少麻烦,用户自然会留下来,并且会带动更多人加入。

他真正创造了什么价值

Jan Koum没有发明互联网,没有发明手机,也没有发明即时通讯。他真正创造的价值,是降低沟通成本。

从商业角度看,很多伟大的企业都在做同一件事:减少摩擦。WhatsApp减少沟通摩擦,让大量用户以更低成本、更高效率完成交流。它的价值不是来自“聊天”这个概念本身,而是来自让聊天这件事更便宜、更顺滑、更少障碍。

这也是我们研究财富创造时必须区分的一点:财富不是凭空出现的。一个产品之所以能产生巨大财富,通常是因为它让大量人的生活或工作发生了某种效率提升。WhatsApp的价值,就是把一件每天发生无数次的事情变简单。

实力、时代与运气

如果把Jan Koum的成功拆开看,大致可以分为三个部分。实力来自长期技术积累、产品思维、对用户需求的理解以及执行能力。时代来自智能手机普及、移动互联网爆发以及App Store生态的形成。运气则来自遇到合适的合作伙伴,身处正确的产业环境,并在合适的时间切入了一个巨大的需求。

很多人喜欢把成功全部归因于努力,也有人喜欢把成功全部归因于运气。这两种说法都太粗糙。更准确的理解是:能力决定你是否能抓住机会,时代决定机会有多大,运气决定机会什么时候出现。

拿掉什么,这个故事就不会发生

如果一定要找出决定结果的几个关键因素,我会选择五项:十几年技术积累、对通讯问题的敏感度、极简产品设计理念、移动互联网时代、持续执行能力。

这五个因素里,任何一个被拿掉,WhatsApp成功的概率都会明显下降。没有技术积累,他很难做出稳定产品;没有对通讯问题的敏感度,他看不到机会;没有极简产品理念,WhatsApp可能变成又一个复杂聊天工具;没有移动互联网时代,产品很难快速扩散;没有持续执行能力,想法也无法变成现实。

这也是这套案例库的分析方法:我们不试图解释100%的成功,而是找出最能解释结果的几个大变量。

其他走同一条路的人

Drew Houston(Dropbox):让文件跟着人走的人

2007年,24岁的Drew Houston创办Dropbox。如果你是今天的年轻人,可能很难理解Dropbox刚出现时为什么会那么受欢迎,因为现在Google Drive、iCloud、OneDrive等云存储服务已经非常普及。但在2007年前后,很多人仍然依赖U盘、本地硬盘和邮件附件来保存、转移文件。

那个时代的文件管理很麻烦。你在办公室电脑上改了一份PPT,回到家可能看不到最新版;你准备出差,必须提前把文件拷进U盘;你给同事发邮件,附件版本一多,大家很快就分不清哪一版才是最新版本。如果电脑坏了,资料还可能直接丢失。很多人都经历过这种烦恼。Drew Houston自己也经常遇到类似问题,据说有一次出门时发现忘带U盘,这件小事促使他开始思考:为什么文件不能自动同步?为什么文件不能跟着人走,而必须跟着某一台设备走?

Dropbox交付的结果是一种云端文件同步服务。你可以把它理解成一块互联网硬盘:用户把文件放进Dropbox文件夹之后,这些文件会自动同步到其他设备。你在公司电脑上改了文件,回家打开电脑也能看到最新版本;你换手机或换电脑,也能继续访问同一批文件。它卖的不是“存储空间”这么简单,而是让文件管理从“人记得带文件”变成“系统自动同步文件”。

Dropbox并不是世界上唯一想到云存储的公司。后来Google、Apple、Microsoft都推出了类似产品。但Dropbox早期的优势在于把一件技术上复杂的事情做得非常简单:安装、登录、拖文件进去,然后不用管了。它和WhatsApp一样,都不是创造一个从未存在的需求,而是把一个高频麻烦变成顺手的工具。如果说WhatsApp解决的是“发消息太麻烦”,那么Dropbox解决的是“管理文件太麻烦”。

Patrick Collison(Stripe):让互联网收钱变简单的人

2010年,Patrick Collison和弟弟John Collison创办Stripe。普通用户每天都在网上付款,却很少思考商家是怎么收钱的。但对创业者来说,在互联网上收钱曾经是一件非常麻烦的事情。

在Stripe出现之前,如果你想做一个网站卖东西,通常需要联系银行、申请商户账户、接入支付网关、处理技术接口、满足安全合规要求。对大公司来说,这些流程还能承受;但对小团队、独立开发者和早期创业公司来说,这些流程非常消耗时间。很多创业者产品还没正式上线,就已经被支付系统折腾得焦头烂额。

Stripe交付的结果是一套在线支付基础设施,尤其面向开发者和互联网企业。它把原本复杂的银行、支付网关、安全认证和技术接口,包装成相对简单的开发工具。程序员只需要调用接口、写几行代码,网站或应用就能开始收款。对用户来说,Stripe常常是看不见的;但对商家来说,它让“把产品卖出去并收到钱”这件事大幅变简单。

Stripe也不是世界上第一个支付公司。PayPal等公司早已存在。但Stripe切入的是一个更具体的痛点:让开发者更容易把支付嵌入自己的产品。它不是只做一个支付按钮,而是把支付变成互联网创业的基础设施。今天大量互联网企业、SaaS公司和创业团队都依赖类似Stripe这样的支付服务。

如果WhatsApp解决的是“如何更方便地发消息”,那么Stripe解决的是“如何更方便地收钱”。两者的共同点非常清楚:它们都没有创造全新需求,而是把已有需求背后的复杂流程隐藏起来,让用户只感受到简单。

Brian Chesky(Airbnb):让空房间变成住宿网络的人

2008年,Brian Chesky和朋友在旧金山生活,经济压力很大,连房租都快付不起。那时他们发现一个现实问题:城市里有人来参加会议或旅行,却找不到合适住处;与此同时,很多人家里有空房间、沙发或临时可用的空间。问题不是完全没有资源,而是资源和需求没有被有效连接起来。

Airbnb交付的结果不是酒店,而是一个住宿交易平台。房东可以在平台上发布自己的房间、公寓或房子,旅行者可以在线搜索、比较、预订和支付。平台负责信息展示、评价系统、交易流程和信任机制。也就是说,Airbnb并没有自己建一堆酒店,而是把原本分散在世界各地的闲置空间组织起来,让它们变成可被搜索、可被比较、可被预订的住宿供给。

在Airbnb出现之前,旅行住宿主要依赖酒店、旅馆或熟人介绍。住别人家当然不是新鲜事,短租也不是新概念,但Airbnb把这件事平台化、标准化、规模化。用户可以看到房源图片、位置、价格、评价;房东可以通过平台获得客人;双方通过平台完成交易。它真正解决的不是“世界缺房间”,而是“有房间的人和需要房间的人彼此找不到、也不够信任”。

Airbnb后来改变了住宿行业,也引发了监管、社区和城市管理等争议。但从创富模式上看,它和WhatsApp、Dropbox、Stripe属于同一类:发现已有需求里的巨大摩擦,然后用产品和平台把摩擦降低。WhatsApp让人更容易联系,Dropbox让人更容易找到文件,Stripe让商家更容易收钱,Airbnb让旅行者更容易找到非酒店住宿。

他们共同发现了什么

Jan Koum、Drew Houston、Patrick Collison和Brian Chesky所做的产品完全不同。一个做通讯,一个做云存储,一个做支付,一个做住宿平台。表面上看,它们没有太大关系。但如果把产品名字拿掉,你会发现他们都在做同一件事:发现一个高频痛点,然后降低摩擦。

发消息太麻烦,于是有了WhatsApp。管理文件太麻烦,于是有了Dropbox。在线收钱太麻烦,于是有了Stripe。寻找住处太麻烦,于是有了Airbnb。它们都不是凭空创造需求,而是让原本已经存在的需求更容易被满足。

这类财富创造模式有几个共同特征。第一,问题足够高频,用户经常遇到。第二,旧方案不是不存在,而是太麻烦。第三,新产品不一定技术最复杂,但体验一定更简单。第四,一旦用户感受到明显省事,就会自然迁移。第五,当这种省事发生在巨大人群和高频场景中,价值就会被迅速放大。

所以,案例001真正要研究的不是“WhatsApp为什么值钱”,而是“降低摩擦为什么能创造财富”。这是一个可以迁移到许多行业的创富模型。

案例启发

Jan Koum最值得学习的地方,不是后来拥有多少财富,而是他看待问题的方式。很多人每天都在抱怨产品难用、流程复杂、效率太低,但大多数人的抱怨到此结束。

Jan Koum多走了一步:他开始思考,能不能让这件事变简单。很多伟大的机会,并不隐藏在未来,而隐藏在人们每天都在忍受的麻烦里。