对讲的产品原则：从问题做起，实现更好的解决方案

“我们要解决的问题是……”

这是对讲机的常见开场白。 不仅在产品评论、路线图会议或产品人员的设计评论中，而且在整个公司中。

这是探索我们产品原理的系列文章中的第八篇。 在这里，斯蒂芬讨论了我们的工程原则“从问题开始”。

在我们周五下午的仪式“展示和讲述”中，来自公司各地的人们演示了他们一直在做什么，这就是他们打开演示文稿的方式——他们描述了问题。 当任何新加入对讲机的人时，他们的入职包中都会包含他们的第一个“Intermission”——我们的问题陈述名称。 当你开始时，你首先要关注一个问题。

我们有充分的理由沉迷于问题。

您的解决方案与您对问题的理解一样好。

大多数公司都失败了。 许多失败的原因之一 - 特别是在早期阶段 - 是因为他们没有为客户存在的实际问题提供令人信服的解决方案。

失败的解决方案有几种常见模式：

• 团队一开始就没有很好地理解问题
• 团队未能不断更新他们对问题的理解以及随着时间的推移它如何映射到解决方案
• 这个问题不值得解决——它可能太小众或不够紧迫，无法立即采取行动

很多时候，公司会迅速从问题跳到他们爱上的单一解决方案。 他们在这个解决方案上投入了时间、金钱和精力，但最终却意识到没有人真正关心它。

“真正伟大的公司意识到，制造人们想要的东西比制造人们想要的东西更容易”

真正伟大的公司意识到，制造人们想要的东西比制造人们想要的东西更容易。 这就是我们在 Intercom 尝试做的事情——我们从了解目标客户遇到的实际问题开始。 听起来很简单，但如果专注于问题如此关键，为什么很少有公司这样做呢？

人们习惯于思考解决方案

我们都听说过“不要给我带来问题，给我带来解决方案”这句话。 我们的大脑一直在努力解决摆在我们面前的问题。 但是，如果我们不花时间分解、探索和分析客户的问题，我们的解决方案就有可能落空。 以下是一些问题被忽视的原因，有利于立即解决。

“挑战在于创建系统视图并了解系统如何一起工作（或不工作）”

1.你的产品是一个系统

您的产品、公司和客户群越大，准确诊断模棱两可的问题就越具有挑战性。

有越来越多的因素在起作用，挑战在于创建系统视图并了解系统如何一起工作（或不工作）。 例如，如果一个产品的使用率很低，那是为什么呢？ 是用户体验或教育问题、缺少功能还是其他原因？

2. 问题定义很难

人们经常以他们想要的解决方案的形式描述他们遇到的问题。 许多产品团队停在那里并构建该解决方案，这通常会错过标记，因为实际问题被埋得更深了几层。 优秀的产品团队不断前进，不断追问为什么。

“问题定义意味着跳出你的头脑，进入他们的头脑，深入了解他们的实际需求——而不是他们描述的第一件事”

这可能在情感上具有挑战性且耗时。 它需要一遍又一遍地与许多客户交谈，以新的角度和新的提问方式进行挖掘。 这意味着跳出你的头脑，进入他们的头脑，深入了解他们的实际需求——而不是他们描述的第一件事。

3. 解决方案很闪亮

更令人兴奋的是：一份研究报告还是一个新的工作原型？ 我们大多数人都喜欢看一些新的很酷的东西。 我们没有时间阅读报告； 反思和获得深入的知识通常被认为是乏味或不重要的。

在 Intercom，我们明白影响比魅力更重要。 当我们看到写得很精彩的问题陈述时，我们会很兴奋，我们知道这些陈述将成为接下来工作的有力指南针。

4. 可见的产出和对“进步”的偏见

有时，一个团队可以投入数周的工作，并产生一个简短的段落，阐明要解决的问题。 对于不重视这个过程的人来说，很难根据产出来推销重要性。

远离实际问题的利益相关者将倾向于“切实的进步”——他们更有可能对任何解决方案感到欣慰，无论它是否能解决问题。

那么，如果这是问题所在，解决方案是什么？

“从问题开始”作为我们的核心研发原则之一出现在首位和中心，表明它的重要性并确保我们在工作时牢记它。 这也是一个触发器； 它激活了我们都可以利用的具体期望和工具。 以下是我们在 Intercom 中优先处理问题的一些方法。

