只有做好需求调研，才能在立项时从容的应对各种疑问。
比如该需求要为谁解决什么问题？为什么你的需求比别人重要？需求要达到什么目的？……需求调研不足将导致产品脱离实际业务需求，造成开发资源的浪费和产品方向的偏差。
本人将需求调研整理为三阶段，即需求搜集-需求挖掘-需求评估，并说明每个阶段的工作思路。
注：公司产品为c2m服装定制平台，以下将结合实际工作经验及对产品的理解整理，仅供参考。
需求搜集
定义：无论是全新业务的探索还是已有业务的优化方案，都存在业务述求，因此需求搜集可以理解为向用户搜集业务述求。
渠道：用户主动通过某个渠道表达对产品使用的不满及建议。像微博吐槽，APP评价，在线客服，产品反馈入口等方式会更适合C端用户。而B端用户（或公司内部用户），会直接向上级或产品经理反馈业务述求。
原则：
接近业务。产品经理未收到业务反馈往往不是意味着产品没有缺点并满足用户的所有需求，而是产品未同用户建立良好的需求沟通机制导致。用户由于思维惯性，不会主动提出业务述求。其原因可能包括：不认为当下的操作行为有何不妥；认为即使提出业务述求也得不到有效解决。此时需要产品经理去接近用户，比如说业务轮岗，种子用户访谈，数据漏斗分析等。
倾听和理解。理论上所有的业务抱怨都可能提炼成一个需求，不要以自己对产品的熟悉程度去质疑用户的各种操作失误；既然这是你的用户，用户会犯错，用户会抱怨，这即使产品需优化的点。因此首先要端正自己的态度，正视业务问题，才会有去改进的动力。
及时反馈。为了提高业务部门反馈的积极性，对于述求方给出回复时间点及回复结果：转化成需求/大致完成时间，需求拒绝/拒绝理由。
有针对性。往往用户在描述问题时容易发散，没有方向，导致搜集了很多问题，但同需调研的需求本身有偏差。因此，针对有目的性的需求，产品经理对产品的框架有事先的认知，带有问题去咨询用户。比如，要做进销存的功能，产品经理要事先对进销存有基本的产品框架，集中同用户讨论采购入库，调拨，盘点等业务场景。
需求挖掘
定义
将业务述求整理成需求池，即场景-用户-问题点（目标）-建议解决方案。
场景：所有的用户行为都必须具化到场景，需求场景描述要尽可能的详细，这样才有利于产品设计。曾经看到地铁广告，公众号二维码置于海报中下区域，也就是用户要蹲下来才能扫到二维码。如果需求挖掘时有考虑到用户扫描二维码的场景，产品设计就会考虑二维码的位置。
用户：你要清楚你为谁设计产品，不同的用户产品设计思路是不一样的。工厂操作员害怕出错，因此产品设计可以侧重强提示，二次复核，傻瓜式操作等避免出错；女生害怕计算，因此产品设计可以将口算的部分转为系统自动计算；特别是C端产品更要考虑用户画像，本文就不再展开。
问题点：所有的需求是为了解决业务问题。功能上线后未解决业务问题，等于资源的浪费。解决业务问题即等同于需求目标，有利于确认需求的优先级。因此罗列出问题点，作为产品设计依据。确认需求目标，可作为上线跟踪的依据。
建议解决方案：在同业务端沟通时，可能会得出初步的建议解决方案。参考该信息有利于产品设计是符合用户需求的。
原则
别把解决方案当需求
很多时候，用户给我们讲出来的想法和要求，根本不是他们的“需求”，而是他们的一种“想要”。“需求”是用户最根本的待解决的问题，而“想要”只是用户已经帮我们想好的一些解决“需求”的办法而已，在需求调研过程中，务必要挖掘到用户的“需求”，通过我们的设计去实现用户的“需求”，而不是盲目的跟从用户的“想要”，结果被用户带到了沟里出不来。
不断问为什么
需求挖掘比较考验产品经理专业业务能力和事物抽象化，比如工厂的说想喝可乐，其用户需求1是解渴，需求2表达我很酷。在用户所在环境，喝可乐是财力和酷的表现，而水却被打上廉价标签。挖掘更直观的表达方式是不断的问为什么，为什么想喝可乐；为什么是可乐；每个业务点去问到最后的为什么，也能收集你想挖掘的点。
需求评估
一般的伪需求在需求挖掘环节不断问为什么，能得到答案。在认定是真实需求时，一般采用重要性和紧急性两个维度考虑。
重要：公司战略；增加营收；降低成本；信息泄露；产品基础模块，比如电商的支付，订单，商品，库存，发货等模块等。
紧急：投诉风险；资金结算；大面积影响用户等。
注：不同阶段，公司对重要和紧急的领域可能会有差异，要视情况而定。比如说，公司初期增加营收，拉新等是重要的，而公司中期，降低成本，隐私泄露又开始被重视。
两个维度组合如下：
重要&紧急：如果这类需求多，需反思是否产品框架有问题，产品基础建设欠缺。
重要&不紧急：要聚焦于这类需求，代表产品的未来，拆分版本逐步迭代，稳扎稳打。
不重要&紧急：往往是临时解决方案，往往对产品没有质的提升。需要反思是过去产品迭代的问题。
不重要&不紧急：尽可能的不做
在大部分情况下，需求和开发资源是呈现狼多肉少的局面。
因此做好需求的优先级，合理利用有限的开发资源，是考验产品经理能力的一大指标。
