产品经理应该如何解决各种需求
编辑导语:作为产品经理,日常工作中少不了解决各种需求的时候,本文作者分享了产品经理解决需求的相关方法,根据自身工作经验分析了解决需求的思路等,一起来看,希望对你有帮助。
A同学:啊好烦呐,公司其他部门每天怎么提出来这么多需求啊!
B同学:真是无语!刚入职一周就要处理这么多需求,都是一些前几个月没有解决的需求都要压在我身上了!
作为产品经理来说,每天会面对不同人员提出的不同需求,那么我们面对这么多的需求,我们是如何做判断的呢,如何去整理归纳呢?
哪些需求是当下最应该解决的需求呢?以下我为大家去总结了一些个人的一些经验供大家参考使用。
一、真、伪需求
需求可以分为真伪需求,真需求就是用户真正的需要,比如:我们去商场买一条裙子,这个裙子很好看,价格对我来说也挺合适,那么我就买了这一条裙子,我的真需求就是这个夏天缺一条这样的裙子。
伪需求就是,用户有某种需求但在某种场合不好意思说出口。
同样去商场买裙子,这个裙子很好看,很合适,但是由于价格太高,我不好意思说出来,那么一般就会说,这个裙子的颜色不好看,等等理由,那么这时,我提出的颜色不好看就是属于伪需求了,我就是觉得价格贵,不好意思说出口,说出来了会让人笑话。
所以产品经理需要对需求进行自己的分析整理,往往在工作中,用户可能表达出来的需求并不是真实需求,我们需要对需求进行深挖,发掘用户的根本目的是什么。
再去对照需求去实现相对应的功能,不然这些功能做出来也无济于事。所以这里我也也想说,产品经理不是为了功能去做功能,要去看用户为什么需要这个功能。
二、需求的收集、整理、分析三部曲
做过To C的产品朋友应该都知道,产品是更注重拉新、促活、留存、变现,产品的方向是更偏重于运营。
往往产品都是免费给普通大众去使用的,产品的也比较容易上手去使用的,用户的逃离成本也比较低。
包括盈利模式也是以流量变现、广告变现为主。
To B的产品往往是面对于企业的,客户使用往往是需要支付费用的,系统也是有一点的复杂程度的,需要产品经理等研发人员去培训客户,所以客户的逃离成本也比较大。
盈利模式也是以买断或收取年费等为主,所以在收集需求方面也会有一定的不同,偏重点也会有变化。
1. 收集
那么C端产品在0-1的开发时,前期需求的来源有很多方式:竞品、行业分析报告、行业资深人士的访谈、用户的问卷调查、公司内部不同岗位的头脑风暴、甚至是老板的需求等等。
B端产品往往需求的来源会比较简单:做外包就是甲方客户为主导,通过对甲方公司的不同人群的狙击访谈等方式,在这里需要注意的是面对不同身份的访谈需要注意方式方法。
系统是公司自己研发的,给内部去使用,需求的来源肯能更多的就是本公司的人员、老板。
那么在时间上外包项目也是比较赶工期的,肯能在时间把控上需要进行控制,自研的给公司内部使用的系统研发时间包括项目的排期可能会比较宽松,按部就班,哪一步出了问题就停下来去解决。
所以面对不同的公司不同的行业要讲究收集的方式方法以及经验。
2. 整理
根据以上的需求进行收集后,我们前期讲究的是横向收集,也就是收集需求不问对错,注重收集需求的广度以及数量。
在有了这么多的需求后,我们产品经理要做的是把他们都放在需求池里,在需求池里进行分析整理。
3. 分析
就是纵向分析,像一个T字形,对需求的本质进行深挖。那么刚刚提到过的需求池是什么呢?
就是把需求做定义,谁提出的、用户提出的需求内容是什么、这个需求的底层需求是什么、以及运用Kanon模型把需求分为:必备型、期望型、魅力型、反向型、无差异型。
通过分析提炼出当下符合产品的版本、公司目前的情况的需求,那么我们在分析时需要分析需求的广度(多少人需要的)、需求的频率(用户多长时间需要一次)、时间节点(哪个版本该上)、用户的痛度(这个需求的痛点有多痛,用户离开这个需求还能不能继续使用产品)。
还有一些方法,比如马斯洛需求原理等方式去对需求进行分层等等在这里就不细说了,感兴趣的同学可以私信我或度娘一下。
三、需求落地
以上通过收集、整理、分析了需求之后,我们产品经理需要对需求进行落地,通过需求分析文档、需求的优先级排表、去把用户的痛点找到后,提出解决方案,把这些解决方案再去交给客户、公司内部的技术人员去看、这里我经常是开一些需求评审会议。
通过会议的方式让不同人员用不同维度进行需求的评定,这里我们需要组织和记录、产出一些会议纪要,再根据会议的内容去修改需求,反反复复,一直到需求评审会议里找不到问题后,再进行原型功能的设计。
所有的工作一多了就会显得一些枯燥无味,那么我们要学会找到方式方法去面对这些困难!知难而退,碌碌无为,只有因难而上,才能无坚不摧!
本文由 @汪仔6447 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
大多数的时候,需求文档和原型是一起产出的,需求文档修改几遍,业务原型也需要反复修改,这来来回回的时间,都是算在需求建设周期之内的,现在的需求来了就是急活,没有那么多反复确认的过程
根据每个业务的习惯、公司的流程、实际产品的情况而定,感谢您的意见~
知识点满满的文章,作者分享产品经理解决各种需求的方法非常适用。
感谢您的支持~