史上发展最快的SaaS 公司如何打造令人尖叫的产品

云计算 SaaS
本文中,堪称史上发展最快的 SaaS 公司 Slack 的首位产品经理分享了 Slack 获取和利用有价值的用户反馈信息、从而打造一款令用户尖叫的产品的经验。

原文编者按:本文来自First Round Review,他们的文章既讲故事,还会向创业者提供具有很强操作性的建议,以助力打造优秀的公司。如何通过获取和利用有价值的用户反馈数据信息来改善产品?大部分创业者都会为此头疼。本文中,堪称史上发展最快的 SaaS 公司 Slack 的首位产品经理分享了 Slack 获取和利用有价值的用户反馈信息、从而打造一款令用户尖叫的产品的经验。

[[154934]]

Kenneth Berger 2014年6月 加入 Slack,那时 Slack 正处于爆发式增长期,媒体报道也是铺天盖地。作为 Slack 的***位产品经理,加入 Slack 后的 1年 里,他全面负责 Slack 的产品功能。在这期间,Slack日活用户从 10 万猛增至 100 万 +,用户好评如潮。

当时 Slack 的用户增长数据一直很抢眼,用户反馈也很好,不管从什么角度看,Berger 的工作似乎并没有太大难度。然而随着用户反馈数据的激增,Berger 需要快速从海量反馈数据中找到那些真正有价值的反馈数据并加以利用。他知道,满足于现有的业绩,光靠吃老本肯定是不行的。要实现 Slack 更快地发展,Berger 必须要走出去,搜集哪些他没有的有价值的反馈信息。

近日,Berger 接受了 First Round Review 的专访,他分享了 Slack 是如何对用户反馈信息进行优先级划分的以及从中学到的东西。他分享了自己为何在 “指标” 和 “目标” 这两者中会更看重 “目标”,为何他认为公司创始人需要像科学家一样去思考和工作。最重要的是,他分享了如何从海量定性数据和定量数据中进行有效筛选并找到那些最有价值的数据的秘诀,这些数据包括网站统计数据、社交媒体上的反馈数据、留存率和客户支持数据等。

要追求目标,不要单纯地追求数据

对于大多创业公司来说,问题不是缺少用户反馈数据,而是他们不知道如何利用这些反馈信息。大多数情况下,人们对自己面前的已有信息或是容易获取的信息更为敏感,也就是说,人们更加看重这类信息渠道,而对其他的信息渠道漠不关心,这就会导致在很多时候无法获得真正有价值的反馈信息。根据 Berger 的经验,要想避免这种情况的发生,***的办法就是将注意力和精力集中关注于公司最重要的目标上。“很多人只关注指标数据,并认为这是验证成功与否的标志。数据指标当然非常重要,但对我而言,它只是目标的一部分,让目标得以量化。”

Berger 对创业公司非常了解,他最开始联合创办了自己的公司 YesGraph,后来加入 Slack,他深知创业公司的发展环境和用户心理是瞬息万变的。如果你不一直不断重新评估什么才是公司最重要的目标的话,你可能就无法知道什么数据指标对目前的公司来说才是最紧要、最值得关注的。

如果你同时还在忙于扩充团队,事情就会变得更加复杂,因为不仅公司的目标在变化,你的责任也在变化。公司可能会成立新的部门,很多事都会朝着不同的方向发展,公司的重点也会随着时间的推移而发生变化。

在确定公司的目标时,要坚持下面这个简单的原则:每个人都需要知道他们为什么做他们正在做的事情。在确定公司的整体目标后,确保每个部门或部门负责人都知道这一目标,并在这一目标的基础上确定各自部门相应的数据指标。

只有当各个部门的人员都参与到数据指标的制定中时,数据指标才能发挥***的作用。

“如果人们身上背负的任务指标是由其他人定的,这时数据指标很难发挥它应有的作用。只有当各个团队和团队里的每个人都能参与到数据指标的制定时,这是大家的工作积极性和才能才能被充分调动起来。”

