需求优先级经常被讨论成排期问题，但从根上看，它其实是结果问题。
先搞清楚要什么结果，再讨论做什么功能，顺序才不会反。
我会先问四个问题#
这个需求解决的是谁的问题。
这个问题如果不解决，会损失什么。
这个方案会不会引入更大的复杂度。
有没有更小的动作就能验证方向。
这四个问题可以把很多伪需求直接筛掉。
高优先级通常有三个特征#
它离收入更近。
它离核心流程更近。
它离风险控制更近。
只要同时满足其中两个，优先级通常就不会低。
我尽量避免的情况#
为了显得完整，先做一堆边缘功能。
为了照顾所有意见，做一套谁都不满意的折中方案。
为了减少争议，把真正关键的问题往后拖。
这些选择看似稳妥，最后往往最贵。
一个更可靠的做法#
先把需求拆成目标、约束、验证指标和最小行动。
只要最小行动能验证方向，就先做最小行动。
当方向被验证以后，再考虑补齐体验、效率和规模化能力。
这样做的好处是，每一步都更接近事实，而不是更接近想象。