What is the MoSCoW Prioritization Method? Definition, Guide, and Template

This article is part of the prioritization chapter of our product roadmapping guide. Check out the full Product Roadmap Guide here.

The MoSCoW method isn’t named after the capital city of Russia, but it is sort of iconic in product management the way that St. Basil’s Cathedral and the Bolshoi Theatre are iconic.

But just because the MoSCoW model is a staple of product management theory, doesn’t mean that it’s always useful.

In fact—get ready for a hot take—I’d usually recommend skipping it for one of the other prioritization frameworks.

I don’t love the MoSCoW method. (I said what I said.)

But you should judge for yourself. Here’s what it is, how to do it, its strengths, and its weaknesses—everything you need to know how to gauge whether it’s a good fit for you.

MoSCoW Analysis (TL;DR)

• MoSCoW is an acronym that stands for Must Have, Should Have, Could Have, and Won't Have.
• It's a prioritization technique product managers use for software development to sort features or requirements into categories that indicate the importance of the features.
• PMs then prioritize features to their roadmap using those categories.
• The method can help PMs make informed decisions, manage stakeholder expectations, and focus on what's truly important.
• But it can also be not very useful because it doesn’t help you prioritize features from within those categories… you may need to pair it with another framework.
• If you want a quick way to implement it, check out our template.

What is the MoSCoW prioritization framework?

The MoSCoW methodology is a way to prioritize product features by categorizing them into four distinct groups, based on their importance to the product's success.

• Must-Haves (Mo): These are the non-negotiable features, the core of your product. They're crucial to meet the basic needs of your users and deliver on the product's core value proposition. Without these, your product is like a bicycle without wheels. A user login sequence would fall into this category for most apps.
• Should-Haves (S): These are the features that enhance your product's usability and desirability. While not critical for the product to be useful, they give it a competitive edge and make users' lives a little bit sunnier. For example, bug fixes or UI enhancements often fall into this category.
• Could-Haves (Co): These are the cherry-on-top features. They’re nice to have but can be postponed or dropped without derailing your product's primary mission. Confetti blasts when a user ticks off a to-do list item or micro-interactions are examples in this category.
• Won't-Haves (W): The "thanks, but no thanks" pile. These features are either out of scope or don't contribute significantly to the product's overall success. They might be interesting ideas, but not worth the resources they’d require—at least right now.

Sorting features into these categories helps create a hierarchy and encourages PMs to focus on what matters.

The process was developed in the 90s by Dai Clegg at Oracle and is often used in a number of agile software development approaches like scrum, rapid application development (RAD), and dynamic systems development method (DSDM).

How do you use the MoSCoW model? Step-by-step guide

Here’s how to use the MoSCoW framework in practice.

1. Set your Development budget. First, decide in advance what percentage of your development budget will be allocated to each category. There’s no fixed rule here. Usually, you’d want to finish off the must-have category, and then split resources among your should-haves and could-haves.

2. Gather your features. List all the features, requirements, or ideas that you're considering for your product. You might want to consult stakeholders, team members, and user feature requests to ensure you've got all your bases covered. At this stage, you can also estimate the development team budget each feature would need.

3. Categorize each feature. With your criteria in place, begin to categorize each feature into the Must Have, Should Have, Could Have, or Won't Have groups. You can do this as a team exercise or individually with a group gut check later. In either case, make sure to involve key stakeholders to try to achieve consensus and avoid disagreement later.

4. Prioritize within categories. The MoSCoW method doesn’t help you prioritize features within each category, so you might want to pair it with another framework, like RICE scoring or weighted scoring. This way, you'll have a clearer view of which features to tackle first within each group.

5. Put your chosen features on your roadmap. Use your budget allocation (step 3) to fill up your roadmap with features from each category, starting with Must-haves, then Should-haves, and then Could-haves. Continue until your slate is full.

6. Review and adjust. As with any good plan, it's important to remain flexible and open to change. Periodically review and adjust your priorities based on new information, stakeholder feedback, or shifting business objectives. Don't be afraid to shuffle features between categories if needed.

Dive into "The Complete Feature Prioritization Guide for Product Managers".

MoSCoW method example and template

Here’s what using the MoSCoW analysis looks like in practice. You can download our MoSCoW method template to help you do this.

Tip: If you already use Savio, skip ahead to see how you can do MoSCoW in the app.

1. Get your list of features

Let’s imagine you’re a Product Manager developing a new project management app. Here's a list of features or initiatives you've identified for the app, along with their required dev hours:

