Intercom 公司的产品经理是如何收集用户需求的？

有些事情运作的非常有效，有些则不以为然。为了尝试和学习如何在公司扩张时复制已有的产品成功，并向新人传授已有的经验与思路，Intercom 公司的产品同事一直在对工作方式进行大量反思。本文源自 Intercom 产品高级副总裁 Paul Adams 在其产品博客上撰写的专栏文章。

我认为，我们在 Intercom 做的一件事，是促成我们取得迄今为止所有进展的一个主要因素。就是「要深刻理解每个项目所需要解决的问题」。虽然这句话听起来很明显，很多产品同行自称也都是这样所做的，但我们与他们的做法略有不同，请看我下文中的解释。

大多数公司在实际业务工作中，都是以这样一个非常标准的开发流程作为实践参照的：

如果你的流程相对于“瀑布开发”更加“敏捷开发”，那么它看上去可能会是这个样子：

同时，在这个流程中，还会产生以下这些行为：

有的公司的研发流程可能并不完全类似，比如在「版本测试」后会回到「设计解决方案」这样的循环，但这并不重要。本文并不是想通过一张非常精确的图表，来描述定义 Agile/Lean/Scrum 等七七八八的流程。我想要说的是，我们会在什么环节浪费时间与精力。

想象一下，假设你在一个项目上使用的时间是 100 个单元。所有的产品经理、设计师、用研、需求分析师、工程师的工作等都会汇总在这 100 个单元之中，那到底需要怎么来拆分？

根据我所了解，Intercom之外的大部分产品开发团队会这样做：

也就是说，我们会在项目的前期，花费较少的时间来定义问题的优先级（即识别问题），然后定义问题，再用多一些的时间来设计，最后把大量的时间花费在产品开发上。

有时候，我们也会这样进行时间的拆分：

为什么会跳过「识别问题与定义问题」的步骤，直接开始设计解决方案呢？

大部分时候都是因为一个「十分重要」（可能是老板）的人想到了一个「十分重要的想法」，这个重要的人会不遗余力的去推动这个方案。而重要的人发现这个「重要的想法」的时候，可能出现在开车的时候，洗澡的时候，或者和那些普通人（比如他们的邻居）聊天时候想到的。

一旦这个想法出现了，就会开始争分夺秒地进入设计与开发的迭代之中。这种「十分重要」的人的想法可大可小。而最坏的情况，就是公司发展相关的路线是由「十分重要」的人的很多不断变化的小想法组成，而大部分想法偏偏没有关联与前后衔接。

我们以往的工作经验，往往会塑造我们现在的工作方式。

对我来说，我在 Google 工作的时候经常遇到这些「十分重要的人」和「十分重要的事」。当时有无数的人有着在开车途中、洗澡时、和邻居交流碰撞时所产生的想法。但大多数此类项目都以失败告终。尽管 Google 在其他许多方面做得非常好，不过以上也的确是我在 Google 的亲身经历。

这种失败也发生在许多初创公司中。每当我和那些初创公司的人聊天，研究他们工作方式的时候，得到的回答就是前面所描述的方式和流程。他们也许会谈到做些用研，或者做些用户访谈，但大多都是嘴巴说说做做样子罢了。

而我在 Facebook 中看到的大部分项目流程是这样的：

这种流程比我在 Google 的经历要更好一些，但始终有两件事情让人情绪紧张，这来自于 Facebook IPO 那天，每个人都收到的来自 Mark Zuckerberg 的那封信中所提到的「Ruthless Prioritization & Code Wins Arguments」。

与其花时间寻找那些需要解决的问题，还不如立马开始写代码。

我不完全同意这样的观点。直接写代码确实能够快速输出对应的解决方案，但解决方案正确与否依然与是否能够正确理解问题有关，确实有的人会通过「直接写代码」来快速理解问题，但大多时候都以解决技术问题为主，而并不是解决用户相关的问题。

一旦我们发现的问题是与用户相关的问题时，基本上直接写代码是没法提供帮助的，反而会更加让人们忽略关注用户所面临的直接问题。

