每个产品经理都应该有需求池。

需求池包含三部分：需求收集、需求处理和需求反馈。

需求收集

所有的需求都应该被收集。

看似简单的一句话，没有对应的机制还真难以做到。不是当事人找到你说我有一个需求的时候，才叫需求。微信公号、微博的评论和私信里，用户通过各种渠道反馈过来的问题，可不都是需求嘛。课程的作业之一就是从AppStore以及微博的评论中，整理出一个需求列表，很容易就能收集到10条以上。

一闪而过的想法、用户的吐槽、产品被投诉都非常有价值，值得被记录并且进行认真的分析。

要收集的信息点有哪些？

1、反馈者。

谁反馈的问题？

2、受影响的用户。

反馈的是谁的问题？

3、详细描述现象。

什么场景下遇到怎样的问题，用户希望怎么解决？

4、补充基本信息。

版本、手机型号、网络环境、浏览器类型等。

需求处理

1、区分需求类型：是BUG，还是改进，还是全新需求。

2、需求是否有效？评估要不要做、能不能做。

BUG

很多人不知道的一个常识是，bug需要能复现才会能修复。

所谓复现，就是通过一定的步骤，可以让bug重现。然而有的bug是在特定情况下才会出现的，如果不能复现，基本上也就难以修复。

所以在收集需求的时候就考虑到这一点，不要漏掉细节，很可能你没在意的地方就是问题的关键。

可以复现的bug，记入bug列表；不能复现的bug，记入观察列表。

改进

比如验证码发送失败是BUG，验证码发送后1分钟才收到是改进。

全新需求

基本上涉及较多改动的都应该算做是全新需求。

需求反馈

需求反馈原则：尽量当下反馈，真诚不说套话，列入需求池之后要有行动计划。

正确的反馈姿势举例：

马上改

暂时没复现

在版本计划里，未来2个月内上线

暂时没有这个计划，谢谢关注

这样看来，类似“需求收到”、“会考虑”这种话不算是好的反馈。

最后，看看曾经的小米论坛是怎么做的：

小米用户反馈BUG需求处理列表