Working with cross-functional teams and key stakeholders to effectively prioritize features isn’t easy, but it’s a key step in the product development process. 

When you’re making your product roadmap, the MoSCoW model can be an effective way to get everyone aligned on the project’s priorities. Once you do align, you can help your team schedule tasks for the upcoming release cycle or sprint. 

In this article, we’ll dive into: 

• How the MoSCoW model works 
• How the MoSCoW model categorizes features
• Benefits of using a MoSCoW analysis
• Who should use the MoSCoW framework
• An example of the MoSCoW model

Not sure if MoSCoW is right for you? There are plenty of other prioritization methods that might be natural fits for your team. Check out our guide to the best product management prioritization frameworks and see which ones make the most sense for you.

What is the MoSCoW method? 

Since the MoSCoW technique doesn’t tell you how to decide which features fit into each of these categories, it allows your team to determine how to prioritize tasks. For example, you can easily prioritize by: 

• Company budget or resource constraints 
• Cross-functional team needs 
• Features with high customer importance 
• Value to the product or potential feature revenue 
• Or other factors 

Once you’ve determined how you’re currently prioritizing features, the MoSCoW model helps by sorting features by must-haves (critical features), should-haves and could-haves (nice-to-have initiatives), and features that you won’t have on the roadmap for now. 

It works somewhat similarly to the Impact vs. Effort model and Kano model. Each of these prioritization methods sorts features into several categories that help you align on what to prioritize next. The MoSCoW model doesn’t include a built-in scoring framework, which makes it much more flexible. 

How does the MoSCoW model work? 

The MoSCoW prioritization method is very popular, in part because it’s so simple. 

Basically, the model sorts all of your potential features into what needs to happen now and what should wait for the future. 

Here’s how it’s typically done: 

1. You and your team will sit down and list all the potential features for your upcoming release (or releases). 

2. Determine the resources you’ll devote to each of the categories in the upcoming sprints or releases. 

For example, in the early stages, your team may devote 80% of your resources to “must-have” features and 20% to “should-haves,” but in later releases, you may decide to devote more time to “should-haves” and then split the remaining resources between “must-have” and “could-haves.” 

3. Then, you’ll need to evaluate each feature to determine which category it should fall into. While the MoSCoW method doesn’t have a built-in evaluation framework, we recommend evaluating each feature by asking three questions: 

• How important is this feature to our users? 
• How valuable is this feature to our product? 
• How much effort and time will this feature take to implement? 

You can use numerical sliding scales to chart these features quantitatively, or you can use another prioritization technique to understand the benefits of each feature.  

4. Using whatever prioritization or scoring model you've determined, sort the features from your list into the following categories: 

• Must-haves 
• Should-haves 
• Could-haves 
• Won’t-haves  

Keep in mind that these categories are simply for the next sprint or release. Putting a feature in the "won't have" category doesn't mean that it's tossed forever – it just means that it won't be on the roadmap right now.

Before you get to work on your product roadmap, let’s break down exactly what these categories are, and which kinds of features should end up in each one. 

MoSCoW method features categories 

The MoSCoW prioritization method uses four prioritization categories: 

“Must have” features

Must-haves are the non-negotiables for your product vision at the current iteration. 

Must-have features are: 

• Essential for your product to work 
• Necessary for users to complete the main tasks or actions with your product 
• Required to meet current business goals 
• Necessary to eliminate dependencies for other important features 

If you’re using a scoring model like the one we mentioned above, must-have features should be high-value to both the business and the users. Performance improvements and major bug fixes often fall into this category.

Most of your development time and resources should go to must-have features first, especially in the early stages of product development. 

“Should have” features 

Should-haves are important to the current vision for the product, but not essential for function or usage. 

Should-haves are features that: 

• Would improve user value or delight
• Would make certain aspects of the product easier or more performant
• Would not cause the product to break without them, but may improve usability
• Resolve user workarounds to accomplish common tasks 

These features are valuable and important to ‌users, but slightly less essential to the product itself. They should be prioritized as time and effort allows. 

“Could have” features

The could-haves are those features that'd be nice to have in the current (or future) versions of your product, but aren’t yet that important. Additionally, the time and effort it takes to implement them may outweigh the benefit at this time. 

These are features that: 

• Aren't that important to the product or users at this stage
• Don't significantly affect product performance or experience 
• Won't cause roadblocks or frustration to the user by not having them 
• Aren't expected from your product 

In general, you should only prioritize these as time and resources permit, and if such a feature is an important customer-facing or strategic win. Otherwise, you should save them for a future release. 

For example, if you’re working on some big must-have features that mostly improve things on the back-end, some cool could-have features can help customers see that your product is improving and innovating. 

“Won’t have” features