“Dont talk show me the code”是基于解决方案的层面。但是解决方案的成功取决于对问题的理解。虽然马上去做有时候能帮助理解问题，但仅限于纯技术端问题，而不是消费者端问题，一旦问题是后者，基本是无法通过马上去做来解决的，反而会让人们在这个问题上飞速略过。

而在 Intercom，我们是这样来分配时间的：

在我们准备着手设计任何解决方案时，我们基本都已经花费了 40 个单位的时间，用来做问题的定义与分析。我们痴迷于问题优先级和问题定义。这里的「痴迷」是指「我会质疑我们是否真的深刻理解了我们正在试图解决的问题」，而这种状态也会让我们的同事为之「欲生欲死」，因此我们非常鼓励产品经理们能够公开分享和辩论我们正在定义的问题的早期定义。

我们为什么要这么做呢？因为只有对所需要解决的问题有着足够深刻的理解，我们所输出的解决方案才能会真正解决问题。这也是无可辩驳的事实。但大部分团队确实直接跳过了问题定义这个阶段。

在我们的流程中，大量工作被前置了，为此我们不遗余力地投入资源，我们使用我们的：

  • 客户支持团队（他们会将与客户的每一次对话进行登记，帮助我们的产品经理进行溯源。顺便说一句，我们当然会使用 Intercom 来做到这一点）
  • 销售团队和营销团队（根据市场的真实需求定义产品营销计划）
  • 研究团队（我们从一开始就投入巨资的团队）
  • 分析团队（我们现在正在大力投资的团队）

如果说有时候到了 Beta 阶段，我们对于问题的理解仍然不够时，那么我们会重新回到问题定义阶段。于是这个流程看起来就会如此：

问题来了，如果解决方案只有在对问题足够理解的前提下才凑效，为什么那么多公司和团队会忽略了这个部分呢？我认为有三大原因：

  1. 找到正确的问题非常非常非常困难。它需要和大量消费者一遍又一遍的深入交流，从而挖掘出新的问题。这个过程需要你抛弃自己的固有看法，真正以用户的角度理解他们真正的需求，而不是最开始他们嘴中的描述。人们通常会以他们能想得到的解决方案形式来描述他们的问题，于是大部分产品团队就止步于此，以这样的理解开始研发产品。但他们忽视了问题的本质还在更深处，这样做完全无济于事。而好的产品团队会继续前行，不停地问自己”为什么"，这往往是非常折磨人也非常花费精力的。
  2. 这部分工作看上去没那么「酷炫」。「一份研究报告，一个新的设计模型，或者可以操作的原型」相比这些对问题的定义往往看起来更有成果。大部分的管理层也喜欢看到「酷炫」的产出，而不是去阅读报告。在现代工作环境中，通过深刻的阅读和反思来获得深度知识，并不是一件人们为之激动和感到重要的事情，这是非常可悲的。其实并没有那些所谓「酷炫」的事情，而只有「重要」的事情。
  3. 可见的产出并不能反映出实际工作量，而且也难以证明其中的合理性。有时候人们进行了几周的工作，而产出只是短小的一段话用来描述着接下来要解决的问题。而如果遇到不重视这一过程的管理层，就很难通过这样的产出来证明其价值。

这就是大部分公司为什么不这样做的原因。虽然这是非常艰苦的工作，但又被错误地视为是乏味的，且难以证实初始产出的价值。

但我相信这才是我们最重要的事情之一，也是项目取得成功的最重要因素之一。只有这样做，才能够极大地降低这种后果的可能性，毕竟花费了大量设计和开发精力及时间所得到的产品，但最终对用户来说无价值，那成本其实都是打水漂的。

我鼓励你尝试改变你的时间构成。通过做一些小事来「痴迷」对问题的定义。然后看看如何快速进行实现，当你发现用户认为你的产品有价值的时候，才是你真正洞悉了他们的需求。

本文原文：https://www.intercom.com/blog/great-product-managers-dont-spend-time-on-solutions/