​走进A/B测试法，看LinkedIn和eBay是如何用它进行产品开发和团队管理的？

编者按： Elliot Shmukler曾分别在LinkedIn、eBay、Wealthfront和Instacart担任过产品负责人，他在这些公司一直都在极力倡导和推行A/B测试法，不仅将A/B测试法不仅作为产品开发的方式，同时将它作为一种有效的产品团队管理工具。他在本文中分享了自己为何将A/B测试法作为产品开发和团队管理工具，同时列出了使用A/B测试法的益处和挑战，并分享了如何在公司里运用和快速推广A/B测试法。不管你是公司的产品负责人还是用户增长负责人，相信你都能从这篇文章里受益良多。

 Elliot Shmukler目前是日用杂货当日送达服务公司Instacart的产品副总裁，他之前还曾担任过理财公司Wearlthfront和职场社交平台LinkedIn的产品负责人。在他截至目前的职业生涯中，他一直都在极力推行和倡导A/B测试法。他不仅将A/B测试法不仅作为产品开发的工具，同时还作为一种有效的团队管理工具。

在eBay工作的时候，Shmukler第一个尝试通过使用A/B测试法来改善eBay的搜索体验，同时还帮助eBay推出了eBay Express这款产品，这应该是eBay当时在产品方面做过的最大胆的尝试。在LinkedIn的时候，他领导的15人的产品团队负责LinkedIn网站将近一半的网站流量。在担任Wealthfront产品副总裁期间，Shmukler不仅带领团队将公司管理的客户理财资产规模从1.5亿美元增至超过30亿美元，同时还带领团队推出了Direct Indexing、单股多元化服务（Single-Stock Diversification Service）和公司的第一款移动App。在Shmukler的整个职业生涯中，他已经熟练掌握了如何让A/B测试在产品开发和团队管理中发挥最大效用。

近日，Shmukler接受了First Round Review的专访，他在专访中解释了自己为何将A/B测试法作为自己的管理框架，并用自己的实际案例说明为何A/B测试法不仅能加速决策，同时还能更好地赋予团队成员做决策的能力。他列出了将A/B测试法作为管理框架的益处和所面临的挑战，同时分享了如何在公司里运用和快速推广A/B测试法。

一、两种完全不同类型的决策

在任何一种管理框架里，其核心目的都是为了做出更好的决策。Amazon的CEO Jeff Bezos在给股东的年度公开信中曾表示有两种决策类型：不可逆型决策和可变型决策。Bezos分别对这两种决策类型进行了描述：

（1）不可逆型决策：有些决策的影响非常重大，而且这些决策是不可逆的或接近不可逆的，这种决策类似单向通道，做出决策后便再也无法更改。所以你必须非常有条理地、谨慎地并在充分协商地基础上做出这类决策。一旦做出了决策，如果发现结果并不是你想要的，你也无法回去重新决策了。

（2）可变型决策：大部分决策都是可变型和可逆型决策，这类决策类似双向通道。做出这类决策后，如果你发现结果并不是最理想的，你可以重新打开决策之门，返回去重新决策。可变型决策可以而且应该由那些具备很好判断力的个人或小组去快速做出。

在公司发展的过程中，有一种倾向是广泛地将“不可逆型决策”的流程应用到每一项选择中。在Bezos看来，这么做会导致决策的缓慢和一味的规避风险，从而会妨碍测试和减弱创新。相反，如果公司盲目地对“可变型决策”不加选择和思考地运用、而忽视“不可逆型决策”的话，Bezos认为大部分公司在发展壮大之前都将消亡。

Shmukler相信，通用的A/B测试法是让公司使用“可变型决策”方法做大部分决策的理想方法。在传统意义上，要想使用A/B测试法，至少需要两个产品版本：A版本是原始版本，B版本是你认为可能比A版本更好的版本。这时，将A/B测试应用到“可变型决策”中时，如果通过A/B测试发现A版本要比B版本好，这时仅需简单地关闭B版本、再回到A版本即可。A/B测试法甚至还能帮你认识到什么时候需要应用“不可逆型决策”流程，

根据掌舵Amazon的亲身经验，Bezos提醒大家千万不要陷入“万能型”决策方法中，即将一种决策方法应用到所有的决策中。Shmukler在早期创业公司中也看到过类似的陷阱，在产品管理中尤其如此。“产品经理是他/她所主导的产品的CEO”是一句在业界非常有名的话，这句话在涉及到决策的时候是有它的道理的。产品经理通常会自然而然地将自己管理风格带到自己的决策方式中。

