SaaS产品分析:我特别害怕那些“自嗨”的产品_saas平台运营

 admin   2018-03-26 20:33   1366 人阅读  0 条评论

你在为谁创造?


在公司扩张时,团队很容易忽视「我们在为谁做产品」这个问题。


在团队固定且缺乏沟通的情况下,用户同理心会被严重稀释,以至于同理心只是在贴在墙上的另外一张海报罢了。但现今的软件公司,客户支持团队是有能力将所有用户和你所解决的问题联系起来的。

SaaS产品分析:我特别害怕那些“自嗨”的产品_SaaS平台运营

只要正确进行配置,他们能确保你的功能路线图上出现适当的功能,为你的研究团队提供正确的客户洞察。在这次Inside Intercom World Tour柏林站,我和其他人讨论了如何在扩张团队时保证用户体验是扩张的核心。


一个异步交流的世界

想象有一个成功实现快速增长的公司,如果你询问该公司的创始人“他们为谁创造”,他们会快速而简洁地给出答案。那是因为一个新产品的起源总是会以前所未有的快速、低成本的方式解决问题。


好的解决方案要求你深切了解你正要解决的问题,但也许更重要的是要了解那些因为问题的解决而受益的人。如果你问同一个公司的工程师们,他们在为谁创造产品?他们会给你相同的答案吗?那如果问这个公司的客户呢?如果你告诉他们创始人的回答,这些客户会认同还是当面报以嘲笑?

一桩成功生意的核心是什么?我认为回答这个问题的最简单的答案是,你创造的这家公司,每一位员工都紧密地为你们所解决的问题联系在一起,更重要的是,为你们服务的客户联系在一起。


让我们回过头去看一下我们一开始为什么问这个问题。在过去,几乎所有的生意都是小型的。它们当中的大多数,实际上是被单个家庭经营。你从小就耳濡目染,学习并理解它的业务、目标、核心价值。你了解你的客户,因为他们就是你的朋友和邻居们。即便工业化让我们坐进了办公室,我们依然采用异步沟通去做生意,或者面对面拜访客户、握手相知,包括电话交流也是另一种方式。



但是互联网改变了所有的事情。突然之间,你可以面向百万级的市场,从产品一端向所有人销售你的产品,接收成千上万的客户支持请求和用户咨询。这一切都在一天里或一周里的不同时间里发生。



这并不是说产品卖出去后,我们就不再关心客户所遇到的问题。而是我们被自己摆了一道:以为自己可以利用互联网售卖产品的方式来取代运行了数千年的面对面销售。我们莫名其妙地忘记了如果没有客户的话,我们最开始根本就不可能做成生意。我们创造的产品之所以存在是因为它解决了特定的问题,它让客户的生活更容易或更开心。但是,在使用互联网销售的时候,你怎么才能表现得像一个真正的销售呢?对我来说,这得从客户体验开始。

客户体验 = 观察,产品+人

我用三个基本元素来定义客户体验:观察,产品和人。


观察:你现有以及潜在的用户如何接触到你的产品和品牌。当你的潜在用户发现你的产品并注册,观察就变成了预期。对你现有的客户来说,你运营产品和做生意的方式将决定他们成为产品的布道者还是诋毁者。


在面对你的产品时,问一下自己以下几个问题:


在使用产品时,它带来的体验怎么样?


它是很简单还是复杂?


它的学习曲线很陡峭还是毫无门槛?


它解决了你最开始想要解决的问题吗?

问其他人以下的问题:


你的客户和你的团队有进行高效率的接触吗?


你能不能举一个私人的简单例子?


你能快速解决问题吗?

你能真正地从客户那里获得获取反馈并有效利用吗?

糟糕的产品支持绝对是差劲的产品体验,嘴炮不会让猪飞起来,我想这点我们都很清楚。明明是个好产品但客户支持做的差,这也难说是好的客户体验。你根本不可能把期待和正在使用产品的人区分开。简单来说,你的客户支持团队决定了人们如何认知你的产品。


Jeff Bezos曾说过:“最好的客户服务是:客户不用打客服电话也不用和你对话,产品本身就能顺利服务客户。”当然,这种描述是你永远无法到达的状态。但我们的工作仍需要尽力消除理想和现实情况之间的鸿沟。理解你永远不可能到达这个境界非常重要:那就是你和你的客户彼此都不需要和对方联络。在实践中你不得不停地去思考,在你慢慢地根据用户反馈改进产品的过程中不断地思考。

你应该从哪儿开始呢?不论你的公司在哪个阶段,打通反馈回路都非常重要:它能确保客户反馈到达开发团队和客户支持团队。

创业公司早期,产品支持和研究的工作几乎可以由一个或几个人完成,通常这个角色是创始人。但当你的产品和业务逐渐增长时,你必须把这个工作分给不同的团队来完成。即便意图是好的,很多时候,增长都可能导致固定团队的沟通匮乏。


如何抵消这种谷仓效应呢——你必须要促使人们突破组织内他们所熟知的的领域。产品永远不能住在象牙塔内,只做让产品开发内部的人兴奋的东西。


