以「哔哩哔哩」为例，教你三步建立自己的需求池
本文以哔哩哔哩为例，分析了如何实现挖掘需求、优先级排序、建立需求池等内容，具体的来看看笔者的分析吧。
需求池，顾名思义就是把很多需求放在一起的东西，在规划版本时，从池子里根据“轻重缓急”和“优先级”来筛选出需求，排排期，弄成一个版本开发计划。需求池工具有很多，比如Project、Excel、MindManager等都可以作为需求池管理工具。
在产品生命周期管理中，靠谱的、不靠谱的、紧急的、不紧急的，所有的需求都应该放到需求池里，每一次安排产品版本计划的时候都要重新审视一遍需求，然后再根据需求池里的所有需求进行“轻重缓急”和“优先级”的权重比较。
需求池是一种项目管理和自我管理的工具，是产品狗每次到版本迭代就发愁、焦虑不知道干什么的良药。
下面我以「哔哩哔哩」为案例，从需求的挖掘、优先级排序到建立需求池进行详细的分析，希望对你有所帮助。
产品简介：
哔哩哔哩是一款娱乐动漫二次元视频社区。哔哩哔哩上的视频来自用户的创作或搬运，不同于其他视频网站存在大量重复、低质量的视频内容，哔哩哔哩的搬运工是一群热爱动画的核心用户，他们能保证动画的内容质量和画面质量，能提供最及时、最清晰的动画视频内容。一部新番在日本播放完约1小时后，该视频的高清版就会被搬运到哔哩哔哩上。
研究方法：
抽样法：从用户评价中抽取有价值的反馈进行分析。
信息提取平台：App annie、七麦、酷传网、新浪微博、各大应用市场等。
一、需求挖掘
1.1 通过用户反馈关注什么？
- 发现自己的问题。
- 发现竞品的问题。
- 通过用户反馈发现可能的机会点。
1.2 通过哪些渠道来收集用户反馈？
1.2.1 公开渠道 ：App store、新浪微博、百度贴吧、七麦、酷传网、雪球等。
第一，公开渠道我这次主要以七麦为主，通过信息总览，大致归纳典型的反馈方向：浏览近3个月用户评价和版本相关信息，整理筛选出一些典型的反馈问题，重点筛选出差评、有实质性内容的评价和异常行为。
第二，微博：通过关键词搜索，了解热度较高的反馈及讨论细节，通过关键词搜索全站，浏览B站官网近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个
在上述需求中再剔除掉无效及重复的反馈，优化类需求本次不做需求整理：
新需求：
- 希望支持ipad分屏功能
- 希望增加播单功能
- 增加弹幕与视频同时缓存功能
- 视频分区增加学习专区
- 增加免流卡识别的功能
- 增加“自动播放下一个视频”开关
- UP主原创内容护盾功能
- 番剧申请收录功能
- 视频内容支持切换语种
二、需求优先级排序
正所谓鱼和熊掌不可兼得，我们的时间、精力或者其他的资源都是有限的，通过第一步的收集，我们挖掘了那么多的需要求，不能都一起做吧，所以，一定要确定优先级，下面我通过几个维度给需求进行优先级排序。
2.1 四象限看用户量与发生频率
优先解决大用户量的高频问题，特别是在产品早期，一定要先解决用户量大且经常发生的，提升基础体验，增加产品的稳定性。最后解决少量用户的低频问题。
2.2 看开发难度和效果
优先开发见效快且开发难度不大的，这就是迭代，最后做很费劲而且见效慢的，这可能是未来的机会。
2.3 看产品价值
- 迫切程度：用户是不是真的非常需要？还是空想的？
- 付费意愿：用户是否会为了解决问题而付费？
- ARPU:如果开发出来，用户会为之付多少钱？
2.4 看你对目标群体的熟悉程度
1. 你是否深入了解用户使用场景？
这个时候需要做功能点的调研（后期我会写一篇如何做功能点调研的文章），这是产品入门的基础，所以，你要想办法去做调研。
2. 你对用户群体的理解是否足够了解？
3. 如果不熟悉，就想办法熟悉它，否则就不要动手。
2.5 总结你的结论
- 用户：这个功能，第一批的核心用户是谁？
- 场景：这个用户在什么场景下会使用？
- 问题：解决了这个用户最大的痛点是什么？
- 对比：和用户现在的解决方案相比，体验/效率提升有多大？
那接下来，我们一起来看看，收集整理了那么多的需求，我们到底先做哪个？
看用户量和发生频率：
1. 频率高，用户量大
播单功能：播单功能能帮助UP主有效的进行视频分类，用户也能快速查找到系列的视频，便于收藏、查看、分享。
2. 频率低，用户量大
视频分区增加学习专区：据相关数据统计显示，2018年度有1827万人在B站学习，用户量还是蛮大的，但毕竟不是一个学习的平台，用户学习的频率想必不会太高，搜索功能基本能也满足这部分用户的需求。
增加番剧收录功能：增加收录功能可以很好的帮助用户管理喜欢的番剧。
3. 用户量小，频率高
增加免流卡识别的功能：使用免流卡却仍然出现流量确认弹窗，会让用户怀疑免流是否生效，更会让多次看到弹窗的用户觉得烦躁，无论哪种情况都会让用户对产品产生不好的印象。
增加ipad分屏功能：ipad分屏可以帮助ipad端用户同时处理多个窗口的信息，提升用户体验。
增加“自动播放下一个视频”开关：B 站是一个长视频 APP，用户在观看视频的时候，有充足时间查看视频信息、评论等内容，自动播放的影响不算很大。不过提高用户的自由度能有效的提高使用体验，后续可以考虑增加此功能。
增加UP主原创内容主护盾功能：UP主辛苦创作的内容，被抄袭，有时自还会被“恶人先告状”，对于原创内容的保护也是刻不容缓的。
4. 用户量小，频率低
增加弹幕与视频同时缓存的功能：随着网络速度的提升，网速导致的问题会越来越少。而且弹幕作为一个多用户、多时段上传的内容，是无法完全缓存至本地的。
视频内容支持切换语种：字幕可以配不同的语言文字，切换语种如果本身内容制作方不是多语言的，那这个工程量不是一般的大。
看开发难度和效果：
1. 见效快，开发量小
增加“自动播放下一个视频”开关：用户看完一个视频能自动播放下一个视频，能减少用户操作，且开发量也不大。
增加番剧收录功能：用户对于自己喜欢的视频可以回看，且开发量小。
增加免流卡识别的功能：对于运营商的免流量卡进行识别，只需把运营商的免流量卡的号段纳入数据库存，进行判断即可。
2. 见效快，开发量大
播单功能：播单功能开发量大，且可能会改变用户习惯。
增加UP主原创内容主护盾功能：开发量比较大，但保护优质原创资源是B站的必经之路。
视频分区增加学习专区：开发量大，能有效提升接近2000万用户的学习效率。
3. 见效慢，开发量小
增加ipad分屏功能：ipad端用户量小，且有分屏需求的用户又会少一些，但开发量相对来说不咋大，可以考虑开发此功能，提升ipad端的用户体验。
4. 见效慢，开发量大
增加弹幕与视频同时缓存的功能：弹幕是实时更新的，不是固定信息，缓存在本地意义不大且开发量大。
视频内容支持切换语种：有这种需求的用户量很少，且开发量巨大。
备注：以上分析没有对错之分，根据你公司当下情况进行排序即可。
2.6 综合以上分析，按顺序对产品功能作出优先级排序
（从上往下，需求优先级重要程度逐渐下降）
- 增加免流卡识别的功能
- 增加ipad分屏功能
- 增加番剧收录功能
- 增加UP主原创内容主护盾功能
- 增加“自动播放下一个视频”开关
- 播单功能
- 视频分区增加学习专区
- 增加弹幕与视频同时缓存的功能
- 视频内容支持切换语种
三、需求池建立
3.1 纳入需求池
所有收到的需求，只要不是当下马上就能解决的，就放到需求池里面去。
3.2 需求池包含哪些内容
最后
好啦，到这就结束啦，下面我们来回顾一下主要内容：
- 第一步：我们通过不同的渠道挖掘需求。
- 第二步：对需求进行优先级排序。
- 第三步：建立需求池。
希望本篇文章对你有所帮助，如果有哪一部分做的不足，还请各路大神指出，感激不尽。
下一篇：如何画一份完美的业务流程图？
本文由 @菜园长 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: