需求池，顾名思义，就是把很多需求放到一起的东西。然后，在规划版本的时候，从池子里捞出几个需求，排一排，搞个版本开发。

当一个产品一旦开始，就会有很多的需求冒出来。很多人自然就想到说，这些需求，先收集起来，然后，等有时间的时候再来排一排，算一算，做什么，怎么做。

这个思路，看上去很自然，也很科学。需求池这个东西，很多产品经理都想搞，很多团队也想用。

不过，我们真的需要这么一个需求池吗？

我认为，实际上，我们完全不需要这个东西。需求池，是一个看上去很美好，实际上意义不大的事情。

首先，任何一个产品，都是变化很快的。不论是市场环境，用户行为，产品演进。

这直接意味着，需求实际上是在不断变动的。就像我之前说的，「需求应该是自然而然的」。

换句话说，这个时间的需求，再过一段时间，已然变化了。

其次，我们一直在说抓重点，做亮点。这句话很好理解，也很好说出来，不过，核心难点在于，怎么判断是不是重点？

我有一个武断且奏效的办法，如果这个功能不能总是在你脑子里留着，这个功能就不是重点。

如果一个功能，这个版本排不上，下个版本的时候你又想不起来，这个功能，肯定不是重点，甚至是，可以放弃的。

这个方法，我一直用，看似很武断，实际上，很好用。

我之前说，不做什么比做什么更重要。很多时候，产品经理的困难在于，从100个功能里只挑3个出来做。

一样的道理，选择越多，选择就越困难，需要从需求开始的时候就筛选，而不是为了筛选去筛选。

当越来越多的工具出现时，你会发现团队使用的工具数量已经快要超过团队成员的数量了，其实我们需要的只是让团队成员之间能够很好的协作和沟通的工具而已。

就像一个朋友说的，「需求池，难道不是用来安慰那些提了需求却没被接受的人吗？」

……

再扩展一个，我们真的需要一个 GTD 产品吗？