Finally, the won’t-haves are features that will not be included in this round of roadmapping. 

This is often the hardest category to sort features into. Keep in mind that this doesn’t mean these features will never be prioritized or developed‌ — just that they’re not urgent for this sprint or release cycle. 

Won’t-haves should be features that: 

• Have no measurable impact on customer satisfaction or product functionality 
• Would be nice to have but have too many dependencies to do well currently 
• Are out of budget or scope given your current resources 
• Aren’t necessary for a good user experience 
• Don't fit your current goals or product vision

What are the benefits of the MoSCoW method? 

MoSCoW prioritization is one of our favorite frameworks, in part because it has so many benefits. For example:

• It’s super easy to learn and use. Some prioritization frameworks have a steeper learning curve: They require more research, have a complicated scoring model, or require a lot of internal data. With the MoSCoW method, once you understand each category, you’re ready to get started. 
• It works for almost any team size and structure. Just getting started with a few folks working on V1 of your product? Got a huge team with a lot of stakeholders? On release version 17.8.2? Either way, the MoSCoW method can help you prioritize features and draft your upcoming roadmaps. 
• It works well as an agile project management method. If you’re building an agile product roadmap, the MoSCoW method can help prioritize and organize upcoming sprints and releases. It’s not an agile-specific model, but it does fit nicely within that framework. 
• It’s a great way to align teams and key stakeholders. Since the MoSCoW method is more open-ended than many other prioritization frameworks, it’s a great one to use to simplify the decision-making process. Product managers and cross-functional teams can work together with other key stakeholders to prioritize tasks and strengthen collaboration from the beginning. 
• It helps simplify project management. MoSCoW analysis is aneffective way to narrow down the current project priorities and objectives for the development process so you can manage expectations and (hopefully) eliminate scope creep. When your entire team can visualize priorities and project requirements for the current stage, it’s much easier to enable success.

MoSCoW model example

Let’s take a look at an example of the MoSCoW method in action. 

For our example, let’s consider a software startup that’s developing a web app to help busy knowledge workers manage their inboxes more effectively. They’re working to build V1 of their product, and want to get a minimum viable product launched as quickly as possible. 

Once they’ve got their potential features brainstormed, here’s how they might use the MoSCoW method:  

Must-haves: 

• Automatic email sorting and organization 
• Clear search functionality 
• Integrated calendar to automatically schedule meetings and events based on inbox contents 

These are the basic features that allow users to manage their inboxes easily and make the product function. 

Should-haves: 

• Ability to manage multiple inboxes from a single dashboard
• Snooze and reminder features for following up on emails 
• Email templates for common scenarios 

These are the features that are important to have and should be prioritized, but aren’t essential to the product’s functionality. 

Could-haves: 

• AI email writer or suggestions based on user’s previous communications 
• Workflow automation rules to automate repetitive email tasks 
• Automated email follow-ups 
• Integrated email notes and to-do lists 

These are all nice-to-have initiatives, and may be a priority at some point, but aren’t really necessary or important for the current version. Users will still get a lot of value from the product without them, and not having them doesn’t impact functionality. 

Won’t-haves: 

• Talk-to-text functionality for writing and responding to emails 
• Offline mode 
• Desktop version (this team is focusing on a web app first) 

None of these features fit with the core vision for the product at its current stage, and none of them are currently necessary or impact the product’s functionality. They shouldn’t be prioritized, at least not for the current sprint. 

When should you use the Moscow method? 

The MoSCoW method is effective as a narrow-scope prioritization technique — that is, for prioritizing tasks and critical features for the current or next-up release of your product. Whether that’s an MVP or V1, or you’re well into product development, MoSCoW prioritization helps your development team quickly figure out what’s needed now vs. later. 

That said, the MoSCoW method comes with drawbacks, too. Some teams find that without built-in scoring, sorting features can be a murky process. Team bias for or against certain features can impact which category they end up in, and prioritization is ultimately subjective. 

With the MoSCoW framework, it helps to think of this as a feature, not a bug. If you’re looking for a prioritization framework that… 

• Uses a more intuitive method for sorting features 
• Doesn't require you to have a lot of quantitative data 
• Allows you to include as many or few stakeholders as needed 
• Helps you narrow your focus to just the upcoming sprint(s) or releases 

… the MoSCoW prioritization technique will be helpful for you. 

Kicking off product development after MoSCoW analysis 

Once you’ve done your MoSCoW analysis, you should be ready to move your prioritized features to your roadmap and kick off product development. 

One way to make the software development process faster and easier? 

Start building with a full-stack, no-code software development tool like Bubble. With Bubble, you can build faster, easier, and more affordably than ever, which means that you can prioritize more features and launch them to users more efficiently.