如何从用户的“功能需求”中，找到真正的需求？

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