6000字长文分析产品经理必懂的需求分析，看这一篇就够了为什么要说普通话

如果有人问我产品经理最重要的能力之一是什么，「需求分析」一定在其中，而且非常重要。需求分析作为产品经理的必备技能之一，为什么这么重要？

从需求的生命周期来看，需求的产生、分析、设计、开发、测试、上线、反馈等一系列关键环节，需求需求处在上游环节，需求分析的正确、合理与否，直接影响到产品的设计、开发等环节，甚至决定一个项目或产品的成败。偏离了用户的核心需求的产品，注定无法为用户带来价值，更无法产生相应的商业价值。

尽管需求分析这么重要，但是对于大多数产品经理，尤其是产品经验较少的产品经理而言，更多的只是需求的搬运工，并没有形成自己的一套需求分析的方法或是模型。

以下就详细谈谈我在实际工作中常用的需求分析的方法，希望能对你有帮助。

01 需求的来源

谈需求分析之前，我们先看下需求的初始环节——需求的来源。这是产品经理开展工作的来源和基础，没有需求，就没有需求分析。

实际工作中，不论是规模大小还是不同行业的公司，需求的来源都有共性，需求来源我以「不同主体的维度」进行区分：

1、老板的需求；

2、用户的需求；

3、市场/运营/技术等业务或协作部门的需求；

4、产品经理自身的需求（竞品分析、需求调研、数据分析等）；

5、......

还有一些产品经理按主观需求和客观需求划分、按内部需求和外部需求划分等维度进行需求来的划分，思路都大同小异，核心目的都是对需求的来源进行标记、记录。

此外，不同的产品经理在级别、经验和工作职责等方面存在差异，因此获取需求的来源也是不一样的。

1、对于产品助理、初级产品而言：

需求主要来源于领导，用户最直接的需求。基于现有需求开展核心工作。

2、对于高级产品、产品总监：

需求主要来源于市场行情分析与发展的趋势、用户的需求挖掘、企业的资源综合给出适合产品发展方案。

3、对于老板、CEO等：

需求主要来源于公司定位与发展规划、商业运作模式等。

02 如何定义需求

需求分析的思路类似我们处理日常问题的基本思路：

1、是什么

2、为什么

3、怎么办

迁移到需求分析上的思路就是：

1、定义需求

2、分析原因/需求

3、确定产品方案

定义需求

每个产品经理每天都在做需求记录、设计原型、需求优先级划分这些基本工作，但这些工作的基于一个大的前提，那就是需求分析。

相应的，用户需求和产品需求之间的关系也更为清晰，用户需求经过「需求分析」之后，从而转化为产品需求。

需求分析之前还有一个重要的问题产品经理必须明确：什么是需求？换句话说就是我们该如何定义需求？

需求是用户在一定场景下产生的未被解决的问题或需要。

一个完整的需求至少包含了3个核心要素：

1、用户

目标用户很好理解，我们定义的产品就是为了解决一部分人的问题，如果遇到问题的用户根本不是我们的目标用户群或者只是极个别用户才存在这种问题，那就需要慎重考虑了。

这里用户是指为解决某个场景问题的「一类用户」。可以理解为：B端产品中的用户角色；C端产品中的用户画像。

2、场景

场景指的是有实际场景，用户切实会遇到的问题，而不是我们主观臆测用户可能会有这样的场景，可能会需要。

3、问题/需要

问题/需要指的是问题是需要被解决的，包括解决问题的能力和意愿。

03 如何进行需求分析

知道什么是需求后，下一步的重点就是去分析需求。下图为需求分析漏斗模型：

需求分析主要通过运用各种分析方法，以“实现用户正确的需求”为原则，对于用户提出的需求进行严格的分析、甄别，去洞悉用户需求的本质，从而提供相应的产品方案。

常用的方法有以下几种：

一、用户-场景-问题

这种方法是根据需求的定义演变来的。这种方法可以描述为：用户在一定场景遇到什么问题？回到需求的本质，进行用户-场景-问题进行分析。