二、将A/B测试法作为管理框架的真实案例

Shmukler在自己职业生涯的早期曾联合创办过Sombasa Media，他后来将这家公司卖给了About.com。他在这段创业经历中第一次意识到了两种完全不同的产品管理决策风格的产品经理：远见直觉型产品经理和数据驱动型产品经理。远见直觉型产品经理对未来有自己的预测，通常会根据自己的直觉进行决策。数据驱动型产品经理则主要根据测试和分析进行决策。有效的决策框架有很多，但我希望使用一种既有助于做出最佳的产品决策、同时也能鼓励团队内部不同产品经理的不同思维方式的决策框架。

对于远见直觉型产品经理而言，当直觉告诉他们需要开发某个功能或产品的时候，他们就会有强大的驱动力将这项功能或产品开发出来并带给所有用户，Shmukler自己也承认，正是基于这个原因，他认识的很多远见直觉型的产品经理后来都成了公司创始人或CEO。相比较而言，数据驱动型产品经理一般都会系统地不断完善自己的见解和洞察力，而不会根据自己的直觉任性决策。数据驱动型产品经理往往通过观察和搜集新数据来支撑自己的立场和观点，随着获得的数据越来越多，他们会不断完善自己的见解。

因为这两类产品经理的思维和做事的风格完全不同，作为团队领导，要想让持这两种完成不同产品管理方法的产品经理达成一致是非常困难的。如果你是公司的产品负责人的话，你肯定对下面这样的对话场景非常熟悉：

远见直觉型产品经理：“我们需要做X。”

数据驱动型产品经理回应说：“不，X是错误的，它是行不通的。我们需要做的是Y。”

Shmukler在自己管理的产品团队里几乎每天都会遇到上面这样的场景。这简直让人筋疲力尽的，你很难在看起来不偏向某一方意见的情况下解决这个问题。面对这个问题，Shmukler并没有选择自己做裁判并在双方的不同见解里选中一方的观点去执行，而是对这两种观点都进行测试，最后让数据成为裁判。咋一看，这个方法似乎偏向数据驱动型产品经理，但它却能让双方的产品经理都去切实推进自己的想法，同时不会让他们感觉决策是专门针对自己的。

为了说明这种方法的有效性，下面是Shmukler 将A/B测试法运用到产品开发和团队管理中的真实案例。团队里几个远见直觉型的产品经理想要调整公司的对外宣传语言，尤其是官网主页的介绍语言。对于这个提议，团队里数据驱动型的产品经理表示他们之前曾做过这方面的测试，而测试结果显示对注册没什么影响。为了解决这种意见相左的问题，必须要有人出面决定是否要部署时间和人力资源进行这方面的测试。这时，不管你的决策是什么，都会有人认为你做了一个糟糕的决策，远见直觉型产品经理会说你做决策时过于依赖数据，而不基于公司宏大的目标进行决策。数据驱动型产品经理会说在这方面花时间和资源是一种浪费。这时，A/B测试法就能很好地解决这个问题，因为使用A/B测试后你就不用再去做这种两难的决策了。因为在A/B测试的管理框架下能让大家形成一个共识：即一个值得信赖的团队的任何想法都能够得到测试，测试结果决定是否要继续践行这个想法。

每当面对这种情形，Shmukler都会让所有团队成员一起协作对他们的想法进行测试并获得测试结果。远见直觉型产品经理会负责撰写新的官网主页内容，数据驱动型产品经理则负责构建测试流程。整个测试只需1-2天就能完成，然后花一个月时间去搜集数据。所有测试结果都会在数据白板上向公司里的所有人公布。这样一来，争执双方就都满意了：数据驱动型产品经理能够根据测试数据进行决策，远见直觉型产品经理能够将自己的想法付诸实施。在这个案例中，最后的测试结果表明官网主页内容对用户注册并没有很大的影响。不过这对那些主张更改官网主页内容的远见直觉型产品经理也无所谓，因为知道测试结果后，他们就不会再死死抓住这个想法不放了，从而将精力投入到新的想法里。

A/B测试法还能够让Shmukler同时对多个产品想法说Yes，唯一的限制在于所有这些想法都需要被测试。这时“可变型决策”流程就能派上用场了，这能够避免团队陷入毫无必要的“不可逆型决策”的困境和陷阱里。更为重要的是，这种方法能够很好地鼓励和团结团队中持不同想法的产品经理，因为每一个人都有机会对自己的想法进行测试。

