【干货】深度解读产品需求的分析方法

什么是真实的需求

首先还原一个场景，业务部门提交一份需求清单：“我要在这里增加一个搜索功能，能搜索XX”“我希望增加一个页面，上面有XX功能”等。如果产品经理就按业务方提供的功能需求进入研发环节的话，最终的结果往往不理想。那到底什么才是真实的需求呢？

下面的广告词，可以感受一下对需求的理解。“你强调动力，其实是想要跑赢时间。你觉得安静很重要，其实是偶尔需要回到个人世界。你说空间要大，其实是你喜欢一家人挤在一起。你说储物要多，其实是要放下每个人的爱好。”

所谓真实的需求，往往是需求方的某种诉求、某个痛点、想要完成的事情、想要实现的目标，这些才是真正的需求。原来的功能清单里很多伪需求，并不是最优解，产品经理需要挖掘出原始需求。而作为产品专家，根据真实需求去设计才能做出真正适用的功能去满足他。毕竟，根据原始需求设计产品是产品经理的本职。

所以这里也就引出了另外一个问题：如何引导业务方表达真实诉求。如果是传统书面的需求提交，结果往往就是跟之前举的例子一样，得到的大部分是一堆功能清单。产品经理应该通过引导性的提问，明白为什么业务方会提这个功能点。原因一定是目前有什么事情做不了或做起来很痛苦。千万要把他的真实需求记下来，做产品设计的时候能够对照需求看自己有没有偏离方向。

如何获取需求

产品需求的来源，主要有四方面：

1、基于对自身产品的理解。产品经理作为产品的owner，相信没有其他人会比你对这个产品更为理解。合格的产品经理，应该深刻理解自己的产品所要解决的核心问题、自己熟悉面向的用户群体、目前产品的完善程度和当前产品的短板在哪里。所以每个产品经理根据自身对产品推进的进度，要有自己的一份需求清单。

2、基于数据。阅读数据也是产品经理用来挖掘需求的一个重要手段，产品设计初期把数据埋点做完善，上线之后可以通过观察数据还原用户的使用场景，并发现缺陷和短板所在。数据出现突然的波动和流程埋点中突然出现的转化下降等情况都应该去认真分析原因。但是需要特别注意一点，很多时候片面的数据是具有误导性的。在做数据分析之前，要尽量保持客观，不要先假设再验证，而是尽量多的覆盖需要调查的场景数据，从而得出全面真实的结论。

3、基于用户的反馈。接收第一手使用产品的用户的反馈，也是新需求的重要来源。要创造一些机会，从旁观者的角度去观察用户，也许你会得到一些数据反馈里发现不了的事情。比如说你的产品是一个扳手，从数据上来看似乎用户挺喜欢用的，但是当你去观察用户使用场景的时候，才发现原来用户都在用它锤钉子。所以用户的真实需求是锤钉子，而你的扳手只是恰巧能用罢了。这时候你才知道，原来你应该打造一把好锤子，而不是去改进你的扳手了。

4、基于其他业务部门的反馈。这个就很好理解了，而业务部门在运营内容和产品的时候，往往会跟用户产生大量的交流，他们属于跟用户最熟悉的人群，所以也会产出很多需求。而他们的需求一般会分为两部分，一部分就是来自用户反馈和日常运营过程中观察到的用户需求，比如用户需要某个运营频道的扩展，用户期望搜索功能更加强大和方便之类的；另一部分是基于业务方的日常操作，需要提升运营效率的需求，也就是对运营支撑平台的完善。

需求的优先级制定

这个时候，每个产品经理手上都已经有一大堆大大小小的需求了，但是不论公司大小，研发资源总是有限的，所以如何给这些需求安排优先级就是产品最重要的工作了，毕竟这个环节决定了一家公司的节奏甚至是创业团队的生死。怎么给手头上的需求定优先级，很难有放到哪里都适用的标准，我只能简单说说我自己是怎么做的：按紧急和重要的时间四象限分布是最基础的方法，但是怎么判断重要和紧急程度，就要结合项目具体的情况了。

我个人大概会按以下三个方面来综合考虑：

1、根据产品线的roadmap。每个产品的推进路线必然是有综合规划的，根据项目当前所处的阶段和实际业务的发展而确定的产品路线图，是我制定产品需求优先级的第一考量。

2、符合近期公司的核心目标。根据业务的推动，公司和项目在各个阶段都会有一些冲刺目标，可能是产品方面的，可能是业务部门的，为了实现这些目标，产品规划方面需要满足哪些需求自然也就变成紧急和重要的事情了。

3.自身负责产品线的需求优先级。一般来说，每个产品经理都会有自己负责的一个领域，也许是按用户群体分，也许是按服务部门分，这些产品线的需求方也会有自己的需求优先级。

根据以上三个方面的考量，加上对功能需求复杂程度的评估，再结合实际的研发资源和研发排期，基本上就可以产出一个合理的产品需求优先级清单了。

需求的落地和效果跟进

最后说几点需求落地过程中需要注意的地方：

1、设计恰当的功能点去满足需求。说起来根据需求设计功能是产品的本职，但如何做到恰当的程度还是需要历练的。需求从根本上来说，都是为了满足一个目标，做成一件事情，而到达这个目标的路径并不是唯一的。资源（不管是时间还是人）永远都是有限的，每个细节都完美的方案，在有限的资源面前就不再是完美的方案。这时候就要求产品经理能对方案进行拆解，知道什么功能是必须的，什么功能是锦上添花，哪些交互是要追求细节的，而哪些交互是可以从简的。特别是对于创业项目，MVP（最小可行产品）原则应该贯彻整个产品迭代过程。

2、保证最后的交付质量。因为有QA部门的存在，这里比较容易被忽视。但产品经理作为产品的owner，应该想尽办法去保证最后产品的交付质量。要做到这一点，仅仅靠最后的验收工作是不够的，或者说，已经来不及了。从需求分析开始到项目上线的整个过程中，每个细节里产品经理都应该去保证最后的交付质量。比如说产品肯定知道某个功能需求里，什么地方的逻辑比较复杂，很容易出错。所以在自己讲解需求和文档中，都要把这些强调出来，让经手的研发和测试都深刻理解里面的逻辑，各种异常状态等。比如说产品知道某个页面的一个按钮的点击率对整个产品功能的意义重大，那么就要传达给ued“这个按钮很重要，我希望用户能够点击”。类似的例子有很多，目的就是通过各种手段去让大家理解需求，从而符合你的预期。

3.设计好数据埋点。这也是容易遗漏的地方，特别是在产品初期人手有限的情况下。但对于一个需要持续优化的产品来说，如何用数据证明这个功能需求的效果，本身就是产品经理设计方案的时候必须考虑的一方面。每个重要的功能都应该有清晰的数据模型去验证，做好了埋点，才能从数据中去挖掘问题，进而进行后续的优化。