在实际工作中，接收到需求后，产品经理一定要多问一句：是什么用户在什么场景遇到什么问题？好记性不如烂笔头，一定要及时记录需求的背景。如果还有问题一定要多问几个为什么！持续的问下去，一定会得到你想要的答案。

通过具体的场景去分析用户需求的本质，为此，产品经理必须十分了解所在业务的用户和场景。

二、需求层次法

大家可能都听过马斯洛需求7层次理论，对应的用户在不同场景的7种底层需求。参考这种思路，在需求分析时，可以抽象为3种需求层次。

1、表层需求：观点和方案

通常用户表达的需求只是一种观点或方案。通常表述为：我想要增加一个***功能、我想要去除一下***页面的展示等

得到的这种用户需求，经常并非实际的用户需求。对于表层需求，可以对用户的需求进行追问，多问几个为什么，直到问出该问题的本质需求。

做产品的这些年，有很多用户教过我怎么做产品，经常会直接提出要做***功能或者优化***页面，他们提出的需求大多数都是存在的，但提出的产品方案并不合理，用户需求到产品需求的分析结果，是产品经理的重要价值。

比如：之前一个用户提出在收银支付页面，针对门店的某个员工不可用户帮助会员进行签到扣课。

细问下原因，是因为该员工为了多赚取课时费，和会员商量扣除时间卡次数赚取课时费后，和该会员进行分摊。

截止到门店发现这个问题时，这种问题已经持续了2个月未被发现。

这里有至少有以下几个重要问题：

1）需不需要对该员工进行扣课权限管理；如何控制；其他员工如果也发生类似情况如何处理；

2）需不需要对时间卡的扣次进行限制；如何限制；其他卡项如果也发生类似情况如何处理；

3）如果存在异常行为，门店管理人员应第一时间知晓，避免更大损失。

后期产品的方案：

1）在权限控制中，针对不同用户进行扣课的权限控制。

2）针对时间卡、计次卡等，不同卡项新增一定周期内扣课的最大次数限制。

3）新增卡项扣卡预警：统一卡项一定周期内扣除次数超过限制后，触发预警通知管理人员。

你看，如果一开始按照用户的需求去处理需求，一定解决不了用户的问题。

2、深层需求：目标和动机

深层就是挖掘用户这么做是想达成什么目标，目标的背后一定是有动机的存在，无论这个动机在产品看来是否合理。

上面的例子中，门店需求背后的目标就是杜绝这种问题的发生，及发生这种问题后能第一时间知晓并处理，避免更大的损失。

3、人性：人性和价值观

深层需求的背后一定有相应的人性存在。人性是基于我们作为人类与生俱来的共同特点：七宗罪、贪嗔痴、马斯洛需求7层次理论等。

这里以我在门店预约业务中做过的一个需求为例，具体说明需求层次的应用：

在门店预约业务中，门店制定课表后，用户通过预约课程的方式进行上课。课程一般有人数的限制，当预约名额满额后，会员不可再预约该课程。

1）针对这一问题，门店提出一个需求：希望增加一个关注的功能，当有用户预约取消时，用户如果关注了该节课程，便可及时收到推送消息，并进行及时预约。

这里用户提出希望「增加一个关注的功能」，就是一个具体的产品方案，这个就需要产品经理进行运用需求层次进行分析，然后多问几个为什么，一致到该问题的本质需求，然后提出具体的解决方案。

2）用户提出希望「增加一个关注的功能」的深层需求是希望有人预约取消后，希望上该节课的会员能及时公平的预约，提升用户的预约体验，同时提升耗卡率或增加收入。

3）相应的人性方面，从会员的角度来说，通过系统方案实现「关注」功能，解决了“懒”的问题，不想去频繁手动操作预约和取消预约等操作；从门店的角度来说，解决了“懒”、“贪”的问题，提升耗卡率或增加营业额。

4）但「关注」的功能并不能解决用户的需求。

一是从体验上来说，仍需要用户收到取消预约消息后，手动进行操作预约；

