What Problem Are We Solving With Prioritization?

What problem are you *really* solving with prioritization?  Not what problem you *think* you are solving, but what problem are you actually solving?

To answer that, we need to take a step back and discuss the justifications for prioritization in the first place.  Those justifications might go something like this:  your product development^1^ team has a customer (or someone who represents the customer) in the form of a product manager or product owner.  One aspect of that product manager's job is to come up with requirements or features for the product they own.  Those requirements are then communicated to an execution team and it is that team's responsibility to turn those requests into something tangible for the ultimate end user.  

Here's where the first problem comes in.  Generally speaking, it is much easier to dream up features than it is to turn them into reality.  In other words, ideas are easy; execution is hard.  The practical manifestation of this dichotomy is that requests arrive (to an execution team) at a faster rate than those requests can be fulfilled.  Simple physics immediately resolves this mismatch of arrival/departure rates by forming a queue at the beginning of the team's execution process.  Owing to the ignorance of the individuals responsible for "inventing" your product development process, this queue is almost never referred to as a queue--even though that's exactly what it is.  No, you probably refer to this queue by its more common, vulgar name:  backlog.

Here's where the second problem comes in.  Product managers believe--or have been told to believe--that their job is to "order" this self-inflicted backlog in such a way as to maximize the value of their product.  The thinking is that there is an optimal sequence of requests that can be fed to an execution team that will ensure that highest value features are always worked on first, thus maximizing the overall value of the product.  That thinking is seductive.  If "Feature A" is more valuable than "Feature B", then obviously it makes sense for the development team to start "Feature A" before "Feature B".  Q.E.D.  You probably refer to this ordering by its more common, vulgar name:  prioritization.

Which brings us back to the very first question I posed.  Most organizations believe that backlog prioritization solves the problem of how to maximize the value of a given product.  But I am here to tell you that they are solving for the wrong thing.  The issue they really should be concerning themselves with is not one of value, but one of economics.

At first glance, you might think there is no difference between "value" and "economics".  After all, they both ultimately speak to money, right?  Well, not really.  Understanding the difference between value and economics will make all of the *difference* in the world.  But for that, you'll have to wait until next time.

## Endnotes

1. "Development" here does not necessarily mean "software development".  Here, I am talking about any product development scenario, be it software or not.

‍