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

编辑导语:产品经理在曰常工作中会接收到很多需qiú,对于这些需qiú产品经理需要有一定的判断,可用的需qiú也要持续跟进;产品经理在工作中也会X到多方面的人,各方的需qiú也不一样;本文作者分享了关于产品经理被需qiú方左右思维的现象,我们一起来看一下。

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

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

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

一、需qiú的来源

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

1. 不shuǎng就走的用户

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

2. 唯我独尊的运营

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

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

3. 经常甩锅的技术

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

4. 不切实际的X

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

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

5. 天马星空的老板

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

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

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

二、需qiú的真伪

需qiú方提了这么多需qiú,到底什么样的需qiú是真需qiú,什么样的需qiú是伪需qiú。

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

那么发现问题本质的方式呢有身临其境的去体验和用户走一样的liú程去感受用户遇到的问题;X用户问卷调研或者用户访谈等方fǎ去发现问题的本质,来判断这个需qiú到底能否解决用户真正的问题。

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

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

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

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

三、需qiú怎么做

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

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

1. 需qiú池

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

当我们有了需qiú池,对需qiú进行管理后,那么到底我们该先做哪个后做哪个呢?

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

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

2. 需qiú可行性

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

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

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

3. 需qiú实现节奏

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

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

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

四、总结

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

产品经理不实现需qiú,只解决需qiú背后的问题。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 99%的产品经理都被需求方左右过思维,你有过吗? https://www.xiongfawang.com/1351.html

常见问题

相关文章

99%的产品经理都被需求方左右过思维,你有过吗?-海报

分享本文封面