The prioritization phase is a key part of the discovery process. During the discovery phase problems and issues are brought into discussion and are analyzed in depth. The objective of the phase is to identify the personas facing this problem and how much it impacts their experience.
Once all the initiatives come out from the discovery phase, the next step to come is prioritizing them on the product roadmap.
The product roadmap
The product roadmap is a tool used to plan the product initiatives, which in turn lets the company know what will happen in the near future. The initiatives that are placed on the timeline come from input other than product discovery, for instance:
Cross pollination from other industries
Once we have a list of initiatives coming from different sources we need to establish an order to place them on the roadmap. Luckily we can rely on different prioritization frameworks to establish which features must be built immediately, which ones to keep on the back burner for a while, and which ones not to build.
Here are some examples:
The MoSCoW framework helps you categorize and separate the core features from the ones that can wait in the backlog. The name MoSCoW is a helpful way to help remember the four categorizations of this framework:
Must-have - features that are crucial for the users’ experience and that could prevent them from using the product if not implemented. These features must be included in the MVP.
Should have - features that will come immediately after the first release because they are needed to drastically improve the user experience.
Could have - improvement features that are not crucial for the product usage and that can be placed in the second half of the roadmap
Won’t have - features that won’t bring value to the user and therefore won’t appear in the roadmap
Based on feedback collected from users, and the impact that the feature would have on their experience, we cluster the features in one of these four categories and we develop them, giving priority to the must haves, followed by the should haves and could haves immediately after and excluding the won’t haves.
Qualitative Cost of Delay
Qualitative cost of delay is a prioritization framework based on two essential factors: value and urgency. These two ingredients are not necessarily dependent on one another, even though we often (wrongly) think that something valuable is also urgent and vice versa!
With the help of a 3x3 matrix, we can define 3 clusters for each factor and identify the crossing areas that define the cost of delay.
The value categories are:
Killer: these are the features that we must carry out, which will impact our product in a positive way if we implement them, or in a negative way if we don’t
Bonus: these are nice-to-have features that are valuable pluses, which would probably increase incomes and reduce costs
Meh: these are maintenance-level developments, which deserve to stay on the roadmap but wouldn’t make much difference whether they are delivered or not. We usually deliver these features while working on something big (killer) to keep users engaged
On the other axis are the urgency clusters:
ASAP!: highest urgency - without this feature, the value of the product will evaporate (whatever the total value might be)
Soon: middle urgency - without this feature, the value of the product will start to decline
Whenever: lowest urgency - delays won’t have much of an impact on the overall product’s value.
A feature that has a Killer value and ASAP! urgency should be surely prioritized whereas a feature with a Meh value and Whenever urgency should be postponed to prioritize a more important task.
So how does BOOM apply this framework? A great example of that is how we used it to develop the gallery to allow clients to manage their visual assets. After an analysis of the users' needs and journey across our platform, we understood that we were missing a crucial part of the product: the visualization of visual assets. We have always known that sooner or later we should have given our clients the possibility to see their photos directly on our platform but we always had more urgent tasks to complete first (and if you work in a startup you know what I mean!). What we were doing was giving voice only to the x axis of the graph above, and so urgency was driving our work. Once we realized that we needed to stop working on emergency mode, we took a moment to talk with our client and analyze the data that we had on hand. It turned out that while it didn’t prevent our clients from accessing the platform, including a gallery was a killer feature since all our competitors had it and it would have made our clients’ life easier. The priority of this initiative became high with a very high value and a medium urgency and was delivered in only one sprint. Needless to say that our clients loved it!
Besides the two examples of prioritization frameworks detailed above, there are many other ways to define priorities, including the ROI scorecard and the Desirability, Feasibility, Viability. Prioritization is crucial for every product company that has a large number of ideas but limited resources, and the need to deliver the maximum value possible with the means available.