对于绝大部分公司而言,有两个指标都是至关重要的:用户留存指标和营收指标。但这两个指标究竟定为多少才最为合适?除了要关注这两项指标外,我们还需要关注哪些指标?这些问题的答案因公司而异。公司的商业模式,公司的产品是企业级产品还是直接面向消费者的产品,以及你所在的团队,这些都会影响上述问题的答案。我个人是非常反对 ‘指标至上’ 的观点的。例如,如果你只关心收入增长指标的话,你怎么能知道客服团队在里面发挥了多大作用?客服团队通常是非常重要的,如果不给他们定一个和他们的工作直接相关的指标的话,就无法充分调动他们的积极性,也就无法将他们的价值发挥到***化。

要定期审视和评估你的目标,不管是一个月一次还是一个季度一次,只要符合公司的实际情况就行。你是否足够关注新用户的获取?是否在为老用户创造价值?公司目前的重点是什么?只有时刻想着这些问题,你才能知道如何处理利用用户反馈信息,才能知道哪些反馈信息是目前最有价值的信息。

对于目前公司内部工作的优先级和重点,要及时分享给大家,让大家都知道。大多情况下,在同时面对几个产品功能需求时,你不得不先选择一个功能优先开发而不得不暂时放弃另外几个功能。或者在面对多个部门提出的不同需求时,你只能先满足其中一个部门的需求。不同渠道的反馈信息是什么以及是如何按优先级将它们进行划分的,这些信息一定要公开透明,让大家知道为什么有的反馈需求可以优先得到满足,这有助于让大家感受到自己的反馈是被认真对待并认可的。

在创业公司,由于资源有限,你不可能一次性满足所有需求。因此,要在公司内部努力营造一种透明、畅通的交流氛围,让大家真正知道为什么有些需求可以优先得到满足。

明智的假设有助于产生明智的见解

实际上,制定和评估公司目标的过程和科学家的工作非常类似,都要不停地提出和验证假设。当科学家要做一项实验时,首先需要提出一个假设,然后思考确定验证假设的方法。运营公司也一样,你需要设定目标,然后围绕这个目标设定指标。

但是你往往是无法通过一个简单的实验就能看清事情的大局和重点,可能是由于提出的假设不对,也可能是因为你选择的用于衡量目标的指标有问题。要科学对待处理你获得的反馈数据,首先要做到的一点就是能看清大局并以此为重,同时能根据实际情况对你的假设理论进行恰当地调整。

在 Slack 早期,为了获得更多的用户注册,Berger 曾尝试了一些当时比较流行的市场推广方法。“我知道,大家通常用的推广方法中的很多我们还没有尝试过,所以我们决定尝试一些方法,看效果如何。我们首先尝试的是邮件营销,给给那些已经注册 Slack 但还不活跃的用户发邮件。接着我们尝试了免费试用的方法。”

我们在部分用户中尝试了上面的方法,也看到了一些效果,但非常有限。我们所做的这些尝试都是要付出一定的代价的,这实际上是一种权衡和交易。从我们尝试的结果来看,这种交易并不划算。用户留存率是提高了,这看似取得了不错的效果,但从全局来看,却并非如此。在认真分析数据后,我们发现,增加的留存率和我们所付出的种种努力其实并不成正比。

验证假设还直接影响了 Slack 的策略转变。最初,公司决定不对外宣称自己是一款聊天类 App,而向外界传达自己长远的理念和愿景:变革现有的工作方式,创建更加透明的工作氛围和畅通的交流环境。

不过当做了产品的可用性测试后,他们发现了问题。刚开始的时候,借助于出色的媒体 PR,Slack 获得了一大批用户。这些用户刚读过有关 Slack 产品的新闻报道,因此对产品有一定的了解,所以即使 Slack 官网上没有具体的产品功能介绍而只有抽象的描述,这也不妨碍他们了解和使用 Slack。然而从其他渠道来的用户就比较困惑了,因为当时 Slack 官网上没有产品功能介绍,没有产品截图,也没有强调即时通讯是 Slack 的主要功能。所以这些用户不知道 Slack 的核心功能是什么,是文件分享?内部沟通?还是效率工具?不去教育和引导用户,用户不困惑才怪。

