需求池管理的常见思路(5点简介需求池管理)

前段时间,我跟几位产品新同学讨论一个问题,产品经理的职责是什么?大家七嘴八舌说了很多,有的说项目管理、有的说功能设计、有的说用户调研,当然,这些都是,其中有个同学回答说:“做需求”,产品经理就是一个做需求的。

诶,我就问他,为什么是做需求呢,他说每一个需求,都是以上这些内容的总和,每一个需求,都包含了用户调研、功能设计、项目管理、资源协调,所以说,产品经理就是做需求的,这没毛病。

可是,做需求只是表象,再往深了想,做需求,其实也是为了解决用户或者客户的实际问题。因此,我觉得说产品经理的职责是「解决问题」,更准确一点。“解决问题”是产品经理的职责,“做需求”是产品经理工作的主要内容。

那我们就说说“需求”。

需求这个话题聊的人太多了,不少前辈、大佬、专家,都深入阐述过,产品新人入门导师苏杰、刘飞、王诗沐、俞军几位老师,在他们的著作中,也用了大量的篇幅来讲需求。站在前人的肩膀上,结合自己的一些思考,我也想同读者分享一下,我对于“需求”的理解。

目录

需求是什么?

两个需求理论

需求从哪儿来?

需求的误区

需求的思维公式

01需求是什么?

生活中,我们经常会有一些行为,这些行为背后,是因为我们有相应的诉求。

临近夏天,天气越来越热,走在街上,忍不住买一根雪糕。

买了一屋子盲盒。

认识到学习的价值,购买了很多付费课程。

以上三个案例,都是最后表现出来的行为。这种行为,分别对应着各自的诉求:买雪糕是因为热,想要获得降温快感的诉求;买盲盒是满足收集欲和好奇心的诉求;买课程是为了满足提升能力、缓解焦虑,然后找到更好工作,或者升值加薪的诉求。

这个“行为背后的诉求”,其实就是需求。

所以我们可以给需求下一个定义:需求是行为背后的诉求。

基于这个定义,我们可以发现,任何行业,其实都有需求的概念,需求这件事,不仅仅存在于互联网产品上,其他的建筑行业、汽车行业、纺织行业等等,都同样通过挖掘用户背后的需求,来实现产品的创新和进步。

对应到产品经理的职业上,我们这个“做需求”,做的是什么“需求”?

产品经理成长过程中,一套思考的全流程,应该是:归纳现象-发现问题-拆解问题-分类问题-提出解决方案-回归分析-发现新问题。

简化来讲,就是:发现问题——归纳核心痛点——解决方案。

这其中的“解决方案”,就成了产品经理工作中所要完成的需求。这是产品经理接触最多的工作内容,也是产品工作的核心。只有通过优雅高效的解决方案,才能真正解决用户痛点,实现产品经理存在的价值。

02两个需求理论

正因为“需求”是一个常悟常新的话题,在绵延的历史长河中,也有很多经典的、历久不衰的需求理论。

对于产品经理,有两个非常经典的需求理论,就是“马斯洛需求层次理论”和“KANO模型”。

需求池管理的常见思路(5点简介需求池管理)

图1:马斯洛需求层次理论

马斯洛需求层次理论就不用多说了,初高中的时候课本里就提到过。马斯洛把一个人的需求分为生理需求、安全需求、社交需求、尊重需求和自我实现的需求,一般来说,这五个需求映射到产品上,则越是金字塔底部的需求,需求面越大,但ARPU可能越小,比如肚子不饿的生理需求,10块钱的炒粉就可以满足。

图2:KANO模型

KANO模型,是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。

KANO模型把产品需求分成五类:

1.基础型需求

基础性需求是一个产品最基础的功能,这个需求不能够被满足,则产品就不能正常使用,比如IM软件的打字聊天功能,美颜软件的拍摄功能等等。

2.期望型需求

3.兴奋(魅力)型需求

图3:拍一拍和动态表情

4.无差异型需求

无差异性需求则是用户并不在意的需求,无论有或没有,用户体验都并不会产生较大的影响,用户满意度也并不会提高或降低。做无差异性需求看似是一个鸡肋的、无意义的行为,但在当下互联网产品大幅度内卷的情况下,几乎每个平台类APP都在疯狂堆砌这些功能,试图抢占用户时间——打车软件做团购、团购软件做打车、地图软件做购物、工具软件做内容,这大抵就是做产品的歧路罢(当然,实际上也有公司战略的考虑)。

