需求收集是产品经理进行需求管理的第一步，我们可以将收集的需求划分为两类，一类是由产品经理主动挖掘的，另一类为用户、老板、运营等人员反馈的需求，属于被动接收且需要处理的需求，针对收集到的需求我们应当遵循“有进有出，宽进严出”的处理原则。
被动接收需求
被动接收需求，指的是由他人提出的产品需求，产品经理作为接收方，主要做的就是理解对方所提出的需求。
产品经理在日常工作中会收到来自各方提出的产品需求，我们可以大致划分为三类，一类为老板吩咐，一般表现为任务或者业务建议，主要目的是为了支撑公司业务，有时此类需求是由市场部提出的；另一类就是用户的反馈，用户直接通过产品或其他渠道向我们提供遇到的问题或针对产品的建议，这种反馈闭环越早建立越好，有利于产品的持续优化与种子用户的积累；最后一类就是运营类需求，主要就是为了支撑运营方案的实施，所需要的产品支持。
产品被动接收的产品需求，由于提出者无法像产品经理一样定义需求，所以针对他人提交的需求需要具备一定的要求，从而来确保需求的完整性，避免获得的需求存在信息缺失，导致无法还原需求或正确理解需求。如果要完整的描述一个需求，至少需要包含以下信息。
1.编号：用于对收集到的需求进行唯一性识别，方便后期追溯；
2.产品端：当产品存在多个终端时，需要说明当前的需求针对的是哪个终端，或源于哪个终端，方便需求的追溯；
3.功能/页面：当前需求针对的是哪个功能或页面，当没有对应的功能或页面时，可无需说明；
4.需求类型：即描述需求的特征。例如由于当前的功能流程或页面呈现做的不够好，用户完成用户任务时遇到了障碍（用户障碍），或者已经针对此障碍想到了较好的解决方案（优化建议），再或者用户在完成用户任务时，其实还想着做其他的事情（新增功能），或者这个需求是为了支撑运营活动的（运营需求），再者为了实现某种市场业务，需要产品支撑（业务需求）；
5.问题描述（需求场景）：描述需求提出方期望借助产品做成什么事情，并且在完成此事时遇到了什么问题。（这个事情指的是业务）
6.需求描述：描述需求提出方期望产品提供什么（功能或内容），以让他顺利做成此事。此描述其实就是需求提出方自己给出的问题解决方案，如果需求类型为用户障碍时，可仅描述问题，无需描述解决方案。
7.紧急性：做成某事对用户的紧急程度，可分为5级，分别为非常紧迫（这个事情很急，并且当前无法做成此事）、紧迫（不是很急，但目前无法做成此事）、一般（能够做成，只是没那么轻松）、不紧迫（能够做成，并且感觉现在这样还能接受）、很不紧迫（能够做成，如果这样做了会让体验更好，，或者无所谓事情是否能够做成）
8.需求来源：描述需求提出方获得此需求的途径，通常为用户反馈、产品体验、参考其他产品、灵感、运营活动、业务需要等，具体如何划分，无需规定的太死，甚至可直接让需求提出方使用一段话进行描述。
9.提交人：指需求提出方，需要描述部门与具体的人员姓名，如果是用户甚至可记录用户信息；
10.提交时间：提交此需求的时间；
被动接收的需求不应该马上移入到需求池，因为还需要产品经理进行鉴别，鉴定为需求并确定需要处理后，再放入需求池，这将涉及到需求定义与需求分析的范畴。在对收集的需求进行鉴别时，产品经理需要在心中将这些内容进行分类，例如一些需求可能只是bug，或者是伪需求（需求对应的问题本不存在）。这些将在需求定义与需求分析中进行阐述。
主动挖掘需求
主动挖掘需求，也就是产品经理使用各种方法，主动去获取产品需求，以寻找产品当前存在的问题与可能的发展路径；主要包含两类，一类为优化原有业务，帮助用户更好的实现用户目标，即优化用户体验，例如滴滴这个产品，可以针对打车流程进行优化，降低打车过程的理解、决策、操作成本，从而给用户一个更优的打车体验；另一类是针对产品原有的业务进行拓展，也就是用户使用产品能做的事情更多了，例如还是滴滴这个产品，在用户乘车时，增加销售矿泉水的业务，或在打车的业务上继续拓展快递货运等业务。
针对原有业务的优化存在两个方向。产品的功能是为了承载业务，从而实现某个业务目标，业务是针对业务目标的解决方案，所以我们可以优化原来的解决方案以实现业务目标，或寻找一个更优的解决方案实现业务目标。
如果是优化解决方案，可以模拟业务场景，亲自体验业务流程，找出所遇到的障碍，你每一次理解、决策、操作上的停顿或迟疑都有可能是一个可以被清除的障碍；或者在用户的反馈中寻找他们所需要的问题；再或者可以回访一下用户，直接找几个用户聊一聊产品的使用体验，这些都是平常经常被用到的方式。
如果是想找一个更优的解决方案，则需要对原解决方案足够理解，清楚原来的解决方案的天花板在哪里，当前是否存在新技术或资源可以帮助突破这个天花板，并时刻留意着这方面的技术与资源。可能在某个时候，由于技术或资源的限制得到突破，可能之前的天花板将不再是天花板了，一个更优的解决方案孕育而生。
针对原有业务进行拓展，我常用的方法是控制变量法，当我们描述一个需求，一般都会提到三要素，用户、场景与期望，当我们控制其中两个，而去考虑剩下的一个时，此时或许会获得很多点子或发现。所以也就存在以下三种视角：
1.同一类用户在原期望下的业务场景中，可能存在的其他期望。例如当你在看电影时，想吃爆米花或喝奶茶，或者你在喝奶茶的时候，希望能够拍张照发个朋友圈；
2.同一类用户产生此用户期望，可能存在的其他业务场景。例如当你在外逛街时，由于看到电影院的某个电影的宣传广告而想去看电影，那是否存在当你在家或公司时，由于朋友的介绍而突然想去看电影；
3.同样业务场景下产生的用户期望，可能存在的其他用户。例如情侣经常在逛街时去看电影，那其他人是否也可能想看电影，或者什么时候想看。
如果要说严格意义上的业务拓展，可能只有第一种才真正是的了。但我觉得不管是用户能够做更多的事、还是更多的用户能够做这件事、或者是用户能够在更多的场景下做这件事，这些统统是在扩大业务的边界，所以我认为应该都被算作业务的拓展。当产品经理有了业务拓展的方向后，后面的工作就是进行验证了，不管是问用户，或者看看隔壁的竞品，再或者自己试验一下，看看用户反馈的结果，拿具体数据来分析，这些都是不错的方法，重要的是需要有最初的假设，也就是那个你认为可行的业务方向。
产品生命周期与需求收集
产品的生命周期可以被总结为初创期、成长期、成熟期、衰退期四个阶段。在初创期时，我们更多的应该是做好一件事，并且应该是确认需求，且验证解决方案，此时你所有的视线都应该停留在用户与市场的反馈上，需求收集的工作对于你没有那么重要；而到了成长期，核心的业务被验证了，此时你需要的就是优化原业务，此时更多的是被动接收需求，特别是用户反馈的需求，或者自己主动去找用户痛点等，当然到了成长期的后半期，可能你已经开始主动寻找业务可能的拓展方向了；到了成熟期，优化工作已经达到一定的天花板，再优化已经没有太大意义，此时主要工作就是寻找业务拓展方向，并不断试验；当到了衰退期，要不然你已经拓展出了新的业务方向，进入其他赛道，或者新的解决方案开始取代你了。
