虎年的第一期产品沉思录精选，是去年看到很想推荐的关于如何判断需求优先级的方法论。这是一种理念上的变化，但是可能落地到工作实践中会有些难度。没关系，在新的一年知道了还存在另一种经过认真思考的方法也是不错的，希望可以通过 fonter 翻译的这篇文章摘要，帮助你获得一个不同视角来观察手头工作。

最近我和 fonter 也在整理产品沉思录的结构体系，2021年的产品沉思录精选集相信不久就会和大家见面。

如果你想获取最新的订阅，欢迎扫描文末二维码。如果觉得有帮助，也欢迎转发给同样走在产品路上的小伙伴。

选自沉思录邮件组
Vol.20210516：只要有空置，就有价格歧视

本文来自 Fibery 的产品博客 ，基于其 CEO 和产品经理 Anton Iokov 的总结。Fibery 的 CEO 说，启发于 Kevin Simler 的一篇《虚无主义者的意义探究指南》，耳听曾经撰文推荐过 Kevin Simler ，他也有一本畅销书《脑中的大象》^[1]。看本文的朋友，很大比例是产品经理岗位的吧，日常工作中遇到的常见的场景恐怕逃不过需求的 battle，优先级排序，你们日常的不满和妥协很大一部分来自于此吧。

需求的优先级排序，有时候是个玄学问题，是产品管理中最困难的问题之一。Fibery 的 CEO 说，有许多技巧可能会有帮助，他已经尝试了所有的方法，但都没有很大成功。简而言之，这些技术只是线性模型，和有经验的产品经理的直觉一样好(或一样坏)。他们 Fibery 团队借鉴 PageRank 引入了网络效应的特性来加强优先级排序的方法。他们的目标不是替换当前的优先级排序的逻辑 （RICE 模型），而是增强现有的优先排序方法。

传统上从客户反馈中收到繁多的线索，如何处理他们？你会注意到一些某些角色岗位的反馈重复出现，从中提炼普适的共性，凝练成features。下一步如何排序这些 features？如何评估 feature 价值的时候到了，大家有了一致的价值评估原则的时候，就可以相对理性的探讨。

RICE 模型是产品经理常用的一种方法，其中包括四个方面：

• Reach 触达力

• Impact 影响力

• Confidence 信心

• Effort 工作量

Reach 触达力

反馈在每个功能将有多少人在一定的时间期限内影响和有多少人会注意到的变化。

定义

估计每个项目在一定时间段内会影响多少用户。尽可能使用产品指标的实际测量结果，而不是随机去拍一个数。

接触数量用每个时间段的用户数或事件数来衡量。这可能是「每季度客户数量」或「每月交易数量」。尽可能使用产品指标的实际测量结果，而不是随机去拍一个数

举例

• 项目 1：500 个客户每月在注册漏斗中达到此点，30％ 选择此选项。那么每季度的接触数量是 500×30％×3=450 个客户。

• 项目 2：每季度使用此功能的每个客户都将看到这一变化。那么每季度的接触数量是 2000 个客户。

• 项目 3：这一变化将对 800 个现有客户产生一次性影响，而且没有持续的影响，则每季度的接触数量是 800 个客户。

Impact 影响力
展示了该功能将如何为产品做出贡献以及该项目将如何影响您的客户。

定义

要专注于那些能对你的目标产生可观影响的项目，预估这个项目对个人产生的影响。

• 对于作者的团队来说，是「当客户遇到这个项目时，能够提高多少转化率？」。

• 你的团队可能会用另一个目标，比如「提高采用率」，或者「最大化满意度」。

分数

影响程度难以准确度量，因此，作者设置了一些选项来衡量：3 为「巨大影响」，2 为「高」，1 为「中」，0.5 为「低」，最后 0.25 为「最低」。

举例

• 对于每个看到它的客户，这将产生很大的影响。则影响程度假定是 3。

• 这将对每个客户产生较小的影响。则影响程度是 1。

• 这在影响方面处于中间位置。则影响程度是 2。

