本文以「哔哩哔哩」为例，讲解了如何进行需求挖掘、需求优先级排序、需求池建立等内容。

前言

需求池，顾名思义就是把很多需求放在一起的东西，在规划版本时，从池子里根据“轻重缓急”和“优先级”来筛选出需求，排排期，弄成一个版本开发计划。需求池工具有很多，比如Project、Execl、MindManager等都可以作为需求池管理工具。

在产品生命周期管理中，靠谱的、不靠谱的、紧急的、不紧急的，所有的需求都应该放到需求池里，每一次安排产品版本计划的时候都要重新审视一遍需求，然后再根据需求池里的所有需求进行“轻重缓急”和“优先级”的权重比较。

需求池是一种项目管理和自我管理的工具，是产品狗每次到版本迭代就发愁、焦虑不知道干什么的良药。

下面我以「哔哩哔哩」为案例，从需求的挖掘、优先级排序到建立需求池进行详细的分析，希望对你有所帮助。

产品简介

哔哩哔哩是一款娱乐动漫二次元视频社区。哔哩哔哩上的视频来自用户的创作或搬运，不同于其他视频网站存在大量重复、低质量的视频内容，哔哩哔哩的搬运工是一群热爱动画的核心用户，他们能保证动画的内容质量和画面质量，能提供最及时、最清晰的动画视频内容。一部新番在日本播放完约1小时后，该视频的高清版就会被搬运到哔哩哔哩上。

研究方法

抽样法：从用户评价中抽取有价值的反馈进行分析。

信息提取平台：App annie、七麦、酷传网、新浪微博、各大应用市场等。

一、需求挖掘

1.1 通过用户反馈关注什么？

1. 发现自己的问题
2. 发现竞品的问题
3. 通过用户反馈发现可能的机会点

1.2 通过哪些渠道来收集用户反馈？

1.2.1 公开渠道

有App store 、新浪微博、百度贴吧、七麦、酷传网、雪球等。

1. 公开渠道我这次主要以七麦为主，通过信息总览，大致归纳典型的反馈方向：浏览近3个月用户评价和版本相关信息，整理筛选出一些典型的反馈问题，重点筛选出差评、有实质性内容的评价和异常行为。
2. 微博：通过关键词搜索，了解热度较高的反馈及讨论细节，通过关键词搜索全站，浏览B站官网近3个月的更新，重点关注高赞和高评论数的内容。
3. 百度贴吧：通过关键词搜索，了解热度较高的反馈及讨论细节，

1.2.2 半公开渠道

朋友圈、微信公众号的文章、微信群、用户评价，ps:如果想获取竞品的可以成为种子用户或者是付费用户。大家可以结合自己的产品性质，去不同的地方搜集哈。

1.2.3 内部渠道

用户投诉、电话录音、客服咨询。别人家的咱们获取不到的哈，如果能获取到那也是犯法的，这种事儿咱不能干。

总之，定期去收集用户反馈，会让你的工作事半功倍。

1.３ 用户反馈不同渠道的处理策略？

• 公开渠道：勤搜索、关键字+收藏夹、使用监测工具。
• 半公开渠道：定期搜索关键字、定期分析用户评论。
• 内部渠道：整合内部用户反馈渠道，定期与一线的同事沟通，或者是自己主动去一线。

总之，去用户量最集中的地方。

1.4 重点看什么？

低分差评：重点看1-3分的差评

因为给差评、低分，用户一定是不满的，用户满意的时候他有可能不吭声儿，但是用户不满意他一定会说出来的。

去应用商店是他们最常见的做法，比如：

QQ音乐曾经做了一个线下的颁奖典礼，但是他们把李宇春的性别弄错了，所以，粉丝就炸锅了，你现在去看QQ音乐的评分，很惨的，大部分用户为了偶像给QQ音乐打的全是低分，当然，这个是不具备参考价值的，但是正常情况下，低分差评是非常值得参考的。

有效评论：重点看有实际描述的评论，如下图：

异常行为：比如水军刷榜，恶意评价，也就是一个时间段，有很多好评或者是很多差评（可以过滤掉）。

比如刚刚QQ音乐的例子，可以通过一些方式判断是否有水军刷榜，刷榜的方式是怎么样的，这样会对一个产品评估会更加的了解，

1.5 「哔哩哔哩」评论信息提取

通过不同的渠道，咱们已经收集好用户反馈了，下面是在各渠道收集的125条有效评论其中一部分截图：

下面需要对用户的评论信息进行提取：

1.6 「哔哩哔哩」用户反馈合并汇总

把七麦、微博、百度贴吧收集的用户反馈数据合并，得到以下结果：

• 优化需求共43个
• 新需求共21个
• BUG类61个

在上述需求中再剔除掉无效及重复的反馈，优化类需求本次不做需求整理：

1.7 新需求

1. 希望支持ipad分屏功能
2. 希望增加播单功能
3. 增加弹幕与视频同时缓存功能
4. 视频分区增加学习专区
5. 增加免流卡识别的功能
6. 增加“自动播放下一个视频”开关
7. UP主原创内容护盾功能
8. 番剧申请收录功能
9. 视频内容支持切换语种

二、需求优先级排序

正所谓鱼和熊掌不可兼得，我们的时间、精力或者其他的资源都是有限的，通过第一步的收集，我们挖掘了那么多的需要求，不能都一起做吧，所以，一定要确定优先级，下面我通过几个维度给需求进行优先级排序。

