A comparison of prioritization methods

In my opinion, there is no best prioritization method that works impeccably for everyone all the time. So, the way to approach this subject would be to define specific criteria against which to assess each of the previously discussed prioritization methods, define how each prioritization approach compares to the other ones, and summarize the best use cases for each technique

The following criteria will be taken into account when comparing the prioritization methods because in my opinion these are the most critical consideration factors for most people when looking for ways to prioritize:

Simplicity. This implies how easy and quick it is to use the method for prioritizing purposes. The reason why this criterium is important is because the simpler the method, the faster we prioritize.

Balance between business value and technology (effort of implementation) constraints. To make sure a product is successful, the customer’s wishes and desires should always occupy a central place. As a result, there are prioritization methods that put the (business/user) value on top. However, this is simply not enough. There are many prioritization approaches that lack technical considerations. A feature, a big initiative or a project can be extremely important in business terms (i.e. benefit resulting from the implementation), but equally difficult and time consuming in terms of development (i.e. cost of implementation). If a prioritization method suggests you grab the low-hanging fruit, i.e. prioritize an important feature that will bring high value fast (because it doesn’t require a big implementation effort) – it may be a no-brainer approach.

Data-driven prioritization. Some prioritization methods rely more on assumptions rather than on proven data. Data-driven is the right way to go if you aim for more accurate and reliable prioritization. However, there are many cases in which data is simply not available or it is too time consuming to obtain, hence in these circumstances it is not worth striving for collecting comprehensive data and performing complex calculations.

Specific sequencing and planning of features or other backlog items. Many of the methods prioritize the backlog items in categories, but do not introduce specific sequencing (ordering) of features/backlog items and hence lack specific planning. As a result, it makes it hard for product people (i.e. product managers and product owners) to decide on the exact priority of a feature compared to another one within the same category. This is not necessarily a problem, but it can be particularly challenging if a set of important features from the same category cannot all be implemented in the same release due to time/resource constraints.

Best use case (MVP/new products or mature products). As covered in my previous articles in the series, some prioritization techniques are better suited for MVP/new product development, whereas others are better used for prioritizing features/work items for more mature and established products. Most of them though work well for both use cases.

Based on the criteria above, Table 1 below compares the five prioritization methods and techniques, covered individually in my previous articles.

Table 1: Comparison of prioritization methods

Looking at Table 1 above, we can conclude that Weighted Shortest Job First (WSJF) model performs the best overall in terms of coverage of most of the criteria. However, as we saw in my article about WSJF, the time it takes for big product teams with hundreds of features to prioritize their backlog using WSJF often makes people search for a quicker and more efficient prioritization technique (but not necessarily as comprehensive). The Eisenhower matrix and Value vs. Effort matrix are all good alternatives to WSJF model, which will allow you to quickly prioritize features in different categories. Value vs. Effort matrix can be especially a good option when you want to prioritize big initiatives or features by taking into consideration the technical aspects and effort of implementation. MoSCoW is by far the simplest and quickest prioritization method to use, but you should be careful with this method because it is probably the most subjective one and is not really recommended for a more mature product with a complex backlog with many time-sensitive releases. On the other hand, MoSCoW is a nice technique to use for portfolio and MVP planning at the highest product management level. I have also seen it working well in combination with the Story Mapping technique when defining an initial MVP and planning the work items for the subsequent releases. For data-driven prioritization with a primary focus on the customer, the Kano model is way to go.

To wrap up, all prioritization methods discussed in my series are not mutually exclusive. You can complement prioritization methods at different stages of the product development lifecycle. For example, for the early stage of development of a new product, you may decide to use the Kano model and the Kano survey to generate useful user feedback from the start, and then use the Value vs Effort matrix to take into account the technical complexity of the features on your backlog and generate quick wins. Once your product becomes more mature and your backlog becomes more complex with many time-critical releases, you may decide to make use of the WSJF model for more specific job sequencing. And if you, as a product manager or a product owner, would like to improve your time management (e.g. because prioritizing many items using the WSJF model takes you significant time) and avoid the “urgency trap”, the WSJF model can be supplemented with the Eisenhower matrix to focus on and prioritize the items that really matter.

This article concludes my article series on prioritization methods and techniques. I hope you’ve enjoyed the series and they've helped you to prioritize more effectively in your daily work. If you want to learn more about prioritization in product or project management, feel free to contact me.