立即登录 周末随手写点。前几天社区里有人聊到"需求优先级怎么排"，正好聊聊这个话题。
成熟的方法论其实不少，我自己平时用得最多的是矩阵分析法，以及它的变种。
最基础的做法是把需求按"重要性"和"紧急性"两个维度分成四象限。但我一直有个困惑：这俩东西真能分开吗？一个特别紧急的需求，会不重要吗？
前阵子淘宝iOS版本出过一件事，某个版本更新后，用户一打开App就弹窗。这种Bug修复紧急性拉满，难道能说不重要？显然也是最高优先级。
所以后来我换了个思路。纵轴还是叫"产品价值"，越高越好；横轴换成"开发成本"，越往右越贵。这样分成四个区域，优先级就清楚多了：
P1是高价值、低成本，闭眼做。P2要么价值低但便宜，要么价值高但贵，属于可以考虑的。P3低价值、高成本，做了吃力不讨好，最尴尬。
这样分的好处是迭代计划好定。现在互联网都讲快速迭代，两周一个版本是常态，能塞进去的需求有限。我的习惯是P1全做，再根据人力塞一部分P2，让开发同学的工作量刚好饱和，不浪费也不透支。
---
具体怎么评估这两个维度？
产品价值高不高，我主要看几点：影响的用户量有多大、使用频率高不高、用户等得有多急。还有一点很实在——能不能让用户更愿意掏钱。尤其是B端SaaS，大客户甩句话："你们把A功能做了，我现在就签单。"几十万上百万的合同摆在那儿，这个需求的价值还用说吗？说白了，产品价值最终就两种归宿：用户增长，或者收入增长。
开发成本相对好懂，主要是工时。具体评的时候最好拉着开发一起估，别自己拍脑袋。毕竟程序员工资摆在那儿，固定成本花出去了，得让他们干点值得的活儿。这么一想，产品经理有时候确实挺像"精神资本家"。
---
当然，理论归理论，真干起来不能死套。
还是前面那个例子：淘宝线上出Bug了，你能说"来，咱们先开个会排下优先级"？不可能。这种时候全停掉，所有人扑上去修就完事了。
另外，优先级排完得有个地方管。我习惯用需求池统一管理，迭代前从池子里捞，做完了再归档。感兴趣的话可以看看我常用的模板，公众号"产品经理日记"回复"需求池"就行。
---
特别说明：本站主要收集互联网运营相关干货，内容来自公开渠道或用户投稿，不代表本站立场，如有侵权请联系管理员删除。
