99%的产品经理都被需求方左右过思维，你有过吗？

每个产品经理在工作中都会遇到各类需求方提到的各种需求，对于产品力不足的产品经理往往在接收到需求后，脑海里都在想着怎么去实现它，这个需求对应的功能该长什么样，页面该怎么交互，逻辑是什么，想到的肯定是这些东西。

而那些高阶产品接收到需求后，首先不会想着去怎么实现，而且先去判断需求的真实性，这个需求是想要解决什么样的问题，哪些用户在什么情况下遇到什么样的问题，才会引发出需求方提出这样的需求；所以产品经理需要的是解决问题而不是满足需求，不同阶段的产品有着不同的职责及思维方式，但是当遇到需求时不要先被需求左右思维。

在汽车没有出现之前，如果需求方告诉你用户需要一批更快的马，那么如果不了解用户实际需求是想最短时间最快到一个地方去；你就可能会听需求方的挑一匹更快的马，而不是解决用户的问题快速到达某一个地方，就不会造出汽车这个产品。

一、需求的来源

作为产品经理可能接收到需求的主要来源有用户、运营、销售、技术以及老板等，当然不同的产品经理岗位对接的需求方各不相同；像B端产品针对的用户有可能是同事或者企业，所以需求来源主要就是这个几部分。

1. 不爽就走的用户

很多公司都是运营侧面多用户多一些，大部分用户需求由运营提出，但是产品经理更应该去洞察用户需求，发现用户问题，进而解决问题；发现问题的渠道有很多比如用户反馈、应用商店评价、产品经理客服听音、用户调研等，不是所有的反馈都是有着正向价值的，也不是所有问题都是要解决的，这就考验产品经理发现问题及分析问题的能力。

2. 唯我独尊的运营

运营一般是最大的需求供应商，很多需求都是运营提的，每个公司对运营的划分也不一样；针对实际的业务划分不同的运营部门，很多运营提需求的时候不是提遇到什么问题，而是我想要什么，直接给的是方案；比如用户反馈密码登录复杂，就提一个增加验证码登录的需求，可能用户真正的问题是密码在设置的时候由于密码设置复杂度或长度导致用户需要来回切换字母数字与字符导致的。

所以运营很多时候提的是需求更是解决方案，那么作为产品经理当接受到这样的问题时应该搞清楚什么样的用户在什么场景下遇到了什么样的问题；再去分析这个需求，给出解决方案，而不是直接按照运营提的增加一个验证码登录。

3. 经常甩锅的技术

一般公司技术提给产品的需求都是一些性能优化的需求，实际因为功能影响了整体的性能，所以会给产品提优化需求，一般都是合理的；比如进入某一列表由于查询字段较多，需要从不同的数据库查询，降低了接口反应速度，甚至可能导致服务器宕机等会要求产品经理删减不必要或影响不大的字段；当然这种需求也有技术架构前期搭建的不合理或小公司资源紧张服务器的容量低导致的。

4. 不切实际的销售

可能最让产品头疼的需求方应该就是销售或者商务了，为了销售额或达成合作，本是造游艇的能力，结果非给对方说我们可以造航空母舰，而且还是那种快速一组装就能用的，一副立刻马上我不管我就要的姿态。

为了公司业务的发展也能理解销售的苦衷，但是很多需求提的毫无章法，客户要这个、客户想那个，那么产品经理就要去了解客户背后的实际需求，并且根据需求寻找所有客户需求的共性；是不是所有客户都有这方面的需求，如果没有单做这个需求的必要性是不是足够大，除非这个客户是一个大金主，公司愿意投入资源为其单独开发。

5. 天马星空的老板

说到老板的需求，可能每个产品经理都是一肚子苦水，老板的需求一般会分为是三部分——战略性体验性需求、创造性需求、借鉴性需求。

老板会基于行业及公司发展提出战略规划需求以及自身使用产品和对产品的敏感度提出体验性优化求，就是用户代表，毕竟老板的能力不是盖的；创造性需求呢就是纯属天马星空式的，我就是要五彩斑斓的黑；借鉴性需求呢就是看竞品及其他产品能否应用到自身产品上。

以上称呼仅为场景需要，不特指不泛指不冠名。

二、需求的真伪

需求方提了这么多需求，到底什么样的需求是真需求，什么样的需求是伪需求。

当遇到需求时我们应该挖掘需求的本质，用户或者需求方在什么场景下遇到了什么问题，这个需求核心要解决的是什么，然后找到需求本质给出解决方案，最后产出产品方案。

那么发现问题本质的方式呢有身临其境的去体验和用户走一样的流程去感受用户遇到的问题；通过用户问卷调研或者用户访谈等方法去发现问题的本质，来判断这个需求到底能否解决用户真正的问题。

前两年共享经济特别火的时候，各种共享产品出现，当共享充电宝出现的时候，某思聪就说这个充电宝没有场景，做不起来；实际上可能他没有这样的痛点，对于共享充电宝这个产品确实解决了户外手机没有电的痛点。

