作为产品经理，需求分析是再常见不过了。本文分析总结需求来源以及如何做好需求分析这件事，希望对你有所帮助。

产品笔记第五篇，返璞归真，回到产品经理的生命线——需求上来。

事实上我觉得需求分析是贯穿整个产品的生命周期的，我个人把单次需求分析分为三个大的阶段：需求来源–需求真伪辨别–需求优先级排序。

一、需求来源

首先，你必须收集得到需求。这一步一般大家都比较熟悉，需求来源分外部和内部两类途径。

1. 外部途径主要有：

• 用户。
• 竞品。
• 政策/行业标准等。对一些政策相关性较高的产品来说尤为重要。

在这里着重提一下“竞品”。在实际工作中除了直接竞品外，在一些“迫不得已”的情况下也可以从一些非直接的竞品身上需求帮助，以我上一篇在《经验总结 | G端产品，很容易G》中的经验为例：

例如我们要做一个政府给企业下发能耗指标和碳配额的功能，我参考了财务系统中的预算管理模块，最终我们设计了用能预算模块。也就是说，有一些产品在功能本身上讲是不同的，但是在流程和目标上是有相似性的，可以从这个角度进行“迁移”。

2. 内部途径主要有：

• 开发、运营、bug修复等。
• 大老板。

这里展开讲一下老板的需求。

（1）首先，对老板的需求要有一定的尊重。尽管在工作中我也常常觉得老板的需求缺乏一定的落地性，但老板之所以是老板，在商业方面一定是有他敏锐的嗅觉的，这一点产品经理还是要给予充分的尊重。

（2）其次，对老板的需求一定要有充足的交流。通过多次提问不断逼近老板的真实需求，解决方案也要多次展开确认；实现这个需求的成本，以及风险或是困难，一定要提前和老板说明。哪怕需求真的没有可行性，你所要做的是把一切告知给老板，由他来决策。

（3）最后，在把老板的需求传达给开发的时候要注意一下：有时面对不靠谱的需求，我们会忍不住直接跟开发说“老板要的”，虽然这样做确实可以减少很多沟通成本，但是也会在无形中削弱产品经理的信誉和权威（作为协作链的上游，保持一定的权威性对产品经理是很重要的）。

因此我们需要把老板的需求价值合理“包装”一下，有时候我们会更习惯和开发们交流功能性需求的价值，其实商业、战略性方面的需求价值也可以传达给开发们。

二、需求真伪辨别

需求来源说完，我们说说需求的真伪辨别。初步收集到了需求别高兴得太早，先问“是不是真的如此”，才能再想“怎么做”。

需求真伪辨别的角度我一般分为以下几类：

• 臆想 or 源于用户。产品经理臆想、臆测需求的情况其实很常见。
• 客观实际的问题/场景 or 问题的表象/用户的一个解决方案。经典的“我想要一匹马”的诉求。
• 场景频率低 or 高。如果一个需求确实存在但其场景频率极低的话，个人认为也可以看作一种“伪需求”。
• 如果需求源于竞品，竞品和我们产品及用户的定位一样吗？

三、需求优先级排序

在需求优先级的学习中，我最先接触到的是Kano模型，直到现在我也很喜欢这个模型对需求的分类。但在实际的工作中我们可能没办法在用户满意度分析上花费大量时间，因此我也摸索出了自己的一些心得。

1. 从大的功能模块的角度去划分

这一条适用的场景更多是0-1的过程中，我们需要从比较宏观的角度对功能模块进行划分，排一排大的功能模块的先后。

（1）首先，要做的是特质性功能。什么是特质性功能，是我们的产品之所以可以叫这个名字，是需要满足一些基本特质的。比如，我们做的能耗监管平台，那么最基本的，我们一定要有能耗采集统计。别的功能抛开不说，如果没有“能耗采集统计”功能，我们的产品就不配称为“能耗监管平台”。这就是特质性功能。

再简单点说，看一看同类产品，它们都有的功能差不多也是这类产品的特质性功能。

（2）其次，要做的是特色性功能、竞争性优势。特质性功能让我们的产品满足这类产品的一个“准入门槛”，下一步要脱颖而出一定要做特色性功能。之所以在众多同类产品中要选择我们，因为我们有特色，有差异化优势。以我们的平台举例，我们的差异化就是不止于数据统计，更着眼于通过数据分析将数据转化为用户可使用的结论和决策依据。因此在能耗采集统计模块做完之后要上的是能耗分析模块。

（3）最后，要做的是横向扩展或纵向深化的功能。比如后续我们平台又迭代了节能考核、综合评价等模块。

2. 一些基本的综合性原则

当然，以上所说的更适用于0-1的大功能模块排序，在具体的需求点上我们有一些基本原则可以综合性考量：

• 有重要影响的bug修复。一般优先级较高。
• 功能逻辑上的依赖关系决定的先后顺序。需要在设计之初从系统的角度考虑。
• 性价比考虑。性价比=价值/开发成本。本身带来的收益很低，开发成本却很大，那这个需求可以往后稍一稍了。
• 先有再完。一个需求先以基本方式实现，再逐渐完善。比如我们采集能耗数据，先实现的是手工填报，后面再迭代物联网采集。

OK，以上就是本篇文章的内容。那么，下一篇再见啦。