Prioritizing what your squad needs to build to solve a lingering problem or fully realize a feature idea is one of your key, if not the key responsibility as a product manager.

No matter what part of your product your squad deals with - whether it’s just important bug fixes or the core feature of the product - you will always have more ideas on how to fix a bug or develop a new feature than you can realize with the resources that you have.

As such, it's important that every product manager has a quick, simple and collaborative way to sit down with their squad and talk through the litany of ideas and organize them in a way where you realize what's valuable, what's a feature delighter, and what's not necessary at all in order to solve the problem or develop the feature.

Cue the MoSCoW framework - this is a prioritization matrix beloved by product managers the world over.

To understand how we can use the MoSCoW framework to prioritize our everyday feature needs, we need to first understand what the MoSCoW framework actually is all about.

What is the MoSCoW framework?

Man's hands working on a project with post-it

The MoSCoW framework is a popular prioritization technique for managing feature requirements. The acronym of MoSCoW represents the 4 categories of initiatives:

  • M: must have
  • S: should have
  • C: could have
  • W: won’t have.

The ‘M’ part of MoSCoW — or the ‘must have’ — represents the non-negotiable product needs that are mandatory for the team. It is the part of the feature that needs to be built, no matter what, so that you satisfy the definition of success or definition of done that you have crafted for your squad in relation to this feature build. For example, let’s say you work for a social media company and your squad is thinking about building a way for users to upload their photos to their profile.

In order for the upload to work, one of your must-haves would be to ‘include a UI element, whether it’s a button or some other function, that allows users to upload a photo of themselves. Another must-have can be ‘access to a user's photo library’.

The ‘S’ part of MoSCoW — or the ‘should have’ — represents the features that are essential to the development of your feature, but they are not vital. A key way that you can differentiate between what belongs as an ‘M’ and what is an ‘S’ is to ask yourself whether the feature or product can meet your definition of success or definition of done even if you leave it out.

For example, going back to our upload profile photo conundrum, a should have can be ‘to give the ability to users to edit and change the background of their profile photo’. Although it’s something that ‘should’ be a part of the experience, it is not essential to delivering the core functionality of the feature, which is to build a way for users to upload their photos to their profile.

The ‘C’ part of MoSCoW - or the ‘could haves’ - are the ‘nice to have features’. They won’t form an essential or necessary part of your feature but they are what you call the ‘delighter’ or the ‘cool’ aspects of your feature build. For example, a possible delighter component for the ‘uploading your profile photo’ conundrum is to allow ‘live’ or moving photos to be uploaded as well. Again, this is not core or essential to the principal functionality requirement of uploading a profile photo, but it can be a fun part of your uploading experience and generate positive user sentiment when they are uploading your photo.

Finally, the ‘W’ part of MoSCoW - or the ‘won’t haves’ - are feature components that you will not be working on now to develop the feature. This is to help prevent scope creep and, where feature components are in this category, the team knows that they are not a priority for this specific timeframe. For example, uploading a music file as background music for your profile photo will probably fall within the ‘W’ of the MoSCoW framework.

How to use the MoSCoW framework?

Work meeting

Applying the MoSCoW framework in practice tends to differ from PM to PM, from squad to squad, and even from feature to feature.

However, the following steps can still be used to ensure you’re applying the framework in a practical manner that sets you up to successfully be able to triage what’s necessary and unnecessary for the delivery of your feature idea:

  1. First, get yourself set up with a whiteboard, whether physical or digital. If you’re after digital whiteboards, try Miro or Whimsical.
  2. Set a time to sit down with your squad, telling them that it will be a prioritization meeting and to come prepared ready to discuss possible ideas on what needs to be built.
  3. Start the meeting by introducing the MoSCoW method, what it’s used for and how it can help the squad figure out what needs to be prioritized so that the feature can be built.
  4. Ask the squad to spend the first 10 minutes just listing down all of the ideas that we can possibly work on as part of the feature build.
  5. Spend the next 10-15 minutes asking the squad to talk through the ideas that they listed down, and why they would be essential to making sure the feature works.
  6. Then, start the voting process - ask the squad to vote for features that would fit in the ‘M’ category, based on what was discussed during steps 4 and 5.
  7. After the voting is finished, confirm with the squad the reason and rationale for the voted feature chunks before placing them in the ‘M’ category.
  8. Repeat steps 6 and 7 for the rest of the MoSCoW anagram - the ‘S’, ‘C’, and ‘W’ part

Conclusion

Hopefully, the above steps will help you and your squad prioritize what is important to ensure your feature works as intended. Until next time!