优秀的产品经理，会把时间花在“界定问题”上

　　在动手去做之前，先搞清楚要解决的是什么问题，如此，才能帮助你避免做出漂亮的废品。
　　今年春季，Intercom（一体化客户沟通系统）刚刚完成了1。25亿的D轮融资（谷歌风投也全面加入），在5年内实现了年经常性营收（ARR）5000万美元。
　　可以说，在这7年的时间里，Intercom一直在不断取得进展，而这其中有一个非常关键的原因：Intercom团队会深刻理解每个项目要解决的问题。
　　你可能会觉得这句话是废话，因为每个产品经理都是这样想的啊。
　　但是，很多产品经理也只是这样想，到具体执行的时候，他们已经离这个关键点越来越远了。
　　接下来我要分享的就是Intercom的产品副总监Paul的经验总结，希望能给大家一些启发。
　　一、大多数产品的开发过程
　　下图展示的是一个非常标准的产品开发流程：
　　这个过程产品经理们应该非常熟悉，就是“瀑布”开发的常用流程。当然，如果你的产品团队比这种瀑布式开发更“敏捷”一些的话，过程可能是这样的：
　　（备注：图中的循环也可能是“设计开发测试”的循环）
　　接下来，让我们一起来思考一个问题：
　　假设在项目里一共有100个单位的可用时间。团队里所有人（产品，运营，设计师，分析师，工程师）都投入工作，你会如何安排？
　　在工作中，大多数的产品开发团队初期是这样规划的：花一点点时间决定问题的优先级，界定问题（痛点），然后用更多的时间去设计解决方案，接下来，把大部分时间放在把东西做出来上。
　　但实际操作的时候，这种规划常常变成这样：
　　发现没有，时间基本都放到开发上了，根本没时间排优先级，明确问题，和初期的想法背道而驰。
　　二、为什么会这样？
　　当一个资历很高的重要人物（比如老板，大家都懂的～）突然想到一个新点子，并且想尽快实现时，团队的工作方式就会走偏研究用户真正痛点、明确问题这一步被无限挤压。
　　这个重要人物的想法可能是拍脑袋“拍”出来的：坐车的时候，洗澡的时候一旦这个想法在他心中成型了，他会觉得一刻都不能浪费，得马上去设计，马上把东西做出来！
　　最糟糕的情况是，一旦你的产品路线图充斥着这些“拍脑袋”的想法，产品就会变的东打一枪西打一耙，功能毫无内在联系。
　　曾经，Paul在做谷歌做某个项目的时候常遇到这种“拍脑袋”的想法，而且他发现大多数被这类想法绑架的项目都是失败的。当然，这并不是对谷歌的全盘否定。
　　很多初创公司会失败也是因为这些“拍脑袋”的想法。这类团队的很多员工表示这就是他们的工作方式。他们会把用户研究，用户访谈这些挂在嘴上，实际工作时并不会执行。
　　Paul在Facebook工作时，他看到的很多项目是这样的：
　　这比在Google时好一些，不过从图中你可以看出来，“开发”依然占着绝对的比重。
　　但是，在Intercom，他们绝对不会这么做。
　　三、Intercom的做法
　　在开始设计、开发之前，他们就花费了大概40的时间。可以说，他们沉迷于确定问题优先级和明确要解决的问题。Paul会不停地拷问大家的灵魂：你真的，深刻的，理解了眼前这个问题吗？同时，在Intercom，他们也非常鼓励产品经理去公开分享、讨论要定义的问题。
　　为什么要这样做呢？
　　因为先理解好问题、痛点，才能有好的解决方案。
　　然而，大多数软件开发团队都会直接跳过问题定义的部分。
　　在实际操作中，Intercom建立了几个团队来确保做好前期定义问题的阶段。
　　客户支持团队（他们会标记与客户的每次对话，以便PM进行审核）；
　　销售团队和营销团队（根据反馈建立产品市场矩阵）；
　　研究团队（Intercom从一开始就投入巨资在这个团队上）；
　　分析团队（I现在非常重视，也在加大投入）。
　　在测试阶段，他们会意识到原来还没有将这个问题痛点研究透彻，所以又会重新对问题进行界定。
　　说到这里，你会发现一个问题，如果大家都认同先有理解好问题、痛点，才能有好的解决方案这句话，为什么许多公司和团队还是会跳过界定问题这个部分呢？Paul认为有三个重要原因：
　　1。首先，理解问题本身就是一件非常难的事情。它需要你和一定数量的用户疯狂交谈，一遍又一遍，进行“巧妙”的信息挖掘；它需要你走出自己的脑袋，进入用户的脑袋，尽可能地“感同身受”。深入了解他们的实际需求（真正的痛点）。人们经常以他们想要的解决方案形式描述他们所遇到的问题。平庸的产品团队会停在这里，不再深挖，就去做了。然而，用户的真正痛点还在他们的思想中埋藏了几层。好的产品团队则会继续前进，不断问为什么。
　　2。在这个过程中你要做的工作听起来不潮也不酷。一份用户研究报告，一个新的UI模型，一个新的原型，你觉得哪个酷？很多位高权重者都喜欢看到又新又能用的东西，他们没时间读那些报告。在现代的互联网环境下，深度阅读和反思来获得深刻的知识并不令人兴奋，也不那么重要。
　　3。前期任务（排优先级，界定问题）的工作量在产品上很难得到体现。比如你花了很长时间去研究、界定问题，希望能把产品做好，但上级领导却觉得你花了这么长时间才做出这么点东西。他们并不重视你花了多少精力研究，他们只注重最终的产量。
　　所以说，前期的问题界定是一项艰苦的工作，它被贴上了无聊又不酷的标签，从产出量来看又很难证明这部分工作的价值。
　　然而，对Paul而言，这是他们做的最重要的事情之一，也是他们项目成功的最重要的因素之一。在动手去做之前，先搞清楚要解决的是什么问题，如此，才能帮助你避免做出漂亮的废品。
　　最后，希望大家都试着去改变对时间的分配，把更多的时间放到“界定问题”上。把问题界定清楚以后，你会发现，接下来的设计、开发都会变得很顺利，最终用户也会喜欢你的产品，因为你懂得他们的需求。