极客时间已完结课程限时免费阅读

32 | 从受众规模、需求频率和强度出发：排定需求优先级的方法（上）

32 | 从受众规模、需求频率和强度出发：排定需求优先级的方法（上）-极客时间

32 | 从受众规模、需求频率和强度出发：排定需求优先级的方法（上）

2018-02-01 邱岳 来自北京
《邱岳的产品手记》
课程介绍

讲述：邱岳

时长09:43大小3.34M

“一朝需求不称意，口里驱蛩心上蚝。”——（明）刘基
在之前几次分享中，我说到了分析产品的时候要反复探求“用什么方法，解决谁的什么问题”，从利益相关者、问题和解决方案三个维度分别介绍了产品分析的思考套路。基于这样的套路，或许我们可以列出产品不同利益相关者面临的不同问题，以及解决这些问题的方案。
那么接下来的问题就是，在资源有限的情况下，应该如何取舍，如何安排需求优先级？我这次就从这个话题开始聊起，跟你分享一些我的思考和经验。

避免毫无价值的正确

在排定优先级时，会有一种产品经理很容易出现的错误，就是“做无可争议的正确事情”。
这句什么意思呢，需求列表里永远有这样的需求，虽然没什么用，但做了肯定没错。比如去不断地优化一张页面的视觉和交互细节；把页面改得越来越好看、越来越好用总没错吧？这样的需求确实不能说它是错的，但这样的需求却大都无关痛痒。
之前我在博客里写过一篇文章，提到我认为产品经理需要让正确的事情相继发生，这句话因为池老师的加持变得广为流传。这里提到“正确的事情”，其实背后有一个叫做“机会成本”的经济学概念。
举个例子，如果我们投入 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 去推算我们自己饭店的业务天花板，这个例子听起来可能会觉得很蠢，但其实很多商业计划和产品规划里的业务模式推算差不多就是这样的逻辑，很无奈。

排定优先级

理解了规模、频率和强度之后，就可以以此来做优先级排序了。我们平时在挑战自己或别人的需求优先级时，首先会关注规模描述的逻辑，也就是刚才说到的，你怎么算出服务的市场规模，这里面的逻辑通不通顺。假设我现在设计一个产品，为一部分的 Python 开发者提供服务，那我如何去计算 Python 开发者的数量，如何对他们进行用户群区分，以及怎样定位自己的目标用户，就会非常重要。
把不同利益相关者的问题列出来，在后面根据规模、频率和强度打分，然后综合考虑。比如当某个用户提出需求期望的时候，我们在挖掘到他背后的动机之后，会考虑他能代表多少人，是一个小众的需求，还是大部分用户面临同样的问题。
然后，我们去客观评价类似的问题出现几率是否高，有的问题虽然确实存在，但因为出现频率足够低，所以有时会策略性地选择暂时不去解决。比如我们做社区，更换会员 ID 这样的需求可能就是一个出现频率足够低的事情，即便有用户真的提出来，可能不会满足，或者线下在数据库里帮他订正一下了事。
最后是从正反两面去评价强度，通俗一点说，就是问自己，如果满足了这个需求，用户会有多开心。以及，如果没有满足这个需求，用户会有多痛苦。我们以前有个同事评价需求的时候有句口头禅是“不做会死人吗？”，后来才知道她原来是做 110 出警系统的，对她来说，这句话并不是夸张。
描述规模、频率和强度的时候，得到结论固然重要，但更重要的是去探求结论的过程，它背后是产品经理对自己产品定位的深入理解，还有对用户的理解、对场景的理解、以及对市场和竞争环境的理解。有时候还会包含产品经理的一些价值取向和判断，比如有人相信薄利多销，有人则愿意高价高质，这并没有对错，选择不同而已。

总结

好了，今天的分享就到这里，我们从规模、频率和强度一起讨论了用户需求优先级判断的方法论，下次我们会讲另一种模型，也就是之前提到的价值曲线分析。你在平时的工作中会怎样安排需求的优先级，有没有什么能够分享的，欢迎在留言中讨论，谢谢你！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 7

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
31 | 产品分析的套路（下）：如何出解决方案？
下一篇
33 | 产品案例分析：Arts & Culture 的架构之美
unpreview
 写留言