一是从功能上来说，有一定的缺陷。关注功能并不能解决预约的公平问题。用户A先关注了课程空位消息，B后关注了课程空位消息，但B很可能比A更早的预约该课程。

5）为解决体验和需求功能缺陷这两个问题，产品方案最终确定了「排队功能」：系统可根据用户排队的先后顺序进行自动候补预约，解决了公平和效率的问题。

三、拆解需求法

积极层面

通过对业务的拆解，拆解出怎么做对用户来讲可以产生更积极的影响。

否定层面

通过对业务的拆解，拆解出不做什么对用户来讲可以产生更积极的影响。

转移

不直接单独解决当前用户的问题，是不是可以通过替代、转移的方式去满足用户的需求。

拆解

把当前问题刨根问底的拆，挖掘更多的可能性、直至找到问题本质。

脑洞

通过以上的维度进行问题拆解后，可能还会有遗漏的场景，就需要我们进行头脑风暴，尽可能发散思维和脑洞。

04 产品优先级及方案

洞悉需求本质原因后，产品经理下一步要做的就是产品方案，我把产品方案拆分为3个环节：要不要做？什么时候做？怎么做？

一、要不要做：解决的是需求过滤问题。

用户需求分析完成后转化为产品需求，有2种情况：做和不做。不做也是一种产品方案，有时候甚至比做还要重要，但前提是「不做」是需求分析的结果。

一个产品需求要不要做，可以通过以下3个纬度进行分析：

1、用户角度

需求是「用户」的需求，从需求提出者的角度思考，该产品需求的实现会给用户带来的价值。如：解决了问题一定场景问题、提升了用户的操作效率、提升了一定程度的用户体验等。

也可从反面进行思考：如不做该需求给用户带来什么样的损失或不便。

2、产品角度

从产品角度思考，该产品需求会给产品带来的价值。如：丰富了产品线、提升了产品的满意度、提升了产品的性能等。

3、商业化角度

从产品角度思考，该产品需求会给商业化带来的价值。如：优化或丰富了产品的商业模式、产生了新的盈利模式等。

二、什么时候做：解决的是需求优先级的问题。

以上列举的3种产品经理在日常工作中经常用到的产品需求优先级排序的方法。

1、KANO模型

KANO模型可参考：

兴奋型属性：是用户意想不到的需求，表现为用户满意度和需求实现及优化程度呈现指数函数关系，如果不提供此需求，用户满意度不会降低，若提供此需求，而且用户满意度随着需求实现及优化程度的增加会有很大提升;

期望型属性：用户满意度和需求实现程度及优化程度呈线性相关性，即随着当提供此及优化需求，用户满意度会提升，当不提供此需求，用户满意度会降低;

无差异属性：用户满意度和需求实现及优化程度不相关，即无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意;

基本型属性：当不提供此需求，用户满意度会大幅降低，但提供了需求后，用户满意度不会随着此需求的优化而提升。

反向属性：用户完全没有此需求，若提供此需求，用户满意度反而会下降;

所以，产品需求的优先级可以排序为：基本型需求＞期望型需求＞兴奋型需求。

2、四象限法则

四象限法则可参考下图：

四象限法则以重要性和紧急性为维度进行需求的优先级的拆分，其中重要性＞ 紧急性。其核心是：合理的安排要做事情的次序。

对于如何合理的安排要做事情的次序，不同的业务和产品可根据以下维度参考划分：

1）是否为核心业务

核心功能涉及用户的使用或体验糟糕，其重要性不言而喻，需要优先处理。

2）是否涉及到钱

不论是用户的钱还是企业的钱，对于涉及到的钱财的风险一定要及时解决。

我曾经做的一个产品就出现过一次这种问题。针对用户营销的秒杀活动，因为没有单人最大购买次数存在bug，导致用户以秒杀价多次购买了同一个卡项。

恰巧又是在周五晚上才发现的bug，问题短时间很难去复现加上缺少日志。我们先建议门店晚上暂停了活动，等周六早上开发赶到公司再做紧急处理。