自从那时开始,为了更好地教育和引导潜在用户,Slack 在官网上专门放了产品功能截图。即便到后来没有再放产品截图了,但还是一直把 Slack 的即时通讯核心功能作为向用户传递的关键内容信息。

Slack 就通过这种方法来解决之前存在的问题。强调 Slack 作为即时通讯工具的功能性,方便用户了解这款产品,并以此为桥梁来向公众阐述你那更加宏伟的愿景。这并不是说 ‘变革人们的工作方式’ 这种理念和愿景是错误的或是不重要的,它非常重要。不过我们需要学着以一种人们容易理解的方式去讲述我们的愿景。

Slack 做的另一个实验是如何向用户证明自己的实用性。为了验证这一假设,团队使用了非常独特的实验方法——邀请潜在用户在一整天的工作中只使用 Slack 作为公司内部即时通讯和沟通的工具,不接发一封邮件。让人们放弃常用的工具而只使用 Slack,这实在是一种冒险的举动。但事实证明,这个实验是非常成功的。让人在 24 小时的工作中不使用邮件而仅使用 Slack 的情况下也能高效完成内部沟通交流,Slack 无疑证明了自己是一款多么高效的工具。

#p#

了解你可能存在的偏见并努力加以遏制

偏见是无法避免的,不管我们思想多么开放,我们都或多多少存在一定的偏见。这些偏见将影响我们如何解读用户反馈的数据。我们在意识到这一点的同时,还要知道如何遏制一些常见的偏见。

  • 选择偏见

在搜集和评估产品反馈数据时,Berger 遭遇最多的就是这种偏见。例如,产品的支持请求通常只来自那些最活跃的用户,了解这一点很重要。如果你只和这些用户沟通交流,那么你就将所有的非活跃潜在用户都排除在外了,更不可能从他们那里获得有价值的数据。

你可能会进行产品的可用性测试。进行可用性测试时,很多人的做法是从 Craigslist 上招募测试志愿者,这看似是很合理的做法。不过你需要时刻记住的是,通过 Craigslist 找到的测试志愿者并不能代表绝大部分的潜在用户。你要了解这种方法可能存在的局限,因为你找到的测试者都是一些经常参与测试的专业测试者,和大部分用户还是不一样的。因此你要意识到,你在测试中获得的数据的一部分可能是无用数据,要学会排除这些数据,然后继续。

  • 确认偏见 or 观察者偏见

大家倾向于在数据中只看那些自己想看到的数据,或是想看自己之前预测的结论,这很自然。这其实也是一种偏见,我们需要努力抑制这种偏见的发生。不妨想象一下,同样一组数据,可能支持一种假设,也可能同样能支持另外一种假设。它可能符合你所想的,也可能完全不符。总之,不要只去看那些自己想看的数据,在这方面一定要极力克制。

实际上,在 Berger 看来,处理上面这类数据偏见的过程是在一家创业公司工作非常激动人心的一部分。那些曾在大公司工作的人会习惯利用数据做一些细微方面的修正和调整——例如在 A/B 测试中,主页上的哪个词起到了一点作用。如果你是在一家成立不久的创业公司,你跟数据打交道的过程就会更加曲折,利用数据做的事情也会重要很多。要尽可能快地积极参与到这个过程中。它可以帮你学到很多关于产品和用户的新东西。

  • 报告偏见

观察者偏见主要指在一堆数据中只看你想看到的部分,而报告偏见主要指只关注那类最让你觉得舒服的数据。这意味着对于那些比较难获取、分析起来较为复杂以及难以量化的数据,就不会给与太多的关注和重视。在就不同的产品决策做出取舍时,这种偏见表现得尤为明显。你可能有一组很容易定量分析的数据,所以你会优先分析这组数据,这组数据可能可以说明一个产品决策的正确性。但同时可能会有很多定性的分析来证明这个产品决策的错误。例如,你们产品的用户增长数据可能非常不错,但用户满意度如何呢?

