从财富 500 强产品团队完成的 2000 个试验中学到的

578 阅读12分钟
原文链接: www.appadhoc.com

“精益改进”已经席卷整个企业世界,但是对于产品团队来说,在适应试验驱动的潮流以及基于客户数据来决策的过程中仍然有着无数的障碍。为了帮助大家更好的适应这个过程,我们和财富500强的产品团队合作,跟踪他们从提出假设到客户洞察的整个试验过程,总结2000个试验之后,我们学习到了很多关于企业文化、用户研究的本质及产品管理的流程。

 

时至今日,我们的研究客户包括来自AT&T, Capital One、PwC、Aetna 等等大公司的前沿思考的产品团队。在这200个试验中,总共产生660个原型方案,总共有将近400000的用户给予我们的反馈,包括:46000分钟的视频采访,6500张图表,数以百计的毋庸置疑明智以及有用的产品决策。

试验

我们整理这些试验数据以及和客户的访谈,用来验证在这个过程中所学到的东西。以下是七个最有意义和可操作的见解:

改变是困难的。

老话说得好,真实就是刻苦。作为一家创业公司,我们必须时刻保持对世界的近距离观察——与客户交谈可能会是我们工作重要的有机组成部分。但是,如我们所知的,在一个大型的组织中很少发生这样的情况。

 

尽管一直以来都相信快速原型和试验的价值,财富500强的产品经理通常在多个项目竞争优先级的情况下工作。用户研究的成本很高,并且是有内部团队或者外部机构以每月或者每季度的节奏来执行。按周甚至按天来完成用户研究对于他们来说是闻所未闻的。

 

虽然“按需的用户洞察”听起来很吸引人,但在实践中它挑战了许多公司的惯例。其中最根深蒂固的是对“额外计划”的偏见。当研究周期需要几个月时,确保每个方面都是精心制作以及审查都是至关重要的。但是一旦当你将这个过程加速到几个小时或几天时,迭代就不要进行彻底全面的规划。

 

我们的数据说明这种心态和行为的变化是多么的困难。在满负荷运行时,每个产品团队在平台上运行的试验大约是8-12个。即便在内部工作组和外部帮助,客户仍然还需要三到六个月的时间来达到广度。当然,有部分时间花在了解如何快速讲数据转化为决策。与从认识到计划的研究与基于迭代的研究相比,大部分时间被作为产品团队从瀑布开发转敏捷开发的文化式消耗中。花两个星期来概述用户研究还是不可避免地存在缺陷,这和在相同时间框架内进行六次迭代是不匹配的。

 

Yammer 用户体验总监 Cindy Alvarez 反复强调在大型组织中“精益”和“客户开发”的实际操作。她号召大家停止空洞的规划相反直接去和客户进行沟通,因为这样是最有效的。

 

毫无疑问她是对的,这也是我们所大力号召投入的。我们在新客户中进行研究,包括客户洞察的基准竞争性和其各自产品的可用性。到目前为止,这是产品团队开始迭代的有用的灵感。

 

有时,正式还是优于非正式的。

从之前的洞察的主题了解到,即使大公司达到全速,也无法像初创公司联系试验的节奏。最初设计的产品,使任何利益相关的人员都可以轻松提交一个临时试验,这是我们期望的状态。不是即兴运行试验,通常情况下他们会每周提交试验计划。

 

事实证明这有一个很好的理由。虽然流程工作在创业公司中是有意义的,但它通常在大型组织内不奏效,这也许是因为其内部的项目组织架构不同并经常有内部竞争所造成的。产品经理在解读客户反馈和决定后续步骤时,会积极咨询这些利益相关团队。往往这就需要一个可预测及周期行的节奏来确保大家在同一状态。

 

这就是为什么类似“冲刺型设计”的概念已经脱颖而出的原因,他们为利益相关的团队准备时间来协调。我们正在接受形式在这里发挥的作用,并鼓励组织内部定期全部召开“试验会议”,直到可测试的假设试验完成。

 

产品试验可以分为不同的类别。

在我们搭建平台和工作流程以加快用户研究流程前,我们必须首先更好地了解产品团队中用户研究所需要的产品类型。这就是为什么,在开发之前我们使用第三方工具手动进行500个左右的试验。

 

我们发现涉及原型的用户研究试验(不是在生产环境中进行试验)基本可以分为六个类型。其中可用性测试是被广泛接受的。虽然我们对于这些试验的定义不是万能的,但是他们还是比较惊讶每个类型的“经验法则“及可配置的试验模板。您可以在原型指南阅读,以下是其概述:

所有运行的试验的频次分类如下:

我们还有大量的研究要进行,但这部分关于试验的定义可以帮助用户研究人员几乎可以接受任何客户的请求,并在几分钟内将其变成可执行的研究。

 

所有的研究都是带有偏见的

我们的平台主要包括所谓的“模拟环境”的试验。提供反馈的用户知道他们是研究的一部分并为此花费他们的时间。他们使用这些高度完成的原型产品,并且知道这些产品并没有上市。

 

我们专注与这种类型的试验,因为产品团队可以从中获得大量的数据,同时也符合组织现有流程以及风险承受能力。无需内部设计、开发资源,无价值的客户成为半成品的小白鼠,且不用咨询法律合规性。当然,这部分数据也许并不像已发布的产品所得到数据那么准确。

