Войти сейчас 一尺之棰，日取其半，万世不竭。这句话搁在需求管理上，莫名地贴切。做产品这些年，我越来越觉得需求就像那根永远砍不完的棍子，你以为砍掉一批，马上又会冒出一批，没完没了。
可真正让我下定决心，把需求认认真真管起来的，还是那个阳光明媚的下午。老板把你叫到跟前，随口问了一句：“那个某某需求，上了吗？”你脑子飞速转着关键词，却怎么也搜不出一个能对上号的答案，只能承认，自己这会儿确实想不起来了。过了几秒才恍然记起，好像几天前和老板聊过那么一嘴。后悔已经来不及了，只能拍拍脑门，赶紧想办法补救。
说真的，产品经理每天要面对的需求，来源五花八门：老板的、运营的、市场的、客服的、用户的，还有自己突然冒出来的灵感。这些需求大多没什么硬性约束，可做可不做，偶尔也会碰上那种“必须马上处理”的急茬，带着一股不容商量的即时性。于是，我们就经常夹在需求方和有限的研发资源之间，来回周旋，彼此试探，直到自己慢慢扛住事儿。无论你看不看，需求就在那里，不增不减，不悲不喜。
既然需求总是源源不断，研发资源又永远有限，光靠脑子记肯定不行。这时候，就需要一个东西来把这些乱七八糟的想法沉淀下来——也就是我们常说的需求池。
先说说什么是需求。我习惯这样定义：需求是用户在一定时期内，尚未被满足的期望。这里面有两个维度。一个是时间，需求总有它的生命周期，初期可能不强烈，到了后期又变得可有可无；另一个是空间，如果已经被满足了，它就不再是需求，而是已有的方案或产品。产品经理要做的，就是挖掘那些有价值的用户需求，并且在恰当的时机把它们落地。
而需求池，字面意思，就是满满一池子需求。但需求总得有个先后，而且它们本身也千奇百怪。有人想根据手机壳颜色自动换软件主题，有人想靠机器推荐信息来拉升业务指标。需求本身没有绝对的对错，有些看似不着边际的想法，一旦做出来，可能释放巨大的价值；而有些看似价值极高的需求，如果时机不对，也能把整个业务拖垮。共享单车要是没赶上移动互联网的爆发，恐怕很难取得后来的成就——当然，OFO的滑坡是另一个话题了。
所以我主张，所有需求，无论大小、急缓，都先扔进需求池里沉淀。这样做的好处是流程简化，也不容易遗漏。
你可能会问，紧急需求难道不应该立刻动手吗？为什么还要进池子？原因有两个。第一，紧急需求往往时间紧迫，我们通常来不及深入思考，先记录下来的过程本身就是一次缓冲，能降低失败率。第二，研发排期毕竟是现实，偶尔插一两次急单可能还行，但紧急情况随时可能发生，一味迁就只会让重大失误的概率越来越高。我的做法是，把紧急需求也纳入需求池统一管理，合理安排产品版本，不要因为突然冒出来的急事就打乱既定的工作计划。如果对原计划冲击太大，就适当把原计划往后延一延。
需求池到底长什么样？其实很简单，就是一个二维表格，说人话就是Excel。下面我把主要字段用大白话过一遍。
ID，唯一编号，每增加一个需求，ID就加1。没什么技术含量，但能保证不重样。端口，记录需求涉及哪个端，比如安卓、iOS、后台，这是初步的划分。如果同时涉及多端，大公司通常拆成多条需求分别处理，小团队则直接记成“综合”。模块，就是需求牵扯到哪个模块，比如登录注册、用户管理、财务管理等。需求名称，用一句话说清楚要做什么，像“根据手机壳颜色更换软件主题颜色”这种。需求描述，就得详细展开了，包括提出的背景、目的，以及具体描述，让接手的人能看懂来龙去脉。需求来源，简单记一笔，是产品、市场、领导还是其他渠道。优化类型，记录当前需求是新功能、功能优化，还是Bug修复。优先级，一般用高、中、低或数字表示，它是动态的，会随着公司战略目标的变化而调整。复杂度，很多需求池模板漏掉这一项，其实加上很有用，它能帮你在众多需求里，挑出那些优先级虽然不高，但稍微调整一下就能大幅提升体验的“性价比”需求。提出时间，记录需求冒出来的时间，用来区分需求的“年代感”，有些项目真的能沉淀出带着历史气息的需求。提出者，谁提的，便于后续追根溯源。跟进者，当决定在某个版本实现这个需求时，指定给某位产品经理跟进。状态，需求在不同阶段的状态流转，我常用的包括：进入需求池（初始状态）→待论证（需要进一步确认）→待设计（论证后有价值，准备近期启动）→设计中（正在做详细设计）→设计完成→研发中（已排入开发计划）→已上线。还有一个特殊状态叫“已关闭”，因为各种原因提前终止。预期实现版本，产品部门计划上线的版本，通常会提前几个版本规划，这样就能提前和相关部门沟通，提高成功率。实际完成版本，上线后填上，方便以后追溯。上线时间，记录实际上线的日期。备注，补充各种情况，比如需求关闭的原因。
填完这些字段，通过筛选功能，就能很方便地查看和分析需求了。
你可能会觉得，这也太复杂了吧，整整17个字段。但稍微拆解一下，就会发现其实没那么吓人。不需要动脑子的字段有四个：ID、需求来源、提出时间、提出者。稍微用点心的有五个：端口、模块、需求名称、优化类型、复杂度。真正需要你大脑快速转动的，只有三个：需求描述、优先级（这个确实重要），以及状态。剩下的跟进人、预期版本、实际版本、上线时间、备注，都可以顺其自然地填。所以，核心就是那三个需要你动脑子的字段。
怎么定优先级呢？举个例子，公司Q2的目标是提升订单转化，那么我们至少在Q1就要提前分析获客流程、产品展示和下单流程中的相关需求，提前摸清运营那边有没有活动需求。所有与此相关的需求，优先级自然会高一些。但研发资源和渠道资源始终有限，即便相关需求之间，也还要继续排优先级。这个阶段思考的重点，就是如何在合适的时间，满足合适的需求。
需求池不能像貔貅一样只进不出。收集需求不是目的，实现公司的长期战略目标才是。所以需求池需要定期复盘。可以按日、周、月的时间维度来审视，可以自己看，也可以拉上产品团队、研发、业务部门代表，甚至目标用户一起看。需求池只是一个开始，一个起点，后续的耕耘才是关键。
半年之后，需求池会越来越丰满，当初的小池塘，慢慢就变成了一片海。我们也会被老板和各业务部门的口水星子淹没。怎么从口水里挣脱出来，是一门艺术。
先想想，为什么会有需求？因为我们总有那么多没被满足的愿望。所有需求都应该满足吗？当然不是。需求有优先级，机会成本也摆在那里。用户总有不满足的地方，怨气很大怎么办？要么转移他的注意力，要么尽量满足他。实在满足不了呢？那就转移注意力。我知道这听起来有点绕，其实核心逻辑很简单：需求不被满足，确实让人不痛快，但需求永远不可能全部被满足。更好的办法是坦诚沟通，转移注意力，或者给一个合理的预期。需求池的目的是沉淀需求，而不是实现每一个需求。
作为产品经理，我们不应该只盯着用研发的方式去解决所有期望，也要尝试通过第三方工具、优化业务流程等更多元的途径来应对。用户不是一个抽象的群体，而是一个个活生生的人，他们有自己的习惯，自己的想法。如果不能满足他，总得想点别的办法。小米早期做MIUI的时候，通过论坛收集用户需求，并积极给出反馈。当用户看到MIUI重视自己的问题，并且真的实现了，那种幸福感，其实已经远远超过了需求本身被满足的愉悦。
在日常整理需求的过程中，有一些工具可以帮上忙。
比如钉钉，它的自定义流程审批功能，对企业内部来说是个福音。我比较喜欢请人协助，定制一套需求提交流程和紧急需求提交流程。针对公司内部人员，无论谁都可以在钉钉上提交需求，提上去之后，先由直接上级明确需求的基本内容，判断是否符合企业价值，通过了再转到产品部负责人那里，由负责人分配给相关产品经理去做后续调研。产品经理了解完详细需求信息，进行初步分析，给出优先级，再记入需求池。紧急需求是临时性的，会打乱既定生产计划，但又必须调整。和一般流程相比，产品部负责人接到这类需求后，需要先弄清楚它的影响，通知上级领导决策，然后尽快进入设计和研发上线的流程。在这个过程中，需求可以自由转交，相关人员也能随时了解最新进展。提出需求后不容易遗漏，每个需求都会得到重视，产品经理也能利用相对空闲的时间来回复，避免总是被打断。
另外，像石墨文档、腾讯文档或者SVN这类工具，可以方便团队协作编辑Excel，需求池的动态能轻松分享给其他人。同时，需求池毕竟属于敏感信息，这些产品都支持权限控制，不需要额外的研发投入。
说到底，需求池不是什么高深的东西，它只是帮助我们把一团乱麻理清楚的那个线团。真正重要的，是背后那个不断思考、不断取舍的人。