5.反向型需求

顾名思义,反向型需求就是做了之后,用户体验和用户满意度会下降的需求。在这里我忍不住要吐槽知乎,现在的知乎,充斥着各种小故事小短文,最关键的是,小故事读着正爽,来了一句“最低0.3元/天开通会员,查看完整内容”,掐死知乎的心思都有了。

值得一说的是,现在的互联网产品中,反向型需求一般是因为商业诉求同用户体验产生了矛盾,做产品是为了盈利,追求效益无可厚非,而产品经理,就要在商业诉求和用户体验中反复横跳,做放纵与克制间的守夜人。

图4:知乎开会员

马斯洛需求层次理论,说得是人性。KANO模型,对应着产品功能。

这两个理论经过多年的发展,其内涵已经足够丰富,许多新的产品理论,也大多脱胎于类似的理念,异曲而同工。

这些“新产品理论”中,梁宁老师格外推崇的“痛点爽点痒点”理论,是非常热门的概念。

痛点是恐惧,上班马上就迟到,迟到就要被扣工资,这时候地铁口有一辆共享单车,非常及时地解决了即将迟到的恐惧,这就是痛点;

爽点是即时满足,周六的早晨一觉醒来已经是中午,依然不想起床,躺在床上动动手指,外卖就送到家门口,暂时的快乐得以满足,这就是爽点;

痒点是虚拟自我实现,看着直播里的小姐姐,甜甜地说giegie你好厉害,你立刻幻想到了迎娶白富美,马上一个火箭送出去,这就是因为满足了用户对于自己的虚拟想象,最近特别流行的“头上长摄像头”短视频,也是一样的道理。

03需求从哪儿来?

了解了需求是什么,也学习了关于需求的理论,作为一名产品经理,归根结底还是要执行力。那落到操作层面,需求到底从哪儿来?

业内有一个非常经典的栗子:索尼要为一款即将面市的游戏机做一个调研,请了很多目标用户来公司,收集用户对于样品的反馈,其中一项就是询问用户希望这款游戏机是什么颜色(有黄色及黑色),很多人在被问及这个问题时,都答了黄色,索尼就认为,黄色的游戏机更受欢迎。

但最后,访谈结束时,索尼公司提出,用户可以从门口随意挑选一个颜色的游戏机带走,以感谢他们参加此次用户访谈,结果时候统计数据却发现,用户们在实际挑选时,纷纷选择了黑色的游戏机。

用户是微观,定性;数据是宏观,定量。

产品经理拍脑袋。不得不说,挺多需求确实是拍脑袋拍出来的……原因挺多的,但也要尽量避免。

协同部门。尤其是体量比较大的产品,产品经理距离客户/用户的距离,其实没有那么近,一线的很多用户反馈,往往并不能直接传达给产品团队,大多数情况下,是销售、客服、市场等协同部门的同事去响应。所以,协同部门就会定期向产品团队反馈需求。

协同部门提出的需求,一般分为两类,一类是“用户希望怎样”,一类是“我们(协同部门)希望怎样”。前者,是一线协同部门把用户反馈过来的问题,传递给产品团队;后者,则是一线部门为了自身的KPI或者工作量,而提出的需求,比如销售部门为了更好的售卖产品,就会不断反馈要求获得产品中更多的入口、更多的弹窗。

针对协同部门的需求,产品经理要做的,首先是要分类整理,判断哪些需求是产品真实存在的问题,哪些是协同部门对于产品规则理解不深刻的问题。针对用户真实存在的问题,又要往深层次思考,用户的核心诉求是什么,进而根据优先级,提出产品方案。

用户很热,想买雪糕,但她正好在姨妈期,如果直接听用户的,就会导致她肚子疼,这个时候,产品经理可以带她去吹空调,解决“热”的问题。“热”是核心问题,“吃雪糕”和“吹空调”都是解决方案,选择哪个解决方案,要结合具体的情况而定。(风险提示:这里就是举个例子,谈恋爱不能太“产品思维”[旺柴]。)

04需求的误区

误区一:自己代表用户

