在这一系列过程中，都需要产品经理做好需求管理工作。这是针对需求管理的系列文章，共计五篇，这是第一篇。在需求管理的第一阶段，产品经理首先要对不同渠道的需求分门别类的管理。可能来自市场、运营、客服等配合部门。产品的完美上线需要各部门的紧密配合。自身的需求来自于产品目标，来源于季度规划，来源于OKRs中的O。预期管理在于及时同步。需求做不做，不做要明确的告知理由和可代替的方式。
本文从需求来源的五类渠道——用户/老板/同事/客户/自身，分析了产品经理应当如何处理这几方的需求。
需求，是产品经理工作中接触最广泛的词。不管是来自用户还是老板，产品经理总会收到各种各样的需求。
产品经理需要在接到需求时辨别真伪、在迭代时排列需求优先级、在开发时处理需求变更、在上线后分析需求效果给出反馈。在这一系列过程中，都需要产品经理做好需求管理工作。
这是针对需求管理的系列文章，共计五篇，这是第一篇。
需求，在经济学中代表用户愿意且能够购买的商品数量。在产品中是用户期望达到某种目的所提出的问题或建议。
需求，不是一个单纯的名词。在需求被提出时，对于提出方是结束，但对于产品经理则是工作的开始，需要打出一套组合拳来承接。至少包含问题梳理、可行性分析、方案选择和具体执行四个方面。
在需求管理的第一阶段，产品经理首先要对不同渠道的需求分门别类的管理。因为需求来源不同，后续对接的做法完全不同。
需求从来源渠道上大致可以分为用户、老板、同事、客户、自身等五方。那么，这几方的需求产品经理应当如何处理呢？
01 用户的需求看问题产品是给用户使用的。那么产品是否符合用户预期、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的，就需要产品经理时刻保持关注。
长链接是保持关注用户需求的常用方式。建立长链接需要找到快速触达用户的方式，可以是收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体中。
具体链接形式不太重要，核心在于能够听到用户的真实表达。比如在访谈时，不要预设有引导性的问题。但是，用户一般不会主动提出需求或者表达想要什么功能，尤其是产品流程相对完善后，用户基本就不会提出建议了，更多是发牢骚和吐槽。
在产品发展的前期要产品经理要找到和关注KOL，在需求上听从他们的建议，根据他们的反馈做产品流程优化，使得产品快速从0到1。
有区别的是，在产品发展的上升期和稳定期，要谨慎对待KOL的需求，他们毕竟只代表小部分用户，大部分用户都是小白，可能用不到KOL的专业诉求。
那这时候用户的需求体现在什么地方呢？
更多的体现在观察用户的使用感受上，从他们的牢骚和吐槽中定位到背后的真实问题，根据他们的实际反馈来不断的调整力度，完善产品。
02 老板的需求看目的老板，是需求的另一来源。大部分情况是，老板提了一个需求，让产品经理去执行。这个时候就要采用对用户完全不同的做法了。
用两个明确来完成老板的需求：
第一个明确：老板不会突然提出需求，肯定会有前因后果
产品经理在接到老板需求时，第一件要事就是弄清楚前因后果。老板有比产品经理更多的信息源，有些他不能说，有些他以为产品经理应该知道。
前因后果决定了需求提出的背景，了解背景对后续的工作至关重要。
- 一是因为不知道背景在执行上可能跑偏；
- 二是产品经理要根据背景有自己的思考。
第二个明确：老板有想要的结果
老板要的永远都是结果，而不是具体做某件事情。因此只要能拿到结果，原则上哪种做法都是老板可以接受的。
那么在拿到结果的前提下，产品经理要思考：
不通过产品手段能验证吗？不要忘了产品经理有自己的节奏，这突如其来的需求，是否会打乱自己的版本计划。
怎么轻量化的尝试？在必须要用产品来实现时，轻量化、少打扰的拿到结果总是好的。
拿到结果，证明可行或者不可行，给出后续的计划和建议，就是对老板需求的好答复。
03 同事的需求看配合同事，也是需求的提出方。可能来自市场、运营、客服等配合部门。
同事也不会平白无故的提出需求，他们最大的可能是因为产品对他的工作造成了影响，突然加大了工作量，因此提出需求期望产品经理去解决。
产品的完美上线需要各部门的紧密配合。产品经理要耐心的听完同事的抱怨，要清楚明白他们是产品的协作部门，不要硬刚，要哄。对于可能对同事造成影响的产品需求上线，产品经理前期要思考透彻，提前告知：影响多大、影响多久、后期是否会改善。让他们有心里预期，做好充足准备。当资源不足时，也要配合同事积极申请资源。
同时，要跟同事画饼。讲清楚产品规划，现在的痛苦都是暂时的，当前只能通过配合一起完成。站在未来的角度打现在，无往不利。
不过若遇到大面积爆发问题，就要加紧改正、紧急上线，做到让同事满意。
让同事配合的舒服，他们提的需求自然也就少了。
04 客户的需求看业务客户是 to B 的客户。客户的需求就是B 端的需求。
B 端需求在于要清楚了解业务情况。客户提的需求是实际的业务需要，是已有流程的互联网化。这时候要一切以业务为主。
B 端产品的阶段不同，需求的优先级可能是完全不同的。产品经理要准确的判断。比如在推广期缺少某个需求，可能就无法拓展客户使用。这个时候要以BD需求为第一优先级。
B端产品的收费方式不同，也决定需求的处理方式不同。免费、收费、不同等级的定制化，就有不同的需求对接方式。用户付费越多，响应需求的速度就需要越及时。
当客户是大批量，且个性化要求较高时，就需要用中台的概念承载，支持客户自定义，灵活可配置。
客户的需求来源于业务，产品经理就需要扎根于业务。用互联网的方式提升业务效率，才是客户需求的处理之道。
05 自身的需求看规划还有，就是产品经理自身的需求。
产品经理在迭代的过程中，最重要、也是最容易忽略的就是自身的需求。
产品是产品经理的孩子，自己对产品有着怎样的规划，要以怎样的节奏拿到期望的结果呢。
自身的需求来自于产品目标，来源于季度规划，来源于 OKRs 中的 O。
目标拆解，规划好每个版本的功能以及进度节点，就是自身的产品节奏。
同时，在每次版本中都预留一些位置，插入可能出现的用户、老板、同事等各方面的需求。这样就能在处理好新增需求的同时，也做好版本把控，保证产品朝着自己期望的目标前进。
06 管理各方的预期需求从各方来源汇集于产品经理，但迭代的版本只能一期一期的推进，每个版本能做的需求就那么几个，这时管理各方对需求的预期就显得非常重要。
预期管理在于及时同步。在收到一方的需求后，就需要认真负责起来，需求的每一个进度节点都要同步给需求方。
需求做不做，不做要明确的告知理由和可代替的方式。什么时间做，预计什么时间上线，上线排期较晚也要解释缘由，使其理解。上线后的效果如何，是否达到需求方的要求，后续有什么优化和改进的计划等。
尽职尽责，善待每个需求方，愿大家都能处理好各方需求。
作者：王海，公众号：产品经理第七班（ID：wanghai-pm）
本文由 @王海 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
,
