需求分析一直是产品经理日常工作中的重要工作。本文作者根据自己多年经验，总结了7个分析过程中的需要注意的点，希望可以帮到大家。

用户提出的需求，通常是解决方案，但这并非是我们需要的需求。真实的需求应该是用户在场景下，遇到的无法解决的问题。

我们要靠近用户，但也不能完全相信用户，而要通过不断地询问、深入地思考、持续地研究，挖掘到真实场景。基于场景，设计方案，解决用户真实需求。

因此，能否挖掘到真实需求，正确地分析需求，也是判断产品经理是否合格的标准之一。

一、尽可能收集需求

需求来源渠道很多，但由于资源有限，每个版本释放的需求也是有限的，所以我们通常会建立需求池，来收集和释放需求。

但有同学认为，只有会做的需求，才需要收集，如果做不了或短期内不做的需求，是可以直接拒绝，不需要放进需求池的。

持续地收集需求，确实会导致需求池越来越臃肿，不利于需求池的管理。但我认为，只要是用户在真实场景下遇到问题，都是要收集的需求。

因为很多时候决定需求做不做，是基于当前的产品定位、业务目标、版本规划、技术成本来决定的。

可是这些决定因素不是一成不变，而是动态变化的。只要是真实需求，就有落地的机会，这些机会，往往能帮产品弯道超车。

21年，我们收到过一条用户反馈——能否通过导入图片，把手机相册里的进货单直接录入到软件中。

当时一听，我就知道做不了。先不说技术上，图片当时能否精准识别到文字；就算识别到文字，软件也不知道该如何匹配哪个品类下的sku。更不用说还有些异常场景，如多余的内容如何去除、单据上有系统没有的商品如何处理等。

但当时我们收到这个需求，并没有立刻拒绝，而是把它录到需求池。因为把进货单录入系统麻烦，需要耗费大量时间，是真实且有价值的需求。

直到去年，国内ai大模型百花齐放后，我们尝试用ai的语义识别去解决这个场景的问题，才把这个需求落了地。上线后，我们也获得较好的效果，获得了用户的称赞，也代表团队获得了公司级别的产品创新奖，还被各大竞品争相模仿。

当初我们并没有放弃需求，所以我们才拥有了超越同行的机会。

所以，拒绝需求标准应该只有一个——缺乏真实的场景的需求。因此，不论需求来自于谁，不论是单个用户的个性化需求，还是不符合产品当前定位的需求，只有有真实的用户场景和需要，我们都应当收集起来。

二、尽量少做需求

做需求也存在“二八原则”，20%的功能可以满足80%的用户需求。同理，上线的 80% 需求，最多也只能满足 20% 的用户。如果我们经常复盘的话，我们就会发现，很多需求，不做其实也没啥影响。

产品经理的思维，是很活跃的，脑子里经常会蹦出需求。我们也很会找借口，时常假借业务需要之手，做了很多本可以不做的需求，有时甚至为了解决研发成本，反向逼出需求，简直是为了做需求而做需求。

但这两年，我逐渐发现，随着产品功能越来越多，操作也越来越复杂了，用户满意度在逐渐下降，这是产品口碑下降的前兆。

因此，我们在做需求，要尽量谨慎一些，少才是多。

需求上线后，一般是不可逆的，不论是对用户还是对产品本身。因为需求上线后，很难下掉。

一个是，要下掉一个功能，往往要多次评估，从数据和业务层反复确认，是否真的没价值了，甚至还要各个层级的领导书面确认后，才能下掉。

再一个是，不论多小的需求，只要上了，就会有用户在用。只要下掉就会对在用的人造成影响。

所以，与其做一些未来会下掉的需求，还不如不做，不仅节约资源，还保护了产品口碑。

最后，团队内部很多需求，经常没有想明白到底要什么就提需求。我们作为产品责任人，要加以限制，否则用户迟早会抛弃我们。

我们业务，之前为了用户增长，提出说要个分享裂变功能，加上当时pdd的分享砍一刀获得了快速的用户增长，所以他们也想试一试。

后来花了两个半月开发的分享裂变功能，数据是一塌糊涂。直到三个月后，我们正式复盘才发现，功能遭到了用户一致抵制。

商户反馈，因为有这个功能，商户更不愿意推荐产品给别人了，推荐出去反而让别人觉得自己是因为贪小便宜才推荐的。让本可以通过口碑获得增长的基本流量渠道，还收到了影响。

可见，C端裂变策略大概率不适合B端业务，业务提出的试一试，可能就会对用户造成不可逆的伤害

所以，需求能不能做的唯一标准是，把需求想清楚，没想清楚就不做，不做就不会错，也不浪费资源。

作为产品的负责人，不要为了迎合各方需要，把自己负责的产品做成了四不像。

三、需求提的人多就要做吗