因为迟迟没有复现问题，后来开发直接查代码逻辑，大概花了2个小时查出问题后，并修复bug再紧急发版。

虽然门店的损失较小，带给我们的教训却很深刻。

涉及到钱的问题都不是小事，一定要优先解决。

产品的测试、验收环节，对于可能的风险一定要严格测试。

所以，涉及到钱的问题，一定要紧急解决，因为有时间损失的可能不仅是钱，还可能是用户。

3）是否在产品规划路线

产品设计初期及不断迭代的过程中一定要有产品规划路线，产品规划路线制定的目的是为了保证产品的大方向。对于在产品规划路线上的需求，一般都很重要，也需要根据业务的紧急性考虑需求的优先级问题。

三、ICE法则

ICE法则也是相对比较严谨的需求优先级排序的方案，通过对需求进行几个维度的总分数多少进行求优先级划分。

ICE法则中的具体维度为：

I（Impact）：影响范围

主要从需求能影响的到用户及现有产品功能范围进行分析估算分值。

C（confidence）：对上线效果的自信程度评估

需求上线后能给用户及公司带来的价值维度估算分值。如：提升用户的操作效率、提升用户体验、丰富公司的产品线等。

E（ease）：开发难易程度评估

主要是从需求的工作量多少及开发的实现难度进行分析估算分值。

采用ICE法则进行需求排序时可参考以下表格形式：

三、怎么做：解决的是具体产品方案的问题。

这里着重强调下关于新需求，对竞品分析的必要和重要性。

互联网产品发展到今天，各个细分行业基本都有相应的产品去满足用户的需求，绝大多数的需求都能找到相应的竞品/功能去参考，如果没有，很可能是你还没找到。

竞品分析是产品经理进行产品设计的必经之路，分析竞品功能，能很大程度上填补产品经理设计时的脑洞大开。当你能想到的功能，市场上的产品大概率已经有相应的功能且已经趋向标准化了，产品经理一定要重视竞品的价值，你走过的路。犯过的错，很大概率别的产品已经走过。

竞品分析绝不是「抄作业」，进行竞品分析时，仍需重点考虑以下几个方面：

（1）找相对成熟的竞品。

每个行业的龙头企业或产品基本都有，相对成熟的竞品在市场上久经考验，产品功能的完善度有一定保证，覆盖的用户场景较多，能相对保证功能的完整性。

（2）找对该功能进行对此迭代的竞品。

对该功能进行对此迭代的竞品，很大程度上能保证功能的方向性。在竞品的历史迭代中可看到产品记录，找到相应功能的迭代方向与迭代点，尤其对于功能的bug修复和优化，对产品的设计有很大的参考价值和启发意义。

（3）分析竞品的功能逻辑及背后的设计思路。

这点是最费时间，但收益最大的部分。需要注意的是，竞品的功能并非都是合理的，很可能并不具有参考价值，所以一定要尽可能的了解竞品功能背后的设计思路。

在收集分析完需求后，我在每设计一个功能前，都会习惯性的思考竞品会如何处理？然后再去找竞品去分析相应的功能。这并非是偷懒的做法，每次分析完竞品后再去结合业务去设计功能，站在前人的肩膀上，总能给我新的想法，而且通过对竞品的分析能在很大程度上保证功能设计的合理性，功能层面的需求至少的存在的，只是体验的差距问题：产品决定功能，交互完善体验。

执行方案、获得反馈

执行方案主要涉及到具体的执行和沟通，与需求分析环节基本独立且可讲述的东西很多，之后会单独写一篇关于执行产品方案有关的内容。

获得反馈可以理解为需求的来源，获得的反馈可以从定义需求、分析原因、拿出方案中任意一个环节作为需求的初始点解决问题。

05 最后

最后我把这些方法整理成了一张图，分享给你，希望对你有用。

需求分析是每个产品经理必备的基本能力，希望每个产品经理都能结合工作实际，拥有自己的一套需求分析的方法或模型，不仅可以提升自己的能力和专业度，更能更好的解决问题。

-END-