“一朝需求不称意，口里驱蛩心上蚝。”——（明）刘基
在之前几次分享中，我说到了分析产品的时候要反复探求“用什么方法，解决谁的什么问题”，从利益相关者、问题和解决方案三个维度分别介绍了产品分析的思考套路。基于这样的套路，或许我们可以列出产品不同利益相关者面临的不同问题，以及解决这些问题的方案。
那么接下来的问题就是，在资源有限的情况下，应该如何取舍，如何安排需求优先级？我这次就从这个话题开始聊起，跟你分享一些我的思考和经验。
在排定优先级时，会有一种产品经理很容易出现的错误，就是“做无可争议的正确事情”。
这句什么意思呢，需求列表里永远有这样的需求，虽然没什么用，但做了肯定没错。比如去不断地优化一张页面的视觉和交互细节；把页面改得越来越好看、越来越好用总没错吧？这样的需求确实不能说它是错的，但这样的需求却大都无关痛痒。
之前我在博客里写过一篇文章，提到我认为产品经理需要让正确的事情相继发生，这句话因为池老师的加持变得广为流传。这里提到“正确的事情”，其实背后有一个叫做“机会成本”的经济学概念。
举个例子，如果我们投入 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 出警系统的，对她来说，这句话并不是夸张。
描述规模、频率和强度的时候，得到结论固然重要，但更重要的是去探求结论的过程，它背后是产品经理对自己产品定位的深入理解，还有对用户的理解、对场景的理解、以及对市场和竞争环境的理解。有时候还会包含产品经理的一些价值取向和判断，比如有人相信薄利多销，有人则愿意高价高质，这并没有对错，选择不同而已。
好了，今天的分享就到这里，我们从规模、频率和强度一起讨论了用户需求优先级判断的方法论，下次我们会讲另一种模型，也就是之前提到的价值曲线分析。你在平时的工作中会怎样安排需求的优先级，有没有什么能够分享的，欢迎在留言中讨论，谢谢你！
评论