Path、Google+和子弹短信,社交产品的第二名没有意义

新闻 移动开发
不久前,Google宣布将于明年8月彻底关闭个人版Google+服务。Google+晚于Path半年发布,和Path一样,也是瞄准Facebook的“错误”和“软肋”,提供更可靠、更安全的社交服务,却也像Path一样,在其生命的第八年彻底关闭服务,不免令人唏嘘。

[[247055]]
图片来源:视觉中国

10月18日,Path的所有服务正式关闭,当我在浏览器中输入path.com,显示服务器未响应,这个运营8年的产品至此终于画上句号。

不久前,Google宣布将于明年8月彻底关闭个人版Google+服务。Google+晚于Path半年发布,和Path一样,也是瞄准Facebook的“错误”和“软肋”,提供更可靠、更安全的社交服务,却也像Path一样,在其生命的第八年彻底关闭服务,不免令人唏嘘。

不少人会提到基因问题,Google没有社交基因,所以做不好社交产品。类似地,阿里巴巴没有社交基因,所以做不好来往;腾讯没有电商基因,所以做不好拍拍;百度也没有电商基因,所以做不好有啊。

假设Google+的失败真的是因为Google没有社交基因,那么Path的失败又是因为什么呢?

Path的创办者戴夫·莫林(Dave Morin)可是Facebook的早期高管,也是Facebook平台和Facebook Connect的联合创建者。莫林最初是扎克伯格的开放社交理念的铁杆支持者,后来他认为Facebook过于宽泛的“朋友”概念和互动模式存在bug,并打算用一个新的社交产品修补这个bug,这就是Path。

2011年,我在知乎上参与了多个Path相关话题的讨论。作为一个坚定的看衰Path的人,我认为Path并不是一个基于用户需求的产品,而是一个基于某种观念的自以为是的产品。

 

我在知乎上参与的Path相关话题

我在知乎上参与的Path相关话题

Path创始人辉煌的履历,和超豪华的创业团队,让投资人发疯。Path产品还没拿出,天使投资就已就位;产品发布头两个月,就成功募集了两轮共计1100万美元的风险投资;这期间还收到了Google的1亿美元收购报价。

最初Path的好友数量上限是50人,因为莫林认为,你可以有成百上千的朋友,但知根知底,可以频繁互动的密友不会超过50人。很多时候,你拍的照片不想分享给成百上千人,你只想分享给你的密友。在我看来,从一开始Path的用户需求就是臆想出来的。

大多数时候,你拍了一张照片,可以给任何人看,你可以发到微博上,发到Instagram,也可以发到朋友圈。偶尔,你拍了一张和女友的亲密照,确实不适合公开发布,这时候你和她分享照片的最好方式,是通过AirDrop直接传给她,或者微信给她,最不济也是email给她,你真的会把这张照片分享给50位密友吗?一张不适合公开发布的照片,却可以在一个最多50人的密友圈里分享,而这些密友可能包括父母、儿时玩伴、大学同学、红颜知己、生意伙伴和同事,这样的场景我想破脑袋也想不出来。莫林却认为,这样的需求可以支持Path成为一个Facebook真正的挑战者。面对这么宏大的未来,莫林当然看不上Google的1亿美元。

后来,Path把好友数上限放宽到150人,不管莫林是否承认,在我看来就是一次自我否定。不过莫林仍然坚持Path的最初设计思想和产品定位,这最终导致它在几乎所有的市场上都未能取得像样的份额,最终凭借几乎是仅剩的东南亚市场,卖身给了正在觊觎国际市场的韩国Kakao。

不过Kakao也没能为Path成功续命,2010年至2014年间,作为一个还算活跃的用户,我曾在Path进行过521次发布。我备份了所有数据,但全部的地标和好友间的互动,全都随着Path的关闭而灰飞烟灭。

很多设计师仍然会怀念Path在手机应用交互设计上的创新,仅此而已。

Google+也差不多,这是Google联合创始人拉里·佩奇时隔10年重回CEO位置后,举全公司之力发起的一场前所未有的重大战役,意在撕开Facebook的铁栅栏,将封锁在Facebook中的信息重新纳入Google搜索引擎的索引范围,同时为Google的产品架构添加至关重要的社交层。不过Google打出的旗号却是让社交更私密,不同的好友应该被放进不同的“圈子”。

Google想用互不干扰的一个个“圈子”,重建用户的互联网关系链。但每添加一个朋友,就要为他选择一个圈子,有时候常常踌躇,到底应该加到朋友圈子,还是同事圈子,抑或是酒友圈子,因为很多时候界限实际上是模糊的。

就像大部分人的书架不会像图书馆那样分类放置,井井有条,就算一开始是分类放置的,要不了多久就全乱套了。无序才是我们生活的常态,有序反倒是反人性的。

Google希望我们的好友列表是有序的,有组织的,这一方面是为了跟Facebook不同,另一方面大概也是Google作为信息整合者的惯性思维作祟。Google的工程师思维会认为,世界的本来面目确实是混乱的、无序的,但有序带来价值。

一开始,Google+好像还长着一张注定成功的脸。

