很多朋友应该有这样的感觉，在产品管理工作中，分析是最费脑细胞的，为啥呢，因为不管现实工作情况是啥样，我们分析出来的结果都得像那么回事，数据，图表展示就不用说了，最起码我们得对每个结论说出个子丑寅卯才行。

也就是说，对产品经理而言，所有的分析过程都必须得有一个能够自洽的逻辑来支撑我们得出结论。

通过前面的工作，我们已经得到了很多的市场/客户的问题，或许对一些产品经理来说，问题有了，该到了形成需求的时候了，而我要说的是，别急，在把问题形成需求之前，我们还有一个工作得做，这个工作就是本节课要讲到的，通过一个问题分析矩阵对得到的问题进行分析。

我们先整体上了解一下“分析市场问题”这个工作，大家看下图：

有朋友可能会有疑问，问题不就代表着需求吗，直接形成PRD了，用户故事什么的不就行了，还分析啥啊？

此话差异，那好，我先来解释一下为什么问题不能直接和需求对应。

1、问题是问题，需求是需求

为什么这么说呢？大家看下图：

这么来理解这张图中的解释呢？

我简单做个说明。

1）痛点与生俱来，只要活着，就有痛苦，痛处，至于死后有没有，我就不知道了，等我去了那边看看有没产品经理就知道了。也就是说，对于产品经理而言，痛点在于发现，但是痛点不存在彻底解决的情况，只能缓解。

2）客户的痛点会受到时间和空间的限制，而在这些时空条件下显现出来的痛点就是问题，换成我们熟悉的话，就是场景。

问题是可以解决的，但也只是解决某个时空条件（场景）下的问题，如果条件改变，那么新的问题还会出现。

3）需求是客户基于问题而产生的一种心理感受，换成我们的熟悉的话，就是用户故事，各位可以想一下用户故事的撰写格式：作为一个【角色】，想【做什么】，从而我能够【获得什么利益】。

需求是可以满足的，因为只要我们能提供适配的产品去让客户获得他们想要的利益就可以了。

举个刚发生的例子，昨天有个让众多骑友感到不太欣慰的新闻，就是张家界天门山举行的第十届天路自行车挑战赛中，有个女骑手在一弯道处不幸从悬崖跌落遇难。

我作为一个骑行爱好者，这个事件带给我的最大感受就是“安全骑行”一定要成为骑手们的第一原则，为什么这么说呢，上个月某天夜骑的时候，大意了，啥装备都没上，下巴直接和地面亲密接触，缝了四针，让一众老师傅们说我“这样的低级错误怎么也犯”。

在这个例子中，痛点是什么呢？就是“骑行安全”，但是，这个痛点是不是始终存在呢？肯定不是了，因为我不动车子就存在，那什么时候存在呢，这就和时间，空间条件有关系了，比方说夜骑，下坡，弯道，非铺装路面，而这都属于典型的“骑行场景”，对吧，这就是现实的问题，那需求又是什么呢，就是我作为一个骑行者，除了我自身不能放松骑行安全意识外，自行车这个产品本身能否有一些必要的安全功能来提升骑行的安全系数呢？这就是我的心理感受，也就是我所期望得到的安全方面的利益。

因此说，问题是问题，需求是需求，问题强调的是我们对产生环境（场景）的理解，需求强调的是我们对问题具体表现（期望利益）的探查。

2、一个问题不代表只有一个需求

这是很多产品经理容易犯的另一个错误，事实上，一个问题可以形成很多需求，比方说在上面的例子中，我提到上个月夜骑就摔了，夜骑是问题（一种骑行场景），但是，作为自行车厂家的产品经理，你能直接把夜骑的安全性当成需求去做吗？

你直接告诉技术人员，有个叫汤圆的骑友的需求是提升夜骑的安全性，你们搞一下啊，技术不抽死你才见鬼了。

规范的操作是要对这个问题所依赖的各种条件因素进行分析，然后从问题和这些条件因素的联系上再导出对应的，多样的需求。

比方说，夜骑安全可能涉及到主动和被动两种安全，主动安全在夜骑中都包括什么，怎么体现，比方说车架涂装是不是可以用在夜色中显眼的颜色，而不仅仅是为了显示酷，高端，而用常见的黑色，或者用黑色也可以，是不是还有其它的技术可以让车子在夜色中更为显眼一些？

这是主动安全，被动安全呢，除了通过搭建和骑友的社交渠道，不断强调骑行的安全意识外，是否可以在产品上也琢磨琢磨呢？比方说在车子必要的位置加一些夜骑安全提示什么的，尤其是对新手而言，这个应该更有积极意义。

你看，一个“夜骑安全”的问题，就能导出至少三个需求：

1）车架颜色是否可以既能呈现该型号车子定位，又能进一步确保夜骑安全的颜色；

2）通过搭建和骑友的社群，加强和骑友们的交流，增加骑行安全知识，提升骑友安全意识；

3）在必要位置，例如把立位置提示骑友如果夜骑，请一定加装骑行灯，如果再到位一些，可以提示加装什么样的骑行灯，比方说至少300流明的。

因此，我们不要把问题简单的和需求一对一的对应起来，换句话说，如果抛开问题产生的环境和条件因素，可能这个问题看起来就是需求，但抛开了环境条件因素，那这样的问题还有什么现实意义呢？

3、问题分析矩阵

一个问题可能会形成多个需求，这个量我估计不会太少，那是不是这就可以形成规格说明交付相关的人去做了呢？

还是不行，为什么呢，因为作为产品经理，你不能把问题的解决方案交给其它团队去做，其它团队只是实现解决方案，你是要去设计解决方案的。

这就涉及到一个很重要的技术：问题分析矩阵。大家看下图：

看起来似乎很简单，不就是个表吗？填一下的事呗。

有这样想法的朋友需要注意一下了，我认为这个表是最不好填的，为啥呢，第一，问题的量比较大，主要是每个问题都需要按照这个逻辑去思考，这算体力活啊，第二，思考的难度很大，这就好比有人指着一片空地，告诉你，我要在这里盖一栋楼，交给你了，一片空白，怎么盖啊，是不是得先完成图上作业啊，这个问题分析其实就类似于在什么都不确定的情况下去思考客户的问题怎么去解决，怎么才能比竞品或现有产品更好，怎么才能带给客户与众不同的利益。

不过好的一点是，在问题分析的过程中，先不用考虑“可行性”，你就天马行空的想就可以了，各位，这个工作的思考可是产品经理在产品管理中为数不多的让思想自由飞翔的阶段，别浪费了。

总结一下这节课的主要内容，两点：1、产品经理在问题分析中常犯的错误有哪些？2、问题的分析一定要有逻辑，别靠经验和主观想象，当然，最关键的，还是所有要分析的问题一定是现实的，也就是图2中所谓的例证。

最后呢，我们总结一下产品管理对这个工作的定义，加深一下大家对这个工作的理解和重视，大家看下图：