前段时间有一个问题讨论得特别火,“产品经理要不要变成自己产品的用户?”有正方认为产品经理只有是产品的核心用户,才能更好地找到目标用户的痛点;反方则认为,对于产品经理来说,冷峻理智地站在上帝视角,才是把产品做好的重要法门。

其实对于这个问题,往深层次思考其实是产品经理的同理心。产品经理既需要客观全面的看待整个产品,也需要瞬间把自己切换到用户视角来提升体验和发现漏洞,对用户有同理心,能够站在用户的视角看待需求。产品经理本身就是这样一个反复跳转的角色,小白用户、资深用户、产品上帝、老板视角,等等等等,这些角色可能每天都要转变几十次。

用户视角看产品,是发现产品问题的一个妙招,但过于依赖这个办法,就会走火入魔。很多产品经理恰好是自己产品的受众,这是一件非常幸运和幸福的事情,但这种情况下,就要格外注意,你要做的功能,是你自己的需求,还是用户的需求?

在产品经理自认为自己是目标用户后,往往会陷入“我自己就是用户,我能代表目标用户群体”这个死胡同当中。最后的结果当然是一场赌博,意外命中了群体需求,那就赚了;如果没赌中,可能就是一个鸡肋的功能,在后期做减法的时候痛不欲生。

这个误区归根结底还是需求调研不充分的问题,依赖主管臆断,陷入经验主义,导致需求偏向。

误区二:确定了产品强行找用户

我之前做过一个产品,是因为老板觉得小众音乐在未来很有市场,应该做一个产品提前占位,就立项了一个创新项目。先定了小众音乐这条赛道,才开始想满足什么需求,甚至才开始为了这个已经定好了方向的项目招聘产品经理。

但现实情况是,产品的痛点和需求并非源自实际的用户群体,只能根据竞品先做了一些功能,然后开始想,哪些用户可能喜欢这些功能,这样倒推回来,确实能够找到一个差不多的目标用户群体写在MRD、PRD里,但事实呢,这些“先有了功能后定下来的目标群体”本身没有任何的动力使用产品。结局自然是可预料的,公司砸钱砸出来几万用户,补贴一停用户就流失,产品就这么不了了之,后来业务调整裁撤了。

误区三:只抓住表象,不能深层次思考需求背后的动机

在拿到一个需求时,我们要思考,这个需求深层次的动机是什么。我刚做产品的时候,经常会被用户提得反馈牵着走,用户经常会说,“这个功能有问题,应该这样做那样做”,我一听还觉得挺有道理,就被带跑了。但其实不应该这样,用户或者老板在提出一个需求的时候,我们要深层次地想一想,他们为什么提出这个需求,是有更多的期待没有被满足,还是这个功能的流程逻辑有漏洞。

用户的需求反馈往往带着主观的影响,一些有想法的用户在提反馈的时候,也会带上一个设想的解决方案,毕竟“人人都是产品经理”,但作为职业的产品经理,还是要理智地思考思考,把需求背后的动机挖掘出来,才能解决更核心的问题,才能提高更多用户的体验。

之前在写互联网销售的文章中,我引用过“卖钻讲孔”的故事,其实这个故事是从王诗沐老师的《幕后产品》中学到的。客户要买一个钻头,我们应该看到他买钻头是想打一个孔,他的真正需求是打孔,我们如果能够给他提供一整套打孔的解决方案,是不是更加符合客户的心意?这样深挖需求动机的思考,是职业产品经理所不能绕开的。

误区四:以偏概全,以孤例代表整体,陷入小众用户的自我束缚

对于产品经理来说,因为产品要服务的用户很多,即便都是同一类目标用户,也会因为用户的圈层而产生需求的差异。产品经理不可能面面俱到每一个用户,因此就必然要在功能上予以取舍。

小众用户的需求是需求吗?当然是,即使是小众的需求,也应当纳入产品经理的需求池当中。但是否要做、什么时候做、怎么做,这三个问题还是要想清楚。相对于“自己代表用户”这个误区,小众需求确实是命中了需求,但小众需求无法与大众市场相连接,从更宏观的视角来看,性价比并不高。

做一些小众需求,的确能够产生比较不错的口碑,但把过多的精力和资源放在小众需求上,某种程度也是在伤害主流用户的体验。需求的把握同样需要遵循二八法则,即优先满足80%用户的主流需求,优先考虑更大众化的痛点,保证大多数用户的体验。