• Task creation and management (80 dev hours)
• Time tracking (60 dev hours)
• File sharing and storage (80 dev hours)
• Calendar integration (60 dev hours)
• Project reporting and analytics (120 dev hours)
• Mobile app version (200 dev hours)
• Email notifications (40 dev hours)
• Task comments (40 dev hours)
• In-app messaging and collaboration (100 dev hours)
• Third-party app integrations (40 dev hours for each one)
• Dark mode (20 dev hours)

A hypothetical list of features in our MoSCoW framework template.

2. Set your development budget

Your team of 4 devs has 30 hours for development a week. So your total dev budget is 120 hours a week, or 480 for the month. You decide to spend it like this:

• Work through all the must-have features
• Spend 60% of the remaining budget on should-have features
• Spend 40% on could-have features
• Spend 0% on won’t-have features

3. Categorize each feature and prioritize within the buckets

With your team, you categorize all the features into each bucket and prioritize them within the buckets from most important to least. Let’s imagine you prioritize your list like this:

Must-haves:

• Task creation and management (80 hours)
• File sharing and storage (80 hours)
• Calendar integration (60 hours)

Should-haves:

• Project reporting and analytics (120 hours)
• Mobile app version (200 hours)
• Email notifications (40 hours)
• Task comments (40 hours)

Could-have:

• In-app messaging and collaboration (100 hours)
• Time tracking (60 hours)
• Third-party app integrations (40 hours each)

Won't-have (this release):

• Dark mode (20 hours)

Here, we’ve assigned each feature to a MoSCoW category, and they’re automatically sorted into a chart by category.

4. Build your roadmap

Now you have your list, choose your features using your dev budget of 480 dev hours. For example, you might first choose all of your Must-have features:

• Task creation and management (80 hours)
• File sharing and storage (80 hours)
• Calendar integration (60 hours)

That’s 220 hours. Now you have 260 left, and you’ve already decided to spend about 60% (156) on should-have features. So you choose:

• Project reporting and analytics (120 hours)
• Email notifications (40 hours)

Now you’ve spent 380 hours, leaving you with 100 hours left. You choose:

• In-app messaging and collaboration (100 hours).

Now you’ve spent your whole budget, prioritized all the must-have features, and prioritized some should-haves and the could-haves in the proportion you wanted. You can put the features on your roadmap and run them past your stakeholders.

How to do the MoSCoW prioritization method in Savio

Savio makes it easy for PMs to understand what to build next. It logs your customer feedback in one place, helps you organize your feature requests, and then lets you slice and dice your feature requests to quickly figure out what different customer segments are asking for.

I (personally) may not love the MoSCoW method, but you can do it in Savio if you want to.

1. First, you can customize the “priority” attribute on feedback and feature requests to be consistent with the MoSCoW categories (instructions here).

Here, we’ve customized the “priority” attribute for feature requests to be the same as the MoSCoW framework categories.

2. Then, go through each feature with your team and categorize each one into one of the MoSCoW categories. Here, we’re assigning a feature to the “Should-Have” MoSCoW category.

3. Finally, when you’re prioritizing, you can filter your feature requests for the must-have group and prioritize those first. Then, filter for the should-have features. And so on.

Here, we’ve filtered our full list of features to see only the ones labeled “Should-Have”. We can prioritize from that list based on other factors like the number of customers requesting the feature or cumulative monthly recurring revenue (MRR).

Strengths of MoSCoW

MoSCoW is a popular prioritization method because it has several strengths:

• It’s easy. The MoSCoW method is easy to understand and apply, making it accessible to team members and stakeholders.
• Focus on importance. The method emphasizes the delivery of the most critical features first, ensuring that the project's Minimum Viable Product (MVP) meets the essential needs of customers and stakeholders.
• Stakeholder alignment. The method helps align stakeholders by providing a common language and framework for discussing priorities, leading to better decision-making and more effective project management.

Weaknesses and pitfalls of MoSCoW

As I’ve said, I don’t love the MoSCoW framework. Here are some of the weaknesses I encourage you to consider (and how you might mitigate them).

1. It’s often not useful

The biggest problem with MoSCoW, in my very humble opinion, is that it’s not that useful.

Here’s what tends to happen. Once you’re past the MVP stage, there are rarely true “must-have” features. And, if your product has any momentum, you’re probably getting at least tens or even hundreds of feature requests a month. So you end up with enormous lists of features in your “should-have” and “could-have” buckets.

Great. Now what?

How do you choose between those?

MoSCoW can’t help you do that—and that’s the hard part. At best, you can use a different prioritization framework… but then, why not just use another one to begin with?

