我们的行业正处于一场关于如何构建我们的产品的基本思考方式的哲学大辩论中，焦点从我们构建的产品的输出转移到这些输出所产生的业务结果。我们一直在深入思考如何在我们自己的组织中做出这种改变，Des和Paul主导了我们的讨论。更广泛地说，像johncutler和Josh Seiden这样的行业思考者正在广泛地写关于组织如何影响他们的思维方式的改变。在某种程度上，这种讨论与产品团队和产品导向型公司的关系更密切，而不是成长型团队，后者的定义是注重结果。但事实上，这是一个讨论，突显出我们对产出和结果之间的关系知之甚少，也就是说，产品与利润之间的因果关系，可以说是如此模糊。为了充分理解这种思维方式的转变需要什么，我们已经意识到理解我们所称的"产品影响框架"是非常重要的，即因果关系的步骤，最终为企业带来积极的结果。

从本质上讲，您所处理的任何项目都会导致产品的变更（通常但不一定是一个特性）。如果这个特性解决了客户的问题，那么它会导致客户在您的产品中的行为方式发生可衡量的变化，并且最终这种行为变化会对您的业务产生影响。但是知道这些步骤是如何工作的并不等于让它发生，我们认为我们知道原因。背景：我们从何而来努力取得成果首先是一些背景。我们的研发文化的一个主要部分是围绕着运输速度。早在2013年，我们的工程负责人达拉赫（Darragh）就创造了这样一句咒语：航运是我们的心跳。"当你正处于公司的初创阶段时，运输速度和过早交货是成功的关键，这样你就可以了解什么是真正有效的。"同年晚些时候，我们的产品负责人保罗写了一篇博文，说航运只是一个过程的开始，我们最终将其提炼为一个核心研发原则"船来学"当你正处于一家公司的初创阶段时，运输的速度和过早的运输是成功的关键。它还允许我们从特性开始，大数据培训哪好，然后很快看到哪些特性有影响，物联网专用卡，哪些特性没有影响，这种迭代的速度自然而然地来到了我们的面前，并且非常富有成效。产品影响框架感觉像是从特性到结果的自然进展。但我们不一定能完全控制这些结果，也不能完全预测它们。随着我们规模的扩大，这种情况不得不改变。让我们的团队更加商业化2018年，我们的联合创始人Des采用了一个新的内部口号："这都是关于市场影响的。""对大多数产品团队来说，从发布改进到衡量其对关键业务指标的影响之间的差距非常大"我们需要我们的研发团队从商业角度考虑问题。仅仅有效地解决客户问题是不够的；我们需要考虑如何帮助我们的业务取得更大的成功。这里的核心问题是，从发布改进到衡量其对您的关键业务指标的影响的差距，对于大多数产品团队来说，差距非常大。在理论上可能很难破译它们之间的关系，但在实践中却很难破译它们之间的关系。工作中的产品影响框架如果我们研究一个最近的例子，以及它如何映射到产品影响框架，这个难题就显而易见了。今年夏天早些时候，我们发布了收件箱应用程序，允许对讲机客户通过安排工具和看到的客户信息来定制对讲机收件箱。以下是此功能如何融入框架：

很简单，大数据网站，对吧？也许是这样，但是最后两个步骤之间的关系，从平均响应时间的减少到更高的支持保留率，这两个步骤之间的关系并不简单。例如，我们能有多自信地预测保留率的增加？随着我们进入一个注重结果的世界，审视框架并将其逆转是非常有诱惑力的——也就是说，我们不再像传统上在快速发布、快速迭代的世界中那样从功能入手，而是简单地从我们希望看到的结果开始，然后逆向工作。

这个框架的优点在于它实际上支持两种根本不同的构建产品的方法：特性驱动的项目和结果驱动的项目。但是，263云通信企业版，只有经过大量的努力和实验，我们才意识到这两种方法有多么根本不同——正如我们发现的那样，一种方法并不是另一种方法的简单相反。功能驱动项目功能驱动项目是构建产品的最常用方法。这些功能可能来自于现有客户的功能请求，或者您的销售团队在试图完成交易时遇到的产品差距。或者这个功能可能是一个新的想法或者你的团队非常兴奋的大赌注。不管这个功能的来源是什么，关键点是我们在过去已经反复讨论过很多次了——了解要解决的实际客户问题是绝对重要的。这是进入框架的第一步：

保罗曾写过，在问题定义上投入更多时间是多么重要，这是我们的第一个研发原则：

让一个团队团结起来支持一个问题是令人难以置信的，因为它可以为解决方案提供更具创造性的方法，并使这些解决方案更有可能实际发挥作用。对我们来说，真正的挑战来自于如何进一步沿着框架向下走，朝着最终的目标前进。特性驱动的项目通常就是这样：很容易看出你是否通过直接相关的客户行为来解决问题，但很难甚至不可能将其与更高层次的客户行为和业务结果联系起来。再举一个收件箱应用程序的例子，我们可以通过观察一段时间内的使用率和采用率来观察新功能的效果，但是要确定这个特定的变化对响应时间的影响，从而确定保留率就要困难得多。"通过使用可测量的客户行为作为业务结果的代理，您可以为您的研发团队创建一个更快的反馈循环"更高层次的客户行为指标（如平均响应时间）和业务结果（如保留率）有许多影响它们的变量。因此，如果不进行非常长的a/B测试，就很难证明其中一个变量的更改会导致业务度量的更改。此外，业务指标往往是滞后的指标，这意味着从测试到学习的反馈循环往往太慢，对团队没有实际用处。要解决这个问题，您需要使用Netflix产品前主管Gibson Biddle所称的代理度量，它是实际业务度量的替代度量。通过使用可测量的客户行为作为业务结果的代理，您可以为您的研发团队创建一个更快的反馈循环。但是，这个团队对收件箱应用程序如何影响我们的业务结果还真的一无所知，甚至没有合理的估计。这个项目，像许多功能驱动的项目一样，在框架栈中被进一步地卡住了。教训是，要让一个功能驱动的项目一直延伸到栈底是非常困难的。确定代理指标有助于加快进度。成果驱动型项目另一种方法是从期望的结果开始。事实上，对于专注于增长的团队来说，这是一种常见的情况，但作为一家传统的产品主导型公司，这种方法并不适合我们。例如，去年我们要求一个团队"改进收件箱的座位扩展"。座位是我们向客户收取费用的主要方式之一，一元云购下载，所以实际上这和"为现有客户扩大收件箱收入"是一回事。"出发点太陌生了，团队基本上都不知道该如何思考这个项目"这听起来很明显，但以前没有团队研究过这一点，而且由于我们收入的很大一部分来自于此，这似乎是一个很大的机会。它是完全开放的-对于如何做到这一点没有任何信念，完全取决于团队。因此，学习如何以结果为中心是一个理想的项目。但这是一个失败。这个项目一无所获，甚至还没有开始。这个项目的起点是如此的陌生，以至于团队基本上都不知道该如何思考这个项目。