不管最后哪一方想法胜出，都不会造成产品经理团队成员之间关系的紧张，因为测试结果来自权威的测试，而不是来自某一个权威的个人。其中的关键在于要快速测试，同时确保整个测试流程和结果的透明。下面就分别系统地总结一下A/B测试法的益处和所面临的挑战。

益处

（1）充分的自主权。采用A/B测试法，我发现非常有价值的一点在于，团队里的每个人，不管他是什么头衔和职位，基本都可以将自己的想法变成现实。作为团队管理者，我扮演的角色更像是一个仲裁者，而非独裁者。我只在完善有关未来的设想的时候才会插手。

（2）更低的风险。一旦公司里有用于快速测试的工具，那么测试成本就会低很多，而测试这个行为本身也将降低总体成本。通过测试，我们能更快地知道一个想法是否是糟糕的或是有潜在危害的，这样我们就不会继续推进这个想法。如果经过测试证明一个想法是好想法，那么我们便可以毫无顾忌地大胆推进这个想法，并最大程度从中受益。

（3）提高员工参与度和敬业度。这种方法能够提高团队产品经理的幸福度，因为他们知道在这样的团队里，他们可以将自己的想法快速变成现实，并证明自己的想法是有用的。很多团队成员都曾告诉我，他们在这个团队里能够更快地学习和成长，因为他们可以快速测试自己的想法并从测试结果中学习。

（4）不会改变大家原有的做事风格。A/B测试法这套产品开发和管理框架不仅能够让数据驱动型产品经理更加理性地评估自己的想法，也能够让远见直觉型产品经理更快地打磨自己的直觉，因为通过测试他们可以更快地“体验”自己的直觉想法是否正确。这种方法不会改变大家原有的做事风格。

挑战

（1）用户样本规模。一开始的时候，创业公司通常需要按照远见型模式去运营。要想让让A/B测试系统有效运转，你首先需要有一定的用户基础。如果你想围绕用户在使用产品中的某一具体行为进行测试，如注册、点击或分享的行为，你一周至少需要有数百位用户有过这个操作行为才能测试。理想情况下，为了更快获得测试结果，你往往需要在数千用户中进行测试，而且同时进行多项测试。当然，那些可以在数百万用户里进行测试的公司在A/B测试时有更大的优势。

（2）公司遗留下来的传统决策方法。我之前工作过的一家公司根本就不知道A/B测试法，更谈不上使用这种方法了。相反，他们要求每一个人对所提出的每个想法可能会造成的结果写一份详细的财务和影响分析报告。在我看来，这是扼杀团队成员想法的罪魁祸首。但现在很多公司依然在采用这种方法。

（3）注重指标文化，而非测试文化。我之前工作过的一家公司，它非常擅长每天监控自己的商业指标，但不做任何的A/B测试或其它小的测试。公司非常看重那些高级指标，然而一旦出现问题，它无法很快确定问题到底出在了什么地方。记得有一次，公司同时发布了7项新功能，所有这些功能都没有经过A/B测试，后来出现了一个大问题。为了重新对这些功能进行A/B测试并从中找到问题的根源，这使得团队不得不撤回大部分新功能。

三、如何运用和大规模推广A/B测试法？

针对将A/B测试法作为产品开发和管理工具这件事，Shmukler在过去多年里听到很多质疑的声音。在发展比较成熟的大公司里，人们早已形成了自己独特的做事风格，你很难仅仅靠A/B测试理论上可能会带来价值说服他们转变做事风格并接受A/B测试法。而对于创业公司而言，他们往往会以耗不起这个时间和成本为借口而拒绝A/B测试法。对于我自己而言，我之前曾加入一家创业公司，加入时公司只有20名员工，后来我使用这个方法让公司规模发展至100多人。

Shmukler同时有过大公司和创业公司的工作经历，他发现，不管公司规模如何，这套测试框架一点都不会耗费你的时间和成本，因此可以帮你非常顺畅地开展测试工作。他是如何做到的呢？

（1）在轻量级A/B测试工具上进行投入。根据Shmukler的经验，只需要几个工程师就能开发一个初始工具和数据仪表盘来运行、监控和评估A/B测试。大部分没有做过这个工作的人会误认为这个工作所要耗费的资源是他们无法承受的。其实只需不到一个月的工作，创业公司就能让A/B测试自动化运行。产品经理在不需要做什么工作的情况下就能快速获得测试结果。