At its worst, though, MoSCoW gives a sheen of objectivity to what is really a super subjective process. Often, PMs just pick features from inside each category without much thought. You can end up choosing features based on feelings with the MoSCoW framework just kind of adding a false legitimacy.

To me, MoSCoW is not much more than a fancy way of calling features “high”, “medium” or “low” priority. Which is great, I’m just not sure we need a special framework or name for it.

What to do: If you’re going to use MoSCoW, have a plan for how you’re going to prioritize features from within each bucket. (I like the method we developed—the Savio prioritization method—best).

2. It’s often not customer-centric

The other big problem is that, the way most people implement it, it’s usually not customer-centric.

Most PMs classify features into the MoSCoW categories based on their own opinions. They often don’t go asking customers what they think. That’s very different from, say, the Kano prioritization framework, which relies heavily on user surveys to categorize features.

The result is that you can end up with your features in tidy categories that are completely disconnected from how important your customers think the features are.

What to do: Make sure you’re building in customer feedback when you’re doing MoSCoW. That could mean using surveys, or it could just mean asking users how important a feature is to them when they request it—whether it’s a must-have, should-have, or a nice-to-have.

In both cases, the information you get will help you better categorize features using MoSCoW.

Related: Why care about customer feedback?

3. It’s subjective

Because most teams don’t categorize features using customer feedback data, MoSCoW is usually just done subjectively by whoever is in the room. That leaves room for certain individuals (I’m looking at you, execs) to rate their pet features as must-haves.

That’s not exactly the ideal way to do prioritization.

What to do: Create some criteria ahead of time about how a feature ends up in each category.

For example, you might start by defining the key functions of your product and then say, “If a feature is required to do one of these functions, we’ll call it a must-have. If it’s not required to do one of these functions, it can’t go in the must-have column.”

That can help your team be a little more objective in your categorization.

What about alternative prioritization frameworks?

If I would personally skip MoSCoW (and I would), what would I use instead? Well, there are lots of frameworks you can use. Really, even if you use MoSCoW, you’ll probably need another one to prioritize from within MoSCoW categories.

Here are some of your options:

• Value vs. Effort model. A way to find low-hanging fruit (high value, low effort) features.  It’s similar to RICE and ICE and shares many of their strengths and weaknesses.
• ICE scoring. Very similar to value vs. effort, but also takes into account your confidence in your scoring.
• RICE scoring. Similar to value vs. effort and ICE, but value is broken up into two metrics: reach and impact. It also considers your confidence in your scoring.
• Weighted scoring model. Similar to the other three, but more flexible because you can include whichever criteria you like.
• The Kano framework. This method categorizes new product features by how they’ll impact customer experience. I love that this method uses customer surveys and data to make categorization calls.
• Story mapping model. Prioritizes based on how customers use the product and what comes next in the story.
• The Savio model. First, keep track of what your customers are asking you, along with customer data. Then look for the features that best accomplish your specific business goals.

Read more about the other prioritization frameworks here.

Takeaway: MoSCoW might just be a fancy way of calling features “high priority”, “medium priority”, and “low priority”

The MoSCoW technique isn’t named after the Russian city, but it does feel like it’s a kind of product management version of a Matryoshka doll—you put your features into prioritization categories, but then you have to prioritize again, inside each category. You’re left with a smaller prioritization problem hiding inside the larger one.

It’s not terrible, but it’s not necessarily super useful—at least, not obviously more useful than just calling features high-, medium-, or low-priority.

But if you like it, fire away. Who am I to judge?

If you want to use MoSCoW, go for it—just make sure you know the risks. I wont’t judge, I promise

Consider another model to use with MoSCoW (if not instead of it):

Up next: 8 alternative popular prioritization methods for PMs

MoSCoW FAQ

What percentage of my resource budget should go to each category?

It depends on many factors such as project scope, timeline, budget, and team capacity. However, as a starting point, consider the following allocation as a general guideline:

• Must-have: 60-70% of your dev hours
• Should-have: 20-30% of your dev hours
• Could-have: 5-10% of your dev hours
• Won't-have: 0% of your dev hours (revisit in future phases or updates)

MoSCoW seems similar to Kano—what’s the difference?

The MoSCoW method is a lot like the Kano method in that both seek to categorize features into buckets and use those buckets to make prioritization easier.

The big difference is how that categorization is done. With Kano, you categorize based on user input—you actually go out and ask your customers how they feel about the features.

With MoSCoW, most PMs just kind of guess based on their intuition (not great).

Last Updated: 2023-04-26

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Send me more like this

Unsubscribe anytime.