If you’re like most PMs, it can feel like everything is a top priority according to your stakeholders.
It can be SO frustrating.
Is it really that hard to decide on just a small handful of things?!?!
Yes! But it can be a lot easier with some frameworks you can keep in your back pocket for when things start to get messy.
If you’ve decided it’s time to wrangle all your stakeholders into a meeting to figure out the top priorities, it can be a good idea to keep the MoSCoW method in your back pocket.
Sure, there are other more “accurate” prioritization methods like RICE out there. But if you don’t want to argue over specific numbers, the MoSCoW method provides a quick and dirty way to figure out which of your top priorities are truly “top” and which can be bumped further down the list.
What is MoSCoW?
MoSCoW is a prioritization method that has a few buckets of things that you can prioritize items into. These buckets are “must have”, “should have”, “could have”, and “won’t have”.
The 'o’s are just kind of thrown into “MoSCoW” to make the framework a little bit more pronounceable…MSCW just doesn’t have quite the same ring.
The framework itself is actually super simple. Just figure which of your ideas/requests/experiments/fixes fit into which bucket.
Let’s take the example of a customer support widget and figure out some things that would go into each of our categories.
What goes into that must have box?
And probably conversational abilities. You’ll need the ability to send and receive messages.
It’s unlikely your CS team is going to want to view things in a terminal, so a basic dashboard where they can view and respond to chats is also required.
Once you have your must-haves all squared away the next category is the “should-haves”. These are things that are not necessarily required functionality but are definitely something to strive for.
For our chat widget this may be something like a way to notify customer support of new messages when they’re not logged in. That way, if they’re not at their computer, they can see a notification on their phone or in their email and they can get back to the customer as soon as they can.
We’d built these once we have our “must-haves” squared away.
“Could haves” are the things that are nice to have, but not necessarily required functionality.
For a chat widget, maybe AI capabilities is a “could have”. Or perhaps automated ticketing workflows.
The final category is won’t have. These are the things that are just out of scope or things you’re not quite ready to build yet.
For our chat widget example, this may be custom chatbots. Maybe something for the future — but not for now.
Add timeboxing if there are still too many “must-haves”
Another thing that you can do is if at the end of this MoSCoW prioritization process, you still have a bunch of must-haves you can add a deadline or a time box and try to figure out which of those things in your must-have list are going to be able to fit into that time box and which should be plucked out and moved to a different time or sprint.