I was recently in a prioritization meeting where the discussion got quite confused and it made me realize one thing… There is a big difference between priorities and working order (I e in what order you tackle things in a project)
Priorities are about business need and how desirable a feature is. A high priority means that the business really wants a specific feature and that they are (hopefully) willing to spend some effort and money on it. A lower priority feature is something that the business can live without if they have to.
This has often been linked to working order, meaning that features should be worked in in priority order, from high priority to lower. The reasoning behind this is often that if, for any reason, the project is stopped at least we have developed the highest priority features and therefore we can put those into use.
BUT (and this is where the confusion often occurs)
There could be other reasons for doing lower-priority features before higher-priority ones.
First, a higher-priority feature might actually depend on a lower-priority feature. This means that the higher-priority feature cannot be developed or deployed before the lower-priority feature is in place. In this case, it makes perfect sense to work on lower-priority features before higher-priority ones.
Second, resource constraints may push us to work on higher priority features before lower-priority ones. Imagine we have 3 features, A, B and C which are prioritized in that order. Furthermore we have 2 developers Albert and Cecilia. Their respective competence areas mean that features A and B can only be developed by Albert whereas C can be developed by Cecilia. In this case, it makes sense to do feature C before B, since Albert is busy developing A.
So, when we are talking about priorities, it would be beneficial for all parties to understand these complexities. Otherwise we could end up PRIORITIZING features based on dependencies or resource constraints, which would be wrong.