需求搜集

定义：无论是全新业务的探索还是已有业务的优化方案，都存在业务述求，因此需求搜集可以理解为向用户搜集业务述求。

渠道：用户主动通过某个渠道表达对产品使用的不满及建议。像微博吐槽，APP评价，在线客服，产品反馈进口等方式会更适合C端用户。而B端用户（或公司内部用户），会直接向上级或产品经理反馈业务述求。

原则：

接近业务。产品经理未收到业务反馈往往不是意味着产品没有缺点并满足用户的所有需求，而是产品未同用户建立良好的需求沟通机制导致。用户由于思维惯性，不会主动提出业务述求。其原因可能包括：不以为当下的操纵行为有何不妥；以为即使提出业务述求也得不到有效解决。此时需要产品经理往接近用户，比如说业务轮岗，种子用户访谈，数据漏斗分析等。
倾听和理解。理论上所有的业务抱怨都可能提炼成一个需求，不要以自己对产品的熟悉程度往质疑用户的各种操纵失误；既然这是你的用户，用户会出错，用户会抱怨，这即使产品需优化的点。因此首先要端正自己的态度，重视业务题目，才会有往改进的动力。
及时反馈。为了进步业务部分反馈的积极性，对于述求方给出回复时间点及回复结果：转化成需求/大致完成时间，需求拒尽/拒尽理由。
有针对性。往往用户在描述题目时轻易发散，没有方向，导致搜集了很多题目，但同需调研的需求本身有偏差。因此，针对有目的性的需求，产品经理对产品的框架有事先的认知，带有题目往咨询用户。比如，要做进销存的功能，产品经理要事先对进销存有基本的产品框架，集中同用户讨论采购进库，挑唆，盘点等业务场景。

需求挖掘

定义

将业务述求整理成需求池，即场景-用户-题目点（目标）-建议解决方案。

场景：所有的用户行为都必须具化到场景，需求场景描述要尽可能的具体，这样才有利于产品设计。曾经看到地铁广告，公众号二维码置于海报中下区域，也就是用户要蹲下来才能扫到二维码。假如需求挖掘时有考虑到用户扫描二维码的场景，产品设计就会考虑二维码的位置。
用户：你要清楚你为谁设计产品，不同的用户产品设计思路是不一样的。工厂操纵员害怕出错，因此产品设计可以侧重强提示，二次复核，傻瓜式操纵等避免出错；女生害怕计算，因此产品设计可以将口算的部分转为系统自动计算；特别是C端产品更要考虑用户画像，本文就不再展开。
题目点：所有的需求是为了解决业务题目。功能上线后未解决业务题目，即是资源的浪费。解决业务题目即等同于需求目标，有利于确认需求的优先级。因此罗列出题目点，作为产品设计依据。确认需求目标，可作为上线跟踪的依据。
建议解决方案：在同业务端沟通时，可能会得出初步的建议解决方案。参考该信息有利于产品设计是符适用户需求的。

原则

别把解决方案当需求

很多时候，用户给我们讲出来的想法和要求，根本不是他们的“需求”，而是他们的一种“想要”。“需求”是用户最根本的待解决的题目，而“想要”只是用户已经帮我们想好的一些解决“需求”的办法而已，在需求调研过程中，务必要挖掘到用户的“需求”，通过我们的设计往实现用户的“需求”，而不是盲目的跟从用户的“想要”，结果被用户带到了沟里出不来。

不中断问为什么

需求挖掘比较考验产品经理专业业务能力和事物抽象化，比如工厂的说想喝可乐，其用户需求1是解渴，需求2表达我很酷。在用户所在环境，喝可乐是财力和酷的表现，而水却被打上廉价标签。挖掘更直观的表达方式是不中断的问为什么，为什么想喝可乐；为什么是可乐；每个业务点往问到最后的为什么，也能收集你想挖掘的点。