邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

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

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

避免毫无价值的正确

在排定优先级时,会有一种产品经理很容易出现的错误,就是“做无可争议的正确事情”。
这句什么意思呢,需求列表里永远有这样的需求,虽然没什么用,但做了肯定没错。比如去不断地优化一张页面的视觉和交互细节;把页面改得越来越好看、越来越好用总没错吧?这样的需求确实不能说它是错的,但这样的需求却大都无关痛痒。
之前我在博客里写过一篇文章,提到我认为产品经理需要让正确的事情相继发生,这句话因为池老师的加持变得广为流传。这里提到“正确的事情”,其实背后有一个叫做“机会成本”的经济学概念。
举个例子,如果我们投入 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 刘祯
    就我个人工作习惯来说,我将需求优先级排序分为三个维度:

    一是用户量和发生频率,这点和二爷说的规模与频率相似,优先解决大用户量的高频问题,这是保证用户的基础体验。

    二是开发难度与实践效果,围绕核心功能进行迭代是较为合适的手段;

    三是产品和商业价值,这一点其实就是需求的紧迫性以及付费意愿,综合考虑成本收益而定。

    当然,需求排序永远都是动态调整的过程。

    这篇文章阅读后,我对打分和量化更感兴趣,希望二爷下次能够多多分享。
    2018-02-01
    12
  • 王岩
    内部的产品经理还得考虑一种情况:受众很小,但是个别重要领导提出,你是做还是不做呢?
    2018-03-07
    3
  • 叹符xo
    规模:固定(地理、人文、经济)范围,用户数量
    频次:固定(日/周/月/季/年均)周期,用户使用次数
    强度:单次使用,用户收益/可避免的损失
    2018-02-23
    3
  • CC
    最近刚刚预订专栏学习,感谢二爷分享。

    总结一下今天自己学到的需求优先级原则:

    1. 避免做正确但没有影响力的事情;

    2. 考虑机会成本,而不仅仅是看得见的工时/工资成本;

    3. 受益者「规模」越大,优先级越高;判断规模的时候,多依据「现在」的情况,适当考虑「未来」,可以让产品的设计更稳固;要特别注意规模计算和描述的逻辑;

    4. 问题的「频率」越高、「强度」越大,优先级越高;常见的场景组合是「高频低强度」和「低频高强度」,会挑战综合判断的能力;

    5. 如果遇到「大规模、高频高强度」的组合,要考虑「主观可达性」,要特别注意推理符合逻辑;

    6. 除了客观打分外,还需要有同理心,用感性思维,从正反两方面去考虑用户的感受。

    期待下半部分的分享。:)

    作者回复: 👍欢迎欢迎

    2018-02-04
    3
  • Bonnie Mei
    在用户需求已经确认好的情况下,我们主要看哪些是重要的基础功能,哪些功能依赖于其他模块比较多,这些会作为研发经理排期计划的重要因素。我跑偏了,您这篇主要是需求管理,排优先级就想到研发管理……
    2018-02-02
    1
  • Weiyung
    二爷,你好。看完了这个章节,对于频率和强度的比较其实并没有很好的了解。可以再详细的指点指点吗?

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

    2019-03-19
  • 北冥Master
    强度是指什么?怎么衡量?
    2018-12-01
  • ñ..h...
    之前需求的优先级衡量一直是用重要程度(类似上述的强度)、紧急程度(类似上述的频率和规模)还有开发成本三个维度来评判的
    2018-05-04
    1
  • 告死ANGEL
    受益者越多、问题的频率越高、强度越大,则解决这样问题的价值就越大,优先级也越高。
    2018-02-21
  • 灿锋
    ”假设,如果我现在设计一个产品,可以给一部分的 Python 开发者使用,”,这里好像漏了后面的?

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

    2018-02-01
收起评论
10
返回
顶部