我们允许专注于问题

在 Intercom，我们重视原则而不是流程，因此无论我们遵循敏捷、精益还是其他一些产品开发流程——这个原则告诉我们应该关注哪里。

大多数公司将时间花在设计和构建解决方案上，而很少关注理解和优先考虑他们需要解决的问题。 如果每个团队有 100 个关注单位，他们通常会这样使用：

大多数公司将大部分时间用于设计和构建解决方案

大多数公司将花费大部分时间设计和构建解决方案，然后向他们的客户发布测试版。 我们认为这是一种有缺陷的方法，过于倾向于基于薄弱的问题理解来构建解决方案。 相比之下，这里是我们如何度过对讲机时间的粗略指南：

在 Intercom，我们将时间更平均地分配到各个阶段，花费大量时间来确定问题的优先级和细化问题

在我们开始设计任何东西之前，我们 100 个单位中的三分之一就已经用完了。 在这个阶段，我们痴迷于问题优先级和问题定义，并随着我们了解更多，不断重新定义我们对问题的理解。 在流程开始时花费这段时间意味着我们知道我们需要构建什么，并且可以更快地将其交付给客户。

我们确定问题定义期望

我们所有的原则都可能在规模或工作量上有所不同，并且没有固定的时间应该花在定义问题上。 您可以花一个小时、一天、一周或 10 周的时间端到端地完成整个过程。 为了帮助个人和团队对给定问题进行分类并确定投资的适当努力，我们使用了几条准则：

1. 在问题和解决方案之间来回跳动是可以的

在他们的书Bulletproof Problem Solving 中， Charles Conn 和 Robert McLean 将其称为“问题和解决方案之间的鼠疫”。 这个想法是，在两者之间进行切换会加深你对每一个的理解，但关键是不要爱上你对问题或解决方案的看法。

“当你试图同时考虑客户和业务需求时，可能会造成混乱”

2.从客户的问题开始，而不是从业务开始'

当您尝试同时考虑客户和业务需求时，可能会导致混乱。 在考虑这些问题对业务的影响之前，我们故意先关注客户的问题。 如果您要解决的是业务问题，请务必将其直接与客户问题联系起来。

3. 谁有这个问题，有什么工作要做？

当客户的期望与他们的现实之间存在差距时，就会出现问题。 您需要定义您关注的期望和经验，以及他们试图实现的结果。

4.关注问题的严重性

问题影响了多少客户，他们受到的影响有多大？

“很多时候，问题陈述都是蓬松而高层次的”

5. 跟随影响

在 Intercom，我们预先指定成功指标作为问题定义过程的一部分。 这让我们知道我们应该注意哪些关键的客户行为变化，以确认我们已经解决了问题。

6. 具体

很多时候，问题陈述都是蓬松而高层次的。 在您的问题定义中达到足以帮助您找出解决方案的具体程度非常重要。

7. 确定问题范围

问题通常是有层次的，根据您的客户和产品，它们可以被触手。 分解您的问题以增加对每个维度的关注非常重要，而且您可以将其映射到您的解决方案选项并确定最适合的解决方案。

我们使用模板作为指南，以确保每个人都遵循通用格式，但该文档通常伴随着许多其他地方的背景研究。

“随着我们在此过程中以及最重要的是在我们发货后了解更多信息，我们会更新我们对问题的思考”

问题定义是基础。 从那里开始，我们的原则作为一个系统协同工作，将我们从问题推向解决方案。 随着我们在此过程中以及最重要的是在发货后了解更多信息，我们会更新对问题的思考。

我们采取全团队的方法来解决问题

在 Intercom，我们都是具有不同专业的产品人员。 产品经理可能拥有问题定义，但每个人都有责任挖掘、理解并让自己对实际解决他们面临的问题负责。

这为问题定义的方法提供了信息。 这意味着让更多的人参与研究，并分享采访和见解以建立共同的理解。 人们可能需要一些时间来适应这种方法并看到其价值，但努力加快构建效率和解决方案的准确性是非常值得的。

从问题入手可以让对讲机的工程团队设计出更周到、更合适的解决方案。 您对我们在 Intercom 的工作方式感兴趣吗？ 详细了解我们的工程团队。