所有的研究,包括我们的都存在一定成都的偏见。但这不是一个避免进行完全用户研究的借口。热情地多更多的试验研究,并试图最小化其偏见,否则也许会错过森林中的某棵树木。

 

科学方法的核心原理之一就是可复制性的概念——任何单个试验的结果可以通过另一个试验在线。我们经常看到产品团队使用单个“统计显著性”来确认可疑的直觉或小项目。但是有一些因素可以,并且几乎总是偏见测试的结果且没有任何故意的错误。错误地问比较前沿的问题或车在目标客户中不足的采样都可能会造成个别测试结果的偏离。

 

为了从个别试验和客户的数据点获得价值,产品团队需要通过迭代来实践验证数据。即使任何既定试验的结果偏移或过时,它们会被稳定的用户研究过程抵消。如果你愿意的话,防止追求不重要结果的爆照是注意不要认为数据是可行的洞察,直到这个模式已经严格建立起来。

这就是为什么我们确保几乎每个试验都进行定性以及定量的研究。此外,我们努力提出可比较的洞察——很少能够了解用户在完全无感的情况下对原型的看法。在现实世界中,用户有一系列选择来满足需求,所以我们需要确保方案的反馈总是参照另外一个替代方案。组合和优化这两种方法大大减少了偏差,而且可以产出大量的数据来帮助我们识别模型和见解。大官人,我们也强调结合其他数据输入的重要性,比如传统的市场调研和应用内分析等等。

 

用户的反馈一直让我们感到惊讶。

你也许会认为,在产生并分析大量的用户数据后,我们会“看到所有”的反馈和见解。但是这绝对不是事实,我们每天都会惊讶于看到新的东西,主要关于“用户所说和他们所做的之间的巨大差别”。

 

目前在预测未来的行为方面是相当糟糕的。我们广泛研究这种动态的心理学。但是,当我们在调研中发现几乎对于某功能几乎一致的支持,但在随后的原型中却完全没有用户有兴趣的时候,这太让人感到惊讶了。将视觉刺激放在目标市场的前面对于证实结果来说是绝对必要的。

 

真诚的情感表达。

市场趋势迅速变化,产品团队紧跟其发展。很少有事情能让他们放下手中任务而静观其变,比如观看用户访谈的视频。有人笑有人哭有人高兴有人震惊,用户研究真的是一个情感的过山车。

 

热烈激情的验证

企业经常会问:“我们如何知道我们何时与客户验证产品概念?”虽然我们没有任何硬性规定,但我们半开玩笑的申请“Pokémon GO Benchmark”。我们对数百个手机游戏进行了研究。玩家对开放式问题进行详细的反馈,话费大量时间与原型进行交流并定期使用新功能。显然,每个产品不需要成为巨大的成功,但Pokémon GO 项目可以作为一个轶事。

 

关键是,即便我们认为用户的细分很合理,研究结果很少是可预测或明显的。你根本不能低估通勤的困难和回报。
较短的迭代周期解开更深入的见解。

 

当我们的前期客户终于在测试版本上快速运行试验时,很清楚为需要几个月执行研究的公司提供有意义的客户洞察很难以捉摸的原因。速度本身是关键。

 

但当我们把研究过程加速,一旦验证产品概念之后客户就不在满意。他们有时间和精力来考虑为何原型被认为比早起迭代和替代品更有价值。为了跟上节奏,我们必须简历一个广泛适应的定性工作流程,以便我们可以回到试验产品的用户样本并询问开放式的问题。这样便能帮助我们解开更加深刻的见解。

 

我们把深入的洞察定义为对客户角色的理解,这个角色的价值超越了产品团队正在开展的单个项目。对于那些专注为同一个市场提供价值的组织的所有成员都是有用的。不仅是理解客户为何喜欢昂贵的一次性付费和相对便宜的分月订阅。这是相当有意义的洞察,可以应用于组织中产品矩阵的其他产品,让快速迭代变成可能。

 

数据意味着一次结束

我们很容易迷失在吵杂中,而不是靠艰苦的工作来发现和提高ROI。快速建立成功的平台让我们不得不想产品团队提供高于”数据驱动“的能力。

 

最初我们假设生成的数据能够直接转化为更好的产品决策。在某种程度上,这对组织这个整体来说很重要。但是,当我们真正深入进去时我们就发现”数据驱动“不是产品经理真正想要或实际需求。

 

我们专心倾听客户如何把试验的价值传递给其他部门的同事。通常情况下,他们提到试验如何使他们的团队围绕假设而不是意见来运转。团队花15分钟假设接着做试验,然后花15分钟来评估解读试验结果。而不是浪费两个小时来进行无用的辩论。有个产品经理讨论他如何运用试验,只是因为数据能帮他给他的主管提供周报中的数据;另一个产品经理却通过试验来进行迭代和学习并收获颇丰。当然,数据对于实现我们目标至关重要,但仅仅是一种手段而不是目的。

 

本文由mili@吆喝科技编译自:https://medium.com/pminsider/after-running-2-000-experiments-for-fortune-500-product-teams-heres-what-we-learned-c4123fb207c8#.6gi1n8h9u