同一个需求提的人多，只说明这个场景下的问题相对严重，应当引起我们的重视，但不能是用户说什么，我们就做什么，更不能因为提的人多，优先级就高，就需要马上落地。

在多人线下访谈或集体调研时，我曾遇到多个客户同时提出类似的需求，在那个情景下，会觉得说“会后再评估”有点敷衍。也会认为领导、销售、客户代表，都希望你把这个需求答应下来。

但用户提的需求，通常都是基于他们的认知，如竞品、类似产品有过类似功能提出的方案。还有不少缺乏真实场景的需求，是用户臆想或脑补出来的场景。甚至在群体环境的影响下，个体缺乏分析能力，从而盲从别人的言论做出的附和之词。

产品经理的专业性，体现在对需求的分析上。合格的产品经理需要根据用户反馈，挖掘背后的场景，再结合产品定位、产品框架、公司和团队的价值等综合因素，权衡利弊后才能设计合适的产品方案。

如果全部照着用户反馈做需求，那就真成了人人都是产品经理，产品也永远不会有创新空间。真正的产品创新，只有在在尽可能地靠近用户，理解用户后做到的，而不是盲目地跟在用户的屁股后面，用户说什么，我们就做什么，更不能因为提的人多，就要做。

四、不要讨论出来的需求

在需求内审讨论会的时候，我们会讨论需求场景和微调方案。但遇到有些需求无法推进时，大家会为了证明自己是对的，引导大家共同去讨论、推演需求。

人是情感的动物，我们在谈恋爱时，容易做一些感动自己的“傻”事。讨论需求也是，我们在特定的空间，特定的人在情境下影响下，很容易陷入需求自嗨阶段。

大家有没有试过，在一个会上，有人提到个点子，然后推理联想讨论，在脑海中就可以构建出庞大的商机，最后越聊越嗨，几十分钟就可以聊出改变行业的需求，但最后落地过程中，却发现是个伪需求。

但其实讨论出来的需求，没有经过验证，不一定能得到用户认可的。脑暴方案，通常是业务推进缺乏策略时，才会使用的下策。

我一直认为产品的工作，很像科学工作，感性和理性缺一不可。既要大胆假设，更要小心求证，所有的需求，都必须经过用户或市场检验，基于大家在会上的讨论得出的需求，不一定可靠。

所以，在分析需求的时候，可以适当讨论，但不要盲从，讨论推演出来的东西，往往经不起市场的验证。毛主席也说，只有实践才是检验真理的唯一标准。

五、需求不来自于竞品

产品工作中，经常需要研究竞品，看看他们做了什么功能，更新了什么运营策略或市场调整。

从竞品里找需求，往往也是最省事的方法，但却并不是一个好办法。

因为所有功能，一定是经过深入的分析和思考，基于某个业务痛点和具象化场景去设计的。

可是单纯的模仿，确实可以获得进入市场的机会，尤其是在产品从0-1的阶段，可以快速追上竞品。

但未经思考的需求，缺乏对场景和用户理解，无法获得用户的认可。即使完成了当前版本的更新，未来也找不到优化迭代的方向，永远也只能跟随竞品，无法超越竞品。

六、需求只来自于用户洞察

需求不来自用户调研，也不来自讨论推理，更不来自竞品。需求只来自于用户洞察，来自产品人对用户的深入研究和理解。

分析需求的核心在于找到动机，动机是需求的源泉。用户会选择认可和接受上线的需求，是因为他们在场景下遇到了问题，而问题就来源于用户动机。

所以找到用户动机很重要，这是确定用户认可需求的密钥。而动机则来自于用户理解。这也是我为什么一直在反复强调，要日复一日，持续地去了解用户、理解用户、研究用户。

因为只有理解用户，才能挖掘到真需求，才能看到产品的机会，才能获得超越竞品和产品本身的创新。

七、评估需求优先级

首先，是基于产品定位，围绕核心场景，影响核心操作流程的需求，优先级最高。尤其是因为缺少某个流程，导致用户无法正常使用该产品的，优先级最高。

其次，产品要为口碑而做。产品的网络效应，是产品能够长久存活下去的关键。而只有产品口碑好，才能让产品具备网络效应，才能让这个产品产品具有绵延不绝的生命力。所以不论B端C端，本着提效和服务的理念，都应该把提高口碑的需求放到较高优先级的位置。

第三，基于目标判断优先级，目标分为长期目标和短期目标。因为短期目标优先级高于长期目标，但长期目标的收益率高于短期目标。

例如，今年的目标是商业化增长，这个季度的目标完成合规化改革，所以仅仅是优先级来看，合规化改革优先级高于商业化增长。但今年的需求价值，是围绕商业化展开的。

因此在优先级可以区分出来，然后每个版本按比例释放不同优先级的需求，优先级越高，版本可以安排的对应维度下的需求越多。

但其实需求评估和版本规划，都是比较主观的，也是要灵活调整的，评估优先级的依据仅作为参考。