产品经理需要在接到需求时辨别真伪、在迭代时排好优先级、在开发时做好需求变更、在上线后分析数据给出反馈。在这一系列过程中，都需要产品经理做好需求管理工作。

在管理需求时，产品经理首先要对不同的渠道进行管理。因为需求来源不同，后续的做法完全不同。

需求的渠道大致可以分为五方：用户、老板、业务、客户、自身。那么，这几方的需求产品经理应当如何妥善处理呢？

01、用户的需求看问题

产品是给用户使用的。那么产品是否符合用户预期、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的，就需要产品经理时刻保持关注。

长链接是保持关注用户需求的常用方式。建立长链接需要找到快速触达用户的方式，可以是收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体中。

但具体链接形式不太重要，核心在于能够听到用户的真实表达。比如在访谈时，不要预设有引导性的问题。

用户一般不会主动提出需求或者表达想要什么功能，尤其是产品流程相对完善后，用户基本就不会提出建议了，更多是发牢骚和吐槽。

在产品发展的前期要产品经理要找到和关注KOL，在需求上听从他们的建议，根据他们的反馈做产品流程优化，使得产品快速从0到1。

有区别的是，在产品发展的上升期和稳定期，要谨慎对待KOL的需求，他们毕竟只代表小部分用户，大部分用户都是小白，可能用不到KOL的专业诉求。

那这时候用户的需求体现在什么地方呢？更多的体现在观察用户的使用感受上，从他们的牢骚和吐槽中定位到背后的真实问题，根据他们的实际反馈来不断的调整力度，完善产品。

02、老板的需求看目的

老板，是需求的另一来源。

大部分情况是，老板提了一个需求，让产品经理去执行。这个时候就要采用对用户完全不同的做法了。我们可以用两个明确来完成老板的需求。

第一个明确：老板不会突然提出需求，肯定会有前因后果。

产品经理在接到老板需求时，第一件要事就是弄清楚前因后果。老板有比产品经理更多的信息源，有些他不能说，有些他以为产品经理应该知道。

前因后果决定了需求提出的背景，了解背景对后续的工作至关重要。一是因为不知道背景在执行上可能跑偏；二是产品经理要根据背景有自己的思考。

第二个明确：老板有想要的结果。

老板要的永远都是结果，而不是具体做某件事情。因此只要能拿到结果，原则上哪种做法都是老板可以接受的。

那么在拿到结果的前提下，产品经理要思考：

不通过产品手段能验证吗？不要忘了产品经理有自己的节奏，这突如其来的需求，是否会打乱自己的版本计划。

怎么轻量化的尝试？在必须要用产品来实现时，轻量化、少打扰的拿到结果总是好的。

拿到结果，证明可行或者不可行，给出后续的计划和建议，就是对老板需求的好答复。

03、业务的需求看配合

业务，是指公司内部同事提出的需求，可能来自业务、市场、运营、客服等兄弟部门。

同事也不会平白无故的提出需求，他们最大的可能是因为产品对他的工作造成了影响，突然加大了工作量，因此提出需求期望产品经理去解决。

产品的完美上线需要各部门的紧密配合。产品经理要耐心的听完同事的抱怨，要清楚明白他们是产品的协作部门，不要硬刚、要哄。

对于可能对同事造成影响的产品需求上线，产品经理前期要思考透彻，提前告知：影响多大、影响多久、后期是否会改善，让他们有心里预期，做好充足准备。当资源不足时，也要配合同事积极申请资源。

同时，要跟同事画饼。讲清楚产品规划，现在的痛苦都是暂时的，当前只能通过配合一起完成。站在未来的角度打现在，无往不利。

不过若遇到大面积爆发问题，就要加紧改正、紧急上线，做到让同事满意。

让同事配合的舒服，他们提的需求自然也就少了。

04、客户的需求看业务

客户是 to B 的客户，客户的需求就是 B 端的需求。

B 端需求在于要清楚了解业务情况。客户提的需求是实际的流程需要，是线下流程的线上化。这时候要一切以业务为主。

但 B 端产品的阶段不同，需求的优先级完全不同。产品经理要准确的判断，比如在推广期缺少某个需求，可能就无法拓展客户使用。这个时候要以BD需求为第一优先级。

B端产品的收费方式不同，也决定需求的处理方式不同。免费、收费、不同等级的定制化，就有不同的需求对接方式。用户付费越多，响应需求的速度就需要越及时。

当客户大批量且个性化要求较多时，就需要用中台的概念承载，支持客户自定义，灵活可配置。

客户的需求来源于业务，产品经理就需要扎根于业务。用互联网的方式提升业务效率，才是客户需求的处理之道。

05、自身的需求看规划

还有，就是产品经理自身的需求。

产品经理在迭代的过程中，最重要、也是最容易忽略的就是自身的需求。

产品是产品经理的孩子，我们对产品有着怎样的规划，要以怎样的节奏拿到期望的结果呢？

自身的需求来自于产品目标，来源于季度规划，来源于 OKR 中的 O。目标拆解，规划好每个版本的功能以及进度节点，就是自身的产品节奏。

同时，在每次版本中都预留一些位置，插入可能出现的用户、老板、同事等各方面的需求。

这样就能在处理好新增需求的同时，做好版本把控，保证产品朝着自己期望的目标前进。

需求从各方来源汇集于产品经理，但迭代的版本只能一期一期的推进，每个版本能做的需求就那么几个，这时管理各方对需求的预期就非常重要。

预期管理的核心在于及时同步。在收到一方的需求后，就需要认真负责起来，需求的每一个进度节点都要同步给需求方。

需求做不做、什么时候做、做了效果如何？不做要明确的告知理由和可代替的方式，做了给出预计的上线时间和上线后的分析结果。

如此，我们的产品规划才有落地的可能。

最后

产品经理，不是需求粉碎机。

不一味的承接需求，不一味的专断独行，产品工作本就是决策权衡的过程。

需求不重要，问题才重要。没有谁的需求是第一优先级，有的是此刻当下最需要解决的问题。

毕竟，产品经理的定义就是解决问题，