|
|
# 30 | 如何制定产品优先级 ？
|
|
|
|
|
|
制定产品优先级是产品经理的必备技能，但这个必备技能着实是一块儿“硬骨头”。
|
|
|
|
|
|
在日新月异的科技行业，计划赶不上变化， A/B测试可能带给你新的结论，竞争对手可能打乱你的步伐，产品功能比之前计划得要复杂得多，这样的变化都会改变产品优先级。
|
|
|
|
|
|
所以，每个产品经理需要做的，就是要在高变化、高不确定性、高复杂性的情况下制定出优先级，让产品以最快的速度、最小的代价取得最大的成功。
|
|
|
|
|
|
可见，制定优先级并不是一件易事，但更难的是要说服其他人认可你制定的优先级。
|
|
|
|
|
|
## 为什么需要产品优先级？
|
|
|
|
|
|
产品优先级，可以让团队成员明确哪些功能是需要优先做的，哪些功能是无关紧要的，从而在最短的时间内解决产品最关键的问题。
|
|
|
|
|
|
如果没有明确的优先级，团队成员就会失去方向，各打各的小算盘无法高效合作；产品优先级弄错了，就会耽误产品进度，而且你认为不重要的功能被竞争对手抢先发布了，对创业公司来说可能就关乎生死了。
|
|
|
|
|
|
我见过许许多多的产品团队，无论是成熟的产品团队，还是从零到一的产品团队，也接触过无数的产品经理，无论是资深的行家，还是刚刚入行的新人，这些产品团队和产品经理，都有一个共同的特点，那就是永远有做不完的产品任务，从来没有把事情都做完的时候。
|
|
|
|
|
|
而且，每次产品发布前的一个星期，总会出各种各样的问题，产品经理总会有各种危机要处理，甚至会修改之前的计划。
|
|
|
|
|
|
所以，如果产品团队没有优先级，而是按照顺序一个一个地做所有的任务，那么产品永远都不会被发布。
|
|
|
|
|
|
在Facebook，我们每个产品经理都要遵循的一个理念是：权衡取舍要无情。这句话重要到我们已经把它做成海报贴在了公司墙上，所有人每天上班前都会看到。
|
|
|
|
|
|
## 产品优先级的误区
|
|
|
|
|
|
在制定产品优先级时，有以下这四大误区，需要特别注意。
|
|
|
|
|
|
1. **认为所有功能都优先，这句话同时意味着所有功能都不优先。** 很多时候我发现，刚入行的产品经理会在产品需求文档洋洋洒洒地写上十几个功能， 而且每个功能都是紧急，这样做根本就是没有搞清楚产品的优先级。
|
|
|
在我看来，产品的优先级是要分等级的，如果你有10个功能， 最多有三个功能是最优先，也一定有三个功能是不优先的。
|
|
|
产品优先级的等级，我一般喜欢用P0、P1、P2表示，P代表priority，P0指最优先，P1指一般优先，P2则可以以后再做。在Facebook，我们的共识是P0是现在要做的，P1是有空就做的，P2是一定来不及做的。
|
|
|
|
|
|
2. **认为优先的功能是最简单的功能，这源于产品经理对最小化可行产品的误解。** 最小化可行产品， 是确保产品功能只要满足用户最基本的需求就可以了，但并不等于说产品只有最简单的功能。
|
|
|
最优先的功能应该是最有价值的功能，如果一个产品只具备一堆锦上添花的、最简单的功能，那它并不能算是一个完整的产品，它的优先级出了问题。
|
|
|
|
|
|
3. **判断产品优先级时只考虑工程难度以及预期效果，而忽略了这个功能的潜在风险。**
|
|
|
如果产品需要下个月发布， 有一个功能非常重要，也不难做，但是涉及到和其他的组的合作。而目前这个组的团队有问题，很有可能这个功能无法按时完成，而产品的发布时间必须要保证。
|
|
|
那么，这时候你就要思考这个功能到底是不是优先，是不是应该先做低风险的功能以确保产品发布。
|
|
|
|
|
|
4. **在做产品计划时，没有明确什么叫做最优先。** 比如，产品有三个最优先的功能，发布前其中一个没做完，那么你到底是应该选择先发布两个已经做完的功能，还是推迟整个产品的发布时间，等第三个功能完成后一起发布？
|
|
|
很多产品经理事先都没有考虑这个问题，导致产品发布前出现了突发情况非常慌，和团队成员争论不休，从而耽误了产品发布的良机。
|
|
|
所以，我建议，在做产品计划时就应该先明确，这些功能到底是不是重要到推迟产品发布也要等的程度。
|
|
|
|
|
|
|
|
|
## 你的产品优先级决定真的算数吗？
|
|
|
|
|
|
很多时候产品经理并不直接管理所有的团队成员，特别是在大公司，每个细分领域都有具体的部门来执行，而这些部门并不直接对产品经理负责。
|
|
|
|
|
|
举个简单的例子，市场营销部门会直接汇报给市场营销总监，所以你的市场营销经理更在乎的是总监在乎的指标，而不是你在乎的指标。
|
|
|
|
|
|
如果你制定的产品优先级和其他部门的不一致，那么你的产品优先级多半不算数。即使你分析得再准确，沟通得再清楚，甚至你的团队成员也哼哼哈哈地同意了，但最终他们并不一定会按照你的优先级来。
|
|
|
|
|
|
我在负责网红产品时，就经历了和市场营销部门的优先级不一致，而影响了产品的事情。我的产品团队有专门负责传媒公司营销策略的市场营销经理，当时我把对小型明星工作室更有帮助的功能，定为了最优先。而这个市场营销经理汇报的部门衡量成功的标准是，传媒公司客户的满意度，因此他们最优先的几个项目都是和传媒公司有关的。
|
|
|
|
|
|
虽然我说服了市场营销经理认可我制定的优先级，他也认为这对我们团队来说是最正确的选择，但在实际工作中，他并没有按照我制定的优先级来。而我们中间又缺乏了有效地沟通，最终影响了我们这个功能的正常发布。
|
|
|
|
|
|
后来，为了解决这种问题， Facebook在每半年计划的时候， 都会让不同的部门交流彼此的优先项目，提前找出利益冲突的部分。
|
|
|
|
|
|
这样，在制定计划时就充分交流，提前发现问题，有冲突时要么修改各自的优先级，要么修改成功指标（毕竟成功指标是决定优先级的核心标准），可以最大程度地避免对产品发布的影响。
|
|
|
|
|
|
## 无情的权衡取舍还要明确我们一定不做什么
|
|
|
|
|
|
在Facebook，我们一直在讲产品经理要无知、无畏、无情：
|
|
|
|
|
|
* 无知，就是产品经理不应该马上下结论，而是应该保持好奇心，提出假设，然后验证假设；
|
|
|
* 无畏，就是产品经理应该勇于制定有难度达到的成功指标，更好地激发团队潜力，而不是为了不担风险只打安全牌；
|
|
|
* 无情， 就是我今天跟你说的， 不管产品的想法多么好，可做的事情多么重要，都一定要分出个主次， 明确我们一定不做什么。
|
|
|
|
|
|
我在Instagram的一个老板，在制定产品线路图和优先级时，喜欢加一个“一定不优先”的板块，这个部分专门写那些我们肯定不做、 明确不是优先级的内容。
|
|
|
|
|
|
我第一次看到这个版块时，完全不理解为什么要花这么大精力去写一堆不用做的内容，但真正和团队磨合时， 我发现经常会有人提出我们要不要试试这个功能、要不要也做一做那个功能，或者某一个领导突然对某个东西感兴趣随口问了一句， 大家就蜂拥而至，要修改原有的产品计划，做这个功能。
|
|
|
|
|
|
这样的情况时有发生，虽说可以活跃产品团队氛围，但更多的却是干扰，导致产品的实际执行不能按照既定轨道进行。我的这个老板的“一定不优先”版块，目的就是降低这样的干扰。
|
|
|
|
|
|
他可以自如地给大家展示这个文档，问大家有没有最新的用户反馈，如果没有的话，我们就明确这个功能一定不优先；有没有什么新的信息需要我们改变策略，没有的话，我们就继续按照原定计划执行。这样一来，大家很快就能回到正轨，减少干扰。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
今天我给你分享的主题是如何制定产品优先级，这部分涵盖了制定产品优先级的计划、灵活调整优先级、沟通优先级、和与其他部门对优先级达成共识。
|
|
|
|
|
|
我还跟你分享了产品优先级的四个误区：第一，认为所有功能都优先；第二，认为优先的功能是最简单的功能；第三，制定优先级不考虑这个功能的潜在风险；第四， 在做产品计划时没有明确什么叫做最优先，什么情况下我们即使推迟产品发布也要等。
|
|
|
|
|
|
最后，我们跟你分享了产品经理的无知、无畏、无情，“权衡取舍要无情”是Facebook的理念，希望和你共勉。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
我在文中提到的产品优先级的四个误区，你曾经中过哪个？
|
|
|
|
|
|
欢迎你给我留言。
|
|
|
|