精选留言(13)

  • 听天由己
    2018-02-01
    就我个人工作习惯来说，我将需求优先级排序分为三个维度： 一是用户量和发生频率，这点和二爷说的规模与频率相似，优先解决大用户量的高频问题，这是保证用户的基础体验。 二是开发难度与实践效果，围绕核心功能进行迭代是较为合适的手段； 三是产品和商业价值，这一点其实就是需求的紧迫性以及付费意愿，综合考虑成本收益而定。 当然，需求排序永远都是动态调整的过程。 这篇文章阅读后，我对打分和量化更感兴趣，希望二爷下次能够多多分享。
    展开
    19
  • 王岩
    2018-03-07
    内部的产品经理还得考虑一种情况：受众很小，但是个别重要领导提出，你是做还是不做呢？
    共 2 条评论
    13
  • 叹符xo
    2018-02-23
    规模:固定（地理、人文、经济）范围，用户数量 频次:固定（日/周/月/季/年均）周期，用户使用次数 强度:单次使用，用户收益/可避免的损失
    7
  • CC
    2018-02-04
    最近刚刚预订专栏学习，感谢二爷分享。 总结一下今天自己学到的需求优先级原则： 1. 避免做正确但没有影响力的事情； 2. 考虑机会成本，而不仅仅是看得见的工时/工资成本； 3. 受益者「规模」越大，优先级越高；判断规模的时候，多依据「现在」的情况，适当考虑「未来」，可以让产品的设计更稳固；要特别注意规模计算和描述的逻辑； 4. 问题的「频率」越高、「强度」越大，优先级越高；常见的场景组合是「高频低强度」和「低频高强度」，会挑战综合判断的能力； 5. 如果遇到「大规模、高频高强度」的组合，要考虑「主观可达性」，要特别注意推理符合逻辑； 6. 除了客观打分外，还需要有同理心，用感性思维，从正反两方面去考虑用户的感受。 期待下半部分的分享。:)
    展开

    作者回复: 👍欢迎欢迎

    7
  • 种菜的渔民
    2020-08-10
    作者所提之处并无不妥，但现实工作中遇到一个问题，在与开发人员讨论优先级排序时，对于小部分的非核心功能的开发，我给出的建议是暂缓执行，后续根据用户的实际反馈在决定开发；而程序员往往说，现在不做，以后就很难做了，改动会很大，这样一般要怎么权衡？
    3
  • Bonnie Mei
    2018-02-02
    在用户需求已经确认好的情况下，我们主要看哪些是重要的基础功能，哪些功能依赖于其他模块比较多，这些会作为研发经理排期计划的重要因素。我跑偏了，您这篇主要是需求管理，排优先级就想到研发管理……
    2
  • Weiyung
    2019-03-19
    二爷，你好。看完了这个章节，对于频率和强度的比较其实并没有很好的了解。可以再详细的指点指点吗？

    作者回复: 需求频率就是平均多久需要一次，比如吃饭就是每天三次；需求强度就是如果没有这个会有多惨，比如三天不吃饭还凑合，但三天不喝水就完蛋了。

    1
  • Sam_Deep_Thinking
    2022-07-13
    深度好文。必须点个赞。
  • 马辉
    2021-05-17
    规模（受众人数，细分到用户画像） 频率（场景发生次数） 强度（有多痛苦，满足度） 补一个，是否满足 商业利益（是否愿意付费，是否与我的利益有重叠）
    展开
  • 北冥Master
    2018-12-01
    强度是指什么？怎么衡量？
  • ñ..h...
    2018-05-04
    之前需求的优先级衡量一直是用重要程度（类似上述的强度）、紧急程度（类似上述的频率和规模）还有开发成本三个维度来评判的
    共 1 条评论
  • 告死ANGEL
    2018-02-21
    受益者越多、问题的频率越高、强度越大，则解决这样问题的价值就越大，优先级也越高。
  • 灿锋
    2018-02-01
    ”假设，如果我现在设计一个产品，可以给一部分的 Python 开发者使用，”，这里好像漏了后面的？

    作者回复: 是的，稍后补上