很多产品人员会遇到这样的问题：
　　（1）不知道自己该做什么
　　（2）需求少的时候，收到一个需求很兴奋地直接开做，辛苦做完后，效果并不好
　　（3）需求多的时候，哪个需求的需求方催地紧做那个需求，做完才发现耽误了其他更重要的事情
　　（4）各部门都在提需求，自己也有很多点子，可当时没有来得及做，过后怎么也想不起来了
　　（5）自己和部门做了很多工作，其他部门不知道你在干什么，甚至自己回过头想，也不知道自己做过啥
　　以上问题的原因在于产品部门没有做好需求管理。
　　什么是需求管理？需求管理是需求的收集、分析和整理过程。
　　产品部门没有建立完善的需求收集机制，会不知道做什么；有了需求后，没有分析过程，要么费力不讨好，效果差，要么是没有抓住重要的需求，没创造价值；没有做好需求整理，不知道每个人正在做什么，以前版本的需求做过什么，千万别发生员工离职，不然新顶替的员工半个月也搞不清哪些事情需要自己跟进。
　　对于需求管理，我的经验如下：
　　一、需求收集
　　需求主要来自下面几个方面，我们如何更有效的收集需求呢？答案是建立一个需求池，收集到需求后立即把需求记录进去。
　　· 自己和同事发现的需求
　　· 竞品分析的结果
　　· 用户反馈的需求
　　· 老板的需求
　　· 数据分析得到的需求
　　· 运营等其他部门的需求
　　· 线上发现的BUG
　　· 同事和自己发现的需求。
　　（1）产品经理要有发现需求的能力，要理解用户需求，发现用户没有被满足的需求，这要求产品经理自身也必须是该类产品的用户，也要常泡相关的论坛，比如用户提现时，有时是有急事需要拿钱应急，用户等不及两三天到账，那么你的产品是可以为用户提高即时到账的服务；
　　（2）要持续关注产品核心流程的优化，理出你的产品的核心流程，想想如何缩短核心流程，如何提高每个环节的“效率”，比如先充值再投资可以简化成一步充值并投资，比如你是做个人借款的，需要大量的人力做个人信息的审核，是否可以设计出更加自动化审核的方式；
　　（3）要关注行业变化和技术发展，发现可能的机会和调整方向，比如当苹果出了指纹解锁功能，你也可以考虑自己的app上是否可以跟进指纹解锁进入app的功能。从工作流程上来说，定期进行头脑风暴是个迸发需求的好方法，会上将产品需求分成几个大类，产品人员甚至其他部门的人对于每个类别逐个提需求和建议，一场风暴下来一定会有不少灵感出现。
　　竞品分析的结果。竞品分析的重要性不言而喻，竞品不断地进化，推出新功能，或者优化了老功能的体验。不知道竞品的状况，则会在不知不觉间丧失市场的地位。如果竞品的某项改动使得体验超过了自己，则要把该改动加入自己的需求池中，等待分析处理。从工作安排上来说，可以让每位同事负责若干个行业标杆竞品的跟踪，每两周出一份对方的改进报告，供大家参考。
　　用户反馈的需求。要收集用户反馈，首先要建立用户能够发出声音的入口，比如app里的意见反馈，比如搭建论坛；其次要有用户反馈意见的奖励机制，引导用户更积极地提出建议。产品经理每天要看用户的反馈，整理所有的反馈到需求池。运营和客服平时接触用户多，他们也要每周发一封用户反馈的问题的整理邮件给产品部门，然后将需求加入需求池中。
　　老板的需求。老板经常会提出他的一些需求，但是不要紧张也不要着急，也是先加入需求池，等待下一步分析。
　　数据分析得到的需求。数据分析的基础是统计，产品团队要找到需要关注的数据指标进行统计，起码必须有用户在核心流程转化的漏洞模型的统计数据和用户在核心流程中遇到的问题的统计报表。有了统计数据，可以帮助我们发现哪个环节做的不好，对该环节进行分析和优化；有了用户遇到问题的统计报表，可以更清楚地了解用户跳出流程的原因，为优化提供依据，比如我们发现每天注册失败的用户中，用户遇到数量多的问题是两次密码不一致，那么是否可以简化成只输入一次密码，密码可以调整是否可见呢。
　　运营等其他部门的需求。产品经理要理清楚和自己有合作的部门的工作内容和工作流程，掌握了他们的业务细节，才能更好的为他们服务。定期和他们沟通，找到对方工作内容中的流程和变量，找到他们的时间瓶颈，人力消耗大的地方，每日工作占用时间多的地方，产生价值的地方，容易出错的地方。这些都是可以优化的点，把这些需求点加入需求池。
　　线上发现的BUG。根据bug的影响范围，紧急程度，要么立即修复，要么也加入需求池。
　　此时，我们已经建立了一个可以看到需求整体全貌的需求池，并且需求池的规模还在不断的增长。
　　二、需求分析
　　我们的目标不是完成需求，而是有效地解决问题。
　　需求分析是为了搞清楚隐藏在需求背后的问题。
　　在分析需求的时候，我们先搞清做不做，然后再看怎么做。
　　做不做这个需求，取决于需求带来的价值，有价值则做，价值高则高优先级做；怎么做这个需求取决于需求的用户、场景、行为路径。
　　需求的价值需要在收到需求的时候，考虑清楚。而需求的解决方案则可以在真的要处理该需求的时候再思考。
　　评估需求的价值。首先要自己探索或者和别人讨论出每个需求的本质是什么，需求到底要解决怎么样的问题，问题发生的频率是怎么样的，做了这个需求后能带来多大改观，改观可以是体验的提升，可以是收益的增加，也可以是成本的减少，也可以是用户出错的几率降低.....频率乘以改观等于需求价值。
　　用户、场景、行为路径。先搞清现状：需求的用户是谁，用户的特征是什么样的，具有这样特征的用户在哪些场景下存在该需求，这些用户在每个场景下现在是怎么解决问题的。再自己想出或者讨论出需求的实现方案。后分析方案能否能解决问题：方案使得目标用户在每个场景下问题解决地更好了么。如果只能解决某些用户在某几个场景下的问题，意味着需求生效的频率降低了，需求的价值也随之下降。
　　三、整理需求
　　我们根据需求的价值和紧急程度，将需求池内的全部需求进行排序。并把分析过的需求转移到不同版本的需求列表中。