(译者注:谷仓效应指企业内部因缺少沟通,部门间各自为政,只有垂直的指挥系统,没有水平的协同机制,就象一个个的谷仓,各自拥有独立的进出系统,但缺少了谷仓与谷仓之间的沟通和互动。这种情况下各部门之间未能建立共识而无法和谐运作)


你的客户支持团队必须培养远见和大局观,并且真正了解产品迭代的节奏是一步一个脚印的,而不是来自于一系列的客户逸闻。你的研究团队必须成为两个团队之间的纽带和粘合剂,为客户支持团队过滤优质的客户数据,并为产品团队提供可执行的见解。

当产品遇上支持


你如何确保产品部门能够持续地为你的用户们带来实际的产品?在Intercom中,我们通过“用户开放日”来实现。这很简单,在这一天中设计师、工程师或者产品经理放下他们平常的工具并投入到前线的客户支持团队。这是一种有启发性的方式,让产品部门以及公司其他所有部门与你的用户们保持联系。


在用户开放日中,所有人最重要的工作是与用户们直接地互动。不管是你结束了一场成功的对话,还是一场与狂暴的用户进行不加掩饰的、糟糕的对话,都会让你分泌不少多巴胺。我确实强烈地感受到“用户开放日”这个项目引领到了一个更加均衡的产品路线图、更好的设计以及更仔细的编程里。

一支高绩效表现的用户支持团队只可能建立在了解产品的基础上。如果对用户支持团队正在试图解决的问题没有基本的了解,且没有一个能够挖掘用户反馈的框架的话,那么这个团队(尤其是在一家快速增长的公司中的团队)会很容易开始为自己的过错辩护。

将JTBD技术应用到用户支持

彼得德鲁克曾经说过一句著名的话:“客户很少因为商家想将商品销售给他而购买”,他进而更加明确地说:“原因是没有人是真正因为产品而购买,他们购买的是满足感”。

在Intercom的用户支持团队,我们使用JTBD(Jobs-to-be-Done)框架去帮助我们发现用户希望通过使用我们的产品真正去实现些什么。事实上,我们尝试去创造出德鲁克所说的给用户的“满足感”。

JTBD框架是一种让你确切地思考你的用户希望通过使用产品而达到什么目的的方法。简而言之,它类似你手机中的待办事项清单或者便利贴。其存在都是帮助你去记住那些你真正需要去做的事情。我们花了很多时间和精力雇佣一些好奇心爆炸的员工,他们在我们的支持团队中具备产品思维。我们随后在产品研发的最初以及与产品相关的每一方面,通过JTBD方法花了双倍代价使员工们都加深了他们的知识

结果是确实强力的。JTBD框架给了团队所有人一个镜头,透过这个镜头他们能够仔细思考正要向用户询问的问题,以及确保他们正在询问的是正确的问题。而且还使他们找到并清晰地表出出达正在使用我们产品的用户们的根本动机。


为用户洞察而行动起来

我们上面说到你已经雇佣了一支超棒的支持团队,并且他们正从所有与用户的对话中生产成千上万的原始数据。但是从这些巨量对话中,你如何能够真正地产生关键的洞察呢?一支质量稳定的分析团队是武装这些原始数据的关键。

在Intercom,支持团队使用标签将所有用户询问的问题进行分类,但是哪些是和产品相关的呢?我们的研究团队通过JTBD框架将这些问题进行了深入地提炼。


当我们掌握到提交问题的数量一周一周地从几百增长到几千,我们变得更加聪明,知道怎么去看或者什么时机去看这些问题。一个简单的范例是在所有问题中寻找发生率波动大的那些问题。如上图,当你看见在某些方面被标记地数量有大的变化,那么这里就是你应该深挖的地方。

上文的另外一个例子是为了非常详细的产品而立即深入挖掘功能需求。大多数人们犯了只了解多少用户为某些功能而咨询的错,而需要继续了解更重要的问题是:


提交问题的用户当中,有多少是正在付费的?



提交问题的用户数占据我们所有用户数的百分比是多少?



那些用户的真实商业价值是什么?如果我们为这些问题深挖到更详细的层面。


当你像上面一样提问,你就会获得更加完整的理解——关于你想将什么功能放到产品路线图中以及至关重要的是,为什么你想将其放入当中。


在线上保持联系


回到我们最早的问题,如何建立一家每位员工对正在解决的问题及那群提出问题的人们都保持紧密的关心的互联网公司?这里有一些方法可供你参考:


建立一支深刻理解产品内涵的支持团队,并且知道如何询问正确的问题,以及如何高效地传递信息


建立一支能够收集所有原始数据并且能够将其提炼成真正关键可执行的洞察使产品部门能够为之所用的研究团队


建立一支可以通过用户体验以及用户角度将关键洞察变成正确的产品路线图的产品团队


挺简单的,对吧?


本文地址:https://ruanzu.com/post/75.html
版权声明:本文为原创文章,版权归 admin 所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?