微信扫码添加客服
客服热线
微信扫码添加客服
客服热线
本文作者将在此通过几个实例的分析,与大家一起聊聊:如何从用户的“功能需求”中,找到真正的需求?
很多时候,我们为了避免“闭门造车”式的产品,一定或多或少需要从用户那里获取需求。
但,你有没有发现,他们喜欢给你一些“功能需求”,而不是真正的需求。
什么是“功能需求”?
举个例子。比如我有一个朋友,是做在线教育产品的,用户A留言跟他说:“我觉得你们应该加一个私信的功能”,用户B则跟他说“学习多没意思,其实你们应该开发一个抢红包功能”。
弄的我的这位朋友是啼笑皆非,但又不能直接怼用户,只能“假装”非常开心的回复说:“感谢你们的意见和建议,我们一定会认真考虑”。
这就属于“功能需求”。
我们简单下一个定义:用户根据自己对某产品的认知,结合自己的需要,给出一个Ta认为完美的解决方案,我们就称为“功能需求”。
下面我们就通过几个实例的分析,学习如何从用户的“功能需求”中,找到真正的需求?
一个1对1在线直播平台,王老师主要负责招聘、服务平台上的所有老师,也是后台系统的用户。某日,Ta跟负责后台的产品经理Dug说:
“可以加一个删除老师的功能吗?”
这就属于典型的“功能需求”,即用户A根据对自己真实需求的认知,以及对后台产品的使用,自己总结出一套解决自己需求的方案,直接提出给产品经理。
多问为什么。
具体可如下:
产品经理Dug:为什么您需要一个删除老师的功能呢?
王老师:因为当有老师长时间不在平台上课后,在帮助同学找合适的老师时,还会看到,影响我的工作效率。
产品经理Dug:也就是说,你是想在帮助同学找老师的时候,提高效率,所以想删除一些长期不排课的老师,避免他们扰乱你,对吧?
王老师Dug:对啊,把他们删除了,数据不就少了不少吗?不就提高我的效率了吗?
产品经理Dug:好,了解了。那如果我们可以做到:自动给你匹配合适的老师,你的工作效率是否会更高?比如长时间不在平台上课的老师,我们不推给你,同时我们还可以根据学习情况推送合适的教师。
王老师:可以这样吗?那更好了。
产品经理Dug:不需要删除老师的功能了吧?
王老师:傻子才要那个呢,这个多好啊。
(哈哈,此处纯属YY…)
王老师的需求其实是提高学生与老师的匹配效率,从而提供Ta的工作效率,而不是一个删除教师的功能。
与实例1同一平台,产品由后台系统变换成了微信服务号,用户也由王老师变成了韩老师,但同属一个部门。
“我们服务号是否可以上线签订合作协议的功能以及请辞?”
同样属于典型的“功能需求”,但韩老师是根据自己对其他产品的认知,结合自己真实的需求,总结出了一个自己的解决方案。
多问现状与困扰Ta的问题。
具体可如下:
产品经理Dug:您现在的问题是什么?
韩老师:每月需要签订接近100份协议,太耽误时间了。所以想在服务号上添加一个产品,像xx产品那样,协议下面有个“同意”按钮,老师只要点击,就算签订协议成功。
产品经理Dug:嗯嗯,那可以说一下你们当前的流程吗?(PS:千万不能被Ta后面的话带偏,去跟Ta讨论实现细节)
韩老师:现在就是我们提供电子版的协议给老师,老师填写完毕,打印出来,签字,然后拍照发给我们。但我们还需要去收集、整理那些照片,太费时间了。
产品经理Dug:哦,明白了,你就是想把现在的合同变成电子合同,以此来提高工作效率,对吧?
韩老师:对的。
产品经理Dug:恩,我了解你的需求了,具体我会评估一下。
PS:最后没上此功能,原因如下:
合同最重要的是签名,而不是“同意”,实现电子签名代价高;
使用频次太低,仅新老师入驻时需要,且平台目前的老师数基本满足,如果开发的话,投入产出比并不划算。
韩老师的需求其实是提高签订合同的效率,不一定是需要服务号来完成,也不是简单的通过“同意”按钮即可。
某线上直播班课平台,目标用户主要是中小学生以及教师(主讲和助教),张老师是教师的其中一员,平常除了上课之外,还需要一部分教师的管理工作。某日,张老师找到产品经理说:
“学生现在都不用App,能不能给我们也做个App,就像微信那样,可以聊天,支持语音、文件、图片、视频等,强制学生使用App进行答疑。”
学生不使用App,张老师迫于上级压力,想通过某种方法让学生使用;
他自己琢磨了一下,觉得如果把答疑功能放到App上,学生也就有使用App的理由,但现在的问题是教师端没有App;
回归问题本质,并注意用户视角。
具体可如下:
产品经理Dug:咱们为什么要强制用户使用App?
张老师:我们做出来了就得让学生用起来啊,领导都发话了。(PS:迫于领导压力,为了KPI)
产品经理Dug:恩,了解了。那咱们目前的答疑工作是怎么做的?
张老师:用微信啊,学生有问题,直接就在群里答疑。
产品经理Dug:那现在有什么问题吗?
张老师:没问题啊,但如果App可以答疑的话,我们就强制学生到App上,并关闭微信答疑服务。
产品经理Dug:嗯嗯,大概清楚了。你看这样行吗?
首先,答疑服务咱们继续在微信上;
其次,通过现有的功能来引导用户使用App,比如提交作业、做练习或测试,或者上免费的公开课等;
最后,学生心理对微信已经有了认知,如果我们的App答疑功能不能超越(或至少达到)微信的体验,那一定会被学生嫌弃。
张老师:但有的学生,连提交作业都在微信群里,根本不用App提交。
产品经理Dug:我们可以确定规则和服务,并引导用户下载即可。
确定微信仅做答疑服务;
提交作业、做练习或测试请使用App,并给出几个原因;
提供用户的下载链接和二维码;
定期将一些公开课、精品课的信息和链接发到群里,并附上需App上领取等;
张老师:好吧,我试试。(PS:还是有点怀疑)
产品经理Dug:其实像这个工作,你可以考虑让运营或我们来做,不用自己琢磨的;
张老师:是吗?那太好了,哈哈
(PS:脸上终于绽放出了笑容,因为不用他自己动手了)
张老师的需求是想让学生使用App,完成上级的任务,而并不是一个有微信一样功能的App;
学生不使用App,可能是App没有满足其需求;也可能是学生不知道App可以满足其需求,张老师仅需引导学生即可;
还是实例3中的张老师,过了没几日,又找到了产品经理Dug,说:
“可以给我们做个App吗?像xx平台一样,方便给学生批改作业”
典型的“功能需求”;
发现xx平台也有批改作业的功能,终于有“现身说法”;
张老师拥有一颗“不达目的不罢休”、“不到黄河心不死”之心。
动之以情,晓之以理。
具体可如下:
产品经理Dug:咱们现在批改作业流程是什么样的?
张老师:用电脑批改,每次打开电脑,感觉有点麻烦,尤其是有时候,在家里或地铁上也不方便。我看xxApp就挺好的,方便快捷,咱们是不也可以弄一个?(PS:为了做App之心,真是“鞠躬尽瘁”啊)
产品经理Dug:恩,那咱们现在大概会有多少的比例会在家里或地铁上办公?
张老师:每周可能会有1-2个小时吧。
产品经理Dug:那咱们目前有几个老师啊?
张老师:差不多十几二十个吧。
产品经理Dug:好,张老师,你这么看哈。
批改作业时,大多需要涂鸦,电脑上操作肯定会更便捷,还不伤眼睛;
95%以上的批改作业都发生在办公室,这时候,电脑是开着的,省去了开电脑的麻烦;
我们的老师并没有达到上千上万的量级;
开发一个App至少需要5-6人,1-2个月的时间,投入产出比真的不划算;而且还会占用了给学生开发App的资源。
张老师:行吧,那再说。我就是觉得xx平台的作业批改功能做的挺好的。(PS:还是有点心不死,但也知道必须得接受)
产品需求不是别人有,我们就要有的逻辑,用户、需求、场景缺一不可;
产品与服务均需考虑投入产出比。
声明:文中出现许多的人物简称,均属虚构,请勿对号入座;
澄清:文中出现多处PS话语,仅做说明使用,并无歧视之意;
最后的最后:如果你喜欢,可以分享给你的朋友;如果你不喜欢,也请你别告诉我(后者开玩笑的啦)。
我搬砖,我快乐,争做一台搬砖领域的缝纫机~