2.1 四象限看用户量与发生频率

优先解决大用户量的高频问题，特别是在产品早期，一定要先解决用户量大且经常发生的，提升基础体验，增加产品的稳定性。最后解决少量用户的低频问题。

2.2 看开发难度和效果

优先开发见效快且开发难度不大的，这就是迭代，最后做很费劲而且见效慢的，这可能是未来的机会。

2.3 看产品价值

1. 迫切程度：用户是不是真的非常需要？还是空想的？
2. 付费意愿：用户是否会为了解决问题而付费？
3. ARPU：如果开发出来，用户会为之付多少钱？

2.4 看你对目标群体的熟悉程度

1. 你是否深入了解用户使用场景？

这个时候需要做功能点的调研（后期我会写一篇如何做功能点调研的文章），这是产品入门的基础，所以，你要想办法去做调研。

2. 你对用户群体的理解是否足够了解？

3. 如果不熟悉，就想办法熟悉它，否则就不要动手。

2.5 总结你的结论

• 用户：这个功能，第一批的核心用户是谁？
• 场景：这个用户在什么场景下会使用？
• 问题：解决了这个用户最大的痛点是什么？
• 对比：和用户现在的解决方案相比，体验/效率提升有多大？

那接下来，我们一起来看看，收集整理了那么多的需求，我们到底先做哪个？

2.5.1 看用户量和发生频率

①频率高，用户量大

播单功能：播单功能能帮助UP主有效的进行视频分类，用户也能快速查找到系列的视频，便于收藏、查看、分享。

②频率低，用户量大

• 视频分区增加学习专区：据相关数据统计显示，2018年度有1827万人在B站学习，用户量还是蛮大的，但毕竟不是一个学习的平台，用户学习的频率想必不会太高，搜索功能基本能也满足这部分用户的需求。
• 增加番剧收录功能：增加收录功能可以很好的帮助用户管理喜欢的番剧。

③用户量小，频率高

• 增加免流卡识别的功能：使用免流卡却仍然出现流量确认弹窗，会让用户怀疑免流是否生效，更会让多次看到弹窗的用户觉得烦躁，无论哪种情况都会让用户对产品产生不好的印象。
• 增加ipad分屏功能：ipad分屏可以帮助ipad端用户同时处理多个窗口的信息，提升用户体验。
• 增加“自动播放下一个视频”开关：B 站是一个长视频 APP，用户在观看视频的时候，有充足时间查看视频信息、评论等内容，自动播放的影响不算很大。不过提高用户的自由度能有效的提高使用体验，后续可以考虑增加此功能。
• 增加UP主原创内容主护盾功能：UP主辛苦创作的内容，被抄袭，有时自还会被“恶人先告状”，对于原创内容的保护也是刻不容缓的。

④用户量小，频率低

• 增加弹幕与视频同时缓存的功能：随着网络速度的提升，网速导致的问题会越来越少。而且弹幕作为一个多用户、多时段上传的内容，是无法完全缓存至本地的。
• 视频内容支持切换语种：字幕可以配不同的语言文字，切换语种如果本身内容制作方不是多语言的，那这个工程量不是一般的大。

2.5.2 看开发难度和效果 

①见效快，开发量小

• 增加“自动播放下一个视频”开关：用户看完一个视频能自动播放下一个视频，能减少用户操作，且开发量也不大。
• 增加番剧收录功能：用户对于自己喜欢的视频可以回看，且开发量小。
• 增加免流卡识别的功能：对于运营商的免流量卡进行识别，只需把运营商的免流量卡的号段纳入数据库存，进行判断即可。

②见效快，开发量大

• 播单功能：播单功能开发量大，且可能会改变用户习惯。
• 增加UP主原创内容主护盾功能：开发量比较大，但保护优质原创资源是B站的必经之路。
• 视频分区增加学习专区：开发量大，能有效提升接近2000万用户的学习效率。

③见效慢，开发量小

增加ipad分屏功能：ipad端用户量小，且有分屏需求的用户又会少一些，但开发量相对来说不咋大，可以考虑开发此功能，提升ipad端的用户体验。

④见效慢，开发量大

• 增加弹幕与视频同时缓存的功能：弹幕是实时更新的，不是固定信息，缓存在本地意义不大且开发量大。
• 视频内容支持切换语种：有这种需求的用户量很少，且开发量巨大。

备注：以上分析没有对错之分，根据你公司当下情况进行排序即可。

2.6 综合以上分析，按顺序对产品功能作出优先级排序

（从上往下，需求优先级重要程度逐渐下降）

1. 增加免流卡识别的功能
2. 增加ipad分屏功能
3. 增加番剧收录功能
4. 增加UP主原创内容主护盾功能
5. 增加“自动播放下一个视频”开关
6. 播单功能
7. 视频分区增加学习专区
8. 增加弹幕与视频同时缓存的功能
9. 视频内容支持切换语种

三、需求池建立

3.1 纳入需求池

所有收到的需求，只要不是当下马上就能解决的，就放到需求池里面去：

3.2 需求池包含哪些内容

最后

好啦，到这就结束啦，下面我们来回顾一下主要内容：

• 第一步：我们通过不同的渠道挖掘需求
• 第二步：对需求进行优先级排序
• 第三步：建立需求池

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

题图来自Unsplash，基于CC0协议。