产品经理最讨厌听到的一句话：
这个需求很简单，怎么做我不管。明天就要。
到底怎么平衡业务需求优先级与产品开发进度的关系，确保有效需求快速上线？
今天来和大家来分享一下，我们团队是怎样通过两张象限表就轻松搞定了增长黑客产品需求的优先级。
具体做法如下：
首先，确认业务优先级
在有了具体的产品功能需求之后，我们会按照象限分析法排出业务需求优先级。
第一步，将具体的业务需求在以下这张表中找到它的位置。
按照这两个维度，由产品经理和需求方一起讨论： “如果有这个功能”，结果是“好”、“无所谓”或者“不好”；“如果没有这个功能”，结果是“好”、“无所谓”或者“不好”。
第二步，快速剔除矛盾需求与无效需求。
如果有/没有这个功能，同时好或者不好，都是矛盾需求，不存在这种情况。
如果有这个功能无所谓，没有这个功能好；如果有这个功能不好，没有这个功能所谓，这两种情况都是无效需求。
这样我们就只剩下四个象限的需求要考虑，分别是
1. 如果有这个功能”好“，如果没有这个功能”无所谓“：
举个例子，运营提了一个营销工具的需求，有这个功能很好，没有这个功能现在的功能也能支撑。
2. 如果有这个功能”好“，如果没有这个功能”不好“：
这个象限的需求肯定很重要，有可能是产品核心功能，不可以缺少。所以优先级一定最高。
3. 如果有这个功能”无所谓“，如果没有这个”不好“：
这个象限的需求是”必要“需求，它的优先级其次。比如，运营后台的配置化需求，当前是产品直接写死的，运营配置非常麻烦。如果没有这个功能，直接用开发也可以实现，但是没有这个功能，运营活动上线速度就很慢。
4. 如果有这个功能”无所谓“，如果没有这个功能也”无所谓”：
这个象限的需求说出来就很搞笑，但是每个公司有些这种“无所谓”的需求，这种需求优先级最弱。这类需求的来源方一般都是强势的业务方或者强势的领导们。
第三步，确认业务优先级。
优先级按照从高到低，分别表示为P1、P2、P3、P4，给上面的四大象限排出优先级，分别是
这样我们就很轻松地得出了业务的优先级。很多公司就以这个业务优先级直接进入开发环节，这样是不对的，特别是对于需求响应速度要求极高的增长黑客行业。有时候虽然在开发P1的需求，但是可能P1需求需要14天开发周期，而P2需求只要4天。如果这样的话，P2需求的价值明显高于P1需求，因为它可以多10天的运营时间。
因此，在确认了业务优先级之后，还需要同步考虑开发的时间周期。
其次，确认开发优先级
我们通过区分业务优先级和开发周期，重新得到一张象限表：
备注：
1. P4需求家家有本难念的经，这里不考虑。
2. 之前文章《做增长黑客之前，请先做好PMF》提过，超过4周开发时间的需求不予考虑。
结合需求的重要性和开发周期，我们就可以很快得出最后的开发优先级：
由于黑客增长对速度要求很高，在上表的9个象限中，我们重点关注需求1-4，5-9的需求因为等到需求排期开发的时候，有效性已经过了，所以不作考虑。
