对讲机的产品原则：我们如何专注于交付成果

在 Intercom，运输只是开始。

我们迭代，争取采用，并不断推动对我们的客户和我们的业务产生最大的影响。 我们努力提供成果和产出，为我们的客户带来真正的成果。

在我们的 Intercom on Product 播客的一集中，我们的联合创始人 Des 以这种方式总结了产出与结果的关系：“这是您交付的内容与因您交付的内容而发生的事情。” 我们努力确保由于我们运送的东西而发生的事情为我们的客户带来有形的价值。

“在忽视业务成果的同时推动出色的客户成果并不能使公司成功”

但归根结底，在忽视业务成果的情况下推动出色的客户成果并不能成就一家成功的公司。 我们努力平衡两者，为我们的客户和我们的业务提供高影响力的成果。 我们是这样做的：

我们制定了我们旨在预先推动的结果

我们从一开始就考虑我们要争取什么样的客户和业务成果，特别是在整理我们的问题陈述时。 在整个过程中，我们会问自己：“成功解决问题会导致客户行为发生哪些可衡量的变化？”，并且通常将这种行为衡量为产品活动或使用情况。

我们使用特定的研发成果指标模板来帮助我们思考和阐明我们的目标。 在其中，我们将我们希望看到的客户利益与我们拥有的任何指标、目标和支持理由相结合。 我们对我们想要推动的商业利益做同样的事情。

“我们发布了一项功能来解决客户问题； 推动某些客户行为，进而影响业务成果”

我们发布了一项功能来解决客户问题； 推动某些客户行为，进而影响业务成果。 也许我们运送的东西会为客户节省时间、提高效率或降低成本。 然后我们考虑业务成果或业务成果。 如果我们解决客户问题并推动客户行为，我们期望在我们的业务中看到什么影响？ 我们使用以下类别来构建业务影响：

• 获取：它会帮助我们获取新客户吗？
• 扩展：它会帮助我们加深或扩大现有客户的使用吗？
• 保留：它会在保留客户或防止流失方面发挥作用吗？
• 收入：我们可以直接将其与商业影响联系起来吗？ 例如，像附加组件这样的东西可以很容易地用收入来衡量。

“衡量每个产品功能的商业影响并不总是可能的”

有时，交付产品和推动业务成果之间的界限似乎是天壤之别——而且衡量每个产品功能的商业影响并不总是可能的。 我们不会为此烦恼，我们当然也不想硬塞每一个功能以适应收入目标——但我们会尽可能多地将其映射回来。

我们检测我们的产品，以便我们可以衡量我们的结果

我们需要确保我们拥有正确的数据来衡量我们正在努力争取的结果。 我们通过跟踪感兴趣的特定事件以及有关这些事件的其他上下文来检测我们的产品。 我们使用内部分析框架进行检测，跟踪每个事件的动作、对象、地点和元数据。 对讲机的每个用户都可以在特定地点对特定对象执行操作，其中：

• 动作：描述用户采取的动作，例如打开、点击。
• 对象：描述被操作执行或受操作影响的对象，例如对话细节、消息。
• 地点：描述触发动作的位置。 这通常代表用户所在应用程序的页面，例如收件箱。
• 元数据：提供有关每个特定事件发生的附加信息，例如 URL、ID、状态。

这是衡量和推动成果的关键一步。 如果该功能尚未进行检测，则它还没有准备好发货。

我们总是假设我们需要迭代我们的产品

我们知道，我们不会总是为我们的客户或我们的业务提供完全正确的产品，因此我们计划并留出时间迭代我们的产品，直到我们这样做。

这并不容易——一旦发布了一个功能，很自然地就会感觉到对路线图上的下一个事物的拉动。 我们都对“运送，继续，运送，继续”的心态感到内疚，但在 Intercom，我们知道我们的工作并没有在我们运送时完成。 所以我们计划迭代​​。

发货后，我们争取采用和使用

我们知道这不仅仅是“建造它，他们就会来”的情况——我们必须争取采用和使用。 这意味着定义、衡量和理解核心指标，如意识、意图、激活、采用和参与。 我们在发布后跟踪和审查这些指标，解释结果，并在需要时采取行动改进。

我们审查结果并分享我们的经验

为了整理我们的学习成果，我们有一个严格的流程来审查结果并在整个公司范围内广泛分享我们的结论。 这不仅针对 PM、数据科学家或研究人员，还针对整个团队。 我们为此使用的主要工具之一是结果报告。

在我们发布一项功能大约一个月后，我们会完成一份结果报告，以反映我们是否看到了我们预期的结果。 我们查看定量和定性反馈来评估我们的表现，并讨论我们因此需要做出的行动或决定。

对于更大的项目或大型发布，我们可能会确定多个检查点，在三个月、六个月或十二个月时评估结果。 团队将他们的成果报告分享到一个专门的 Slack 渠道，以便在团队内部和整个公司范围内尽可能多地接触到更多人。

“我们总是假设需要一些发布后的迭代，并且通常认为这是原始项目的扩展”

我们总是假设需要一些发布后的迭代，并且通常认为这是原始项目的扩展。 也就是说，有时我们需要重新确定路线图的优先级，以便为更大的变化腾出空间。 一个好的指导原则是问自己：“我们是否为大多数目标客户充分解决了已识别的问题？ 我们是否实现了我们的目标客户和业务成果？”

注意反模式

这些做法可能会在一段时间后潜入，而不会引起任何人的注意。 这些可能看起来像：

• 在项目开始时未能决定我们期望的结果。
• 未能为产品、功能或结果定义合适的指标和正确的工具。
• 运送并继续前进。
• 把我们不打算造成的结果归功于自己。
• 匆忙完成结果报告流程只是为了检查一个框。

与这些反模式作斗争需要真正理解“交付成果”原则以及它对我们的客户和业务的重要性的团队的大量工作。 我们需要继续将这一原则应用于我们构建的所有东西，以确保它融入我们的文化和我们解决客户问题的方式中。 这样做有助于我们为客户和公司大规模提供有形价值。

这是我们的 Intercom on Product 系列的第二篇文章，Intercom 研发团队的专家在其中谈论指导他们日常工作的原则。 在此处阅读该系列中的其他博客文章。