提到PM（产品经理的简称，product manager），一个绕不开的词是需求。PM因为需求而存在，需求是孕育PM的土壤，高质量的需求可以培养出优秀的产品经理，如果没有需求，产品经理就不再被需要。
1、需求是什么
那么到底什么是需求？
要回答上面的问题，不妨先看下面的一个例子。
假设你是一家手机制造公司的产品经理，每天都会有人来和你反馈各种各样的问题。
今天有十个顾客想要绿色外壳的手机，但是我们只有黑白两种颜色的，能不能让工厂设计制造一些绿色手机给客户？我们的手机价格太贵了，有一些潜在的消费者因为价格原因选择了其他厂家的，我们能不能降价？有些客户觉得我们充电太慢了，能不能配备快充插头让充电快一点？
上面的这些问题，都可以理解为是用户的需求。
需求是一个场景，在这个场景中，用户遇到了问题，这个问题让他痛苦或者不爽。
至此，我们可以给出一个定义：谁在什么场景下遇到了什么问题，这个实际的场景就是一个需求。
2、需求的层次
需求是分层次的。
需求越细，场景越明确，但解决方案可以创造的价值越小；需求越粗，场景越宽泛，解决方案可以创造的价值越大。
比如一个年轻人中午肚子饿想吃东西，但是最近的餐馆离家3公里，他想打个车过去。这个需求可以描述为：一个年轻人在中午肚子饿、想去餐馆吃饭的场景下，遇到了路远走路太累的问题。
如果把需求定义为上述的场景，那么问题点在于出行需要代步工具，解决方案有打车、共享单车、电动车、公交、地铁等。
同样是上面的问题，需求可以这样描述：一个年轻人在中午肚子饿的场景下，遇到了想要吃饭的问题。
这时候解决方案就不止局限于出行了，而是能吃饱肚子的一切方式。做饭阿姨上门烧菜、外卖、方便面这类的自己可以做的速食食品、网上教人做饭的视频教程都是解决方案。
甚至更进一步，如果有一种吃了就不会饿的药物，价格足够便宜，大多数为了果腹的人都会选择它。那么对于餐饮企业、外卖平台、出行公司、网上的美食博主、炊具制造的公司、蔬菜水果的供应商都会有巨大的冲击。
3、需求有什么用
理解了需求是什么，对于PM来说，需求有什么用呢？
可以分两个角度来看。
对外方便和项目组明确要解决的问题，和相关方达成共识，利于互相配合和项目推进；同时能更好的向上协调、调用资源。对内可以确定任务的优先级。
首先说对外的好处。
第一点好处是，清晰的需求有利于项目组同事理解要解决的问题，相关方配合和项目推进也会更顺利。
PM自己单打独斗基本做不成任何事情，和研发、运营、设计等同事配合完成项目，才能拿到业务结果。
研发、运营、设计作为资源方，很多时候不怕加班加点去完成一个需求明确的项目，但很怕去做一件需求不明确的事情，因为如果需求不明确，很可能这个需求是不存在的，一堆人吭哧吭哧做完了，结果发现要解决的问题本身不存在，不是一件很可笑的事情吗？
什么是不明确的需求？
凡是不说人话，说出来爷爷奶奶听不懂的需求，就是不明确的需求。
这类需求的第一个特征是有很多的专有名词，包括行业公认的和PM自己创造的，像“用户体验、生态、社交元素、信息传递效率、声量”；第二个特征是别的公司都这么做，所以我们也要这么做。
一个明确的需求才能让相关方理解到底要解决什么问题，创造什么价值，从而更愿意配合你。
第二点好处是能更好的向上沟通、调用资源。
在层出不穷的需求面前，资源永远是紧张、无法满足所有需求的。
当出现两个需求同时调用一个资源时，会出现排优先级的情况，一个清晰的需求与一个说的人云里雾里的需求比，大概率是一个清晰的需求会排在前面。（如果你的leader很喜欢不清晰的需求，要么说明他的理解能力超强，能知道你在干什么，预期的结果是什么；要么说明他能力有限，对于优先级的判断比较混乱）
其次聊聊对内的好处。
清晰的需求可以让PM知道如何排列任务的优先级，在项目进行中接到有关的需求时，知道做哪些、不做哪些、先做哪些、后做哪些。
拿文章最开始提到手机的需求举例子，你是一个手机厂家的PM，你们公司提供的手机是为了满足农村低收入人群使用智能手机的需求，他们对于价格很敏感，能接受的上限在800元左右，对于手机的需要是能看短视频、玩游戏，电池足够耐用，充一次电可以玩一天。
这个时候，一线销售同事和你反馈，有一些农村的高收入人群，他们觉得800元的手机太便宜了，想买5000的，问你能不能生产高端机型？
如果你对产品满足的用户需求很清楚，那答案是显然的，不会去造高端机型。
但如果你没想清楚，觉得我们就是卖手机的，卖给谁不一样，那可能就会建生产线去生产高端机，最后因为资源被分散导致在性价比高的、便宜的机型上失去了竞争力。
知道不做什么比知道做什么更重要。
4、理解需求过程中的坑有哪些
最后一部分，我们来聊聊PM在理解需求过程中存在哪些坑，以及如何避免。
第一点，不理解真实业务场景，只承接需求，导致需求不够明确。
这种情况多出现在外包公司和内部的信息化部门，平时接触用户的机会不多，导致对于场景的理解不准确。
解决的方法有两个，一是多深入一线，多多陪访见用户，建立业务上的感知；二是和一线业务部门的关键角色定期约饭，了解业务部门近一年、近一个季度最重要的三件事。
第二点，将方案作为需求本身。
比如有位售后管理者询问我，能否给他提供一个SQL（数据工具），想看一些最近需要上门的门店。
这时候，不能简单的直接照他说的做，而要意识到他反馈的是一个方案，背后的场景是什么还不明确。
常用的方法是多问几个为什么，挖出实际场景。
我：为什么需要这个SQL？
售后管理者：安排工程师明天的工作要用到。
我：平时是怎么安排工程师一天工作的？
售后管理者：前一天下午先安排A类工单，然后安排B类，再给工程师留出一些时间响应紧急报修。
我：安排工单时有遇到什么问题吗？
售后管理者：有问题1、2、3。。。
我：这些问题现在是怎么解决的？
售后管理者：吧啦吧啦。。。
这个时候，你就清楚了，他要的不是一个SQL，而是需要安排工程师明天的任务时不知道安排给工程师哪些门店。
这时需要把派单的场景理解搞清楚，管理者派单时是怎么操作的？遇到了哪些问题？把这个场景了解清楚才是最关键的。
第三点，需求来源不可信。
比如别人给你提需求时说自己做了一个调研，但是调研的问题设计的有明显的引导性，并且选择的调研对象也是经过筛选的，这个时候要保持警惕了。
第四点，逻辑不通。
假设你是一家租车行老板，合作形式是一辆车一天租金100元，不管是否使用了汽车，合同里都有写，并且提前和顾客讲清楚了。
结果一位顾客租了一周车，最后还车的时候和你说，我虽然租了你的车，但是没怎么开过，所以你能不能不收我的钱？
这时候，不能在应不应该收钱的角度去思考问题，因为顾客要求免费的逻辑是说不通的。
这时要从怎么提前发现这种情况，尽早解除协议，让双方受益；以及如果遇到利益产生纠纷时，应该如何妥善处理，在利润、口碑、客户满意等更高的角度去思考问题。