如果你没有足够多的工程师人力资源去自己开发A/B测试工具，也没有关系，因为现在市场上已经有很多可以直接拿来用的测试工具，例如Optimizely。如果你使用Optimizely这款工具的话，你甚至不需要写任何代码就能进行A/B测试，所有工作都由Optimizely帮你完成，包括测试、搜集数据和评估数据等。因此，如果你选择使用一款外部的A/B测试工具的话，你基本上不需要做额外的工作。不过有些这类工具需要付费才能使用，不过一般基础功能免费，增值功能付费。即使需要付费，这也是非常划算的一笔投资，因为这样的工具有助于你做出更好的产品决策，同时还能增强团队凝聚力。

（2）降低测试的决策障碍。要想让A/B测试成为公司内的通用做法，就要做到通过一个简单的决定就能顺利推动测试的进行，尽可能降低测试的决策障碍。在确定做一项测试后，整个A/B测试系统便会自行运行和评估。归根到底，需要打造一个优秀的A/B测试框架。对于工程师而言，需要一个让运行一项测试变得非常容易的框架，可能仅需几行代码就能做一项新的测试。对于团队里的其他人来说，则需要一个能够自动评估测试结果的内部仪表盘。

Shmukler建议产品团队使用那种能够自动识别新测试项目的仪表盘。他分享了他自己之前曾开发过的这样的仪表盘：“它能够让你针对一项测试选择一个目标，基于你选择的目标，仪表盘会自动显示那些你应该跟踪的测试指标。然后它会即时让评估数据，并给出红色、绿色信号告诉你是采用新测试项目还是维持原状。如果还没有搜集足够多的数据，仪表盘会提醒你需要继续运行这个测试。你需要的正是这种简单和自动化仪表盘。

（3）理清不同测试间的相互影响和作用。当年在LinkedIn的时候，我们最后发现了不同测试间的相互作用。举个例子，对注册流程和个人资料页面的测试可能会影响其它的测试结果，而且很难梳理清楚不同测试间的相互作用。这时，可以使用统计方法去提醒仪表盘是否存在有问题的交叉影响，这时你可以在选择关闭其中的一项测试后再评估剩下的测试结果。

如果你在测试之前就预测到可能会出现这样的问题，为了避免不同测试间的相互影响，可以考虑使用不同的筛选标准将特定的用户导入到特定的测试中去。在LinkedIn，Shmukler就和他的团队采用了非常严格的筛选标准来避免不同测试间的相互影响。“在为新测试项目选择测试用户的时候，我们会从那些没有参与其它测试的用户里选取，或是对用户进行分区，确保一个区的用户一次只参与一项测试。”

此外，在需要同时进行多项测试时，其中的复杂度也会大大提升，这就需要让仪表盘变得更加容易去解读。最好的仪表盘通常都是最简单的，只显示红色或绿色这种简单的指示信号。

（4）理解测试对整个产品或公司所产生的广泛影响。当A/B测试法发挥的作用越来越大的时候，不管是远见直觉型产品经理还是数据驱动型产品经理都会越来越信任A/B测试。大部分A/B测试都能够告诉你一项测试是好是坏。下一步工作就是开发一个能够显示一项测试对整个产品或公司的关键指标造成的影响的仪表盘。例如，你可能通过优化注册流程的个步骤，并将那个步骤的操作完成率提高10%，但这并不意味着你的整体注册量提高了10%。

因此你需要加强测试软件的能力，让它能够解读测试对整个产品或公司所产生的宏观影响，这应该作为每一个产品团队的A/B测试路线图。此外，它还能帮你在选择测试时将它可能对整个公司的影响都考虑进来，从而更明智地选择要测试的项目。一项测试是能将整个产品改善10%还是仅仅能将产品的某一个部分改善10%，了解这一点很重要。

结语

A/B测试不仅在完善产品开发中有重大价值，它还有助于打造一个更加卓越的产品团队。A/B测试法不仅能够化解不同类型产品经理之间的紧张关系，同时还能够赋予团队成员更大的自主权，让他们保留自己原有的做事风格，而且能够提高他们参与度和幸福感。尽管A/B测试法也会面临诸如测试样本规模、传统的决策方法和不注重测试文化等方面的挑战，不过在轻量级的A/B测试工具上进行投入依然是你最好的选择。随着公司规模的扩大和测试项目的增多，测试软件也需要与时俱进，确保测试软件和仪表盘的简洁，这样所有员工都能准确了解测试进程和结果。

A/B测试法不仅有助于更快地完善产品，它还有助于打造一个更加紧密团结的团队，要想走得快，就一个人走，要想走得远，就结伴同行。将A/B测试法作为管理工具向公司里的两种不同类型的产品经理都传递了这样一个明确信号：明智的测试想法总能脱颖而出，不管这个想法是谁想出来的。