In the messy world of technology, there is an immeasurable demand for the resources from product and development teams. This is where prioritization comes into play.
Prioritization is one of the core responsibilities of the product manager. With the proper prioritization framework and/or criteria, the product manager can save their team resources while moving closer to the business goals.
In this article, we will dive deep into one of the most widely used prioritization techniques, the MoSCoW method.
The MoSCoW method (also known as MoSCoW analysis) is one of many qualitative prioritization techniques used to prioritize features, user stories, and requirements.
The MoSCoW method groups the features into four groups:
Features or stories are critical for the product’s success. These features represent the non-negotiables which, if not implemented successfully, might put the product at risk of failing.
For example, let’s say you are the PM of a university’s e-learning system. A must-have feature might be the assignment submission feature because it serves a primary and essential need for both ideal customer profiles.
This classification represents the features that are important, but not as crucial as the must-haves. These features, if not implemented, can cause a severe risk to the product’s success, but their risk is lower than the must-haves.
Typically, product teams use this classification for minor bug fixes and/or performance improvement initiatives.
Returning to our example, a should-have feature for our e-learning system might be an integrated plagiarism tool for teachers to use. This can be a should-have because it would not stop the teachers from doing their work, but not implementing it might lead them to churn and move to other platforms that save them time.
This classification represents desirable features that are not important to the core function of the product. Not implementing this feature will not cause any risk or failure.
Could-have features might help your product or do nothing at all. Features that are tagged with the could-have classification end up deprioritized and treated as a sprint filler.
For our e-learning, one feature could be the ability for the teachers to message other students through the platform. This is nice-to-have because this problem is typically dealt with through email and other platforms.
This classification represents features that are not aligned with the vision and the strategy of the product. These are the features requested by other departments or stakeholders, but are entirely irrelevant.
If we were to reflect this in our e-learning example, this might be a feature that enables teachers to develop a curriculum collaboratively on the platform. This feature is a won’t-have because it doesn’t align with the vision of the product because the product is intended to mainly serve the students.
The MoSCoW prioritization method can be used to prioritize both the product backlog and the sprint backlog. This tells engineers what they need to deliver first and gives them an idea of what task could potentially spill over into the next sprint.
Below is a simple template that can get you up and running with the MoSCoW prioritization technique:
The MoSCoW method was introduced first in 1994 by Dai Clegg, a British business consultant and software engineer.
Clegg was working on a software project with the British government and was looking for a method to prioritize the system requirements based on their urgency and criticality. He came up with the MoSCoW method to rank and prioritize the features and ensure the right investments were put into the top features.
Using the MoSCoW in the real world is more than tagging features with four different tags. It requires additional steps to ensure the proper prioritization is put into place and that features align with your stakeholders.
To apply the MoSCoW prioritization method in product management, take the following steps:
It is always a best practice to start by listing your features in your product backlog. Add some details to them like the basic idea of the feature, some simple user flows, and wireframes, and meet with your engineers/technical navigators, or system analysts to check on the technical feasibility and the edge cases.
After you have all of your features groomed, start prioritizing them. Classify them into must-have, should-have, could-have, and won’t-have. Prioritize based on the available resources and insights gathered from any user research and product analytics.
Present your initial priority to your stakeholders. Gather their input and try to persuade them of your priority based on the insights and the data you have.
Don’t leave the meeting without alignment on the priority of each feature. The outcome of the meeting should be a prioritized list agreed on by each and every stakeholder.
After finalizing the backlog, make sure to give it a final review and announce it publicly using your internal roadmap and any communication channel that includes all the stakeholders.
We are in the agile era. That means we should embrace change and understand that changes happen all the time.
A feature that is a could-have in this quarter might be a must-have in the next one. So make sure to communicate changes in the business and feature priorities continuously with your stakeholders.
Ensure all the related documents, like the roadmap and the backlog, are updated accordingly and on a timely basis to avoid any miscommunication and to make sure that everyone is aligned on the timeline and the priorities.
The MoSCoW method is one of the most powerful and widely used prioritization techniques worldwide. It helps classify features and initiatives into four groups.
For the MoSCoW method to be applied effectively and deliver the intended value, it should include a lot of stakeholder alignment and involvement. The product manager should dedicate more time to the must-have features to come up with a killer solution that helps solve the major problem for the users.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.
MQ Qureshi talks about his experience with “unexpected sparks of brilliance” — solutions get to the core of what you’re trying to do.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.
A knowledge base is a centralized location where information is stored in an organized and easy-to-access way.
Learn more →
