Ordinal prioritization - not everything gets to be #1
When everything is a P1, nothing is a P1.
One of the process improvements I’m most proud of introducing is laughably simple - ordinal prioritization. As an organization, we were quite good at separating the critical requirements from the important and nice-to-have requirements. The problem was, when we classed requirements as P1, P2, P3, and below, we were unknowingly withholding the even more useful information from our overseas development teams.
Simply put, if we as an organization could only complete one requirement, what would it be? If we could only complete two requirements, what would they be?
By lumping together all “critical” requirements into one designation, we lost that information. We also lost valuable time in the change request process - if a new feature request came up, we needed extensive discussions to identify what could be “bumped” to make room for it.
Ordinal prioritization forces some lively debates, and generally requires signoff from an executive sponsor. The criteria for what makes a #1 a #1 and not a #4 will vary from organization to organization. For us, it was “Will this feature have definite quantifiable revenue impact in landing deals?”, “Will this feature have definite quantifiable usage impact (which drives more revenue?)”, “Will this feature significantly differentiate our products from that of our competitors?”, “Will this feature fix something which is causing significant user experience issues, support issues, or deployment issues?”
-->