从0到2000万用户,Facebook用了1152天,Twitter用了1035天,Google+只用了24天。Google巨大的用户规模和产品矩阵,让它导入用户相对容易,但让用户持续使用,就难了。用俞军的用户价值等式来表示:

  • 用户价值 = (新的体验 - 旧的体验) - 替换成本

Google+带来的新的体验,并不见得比Facebook的旧的体验更好,可是替换成本却极其高昂——我得费多大劲才能把我的Facebook好友一个一个加到Google+上呢?而且就算都加上了,我又怎么能保证他们都像我一样把Google+当作主力社交平台来用呢?原本在一个平台就可以保持联系的那些人,现在必须在两个平台上跟他们保持联系,我不是吃饱了撑的吗?

尽管Google+初期的增长看起来相当喜人,但完全没有影响Facebook的增长。而且在Google增长最好的头两年,在全球任何地区,跟Facebook相比,Google+的存在感都低到土里面。

 


Google Trends显示的Google+和Facebook的趋势对比

Google+的失败,跟Google有没有社交基因毫无关系,而是因为Google+从来都没有提供一个比Facebook更好的产品,同时社交网络的转换成本高到无法承受。失败基本上是注定的,只是Google碍于创始人的颜面,一直不肯承认。这次决定关闭个人版Google+,也是借着隐私安全的由头,把一个本来就不该出现的产品关闭了。

同样地,阿里巴巴把来往做砸,不是因为阿里巴巴没有社交基因,而是因为它用它习惯的大促、拼命刷存在感、高调PR等手段,去推一个必须靠用户主动拉动的东西,并且这个东西必须比微信做得更好、更细致,才稍微有点机会。除了阿里巴巴自己,真有人曾经看好过来往吗?

在社交战场上,后来者往往是急功近利的、没有耐心的,他们渴望一招制敌,渴望后来居上,然而这从来都是妄想。

按说有社交基因的腾讯,不该把微博、微视做死才对,可事实是,微博、微视这种社会化媒体,腾讯从来都没做好过。

我承认路径依赖这回事,但从不相信互联网产品的所谓基因决定论。

腾讯做不成电商,是因为腾讯从来都没有过阿里巴巴那样的重金培育电商市场的想法。在电子商务发展之初,阿里巴巴只花钱不赚钱,淘宝宣布三年不赚钱,三年期满再加三年,之后你才摘得到这个市场的果实。

两个月前,有人在大弓上甩给我一个关于子弹短信的问题:“今天下了一个体验了一下,像WhatsApp的一个聊天应用,感觉用起来干净舒服,相比之下,觉得微信现在略臃肿,承载的东西太多了。请问您会觉得子弹短信是微信的威胁吗,是微信的竞争者吗?”

 

我在大弓上关于子弹短信的问答

我在大弓上关于子弹短信的问答

我是这么回答的:

  • 没有一个产品是因为做了另外一个产品的精简版而成功的。
  • 很多时候,我们会觉得某个产品功能太多,过于臃肿,但恰恰是这些臃肿的功能,才是真正让我们无法割舍的。
  • 另一个产品的简洁,让人喜欢。但也只是喜欢而已,你不会真的长期使用它,更不会依赖它。如果这是一个社交和通信工具,你根本不会动员你的所有好友都来用它,你也知道,就算动员,也是徒劳的。

我没用过子弹短信,也没有兴趣用。现在不是一个可以再做一个即时通信工具的时候了。

综合社交产品,做第二名是没有意义的。因为第一名几乎满足了所有用户的所有需求,第二名没漏可捡。

罗永浩说:“子弹短信在特定的需求领域里转化几千万甚至1个亿用户是没问题的,在通讯工具里拿到10%-20%的份额,可以做成几十亿甚至上百亿估值的公司。”他未免太乐观了,Google+曾经比他更乐观,也曾经比他看上去机会更好,结果是拖了8年才承认失败。

罗永浩效应能让子弹短信支撑8年吗?

责任编辑:未丽燕 来源: keso怎么看
相关推荐

2021-02-19 09:45:50

Python面向对象代码

2021-03-04 13:25:22

Python面向对象代码

2021-04-06 11:21:50

Python面向对象代码

2016-02-17 09:06:42

代码注释代码规范

2013-05-20 10:09:19

过时应用迁移云计算

2018-09-26 17:28:15

KubernetesServerless云计算

2022-07-13 17:56:09

Bug率产品经理系数

2016-02-17 10:01:36

编程代码注释

2022-05-06 16:11:17

iOS安卓电池

2020-10-11 20:50:59

编程语言JavaPython

2022-01-07 10:36:41

宁畅

2021-12-23 14:12:16

阿里云神龙架构大数据

2018-02-07 11:03:20

阿里巴巴区块链企业

2023-01-30 07:55:44

代码过度设计

2019-01-24 10:23:58

Web前端密码加密

2015-06-09 17:19:17

2011-09-09 10:31:40

Xen虚拟化linux内核

2016-04-29 18:31:15

明厨亮灶公约/360

2022-02-28 22:52:56

混合云工具技术

2015-04-23 16:21:23

点赞
收藏

51CTO技术栈公众号