Confidence 信心

表明了对所有估计的把握- 包括影响和工作量。

定义

有些主意非常激动人心但是并不明确，为了遏制住马上去实践它们热情，在评估时请把信心指数考虑进去（我们认为这个功能能实现 R 和 I 的自信程度）。

信心指数是一个百分比，作者设置了另一种选项来避免决策瘫痪。

• 100％ 是「高信心度」，80％ 是「中等」，50％ 是「低」。

• 比这更低的信心指数都可以认为是「登月计划」

举例

• 项目1：我们有定量指标来衡量接触数量，有用户研究来证明影响程度，还有工程预估会投入的精力。则这个项目的信心指数是 100％。

• 项目2：我有数据支撑接触数量和投入精力，但我不确定项目的影响会是什么程度。则这个项目的信心指数是 80％。

• 项目3：这个项目的接触数量和影响程度可能低于预期，需要投入的精力则高于预期。则这个项目的信心指数是 50％。

Effort 工作量

取决于需要的“人月”，周或小时。这是一个团队成员在特定月份可

完成的工作。

定义

估算项目需要团队的所有成员（产品，设计和工程）的总时间。

投入精力的预估单位是「人/月」

• 一个团队成员可以在一个月内做的工作

• 有很多未知数，所以考虑用整数来预估（一个月以下的任何事情都用0.5来预估）

举例

• 项目1：这个项目需要约一周时间做计划，1- 2 周的设计和 2-4 周的研发时间。则预估的精力投入是 2 人/月。

• 项目2：这个项目需要几周时间做计划，大量的设计时间和一个工程师至少两个月的时间。则预估的精力投入是 4 人/月。

• 项目3：这只需要一个星期的计划，不需要新的设计，几周的工程时间。则预估的精力投入是 0.5 人/月。

   需要使用“Reach”，“Impact”，“Confidence”和“Effort”对建议的功能进行排名，并使用最终得出的分数来决定应首先实施的功能。 

举个例子

其中红色圆圈是用户的场景用户的要解决的问题，绿色圆圈是需要开发的功能。

需求 A 和需求 B 如何评估价值进行排序？

按照 RICE ，似乎需求 A 能影响更多的人成本较小，似乎 A 更高优？

上述这种思考方式其实就是典型的一阶思维，这种思维快速而简单，但是往往只解决眼前问题，却没有考虑后果。

然而，在判断需求优先级时，我们需要使用更深思熟虑的二阶思维。它是从互动和时间的角度来思考，明白我们的干预往往会造成伤害。

使用二阶思维时，需要习惯性地问自己，然后呢？试着连续问五个然后呢，或许会有清晰的答案。在思考中加入时间维度，比如10天/10个月/1年后会怎样也是经常用到的方法。最后，切记要考虑利益相关者的反应。

那接下来我们就用RICE方法论和二阶思维重新再思考下这个案例

用户反馈之间的联系是什么？

• 解决一堆不相关的用户反馈案例

• 意味着为每个人而不是任何人构建一个产品。

• 大多数情况下，这是一个糟糕的策略

• 用户反馈的真正重要性在于他们之间的 connections

功能之间的后续影响是什么？

• 一些功能开启了新的可能性并增强了现有的功能；

• 其他的功能增加了复杂性并减慢了开发速度；

• 虽然一些功能可以解决重要的用户反馈，但它们对整个业务的网络是有害的。

考虑了上面2个问题，再来看下图

需求 A 似乎没那么重要了，如果优先做了 A 似乎是笨蛋

那么这个过程该如何量化并实践到工作中去？请看产品经理 Anton Iokov 的文章 《Enhancing prioritization with networks》^[2]。

References

[1] 《脑中的大象》: https://book.douban.com/subject/35235952/

[2] 《Enhancing prioritization wtih networks》: https://uxdesign.cc/enhancing-prioritization-with-networks-894760555b04

如需获取最新订阅，或访问会员专属数据库，请扫描下方二维码或点击阅读全文