你经常要去面对和衡量来自不同渠道的用户反馈数据,并需要从不同的角度来评估产品决策,这些工作量虽然繁重但都是值得的。对于任何在产品决策中所面对的赞同意见和潜在的反对观点,都要保持清晰的头脑。数据的来源渠道是多种多样的,认识到这一点可以帮你获得更为清晰的视野。这已经帮助我们在 Slack 做出了很多明智的决策,例如之前提到的邮件营销,在我们从全局的角度来分析邮件营销所取得的效果时,我们才知道做邮件营销是不划算的。

融合定量数据和定性数据,让他们共同发挥作用

在你确定假设并对其进行验证时,你就需要从那些你认为比较有价值、有启发性的数据入手。你确定了哪些用于验证假设的问题?有哪些搜集反馈信息的渠道?又如何正确地开展这项工具?定量反馈和定量反馈的区别在哪里,Berger 总结出来的经验是:定量数据可以帮你了解某件事情的对或错,而定量数据则可以告诉你它为什么是对的或错的。

当你在对你手中的反馈数据资源进行优先级划分时,你是否还需要去获得其它的数据。换句话说,在一个任何数据都可以获取的世界里,是否有必要去获得所有的数据,有备无患?

其实在通常情况下,获取数据并非完全免费的,是需要获取一定的成本的,有时是显性成本,有时是机会成本。有时数据即使可以 “免费” 获得,但我们仍要考虑是否值得我们花心思去获得这些数据,因为里面通常会含有隐形成本。

现在获取信息是非常容易的,正如你可以很容易浏览用户在产品官方 Twitter 上的反馈。你在工作中总会去搜集一些相关反馈信息,有时是定量数据,有时是定性数据。不过如果你有清晰的目标,并知道如何通过假设验证来实现你的目标,你就不会因为有一个用户不喜欢某项功能就匆忙地去改动你的产品。你需要知道哪些数据适合用作测试使用。

你需要详细地了解并清楚你的数据来源,这比其它所有事情都要重要,但这并不是说你不需要关注其它事情。如果你认为新上线的产品功能非常重要,但用户的普遍反馈却一般,这时你就需要倾听用户的声音了。不过你不能对所有反馈数据都一视同仁的对待。

搜集你手里没有的数据

通常情况下,如果定量数据反馈暴露了产品中存在一个问题,你可以一眼就在分析仪表盘上发现。定性数据反馈就不同了,它分析起来更加复杂和棘手。还记得上面说到的 “选择偏见” 吗?和网站流量数据和留存率数据不同,当你浏览产品支持反馈或是社交媒体上的反馈信息时,你通常只会本能地看一些局部信息,无法看清全貌。要想获得可直接使用的实用的定性数据,你需要主动走出去积极搜集相关数据。

Berger 加入 Slack 时,他面临的是一个貌似令人艳羡的问题:产品反馈都非常正面。“开始的时候,我就对自己说:‘如果在 Slack 官方 Twitter 账号下留言的人都说 Slack 是一款很棒的产品,那么我加入 Slack 是干什么来了?我怎么才能为 Slack 创造价值?'。

所以 Berger 开始努力走出去接触那些还没有对 Slack 发表过评论亦或是还没用过 Slack 的人群。他知道 Slack 的下一步战略是为规模更大的团队提供服务。所以 Berger 开始拜访他能找到的规模***的那些团队。这次团队拜访工作是非常有价值的,因为这些大团队使用 Slack 的体验和那些经常在 Twitter 上给 Slack 留言的活跃用户(这些团队的规模通常和 Slack 自己差不多)的体验是非常不一样的。

Berger 在用户拜访中发现,Slack 确实给这些规模较大的团队创造了很多价值,但 Slack 的有些地方却并未能很好地满足他们的需求,给他们造成了很大的困扰。而他们所遇到的问题其实是可以很快解决的,只是 Slack 之前一直没发现而已。“只通过一种渠道了解用户反馈当然很简单,而且这些反馈大都是正面的—似乎每个人都喜欢 Slack!但这么做从长远来看是存在问题的。”

搜集这种定性数据似乎和在分析监控面板上舒服地了解定量数据的方法是彻底背离的,其实并非如此。搜集和研究定性数据时,你同样需要首先作出假设,然后确定指标和验证流程。

