B端产品经理专业技能（下）

五、用户需求分析

需求定义

在某个角度而言，需求就是欲望。
用户需要某物，一句话就构成了一个用户需求。

而产品需求从用户需求而来，在收集产品需求的同时，必须了解用户在提出自己的用户需求时，是基于什么样的背景和前提。

例如，乌鸦说瓶子里的水够不着，那结合瓶口太小等原因分析，转化为产品需求就是，换一个广瓶口的瓶子。如果不了解用户需求的背景，那么可能选择将往瓶子里扔石头，给乌鸦一根吸管之类的。

需求来源

产品需求来源于用户需求、数据分析和竞品分析，用户可按照使用者身份划分为内部员工和外部客户。内部员工按职位分为领导、产品经理、产品运营、售前、商务、研发、测试、交付；外部客户则分为买方和使用方。
B端产品购买者一般并不是产品的实际使用方，领导购买产品为了实现工作效率的提升，所以产品既要满足领导的要求，又要让实际使用方足够方便好用，一般用户需求通过客户沟通获取。这里要强调一个概念，叫做“核心用户群”，这个群体里聚集着你的产品的核心用户，比如小米手机的核心用户群就是那些混迹论坛的发烧友，腾讯动漫的核心用户群就是那些热爱动漫的早期APP启动阶段的种子用户，而在B端，核心用户就是你的甲方“爸爸”们，那些出钱多、订单量大的大客户，这些客户的需求是要被优先满足的，因为他们除了本身具有大订单外，还往往能带动周边区域的销售。对于这些大客户，可以专门维护几个反馈群进行售后支持和建议收集，同时建立一个产品需求池来记录需求，后续根据需求筛选和项目具体情况，甄别出真需求后规划进版本特性。
内部员工也是一款产品的相关联系人，产品经理、研发、测试对产品的建议，领导基于对市场把握提出的建议，产品运营、售前、商务和交付在交付和推广过程中提出的建议。
数据分析得来的需求往往是来源于市场变化，通过大数据分析客户关注点变化情况确定市场方向。而竞品分析得到的需求一般是无法复用的。to B也就是to Business，产品面向企业用户，不同企业用户需求都不一样，侧重点不同，产品复用程度低，所以竞品分析得到的用户需求往往要结合使用场景筛选。

需求往往是源源不断的，当挖掘不到需求，那产品将很难存活。

需求分类

如上所述，需求来源众多，那么在有限的产品迭代周期内，如何进行需求筛选。
并非所有的用户需求都是真需求，很多需求是伪需求，那些伪需求纯属个人建议但无法给实际用户带来收益的。

我们按照需求的紧急程度和重要程度会分为四类：

重要且紧急
重要不紧急
不重要但紧急
不重要也不紧急

重要且紧急的需求也就是我们俗称的强需求或刚需，而不重要也不紧急的需求则称为弱需求。

也可以按照使用次数分为高频需求和低频需求。

按照KANO模型将需求分为五种：

兴奋型需求（用户意想不到的需求，不提供用户满意度不会下降，但提供客用户满意度会大幅提升）
期望型需求（不提供该需求，用户满意度会下降，有则会提升）
基本型需求（必备，不提供该需求，用户满意度大幅降低）
无差异型需求（提不提供该需求，没有差异）
反向需求（提供了该类需求，用户满意度反降不升）

需求排序

强需求肯定要优于弱需求，高频需求优于低频需求，而按照重要程度和紧急程度而言，重要且紧急>重要不紧急>紧急但不重要>不紧急也不重要。

而KANO模型的五种需求中，基本型需求必须满足，期望型需求其次，再是兴奋型需求，无差异和反向需求一般不在需求范围中。
在完成需求排序后，产品经理将本次迭代的需求整理成需求清单，并进行优先级排序，组织评审小组进行内部评审，评审通过的需求将进行开发，而评审未通过的需求一般进入产品需求池，等待下次版本迭代。

内部评审一般会分为好几轮，如果在评审过程中一个需求点耗费过多时间，请注意立刻终止该需求讲解，待下轮评审继续商讨解决方案，注意评审进度不要浪费时间。

内部需求评审完成后，产品经理将组织参与迭代的所有研发、测试、项目经理等人员进行全员需求讲解，如一次全员讲解完成后，部分内容待线下确认，则确认后需连同全员需求评审的所有内容进行邮件通知，全员需求讲解完成后需要发邮件进行定稿通知，研发和测试人员以定稿邮件内的需求清单为准进行需求开发和测试，如在开发和测试过程中有需求变更，则产品经理需要按流程发起需求变更，登记需求变更单，由项目经理组织相关人员对该需求进行分类和评审，评审通过的需求加入研发需求池，新增的需求也需要发邮件通知全员。最后是需求验收，在需求完成开发和测试后，产品经理在发布前需要进行需求验收，这个需求不单包括功能验收，还会有性能、UI、交互等。