本文作者将在此通过几个实例的分析，与大家一起聊聊：如何从用户的“功能需求”中，找到真正的需求？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：最后没上此功能，原因如下：

1. 合同最重要的是签名，而不是“同意”，实现电子签名代价高；
2. 使用频次太低，仅新老师入驻时需要，且平台目前的老师数基本满足，如果开发的话，投入产出比并不划算。

4. 总结

韩老师的需求其实是提高签订合同的效率，不一定是需要服务号来完成，也不是简单的通过“同意”按钮即可。

实例3

1. 背景

某线上直播班课平台，目标用户主要是中小学生以及教师（主讲和助教），张老师是教师的其中一员，平常除了上课之外，还需要一部分教师的管理工作。某日，张老师找到产品经理说：

“学生现在都不用App，能不能给我们也做个App，就像微信那样，可以聊天，支持语音、文件、图片、视频等，强制学生使用App进行答疑。”

2. 解析

• 学生不使用App，张老师迫于上级压力，想通过某种方法让学生使用；
• 他自己琢磨了一下，觉得如果把答疑功能放到App上，学生也就有使用App的理由，但现在的问题是教师端没有App；

3. 解决方案

回归问题本质，并注意用户视角。

具体可如下：

产品经理Dug：咱们为什么要强制用户使用App？

张老师：我们做出来了就得让学生用起来啊，领导都发话了。（PS：迫于领导压力，为了KPI）

 

产品经理Dug：恩，了解了。那咱们目前的答疑工作是怎么做的？

张老师：用微信啊，学生有问题，直接就在群里答疑。

 

产品经理Dug：那现在有什么问题吗？

张老师：没问题啊，但如果App可以答疑的话，我们就强制学生到App上，并关闭微信答疑服务。

 

产品经理Dug：嗯嗯，大概清楚了。你看这样行吗？

• 首先，答疑服务咱们继续在微信上；
• 其次，通过现有的功能来引导用户使用App，比如提交作业、做练习或测试，或者上免费的公开课等；
• 最后，学生心理对微信已经有了认知，如果我们的App答疑功能不能超越（或至少达到）微信的体验，那一定会被学生嫌弃。

张老师：但有的学生，连提交作业都在微信群里，根本不用App提交。

 

产品经理Dug：我们可以确定规则和服务，并引导用户下载即可。

• 确定微信仅做答疑服务；
• 提交作业、做练习或测试请使用App，并给出几个原因；
• 提供用户的下载链接和二维码；
• 定期将一些公开课、精品课的信息和链接发到群里，并附上需App上领取等；

张老师：好吧，我试试。（PS：还是有点怀疑）

 

产品经理Dug：其实像这个工作，你可以考虑让运营或我们来做，不用自己琢磨的；

张老师：是吗？那太好了，哈哈

（PS：脸上终于绽放出了笑容，因为不用他自己动手了）

4. 总结

• 张老师的需求是想让学生使用App，完成上级的任务，而并不是一个有微信一样功能的App；
• 学生不使用App，可能是App没有满足其需求；也可能是学生不知道App可以满足其需求，张老师仅需引导学生即可；

实例4

1. 背景

还是实例3中的张老师，过了没几日，又找到了产品经理Dug，说：

“可以给我们做个App吗？像xx平台一样，方便给学生批改作业”

2. 解析

• 典型的“功能需求”；
• 发现xx平台也有批改作业的功能，终于有“现身说法”；
• 张老师拥有一颗“不达目的不罢休”、“不到黄河心不死”之心。

3. 解决方案

动之以情，晓之以理。

具体可如下：

产品经理Dug：咱们现在批改作业流程是什么样的？

张老师：用电脑批改，每次打开电脑，感觉有点麻烦，尤其是有时候，在家里或地铁上也不方便。我看xxApp就挺好的，方便快捷，咱们是不也可以弄一个？（PS：为了做App之心，真是“鞠躬尽瘁”啊）

 

产品经理Dug：恩，那咱们现在大概会有多少的比例会在家里或地铁上办公？

张老师：每周可能会有1-2个小时吧。

 

产品经理Dug：那咱们目前有几个老师啊？

张老师：差不多十几二十个吧。

 

产品经理Dug：好，张老师，你这么看哈。

• 批改作业时，大多需要涂鸦，电脑上操作肯定会更便捷，还不伤眼睛；
• 95%以上的批改作业都发生在办公室，这时候，电脑是开着的，省去了开电脑的麻烦；
• 我们的老师并没有达到上千上万的量级；
• 开发一个App至少需要5-6人，1-2个月的时间，投入产出比真的不划算；而且还会占用了给学生开发App的资源。

张老师：行吧，那再说。我就是觉得xx平台的作业批改功能做的挺好的。（PS：还是有点心不死，但也知道必须得接受）

4. 总结

• 产品需求不是别人有，我们就要有的逻辑，用户、需求、场景缺一不可；
• 产品与服务均需考虑投入产出比。

写在最后

1. 声明：文中出现许多的人物简称，均属虚构，请勿对号入座；
2. 澄清：文中出现多处PS话语，仅做说明使用，并无歧视之意；
3. 最后的最后：如果你喜欢，可以分享给你的朋友；如果你不喜欢，也请你别告诉我（后者开玩笑的啦）。

我搬砖，我快乐，争做一台搬砖领域的缝纫机~

本文由 @邢小作 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议