硅谷产品总监教你如何构建产品开发流程

在产品开发流程中，最重要的是要理解 用户痛点。

今年春季，Intercom（一体化客户沟通系统） 刚刚完成了 1.25 亿的 D 轮融资（谷歌风投也全面加入），在 5 年内实现了年经常性营收（ARR）5000 万美元。可以说，在 这7 年的时间里，Intercom 一直在不断取得进展，而这其中有一个非常关键的原因：Intercom团队会深刻理解每个项目要解决的问题。
你可能会觉得这句话是废话，因为每个产品经理都是这样想的啊。但是，很多产品经理也只是这样想，到具体执行的时候，他们已经离这个关键点越来越远了。接下来我要分享的就是 Intercom 的产品副总监 Paul 的经验总结，希望能给大家一些启发。

大多数产品的开发过程

下图展示的是一个非常标准的产品开发流程：

这个过程产品经理们应该非常熟悉，就是“瀑布”开发的常用流程。当然，如果你的产品团队比这种瀑布式开发更“敏捷”一些的话，过程可能是这样的：

备注：图中的循环也可能是“设计-开发-测试”的循环

接下来，让我们一起来思考一个问题：

假设在项目里一共有100个单位的可用时间。团队里所有人（产品，运营，设计师，分析师，工程师…）都投入工作，你会如何安排？

在工作中，大多数的产品开发团队初期是这样规划的：花一点点时间决定问题的优先级，界定问题（痛点），然后用更多的时间去设计解决方案，接下来，把大部分时间放在「把东西做出来」上。

但实际操作的时候，这种规划常常变成这样：

发现没有，时间基本都放到开发上了，根本没时间排优先级，明确问题，和初期的想法背道而驰。

为什么会这样？

当一个资历很高的重要人物（比如老板，大家都懂的～）突然想到一个新点子，并且想尽快实现时，团队的工作方式就会走偏——研究用户真正痛点、明确问题这一步被无限挤压。

这个重要人物的想法可能是拍脑袋“拍”出来的：坐车的时候，洗澡的时候……一旦这个想法在他心中成型了，他会觉得一刻都不能浪费，得马上去设计，马上把东西做出来！

最糟糕的情况是，一旦你的产品路线图充斥着这些“拍脑袋”的想法，产品就会变的东打一枪西打一耙，功能毫无内在联系。

曾经，Paul 在做谷歌做某个项目的时候常遇到这种“拍脑袋”的想法，而且他发现大多数被这类想法绑架的项目都是失败的。当然，这并不是对谷歌的全盘否定。

很多初创公司会失败也是因为这些“拍脑袋”的想法。这类团队的很多员工表示这就是他们的工作方式。他们会把用户研究，用户访谈这些挂在嘴上，实际工作时并不会执行。

在 Facebook 工作时，他看到的很多项目是这样的：

这比在 Google 时好一些，不过从图中你可以看出来，“开发”依然占着绝对的比重。但是，在 Intercom，他们绝对不会这么做。

Intercom 的做法

在开始设计、开发之前，他们就花费了大概 40％的时间。可以说，他们「沉迷」于确定问题优先级和明确要解决的问题。Paul 会不停地「拷问」大家的灵魂：你真的，深刻的，理解了眼前这个问题吗？同时，在 Intercom，他们也非常鼓励产品经理去公开分享、讨论要定义的问题。

为什么要这样做呢？

因为「先理解好问题、痛点，才能有好的解决方案」。

然而，大多数软件开发团队都会直接跳过问题定义的部分。

在实际操作中，Intercom 建立了几个团队来确保做好前期定义问题的阶段。

1. 客户支持团队（他们会标记与客户的每次对话，以便 PM 进行审核）；
2. 销售团队和营销团队（根据反馈建立产品/市场矩阵）；
3. 研究团队（Intercom 从一开始就投入巨资在这个团队上）；
4. 分析团队（Intercom 现在非常重视，也在加大投入）。

在测试阶段，他们会意识到「原来还没有将这个问题 / 痛点 研究透彻」，所以又会重新对问题进行界定。

说到这里，你会发现一个问题，如果大家都认同「先有理解好问题、痛点，才能有好的解决方案」这句话，为什么许多公司和团队还是会跳过界定问题这个部分呢？Paul 认为有三个重要原因：

1. 首先，理解问题本身就是一件非常难的事情。它需要你和一定数量的用户疯狂交谈，一遍又一遍，进行“巧妙”的信息挖掘；它需要你走出自己的脑袋，进入用户的脑袋，尽可能地“感同身受”。

深入了解他们的实际需求（真正的痛点）。人们经常以他们想要的解决方案形式描述他们所遇到的问题。平庸的产品团队会停在这里，不再深挖，就去做了。然而，用户的真正痛点还在他们的思想中埋藏了几层。好的产品团队则会继续前进，不断问为什么。

2. 在这个过程中你要做的工作听起来不潮也不酷。一份用户研究报告，一个新的 UI 模型，一个新的原型，你觉得哪个「酷」？很多位高权重者都喜欢看到「又新又能用」的东西，他们没时间读那些报告。在现代的互联网环境下，深度阅读和反思来获得深刻的知识并不令人兴奋，也不那么重要。

3. 前期任务（排优先级，界定问题）的工作量在产品上很难得到体现。比如你花了很长时间去研究、界定问题，希望能把产品做好，但上级领导却觉得你花了这么长时间才做出这么点东西。他们并不重视你花了多少精力研究，他们只注重最终的产量。

所以说，前期的问题界定是一项艰苦的工作，它被贴上了「无聊又不酷」的标签，从产出量来看又很难证明这部分工作的价值。

然而，对Paul 而言，这是他们做的最重要的事情之一，也是他们项目成功的最重要的因素之一。在动手去做之前，先搞清楚要解决的是什么问题，如此，才能帮助你避免做出「漂亮的废品」。

最后，希望大家都试着去改变对时间的分配，把更多的时间放到“界定问题”上。把问题界定清楚以后，你会发现，接下来的设计、开发都会变得很顺利，最终用户也会喜欢你的产品，因为你懂得他们的需求。