至于小众需求怎么处理,有两种思路。一种是先暂时延期,等到大众需求基本满足,产品主流用户增量见顶,开始寻找额外增量的时候,通过满足小众群体的需要,来寻求产品突破点;另外一种则是找到小众需求和大众需求的相通之处,深入挖掘深层次需要,既提高了主流用户的体验,同时也用一种更加优雅的方式解决了这些小众需求。

误区五:需求确实存在,但不符合产品整体目标

我们常说产品经理是CEO的预科班,做一家公司,必须要明确公司的目标、愿景,对于一个产品来说,思考它的整体目标是一件至关重要的事情。

正如前面所说,产品经理会面临各种各样的需求,有真需求、有伪需求,有大众需求、有小众需求,有商业需求、有性能需求,面对这么多需求,如何取舍如何排序就是一个关键的问题。

对于这些数不清的待办需求,产品经理要做到心中有数。需求池当中的这个需求,能否在产品长期目标的主线上发挥作用;如果需要开启一个支线的产品目标,那这个支线的投入和产出又是如何。产品经理不仅要为用户体验负责,也需要对产品良性发展负责。

可能会有同学说,思考产品长期目标是产品总监的事情,新手期产品经理做好自己的事情就可以了。但其实,即使初级产品经理没有权力做出产品目标的相关决策,至少也可以把自己放在更高的视野做做沙盘推演,学会用更大的视野思考整条业务线的宏观目标,对于一个产品经理的成长,会非常有帮助。

05需求的思维公式

我给出这样一个公式:

需求=目标人群 场景 痛点/问题 解决方案

图7:需求思维公式

一个完整的需求,应当是有特定的目标人群,在特定的场景下,发现特定的问题,并提出针对这个问题的解决方案。

任何一个需求,都不能脱离这四个组成部分。

1.目标人群

目标人群代表着“什么人”的问题。任何一个产品,都一定是面向某一个群体,而不是面向所有人,因为人和人的诉求,不可能完全一致,会因为性别、年龄、学历、收入水平、从事行业等许多因素,产生差异。因此,一个需求面向的人群一定是有一个范围的,比如“找互联网工作的人”“骑行爱好者”等等。

2.场景

场景还有一个重要特性,就是用户具体怎么使用这个功能。比如用户在支付时进行扫码,就是在“支付”场景下,用了“扫一扫”的功能。有时候,用户天然产生的场景不够多,那我们就可以创造场景,比如支付宝为了更多的使用场景,投资了哈罗单车,提供了支付宝直接扫码就可以骑车的功能,于是,就创造出了一个新的使用支付宝扫一扫的场景。

3.痛点/问题

明确了目标人群和场景,还要知道,这一些人 在 这个场景 下,遇到了什么问题,只有把问题找准了,才不会马屁拍在马蹄子上。比如:西二旗上班的白领(目标人群),出了地铁口距离公司还有一公里,马上就要迟到了(场景),走路来不及,打车打不到(遇到的问题)。这个时候,帮助用户快速到达公司不至于迟到,就是要解决的问题。

4.解决方案

找到了问题,那就要提出需求中最核心的“解决方案”,产品终归是要解决用户问题的,要不然,找到了一堆问题,一个都不解决,那依然没什么用。这一群人,在这个场景下,遇到了问题,你打算用什么方法解决。

值得注意的是,解决方案不一定有一个,而且大多数情况下,是有多个。产品经理就要在这多个解决方案中,找到最合适的那个。还是白领迟到这个例子,最后一公里,走路来不及,打车打不到,我们可以给一个共享单车的解决方案,也可以给通勤摆渡车的解决方案。分析之后发现,上班高峰容易堵车,摆渡车依然有迟到风险,所以,最后给用户提供了共享单车的解决方案,帮助用户解决了问题。

一般情况下,大部分需求,都可以用这个思维公式进行提炼。但任何产品理论都是教科书式的知识,在实际工作中,还是要灵活应用,具体问题具体分析。

以上,就是关于“需求”模块下,我的总结、分析和思考,逐渐形成的一点小体系。但依然不够完善,我也会在后面的工作中,持续反思完善。

↘好文推荐:

俞军:产品经理必备的2个模型

SaaS产品设计,从0到1案例实操

To B设计系统-在平平淡淡中开花结果

发表评论

登录后才能评论