本文来自 Fibery 的产品博客 ,基于其 CEO 和产品经理 Anton Iokov 的总结。Fibery 的 CEO 说,启发于 Kevin Simler 的一篇《虚无主义者的意义探究指南》,耳听曾经撰文推荐过 Kevin Simler ,他也有一本畅销书《脑中的大象》。看本文的朋友,很大比例是产品经理岗位的吧,日常工作中遇到的常见的场景恐怕逃不过需求的 battle,优先级排序,你们日常的不满和妥协很大一部分来自于此吧。
今天这一篇是去年看到很想推荐的,是一种理念上的变化,但是可能落地到工作实践中比较难的案例。没关系,知道了还存在另一种经过认真思考的方法也是不错的,可以获得一个不同视角的观察你的工作。
需求的优先级排序,有时候是个玄学问题,是产品管理中最困难的问题之一。Fibery 的 CEO 说,有许多技巧可能会有帮助,他已经尝试了所有的方法,但都没有很大成功。简而言之,这些技术只是线性模型,和有经验的产品经理的直觉一样好(或一样坏)。他们 Fibery 团队借鉴 PageRank 引入了网络效应的特性来加强优先级排序的方法。他们的目标不是替换当前的优先级排序的逻辑 (RICE 模型),而是增强现有的优先排序方法。
传统上从客户反馈中收到繁多的线索,如何处理他们?你会注意到一些某些角色岗位的反馈重复出现,从中提炼普适的共性,凝练成features。下一步如何排序这些 features? 如何评估 feature 价值的时候到了,大家有了一致的价值评估原则的时候,就可以相对理性的探讨。
RICE 模型是产品经理常用的一种方法。
定义
- 估计每个项目在一定时间段内会影响多少用户。
- 尽可能使用产品指标的实际测量结果,而不是随机去拍一个数。
- 接触数量用每个时间段的用户数或事件数来衡量。
- 这可能是「每季度客户数量」或「每月交易数量」。
- 尽可能使用产品指标的实际测量结果,而不是随机去拍一个数。
举例
- 项目 1:500 个客户每月在注册漏斗中达到此点,30% 选择此选项。
- 每季度的接触数量是 500×30%×3=450 个客户。
- 项目 2:每季度使用此功能的每个客户都将看到这一变化。
- 每季度的接触数量是 2000 个客户。
- 项目 3:这一变化将对 800 个现有客户产生一次性影响,而且没有持续的影响。
- 每季度的接触数量是 800 个客户。
定义
- 要专注于那些能对你的目标产生可观影响的项目,预估这个项目对个人产生的影响。
- 对于作者的团队来说,是「当客户遇到这个项目时,能够提高多少转换率?」。
- 你的团队可能会用另一个目标,比如「提高采用率」,或者「最大化满意度」。
分数
- 影响程度难以准确度量。
- 因此,作者设置了一些选项来衡量:3 为「巨大影响」,2 为「高」,1 为「中」,0.5 为「低」,最后 0.25 为「最低」。
举例
- 项目 1:对于每个看到它的客户,这将产生很大的影响。
- 影响程度是 3。
- 项目 2:这将对每个客户产生较小的影响。
- 影响程度是 1。
- 项目 3:这在影响方面处于中间位置。
- 影响程度是 2。
定义
- 有些主意非常激动人心但是并不明确,为了遏制住马上去实践它们热情,在评估时请把信心指数考虑进去(我们认为这个功能能实现 R 和 I 的自信程度)。
- 信心指数是一个百分比,作者设置了另一种选项来避免决策瘫痪。
- 100% 是「高信心度」,80% 是「中等」,50% 是「低」。
- 比这更低的信心指数都可以认为是「登月计划」
举例
- 项目1:我们有定量指标来衡量接触数量,有用户研究来证明影响程度,还有工程预估会投入的精力。
- 这个项目的信心指数是 100%。
- 项目2:我有数据支撑接触数量和投入精力,但我不确定项目的影响会是什么程度。
- 这个项目获的信心指数是 80%。
- 项目3:这个项目的接触数量和影响程度可能低于预期,需要投入的精力则高于预期。
- 这个项目的信心指数是 50%。
定义
- 估算项目需要团队的所有成员(产品,设计和工程)的总时间。
- 投入精力的预估单位是「人/月」
- 一个团队成员可以在一个月内做的工作
- 有很多未知数,所以考虑用整数来预估(一个月以下的任何事情都用 0.5 来预估)
举例
- 项目 1:这个项目需要约一周时间做计划,1- 2 周的设计和 2-4 周的研发时间。
- 预估的精力投入是 2 人/月。
- 项目 2:这个项目需要几周时间做计划,大量的设计时间和一个工程师至少两个月的时间。
- 预估的精力投入是 4 人/月。
- 项目 3:这只需要一个星期的计划,不需要新的设计,几周的工程时间。
- 预估的精力投入是 0.5 人/月。
您需要使用“Reach”,“Impact”,“Confidence”和“Effort”对建议的功能进行排名,并使用最终得出的分数来决定应首先实施的功能。
举例
其中红色圆圈是用户的场景用户的要解决的问题,绿色圆圈是需要开发的功能。
需求 A 和需求 B 如何评估价值进行排序?
按照 RICE ,似乎需求 A 能影响更多的人成本较小,似乎 A 更高优?
下面是一堆灵魂的拷问分析了
用户反馈之间的联系是什么?
- 解决一堆不相关的用户反馈案例
- 意味着为每个人而不是任何人构建一个产品。
- 大多数情况下,这是一个糟糕的策略
- 用户反馈的真正重要性在于他们之间的 connections
功能之间的后续影响是什么?
- 一些功能开启了新的可能性并增强了现有的功能;
- 其他的功能增加了复杂性并减慢了开发速度;
- 虽然一些功能可以解决重要的用户反馈,但它们对整个业务的网络是有害的。
考虑了上面2个问题,再来看下图
需求 A 似乎没那么重要了,如果优先做了 A 似乎是笨蛋
那么这个过程该如何量化并实践到工作中去? 请看产品经理 Anton Iokov 的文章 《Enhancing prioritization with networks》。