MOSCOW — Prioritization Method in Product Management
As the ServisSoft Product Management Team, Zeynep Ozay Mahmutoğlu and I started this content series, where we’ll talk about the different prioritization methods you can use while creating product roadmaps.
We’re trying to use various prioritization methodologies to find out what’s best for us, and we’ve created a scoring method according to feasibility, creation times, and the ability for other teams (stakeholders) to understand the system.
What is prioritization?
Prioritization is prioritizing your duties to the degree that how important are they.
Especially when the deadline is at the eleventh hour, all work will seem important to you, and during these times prioritization will save your life and work plan.
Prioritization will help you to use your limited time in the best possible way and finish the most important tasks.
Prioritization is the easiest thing when you list all of your tasks. Sorting and prioritizing all the works (backlog items) of the module to be developed will make it much easier to reach MVP.
We’ve used MoSCoW Prioritization for the Maintenance Module that we’ll add our product.
To give an example of other prioritization methods; Dot Voting, Fist of Five, ABCDE, Ivy Lee, and Spotify Team Health Check.
We’ll try every method on our product roadmap and share our experience with you.
What’s MoSCoW and why have we chosen MoSCoW methodology?
MoSCoW represents the definition of whether the feature is a Must Have, Should Have, Could Have, or Won’t Have.
M — Must Have:
Most important features that your product has got, you cannot sell your product to your potential customers unless you have these features. You can determine which features to include in this category by asking the question “What are the indispensable features of this product?”
In a nutshell, we can say that your non-negotiable priorities will take place here. With these items, we also reach our MVP directly. ( MVP : Minimum Viable Product )
Sample questions to ask for Must Have:
‘Will the product work/sell without this feature?’
‘Is there a simpler way to do this?’
‘What happens if this feature is not added?’
S — Should Have:
The features here are those that support other features, increase the quality and functionality of the product, but do not prevent it from being sold. You can ask “What other features do we want the product to have?” to learn which features you should add to this category.
C — Could Have:
You can add the features that you think it would be nice if have done, but that won’t prevent you from going live and you can’t spend effort and budget for right now. You can ask “What do we add to this product later, which will make it easier for our audience?” and this question can help you to get answers to which feature you can add to this category.
We can think of features of this category as nice things to have, but the effect of these features won’t be as big as M or S. These are features that provide small conveniences.
W — Won’t Have:
The features you write here are the features that will distract you from your goal. By asking the question ‘Which ideas do not serve our purpose?’, we can reach the features that distract us from our goal and cause us to waste our workforce and budget.
Of course, there’re things that you should have done before applying MoSCoW prioritization.
First and foremost, stakeholders and the product team should agree on objectives and prioritization, and agree on which features to prioritize.
Before MoSCoW, it would be a great convenience for you to determine the priority of the tasks, which ones can be done by your deadline, and whether they are suitable for your budget.
Also, if you don’t do this before, you may have to do everything all over again after prioritizing, which can be a huge waste of time and budget.
Scoring of MoSCoW
Applicability:
We gave the applicability a 7 because, as the product team, we made the prioritization easily, but when we presented it to other teams, we had to argue a lot over the must-haves at the points that touched the customer. Then, at the point where we came together with the development teams, the 1st phase will only consist of must-haves, but it also covered some of the shoulds, which did not provide the applicability in our dreams. That’s why our score is 7.
Cost:
It took us a very short time to prioritize since we already know what we call cost, the effort we spend, and our backlog items. So our score is 9.
Stakeholders Understanding:
After the document we created, when we shared it with the teams, it became a document that they could easily understand, we worked on it together and held a meeting. Thanks to this, the meeting was very productive, so our score is 9.
Our MOSCOW Prioritization Document
In the first column, we put our requirements for the maintenance module. We have also categorized the requirements according to the page or title they are related to.
In the second column we put our prioritization; With the abbreviations, M, S, C, W. We have added the legends of these abbreviations at the top of the document. Thus, we managed to be in the same spot as everyone who looked at the document.
In the third column, we added the design status, this is a critical situation for us to start the project, so we checked the existence of all the instruments to produce the MVP.
We called the fourth column “prioritization with teams”, and when we shared this document with other teams, we asked them to fill out this column.