目前各类短视频APP，游戏等都是吞电兽，就算不玩正常待机也非常的耗电；所以共享充电宝就是解决这样的用户痛点，随借随还，用户发生租借的场景很广，而且成本很低；当然目前充电费用还是很贵，毕竟圈养肥了——有场景、有需求、并且需求为高发需求，所以共享充电宝能火。

那相比共享雨伞这个就是一个伪需求，首先伞的场景就是挡雨和遮阳，在挡雨这个场景一般像突如其来的雨恰好没带伞或没有避雨的地方才会感觉到痛点；我从来不会因为出门没带伞下雨淋雨而焦虑而不安，所以大部分针对这个场景是不存在的；就算下雨地铁口卖伞的也很多，10元一把没有任何的心理附加成本，借伞后你还会考虑还的问题。

对于遮阳这个场景更是几乎不存在，首先遮阳几乎都是女性群体，女生又特别爱美，基本不会去租借那么丑的伞去用，所以整体来讲共享雨伞就是一个伪需求。

三、需求怎么做

那么当需求方提的需求后，当我们认为需求可行时到底该怎么去完成这些需求，到底是先做哪个再做哪个，直接上线一个大项目还是分阶段进行上线都是需要产品经理考虑的。

那么常用的就是最小化可行性试验，经常说的“MVP”的形式进行快速试验需求的可行性；先做哪个再做哪个那就看需求的紧急程度及价值的高低，这里常用需求池的方法进行管理需求。

1. 需求池

每一位产品经理都应该有自己的需求池，这样才能科学的管理需求方所有的需求，那么需求池也有助于自己对产品整体进行合理的规划；通过需求池也能清晰的知道每一版本该做什么样的迭代以及每一个需求的核心价值及实现目标，那么等功能上线后通过数据监测及分析看是否达到之前所需要解决的问题。

当我们有了需求池，对需求进行管理后，那么到底我们该先做哪个后做哪个呢？

对于需求方来讲每个人的需求都是重要且紧急的事情，这时候需求方就各种的来讲关系了，资源有限我们就是让有限的资源发挥最大的作用。

首先按照优先级删选出最优级别的需求，然后按照收益进行排序，并且根据四象限原则划分出哪些需求是重要且紧急、重要不紧急、不重要紧急、不重要不紧急；然后重点关注重要不紧急的需求——为什么这里我们重点关注重要不紧急呢？因为紧急且重要的是我们必须要做的，但是如果全都是紧急重要，那么我们在时间管理需求管理的方式上就存在问题，我们应该重点是计划做，而并立刻马上做，这样对于需求的完成度和思考完整度才会有保证。

2. 需求可行性

很多人都会说只有想不到的没有做不到的，目前是这样，只要能想到就能做到除非当前技术达不到；这里所指的可行性说的是“成本问题”，这里的成本有时间成本，人员投入成本和资源投入成本。

比如当前业务正是高速发展的时候，需求方一个需求需要大部分开发人员投入一个月甚至更久的时间去完成，那么对于此时公司的状态这种方案显然是不可取的；再有甚者就是一块小小的改动需要底层的架构进行调整，那么此时这个方案是否可行，则需要整体进行把控。

所以产品经理在做任何需求时应该对整个需求所涉及的开发量及难度有一个大概的预估，如果预估不来可以出一个大概框架找技术沟通；如果是大需求可以将方案进行分步实现，避免出现大量资源占用或者目前架构实现不了等问题，耽误需求的进度。

3. 需求实现节奏

很多产品在拿到需求后，会进行需求分析、设计产品方案、设计界面、技术评审、开发测试上线等流程；其实在我们有了产品方案后，应该要不怕麻烦，需要多次和需求方沟通方案是否解决了他们的问题（解决问题并非满足需求），可能需求方会提出质疑，比如为什么没有我要的是一匹马而你要给我造个汽车呢？

我们需要将每个方案的需求及需求所面临的问题和需求方沟通清楚，如果是功能迭代目前线上是什么样的，有什么样的问题，根据需求实际用户遇到的问题是什么样的，所以才会出这样的产品方案；在进入开发之前一定要和需求方沟通的特别清楚，让他明白你的方案就是解决他提出需求所对的问题。

切记开发前不和需求方沟通方案，这样无伦是在开发过程还是方案上线后，一旦需求方不理解这个方案是否能解决自己的问题，就会存在各种扯皮现象，如果需求方不认可，则就浪费了资源。

四、总结

当我们拿到需求后，切记不要让需求方的需求限制思维，直接去画原型或者脑海里想怎么实现；而是先要思考这个需求所要解决的问题是什么，搞清楚什么样的用户在什么场景下遇到这样的问题，那么解决这个问题的方案能有哪些，哪个方案是最优的能带来最大效果的；然后将需求归入到需求池，根据四象限原则进行排序；产出产品方案后需要与需求方确定问题解决的方案的可行性以及技术沟通方案实现的可行性。

产品经理不实现需求，只解决需求背后的问题。

本文作者 @北漂青年 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！