本文来自 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》。