避免需求目标不可测量。换言之，要避免让用户的需求缺乏检验的标准。有时候用户给出的需求点很笼统，产品经理一定要将其具体化，只有这样才能在实现、测试、验收阶段设立标准。避免和不适当的人讨论。调研对象不合适，一方面无法获取真实的需求，另一方面也无法确认最终需求方案，最后往往事倍功半。一般调研的对象以该业务用户的组长或其他经验丰富的员工为佳，并与对方强调调研内容的唯一性和准确性。

避免把要求当作需求。用户的要求可能超出了业务需求范围，或者超出了技术储备范围。遇到这种情况，要引导用户克制自己不合理的欲望，同时引导用户回归到解决问题的轨道上来，从实际出发寻求合理的需求。在与用户沟通的时候，避免提问过于技术性。针对用户的调研，不要使用过多的技术术语。如果是调查问卷形式的调研，那么问卷内容不能过于技术化，否则就会造成用户理解困难。正确的做法是尽量穿插用户场景，使用用户熟悉的语言进行引导。

8最后需要注意的是，获得需求调研结果的标志是获得调研文档。调研文档可以使用思维导图、Excel或Word去描述。调研文档需要粗略描述需求的梗概，包括背景、目标要点、注意事项、界面草图等。调研文档的主要阅读用户是产品经理自己，因此其详细程度根据实际情况而定，不必太详细，但是要能让人看得懂、不遗漏要点，从而作为需求文档的蓝本。

7确定大致方案在调研需求时，虽然还没有开始进行方案设计，但是基本的方案轮廓已经在产品经理的头脑中形成，因此产品经理可以跟开发人员交互意见，大概描述出方案的轮廓，咨询其可行性。同时产品经理也应该与需求方沟通方案的可接受性。当然在最终的方案输出之后，产品经理还要正式与需求方确认具体的细节。

6需求的合理性包括需求的定位是否合理、需求的实现是否合理两个方面。确定需求的定位是否合理：比如该需求在本系统中实现是否恰当，权限开放出来是否合适，是否泄漏了公司的机密等。有的时候，用户并不区分某需求是不是应该在这个系统中实现，所以他们提出的需求有可能与本系统无关，这时候就要求产品经理能分析出合理的功能归属。确定需求的实现是否合理：比如技术的投入产出比是否合适，使用第三方的应用的成本是否更低，当前公司的人才储备是否足以支撑该需求的实现等。实现起来不合理的需求，就应当过滤掉。

5确定需求是否有价值需求的价值就是需求能带来什么收益。比如做了该需求能节约多少劳动力、挽回多少损失、增加多大社会效益等。不做有多大损失，是否影响业务的连续性，是否造成巨大损失等。如果一个需求做和不做没多大区别，那么就说明该需求并无实质价值，建议把该需求过滤掉。

4通过需求背景的调研，掌握了需求的基础信息，对需求的目标有了一定的预知。那么接下来就要明确需求的目标，即明确该需求究竟要干什么？并将需求目标具体化到可测量的维度上。可以使用5W2H规则明确需求目标，包括：需要的功能是什么（What），为什么要有这样的功能（Why），功能的用户是谁（Who），用户在什么时候使用（When），在哪个模块使用（Where），怎么使用（How），频次或数据量怎么样（HowMuch）。

3需求调研是需求实现过程的重要环节。了解需求背景、明确需求目标、过滤不当需求、确定大致方案，是需求调研的内容中主要的四个部分。1.了解需求背景这一环节主要完成的就是对业务背景、问题场景、用户群体、当前相关产品功能的摸底和确认，旨在复原业务场景、明确用户要解决什么问题，以及找到用户需求与现有功能体系的联系。

2了解需求背景一般通过谈话、观察等方式进行。需了解的需求背景包括但不限于如下。（1）该需求发生的业务场景是什么，这些业务活动是为了实现什么目的。（2）在这些业务场景中用户遇到了哪些困难，当前是怎么解决的，期望通过该需求怎么解决这些困难。（3）该需求还与哪些周边系统或哪些模块相关，它们的运行逻辑是什么样的。（4）该需求可能还有哪些用户会用到，会对他们有哪些影响，他们的期望会有哪些。（5）业务模式是否已经成熟稳定，预计未来何时可能会发生调整。

1需求的用户是谁？需求解决的核心问题是什么？使用场景有哪些？哪些是主要和次要场景？业务的流程是什么？除了主要业务还有哪些流程可能使用这个功能？除了本系统还有哪些系统会关联到这个功能……这些就是需求调研的“十万个为什么”。需求调研的内容很多，但基本可以分为两个方面：一方面向内，就是向功能自身调研；一方面向外，就是对需求方进行调研。

功能归属分析法专门系统做专职功能，有助于合理的产品体系建设。因此在进行需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统中完成。如果该需求不属于该系统范畴，那么直接说服需求方更换方案，以下面的案例说明。背景：CRM（顾客关系管理）系统有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联标签（如优质顾客、高潜力顾客、欺诈顾客等）。需求：业务用户提出需求，除了做出上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：经过调研，产品经理能够了解到，翻译之后的标签不是在CRM系统中使用的，而是在SMS（客服系统）中使用的，所以应该由SMS根据CRM系统提供的基础标签数据，自己做二次的衍生工作。之所以这样安排，首先可以避免未来更多语言版本的扩展需求或更多系统提出类似的需求，其次CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理。在这个案例中，需求本身是真需求，并且在实现上也没难度，但是该功能的定位超出了本系统范畴。专门系统做专职功能，衍生需求应该在下游执行，否则过高的耦合性会增加系统的复杂程度，难以维护和扩展。

在收集到需求之后，往往需要进行统一的管理和整合，这时就需要一个“需求池”。需求池是需求的集中地，集合了最初获取的原始需求信息，以便日后进行需求过滤、跟踪调研等。需求池的需求通常包括功能改进类需求、体验提升类需求、BUG修复类需求、新增功能类需求等，因此需求池也可以叫作“原始需求库”“需求漏斗”等。需求池以“宽进严出”的理念进行管理，目的就是不遗漏任何有价值的需求点。

可以使用5W2H规则明确需求目标，包括：需要的功能是什么（What），为什么要有这样的功能（Why），功能的用户是谁（Who），用户在什么时候使用（When），在哪个模块使用（Where），怎么使用（How），频次或数据量怎么样（How Much）。基于以上，基本可以确定需求的范围、功能流程、用户体验要素、功能模块、功能性能等。这些就是构成需求目标的成分。需求目标的明确，关系到未来需求验收标准的制定。

确定需求是否有价值需求的价值就是需求能带来什么收益。比如做了该需求能节约多少劳动力、挽回多少损失、增加多大社会效益等。不做有多大损失，是否影响业务的连续性，是否造成巨大损失等。如果一个需求做和不做没多大区别，那么就说明该需求并无实质价值，建议把该需求过滤掉。高效调研高效调研就是节省调研时间、提高调研的质量。建议产品经理能够一次性调研完毕，这样既节约各方的时间，又锻炼产品经理的思维缜密性和执行力。但是，如果经过一次调研后发现调研过程有所遗漏，或者衍生出新问题，那就还要继续调研，直到彻底弄明白。如果产品经理经过调研之后还是一知半解，那么输出的方案就经不起考验，在后面的评审和研发阶段仍要做反复修订。