32 | 从受众规模、需求频率和强度出发：排定需求优先级的方法（上）
邱岳
该思维导图由 AI 生成，仅供参考
“一朝需求不称意，口里驱蛩心上蚝。”——（明）刘基
在之前几次分享中，我说到了分析产品的时候要反复探求“用什么方法，解决谁的什么问题”，从利益相关者、问题和解决方案三个维度分别介绍了产品分析的思考套路。基于这样的套路，或许我们可以列出产品不同利益相关者面临的不同问题，以及解决这些问题的方案。
那么接下来的问题就是，在资源有限的情况下，应该如何取舍，如何安排需求优先级？我这次就从这个话题开始聊起，跟你分享一些我的思考和经验。
避免毫无价值的正确
在排定优先级时，会有一种产品经理很容易出现的错误，就是“做无可争议的正确事情”。
这句什么意思呢，需求列表里永远有这样的需求，虽然没什么用，但做了肯定没错。比如去不断地优化一张页面的视觉和交互细节；把页面改得越来越好看、越来越好用总没错吧？这样的需求确实不能说它是错的，但这样的需求却大都无关痛痒。
之前我在博客里写过一篇文章，提到我认为产品经理需要让正确的事情相继发生，这句话因为池老师的加持变得广为流传。这里提到“正确的事情”，其实背后有一个叫做“机会成本”的经济学概念。
举个例子，如果我们投入 1 人日的研发资源，做了一个功能 A，假设我们用钱来衡量，获得了 1 万块钱的收益，我们算 1 人日的研发资源成本是 5 千块。那算起来 1 万减去 5 千，我们有 5 千块的利润。
但我们真的赚了吗？如果产品经理可以找到另一个功能 B，让收益可以达到 2 万块钱，那这 1 人日的研发资源去做之前说的功能 A， 就会产生一种机会成本，因为产品经理的选择而不得不失去获利更大的机会。
我们简单地把机会成本计算进去，2 万加 5 千是成本，收益是 1 万，这两个一减，就是亏损 1.5 万。当然经济学可能没有这么粗暴，但是要提醒你从绝对收益的概念里跳出来，去考虑收益的相对性。
接着说对需求优先级的衡量和排定，刚才我们说要尽量避免去做无关痛痒的事情，把资源尽可能投入到高优先级的功能中，那么怎样去区分优先级呢？
还是从“谁的什么问题”出发，首先我们去将所有的利益相关者以及他们的问题列出来，逐条分析受众的规模，以及问题的频率和强度。最简单的逻辑是：受益者越多、问题的频率越高、强度越大，则解决这样问题的价值就越大，优先级也越高。
规模、频率与强度
判断规模，有一个概念叫做 TAM（Total Addressable Market），这是指潜在市场范围，每项服务都有受众天花板，比如我们做一个面向中国影像科医生的服务，我们在网上查一下，发现全国从业的影像科医生不足二十万，那这就是当前的规模天花板。
当然这个天花板是会动的，比如我们可以用历年影像科医生的复合增长率估算接下来一段时间的市场规模增量，或者可以用医疗需求的数量作为准绳，去估测可能的市场发展潜力。比如我们根据中国的人口推测国内合理的医疗资源需求，然后根据医疗需求中影像科需求的占比反推需要的影像科医生。
不同的推测结果可能会有差异，但这其实不重要，重要的是要有完整和健全的逻辑链条，在这个逻辑链条中，客观因素越多，可控性就越差，整个产品模式的设计也就越不稳固。
比如上面的例子，如果我们用人口推测资源需求潜力，或许就只能寄希望于医疗体制改革和医疗服务市场化进程，而这种趋势对于一个团队来说，只能期待，很难推动。但如果以当前影像科医生数量做为依据，则会更加清晰和稳固，也更容易跟具体的业务计划建立联系。
另一方面，如果对趋势的判断足够准确或运气足够好，你服务的受众规模天花板可能会在短期内爆发性增长，比如 2010 年左右的移动互联网，原来用电脑上网的人都开始用手机上网了，那么手机应用的规模天花板或者说潜在市场范围，就会快速地大幅度提高。
另外还有地域优势，咱们国家的互联网公司算是占了挺大的便宜，我们随便做个什么 To C 的服务，潜在市场基数就是 10 亿网民，可能在别的国家，算破天也就几千万。这两种其实也是我们常说的流量红利和人口红利。
需求的频率和强度比较容易理解，比如我们知道吃饭和打车跟相亲和找工作相比是高频场景，而结婚和求职比吃饭和打车的强度大。跟规模一样，频率和强度也会随着时代、基础设施以及环境的变化而发生变化。
比如带宽增加和流量成本降低让人们在移动设备上观看视频的频率大幅度地提高，或者随着用户关系链从线下到线上的结构性变化，人们对“在线”这件事情的需求强度也更大了，我小时候只有个别人有 BP 机，平时大家不经常联系非常正常，但现在如果亲人或者朋友微信上一天没回你消息，可能你就会很焦虑。
在规模、频率和强度之外还有一个考虑因素，叫主观的可达性，我们拿吃饭举例子，按理说吃饭这个事情的规模、频率和强度都很高，所有人都要吃饭、每天至少三顿、不吃就饿死了。
但是，显然我们不可能按照全世界人口 x 3 去推算我们自己饭店的业务天花板，这个例子听起来可能会觉得很蠢，但其实很多商业计划和产品规划里的业务模式推算差不多就是这样的逻辑，很无奈。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
排定需求优先级是产品经理工作中的重要一环。本文介绍了一种基于受众规模、需求频率和强度的方法来进行需求优先级排定的系统方法。作者首先指出了产品经理在这一过程中容易犯的错误，并引入了机会成本的经济学概念。随后，文章详细讨论了衡量和排定需求优先级的方法，强调了规模、频率和强度的重要性，并提及了TAM（Total Addressable Market）的概念。最后，强调了在描述规模、频率和强度时，深入理解产品定位、用户、场景、市场和竞争环境的重要性。通过经济学概念和实际案例，本文为产品经理提供了一种系统的方法来排定需求优先级，强调了对需求进行全面分析的重要性。文章内容深入浅出，为产品经理提供了有益的技术指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《邱岳的产品手记》，新⼈⾸单¥59
《邱岳的产品手记》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
CC最近刚刚预订专栏学习，感谢二爷分享。 总结一下今天自己学到的需求优先级原则： 1. 避免做正确但没有影响力的事情； 2. 考虑机会成本，而不仅仅是看得见的工时/工资成本； 3. 受益者「规模」越大，优先级越高；判断规模的时候，多依据「现在」的情况，适当考虑「未来」，可以让产品的设计更稳固；要特别注意规模计算和描述的逻辑； 4. 问题的「频率」越高、「强度」越大，优先级越高；常见的场景组合是「高频低强度」和「低频高强度」，会挑战综合判断的能力； 5. 如果遇到「大规模、高频高强度」的组合，要考虑「主观可达性」，要特别注意推理符合逻辑； 6. 除了客观打分外，还需要有同理心，用感性思维，从正反两方面去考虑用户的感受。 期待下半部分的分享。:)作者回复: 👍欢迎欢迎
2018-02-048
Weiyung二爷，你好。看完了这个章节，对于频率和强度的比较其实并没有很好的了解。可以再详细的指点指点吗？作者回复: 需求频率就是平均多久需要一次，比如吃饭就是每天三次；需求强度就是如果没有这个会有多惨，比如三天不吃饭还凑合，但三天不喝水就完蛋了。
2019-03-191
灿锋”假设，如果我现在设计一个产品，可以给一部分的 Python 开发者使用，”，这里好像漏了后面的？作者回复: 是的，稍后补上
2018-02-01
听天由己就我个人工作习惯来说，我将需求优先级排序分为三个维度： 一是用户量和发生频率，这点和二爷说的规模与频率相似，优先解决大用户量的高频问题，这是保证用户的基础体验。 二是开发难度与实践效果，围绕核心功能进行迭代是较为合适的手段； 三是产品和商业价值，这一点其实就是需求的紧迫性以及付费意愿，综合考虑成本收益而定。 当然，需求排序永远都是动态调整的过程。 这篇文章阅读后，我对打分和量化更感兴趣，希望二爷下次能够多多分享。2018-02-0120
王岩内部的产品经理还得考虑一种情况：受众很小，但是个别重要领导提出，你是做还是不做呢？2018-03-07213
叹符xo规模:固定（地理、人文、经济）范围，用户数量 频次:固定（日/周/月/季/年均）周期，用户使用次数 强度:单次使用，用户收益/可避免的损失2018-02-237
种菜的渔民作者所提之处并无不妥，但现实工作中遇到一个问题，在与开发人员讨论优先级排序时，对于小部分的非核心功能的开发，我给出的建议是暂缓执行，后续根据用户的实际反馈在决定开发；而程序员往往说，现在不做，以后就很难做了，改动会很大，这样一般要怎么权衡？2020-08-103
Bonnie Mei在用户需求已经确认好的情况下，我们主要看哪些是重要的基础功能，哪些功能依赖于其他模块比较多，这些会作为研发经理排期计划的重要因素。我跑偏了，您这篇主要是需求管理，排优先级就想到研发管理……2018-02-022
马辉规模（受众人数，细分到用户画像） 频率（场景发生次数） 强度（有多痛苦，满足度） 补一个，是否满足 商业利益（是否愿意付费，是否与我的利益有重叠）2021-05-171
Sam_Deep_Thinking深度好文。必须点个赞。2022-07-13
收起评论