SaaS 产品从 0 到 1 的艰辛历程:Atlassian 产品负责人独家揭密(上篇)

财富   2024-07-28 17:17   广东  
这篇文章是从 Tanguy Crusson 近期的一期播客节目中整理而成。Crusson 是 Atlassian 公司 Jira Product Discovery 的产品负责人。


在公司的 10 多年时间里,他先后参与了多个新产品的构建,其中包括 HipChat、Status Page 和 Jira Product Discovery。

在节目中,Crusson 深入探讨在大公司内部创新和构建新产品的艰难历程,并坦诚地分享了成功的经验和失败的教训

播客内容干货很多,在做了大量精简之后,还是拆分成了上下两篇来讲。上篇主要讲的是 HipChat 产品失败的教训,下篇围绕 Jira Product Discovery 的成功经验来展开。

上篇目录如下:
  • 00 前情提要
  • 01 过去的成功并非未来胜利的通行证
  • 02 先解决客户需求,再考虑平台化
  • 03 竞争性短视会让你忘记最重要的事
  • 04 什么时候应该进行产品重构(Rebuild)

全文 3400 字,读完预计需要 9 分钟,希望能为你带来一些的启示和行动参考。


00

前情提要


Atlassian 成立于2002年,总部位于悉尼,提供协作和软件开发工具,以Jira、Confluence、Bitbucket 等产品著称,服务于全球 30 万多家企业客户。

HipChat 是一个比 Slack 更早推出的团队协作沟通产品,早期聚焦于游戏沟通的利基市场,实现了快速增长,在 2012 年被 Atlassian 收购。

但在大而全(HipChat Go Big)产品战略下,HipChat 失去了产品的核心竞争力,为了支撑更多用户的需求而过早重构产品,错过了产品增长的最佳窗口。最终在与 Slack的竞争中败下阵来,并于 2019 年停止服务。


值得一提的是,当年的 Slack 风光无二,在微软发布 Teams 之后,Slack还在《纽约时报》买下整版广告,来“欢迎微软加入竞争”。


但却在 3 年后就败给了 Teams,最后被 Salesforce 收购。


这很讽刺,因为从理论上讲,Atlassian 也具有微软同样的产品捆绑优势,为什么 HipChat 败了呢?


01

过去的成功并非未来胜利的通行证


有时我们在做一些事情的时候,会倾向于相信一些东西,因为它曾经对我们起过作用,我们会假设它将永远对我们起作用

创始人一直在告诉我们,把我们带到这里的东西不会把我们带到那里。这句话我们听了一遍又一遍。但是,当团队看到某件事情取得成功时,他们很容易认为这是因为 X,但 X 并没有得到验证。

这就回到了我们今天讨论的话题,为什么在一家成功的大公司里,从 0 到 1 做产品如此艰难?

Atlassian 的打法是成功的,大量的开发、技术和 IT 人员选择了 Atlassian 旗下的产品,成为产品的忠实用户,并增购更多的产品。

当我们决定将 HipChat 纳入麾下,我们怀揣着一个宏伟的愿景:首先在我们的技术团队中深度整合 HipChat,然后逐步将其影响力扩展至整个业务团队

但事情并没有按照我们设想的剧本上演,为什么 Atlassion 坐拥有 30 万家客户,却在企业 IM 赛道上败给了初创公司 Slack

我记得我和很多客户聊过,他们都说:"我们的 IT 部门用的是 HipChat,但业务部门更喜欢 Slack"。然后,我们开始看到这些企业选择 Slack。

Atlassian 在向组织内部的购买者(即 IT 团队)进行销售时非常成功,因为他们拥有所需的一切。但在 Slack 案例中,业务团队最终对他们选择什么样的工具影响最大

实际上,我更倾向于认为两者都在追求用户。Atlassian 追求的是技术团队的用户,Slack 追求的是业务团队的用户。在这两种情况下,发生的都是自下而上的采用。

业务人员更喜欢 Slack,而开发人员则更喜欢 HipChat。我们在我工作的流程中做了很多工作。我们整合了所有开发人员的工具,确保他们使用的每个工具都能进入 HipChat,并从 HipChat 返回到这些工具。

基本上,开发人员可以通过查看 HipChat 中的活动流来完成大量工作。业务团队却对 HipChat 没那么兴奋。表情符号和其他很多东西,在我们看来微不足道,迟迟没有进入产品排期。

我们与业务团队的交流远远不够,以至于我们逐步失去了他们的支持

这里的教训就是,不要低估说服新客户群购买你的产品所面临的挑战。你可能认为他们很接近或相似,但他们很可能不是。

