在大多数产品团队中，待办事项清单是紧急性消亡的地方。进入它的所有东西在添加时都是紧急的——一个客户投诉、一个销售请求、一个竞争对手的功能、一个内部想法。六个月后，它仍然都在那里，它看起来仍然全部紧急，没有人确切知道接下来做什么。
问题不是缺乏工具。有几十个优先级框架：RICE、MoSCoW、Kano、ICE、加权评分。问题是大多数框架需要一种虚假的精确度——将数字分配给未知数——这使他们感觉严格，而实际上只是通过电子表格清洗内直觉。
实际有效的要简单得多：两个维度，诚实地评估，以及采取行动的纪律。
优先级折叠为两个问题。首先：这在多大程度上改善我们关心的结果？（影响。）其次：我们需要花费多少来交付它？（努力。）其他一切要么是这两个的精细化，要么是对它们的分心。
有时会添加信心作为第三维度——"我们对影响有多确定？"——值得牢记。但在实践中，大多数团队都知道他们何时在猜测。纪律是诚实地标记猜测，而不是在 1-5 的量表上评分并将其添加到公式中。
困难的部分不是理解网格——是在填充它时诚实。每个团队都有他们想构建的功能，属于"时间浪费"但不断重新分类为"大赌注。"框架仅在团队对影响可以诚实时有效。
影响是团队发现最难评估的维度，因为它通常需要预测未来。诱惑是数值评分它并对此感到科学。更好的方法是定性但结构化。
为每个考虑中的功能提出三个问题：
团队系统地低估努力。这是有据可查的——它与规划谬误和乐观偏差有关——对于触及多个系统、需要跨团队协调或涉及团队尚未构建的能力的功能，特别是明显。
优先级真正破损的地方不是在计算中——是在沟通中。一个优先级的待办事项如果团队不理解为什么某些东西在顶部而其他人在底部，那就是无用的。如果销售人员要求"功能 X"三个月前在待办事项中仍然看到它，没有影响和努力的解释，系统就会失败。
最佳实践是记录每一条的优先级象限——不是作为量表上的数字，而是作为"这是快速赢利"或"这是我们有意识地决定现在不构建的时间浪费"的口头声明。然后，当有人问"我们为什么不构建功能 X？"答案是一个对话，而不是一个数字。