The MoSCoW analysis or the MoSCoW method as it is sometimes called is a powerful prioritisation method and could be the framework for you. It’s commonly used to help you keep your stakeholders aligned with the importance of key aspects during the release of a product. In short, this prioritisation framework is geared towards team members effectively prioritising requirements under agile project management.
In some cases, you can adopt the MoSCoW prioritisation method when building your minimum viable product (MVP) in other development teams and product managers can use this when focusing on an upcoming feature release.
The MoSCoW framework has four different categories of initiatives:
Note that in certain organisations the “W” in MoSCoW can also stand for “wishes” for the future.
This analysis framework can help you divide the features of a product launch into the above four priority-based groups. So, let’s break these down:
This part of the framework focuses on the essential part of the product that is being released. Everything that is listed in this section has to be implemented to ensure a successful launch.
An example of this would be that if a certain feature or initiative would directly impact the ability of your product to perform then it is a must-have. By using the MoSCoW rules in your future feature releases you can clearly define your prioritisation categories focusing your project team's approach.
In this section of the methodology, you focus on the things that sit just below your must-haves. These are the functionality or features that would enhance the product but wouldn’t impede you from launching your product.
A good example of this is looking at performance-enhancing features, they are important but wouldn’t stop your app from functioning properly. Therefore, you add these features as should haves.
Could haves or nice to haves make up the third of the sections of the MoSCoW framework? These features will not be essential to the product’s core functionality.
It will be tempting to try and add these to the product roadmap in the earlier stages but the aim of this process is to be absolutely ruthless and leave personal opinion out of the decision-making process.
The items listed here will be the first to get cut, pushed to a later release or be completely left out.
Why would you have a list of will not-haves? It actually makes more sense than you first think. Imagine, you finish your brainstorming session, and you have all these product features but not all of them can make the cut.
The creative session is just that, a no holds barred session where you get everything down from the data and personal opinions/suggestions. Some of those will be an absolute no. Therefore the will not haves plays a part and you can track how many ideas never made it to the final edit.
There will be varying reasons why these don’t make the final cut, think;
By making this a valuable part of the decision-making process, you can prevent things like scope creep, and build a catalogue of items that could become useful further down the road in future updates. Remember, this category says, these items are not for today, they are not declined forever.
Now I’ve run through what the components of the analysis are it’s best to discuss your pre-planning so you maximise the use of the methodology. To do this, take the following into consideration:
By setting and adhering to these rules it can allow seamless collaboration, make features easy to evaluate, capture broader perspectives, and ensure the delivery of a rich variety of features in each release.
This framework works really well when your product ideation team is made up of representatives from across the organisation. To ensure that your teams remain agile and pacey through the product development process, prioritisation frameworks are an essential ingredient to the success of the sprint cycle.
In our last article, we focused on pirate metrics (AARRR) which help your team tie each stage of the framework to relevant stages of the user journey. These metrics will help guide you across your product development lifecycle and are extremely useful for early-stage SaaS.
If you are reading this and are still in the early stages of your product-led growth initiatives try reading our guide to product-led growth for SaaS leaders and other content on our product growth blog.
Our team are available to help you find your strategy for onboarding, PLG initiatives and other aspects of the go-to-market strategy and are on hand for a no-obligation conversation. Feel free to reach out at any time.