过去的成功并非未来胜利的通行证

因此,回头解释一下你今天成功的原因,然后如果你认为可以在下一件事上使用同样的方法,就想办法去验证它,想办法去测试它,而不要只是去建立在这些假设之上。



02

先解决客户需求,再考虑平台化


Atlassian 是一家大公司,我们可以为感兴趣的事情投入大量资源。

因此,我们重建 HipChat 的概念,与重建相结合的是,我们在一个新的平台上完成这项工作,这个平台是基于微服务构建的,我们构建的一切都可以在所有其他产品中重复使用

例如,你看到的聊天文本框是一个可以全屏打开的编辑器,它是一个 Confluence 编辑器,你可以在这里做任何事情。它是作为平台组件构建的,当你开始构建产品时,平台就已经存在了,这就非常了不起。

但是,你会发现,作为一家大公司,让我们变得超级强大的东西,也会拖慢我们的脚步,让我们专注于错误的假设

有趣的是,我们坚信我们在这个市场上有很大的机会。同时,我们认为我们可以解决重构问题,可以解决平台化问题。所有这些事情都是必要的,但同时做所有这些事情可能让我们步履蹒跚

如果让我再次参与 HipChat 的工作,并由我来领导这件事,我会这样做:好吧,我们的目标是赢得比赛。如果平台已经存在,我们就使用它。如果不存在,就单独构建它,测试它,与客户一起迭代它。

先解决客户的需求,以后再考虑把它平台化



03

竞争性短视会让你忘记最重要的事


在某些时候,Slack 确实越来越受欢迎,并占据了更多的关注度。

我们对 Slack 所做的一切做出了快速反应,我认为这真的非常糟糕,因为我们失去了 HipChat 迄今为止成功的根本原因,那就是为一些游戏用户提供了更好的服务。

如果你把 Slack 所做的事情想象成一座冰山,最上面的那一面浮出水面的是他们所提供的功能,但这是基于他们在研究和了解客户群以及其他方面之后所形成的想法、认知、策略和行动。

所以,基于他们现在交付的产品,你看到的只是他们一年前的想法

而市场上有成千上万家客户,并非每个客户都有相同的需求。我们完全可以为特定的细分市场服务。

与关注竞争对手在做什么相比,我们更应该向客户学习,然后扩展到其他市场

我们是为客户构建产品,而不是竞争对手。让我们花一点时间提醒自己,我们的客户一直在要求我们做什么,让我们来看几个用户访谈。

即使竞争对手所做的某些事情是正确的,但请记住,我们要做的是长远的事情,我们不需要在任何时候都保持领先,也不需要一直站在聚光灯下

我们要确保解决客户的问题,提供产品价值,这才是我们应该执着于做的事情



04

什么时候应该进行产品重构(Rebuild)


像 Atlassian 这样的大公司,银行里趴着大量的现金,因此在实现产品战略的路径上,可以有非常多的选项。

对于一个有潜力赛道,公司可以考虑是否应该自建、是否应该收购、是否应该合作?收购对加速发展非常有帮助。Trello 就是一个很好的例子。

于是我们决定收购 Status Page,并让 Status Page 保持独立运行,并没有将其整合到 Atlassian 平台中。

也就是说,Status Page 无法与 Atlassian 平台上的产品进行联动,不同的交互设计,相互割裂的账号体系

这看起来就像是产品的拼凑,而这并不是客户想要的

如果再让我负责这类产品的收购事宜,我会换一个策略:把它作为技术入股,关闭该产品,在 Atlassian 平台上重建它,来加速路线图

同样是重构,为什么先前的 HipChat 重构却失败了呢?

这其中有一个很重要的区别:收购的产品与现有的产品是否有相同的客群

HipChat 早期积累的核心客群与 Atlassian 存量客户并不重合,重构并没有带来 1+1 >2 的效果,反而打乱了 HipChat 的产品节奏,丢掉了市场。

而 Status Page 与 Atlassian 一样,面向的都是研发团队,且当时还不够大,客户也不多,这样你就可以关闭这个产品,然后在 Atlassian 平台上重建它,并推广给存量的客户群。

因此,这与在飞行途中重建飞机不同,重建 Status Page 只是推迟起飞。

这就像,"是的,我们做了一次试飞,飞机着陆了。好的,没问题。换另一架飞机,再次起飞”。



以上是 HipChat 失败的教训以及在整合 StatusPage 走过的弯路,下篇更精彩,千万不要错过。

点击「阅读原文」,获取播客地址。

凡哥杂谈
三年后台研发路,一朝沦为产品汪。焊过板子,编过内核,写过前端,AGI 实干派。
 最新文章