“我的假设是我们的产品并没能很好地服务好规模较大的团队。所以我决定从离公司较近的旧金山湾区的一些使用 Slack 的大公司入手,在拜访这些公司的过程中,我问了他们很多问题,主要围绕他们的团队是如何使用 Slack 的。”我问的这些问题非常直接:你是如何使用 Slack 的?公司内部哪些人在用?他们主要用 Slack 干什么?他们还在用其他什么工具,Slack 是否能和这些工具实现互补?

举个例子,Slack 最初内置有一定比例数量的默认通知和通知偏好的切换功能。所以当你在团队中工作的时候,你每天会收到一定量的有关其他同事工作动态的邮件或桌面通知。这个对小团队非常有用,因为这些通知可以帮助他们实时了解其他同事的工作进展。但同样的消息通知机制对于大团队来说就是一个灾难。

Berger 听到很多大团队在抱怨这个问题,*** Slack 专门为大团队提供了一套不同的默认通知功能。新功能按比例减少了每天收到的桌面通知数量,同时为他们提供了了解团队全部动态信息的功能选项。这个功能对于大公司太实用了。

定量反馈数据分析起来很方便,但类如 “我每天收到的通知太多了” 这样的定性反馈你如何分析并和团队分享呢?

很多人不知道如何使用定性数据。例如你出去拜访 5 个用户,你可能会想:‘只拜访 5 个用户,我怎么知道该注意哪些东西,或者这访问到底有没有意义?’ 。这个时候就会发现前期准备工作的重要性了,因为你并不是访问随机选出的 5 个用户,你要清楚你的假设是什么,并知道应该访问哪些用户去验证你的假设。如果你拜访大团队,你只能做出和大团队相关的结论;如果你只和高度活跃的用户交流,那么你只能获取和活跃用户相关的有用数据。

有时候,你收到的有些用户反馈并不需要去测试验证,因为你一看就知道怎么回事。有时你会碰到一个用户以一种非常不正常的方式使用你的产品,极少有人这么用,所以即使他在使用的过程中遇到问题,你也可以不用管,因为一般用户是不会这么用的。还有些时候,有用户在使用 Slack 时遇到了了严重的问题,这时你不需要了解其他用户的使用情况就能知道,每个人在使用 Slack 时都会遇到这个问题。

走出办公室去拜访用户虽然很辛苦也很难,但它真的是非常值得的,因为你可以从中了解你的产品需要有哪些值得改进的地方,让你知道产品下一步的开发重点是什么。

Berger 建议早期的创业公司不要过多地担心自己是否知道如何利用用户反馈数据。“要小心谨慎地选择你的假设,然后选择适合的用户群去拜访,获得有价值的反馈数据来验证自己的假设,你自然而然就能知道接下来该做什么。”

原文链接:http://36kr.com/p/5039243.html

 

责任编辑:Ophira 来源: 36Kr
相关推荐

2013-04-15 10:20:24

SaaSOptimizely云服务

2014-01-24 09:31:18

微软Office 365云计算

2022-04-27 15:18:30

Go 语言API排序算法

2009-10-12 15:03:18

SaaS软件即服务

2010-04-07 11:14:58

2016-01-11 09:23:00

Saas云计算

2016-08-04 14:08:57

前端javascripthtml

2016-11-07 21:15:12

前后端分离expressJavascript

2016-11-07 21:24:08

HtmlNode.jsJavascript

2016-08-11 17:09:14

Javascripthtml前端

2020-12-02 08:16:47

SaaS

2015-12-02 09:48:15

AdMaster金数据大数据

2015-12-29 10:28:52

硅谷SaaSSaaS产业

2022-03-09 20:30:53

SaaS核心指标

2013-01-14 09:19:12

SaaS甲骨文SAP

2016-01-05 10:14:33

2010-10-21 22:21:42

应用交付负载均衡A10 Network

2013-01-23 10:20:48

2024-06-26 12:13:05

2016-04-21 09:53:42

六度人和SCRMEC
点赞
收藏

51CTO技术栈公众号