每个产品经理都应该有需求池。
需求池包含三部分：需求收集、需求处理和需求反馈。
需求收集
所有的需求都应该被收集。
看似简单的一句话，没有对应的机制还真难以做到。不是当事人找到你说我有一个需求的时候，才叫需求。微信公号、微博的评论和私信里，用户通过各种渠道反馈过来的问题，可不都是需求嘛。课程的作业之一就是从AppStore以及微博的评论中，整理出一个需求列表，很容易就能收集到10条以上。
一闪而过的想法、用户的吐槽、产品被投诉都非常有价值，值得被记录并且进行认真的分析。
要收集的信息点有哪些？
1、反馈者。
谁反馈的问题？
2、受影响的用户。
反馈的是谁的问题？
3、详细描述现象。
什么场景下遇到怎样的问题，用户希望怎么解决？
4、补充基本信息。
版本、手机型号、网络环境、浏览器类型等。
需求处理
1、区分需求类型：是BUG，还是改进，还是全新需求。
2、需求是否有效？评估要不要做、能不能做。
BUG
很多人不知道的一个常识是，bug需要能复现才会能修复。
所谓复现，就是通过一定的步骤，可以让bug重现。然而有的bug是在特定情况下才会出现的，如果不能复现，基本上也就难以修复。
所以在收集需求的时候就考虑到这一点，不要漏掉细节，很可能你没在意的地方就是问题的关键。
可以复现的bug，记入bug列表；不能复现的bug，记入观察列表。
改进
比如验证码发送失败是BUG，验证码发送后1分钟才收到是改进。
全新需求
基本上涉及较多改动的都应该算做是全新需求。
需求反馈
需求反馈原则：尽量当下反馈，真诚不说套话，列入需求池之后要有行动计划。
正确的反馈姿势举例：
马上改
暂时没复现
在版本计划里，未来2个月内上线
暂时没有这个计划，谢谢关注
这样看来，类似“需求收到”、“会考虑”这种话不算是好的反馈。
最后，看看曾经的小米论坛是怎么做的：
小米用户反馈BUG需求处理列表
