Don’t Use MoSCoW for Product Prioritisation

I often see MoSCoW being used to prioritise product development work but for anything mildly complex (almost anything) with more than one customer it isn’t appropriate. Here’s why.

MoSCoW – Must Have, Should Have, Could Have, Won’t Have – isn’t appropriate because:

1. It conveys a level of certainty that doesn’t exist in reality. 
2. In practice it takes a binary view of the world, it’s either must have or you don’t do it. But reality is far more nuanced, there are far more shades of grey in choosing what to do next and multiple factors that should be considered.
3. The words themselves are useless or, at best, problematic. 
4. It provides limited useful information to enable robust discussions about priorities or solutions.

You’re much better off with one of the frameworks that explicitly communicates certainty/confidence, takes a non-binary view and provides additional information like Kano or RICE.  

Still not convinced? Let me elaborate on each point above.

#1 It conveys a level of certainty that doesn’t exist in reality

The problem starts with the first keyword “Must” for Must Have. Define must. When pressed most people respond with “the customers said they must have it” which is a problematic statement. 

First, must itself has no relativity built in. It’s binary but the reality is different. It’s rare that 100% of customers have unanimously and unambiguously agreed that they Must Have a certain feature. In reality they’ve given some hints, maybe even some observed behavioural data, about what you hypothesise might be their more important needs but even then you will get mixed signals.

You will get differences between customers in the nature of the need; differences between value of the item to a customer, differences in the value of the items to the business, differences in the attractiveness of your proposed solution and differences in the number of customers it applies to.

Second, the word must itself conveys a level of confidence that is misleading and even dangerous. You cannot say with complete confidence, especially in a new product or feature, what is a Must Have. You have some assumptions about what is more valuable, you can even make these assumptions with high confidence. But MoSCoW as a framework for product prioritisation provides no metadata around what that confidence level is or how you arrived at it. 

If I ask my 5 year old which toy she wants to take to the farm then they’re all “must haves”. If I tell her she can only pick two, then suddenly she prioritises. If a feature or need is taken on it’s own then people will say “I must have” but when confronted with choices they tell a different story. 

Before you jump to make the argument “that’s what Should Have and Could Have are for”, let me jump in and point out that within Must Have you still need to prioritise. Say you have 49 Must Haves (very common) then how do you decide which is most important? Which is the “most must”? MoSCoW falls apart here.

#2 In practice it is a binary framework

In practice with MoSCoW something is either done or it is not. So why pretend at the outset that MoSCoW is anything but binary? Why not just reduce it to MW – ‘Must Have, Won’t Have?’

There isn’t leeway within the MoSCoW framework to alter the effort being made into needs depending on their relative value. Nor does it allow for changes from information emerged during the development process that altered the data the original prioritisation was made on.

If you’ve worked around this in practice and you are determining value beyond the MSCW buckets then this implies that you’re actually using different measures of value (thus not MoSCoW so why use it?).

#3 The keywords themselves are useless

We’ve already dealt with the word must, now let’s move onto addressing the other keywords of MoSCoW. 

• Should is a useless word when it comes to taking action or not taking action. You either need to do something and are able to do it, in which case do it. Or you don’t need to do something, or are unable to do something. Consider the phrase “I should do some exercise”. It provides nothing little to no information to act on, not act on or better understand the situation. The reality is likely to be one of these:
  • You have established that you need to exercise and you have a plan to do it. So you do it.
  • You don’t believe you need exercise (for implicit or explicit reasons), so you don’t do it
  • You have established you need to exercise but you cannot make or adhere to a plan to do it.
• Each of these statements is more useful to work with then the statement containing should. That is, you either do it or don’t do it. By saying should do you’re almost lying to yourself that you will do it.

• Could: If you could do it then why aren’t you doing it? Because it’s not important right? In that case, don’t do it because you know more important things will come up. Provides no extra information compared to won’t or must.
• Won’t: I can actually get on board with this word. No’s are good.

#4 It provides limited information for robust discussions

In addition to the actual prioritisation itself, prioritisation frameworks perform another key function, enabling better communication between all the people required to make decisions and implement the solution. MoSCoW squarely fails at enabling better communication.

MoSCoW provides little to no information to stakeholders about the underlying assumptions being made or the value of a need/requirement/solution. So they can’t really help. 

As I’ve said earlier in the article all your teammates are hearing is a yes or no, a binary signal. It’s either something we need to do or not. No why, no other information. 

Other frameworks provide rich information like how many customers are affected, how valuable this is to them in relation to others, what assumptions are made, how convinced you are that a given feature is needed.

What do I use then?

There are a range of other frameworks available that overcome some of the issues with MoSCoW. I’ve previously put together a fairly comprehensive list of product prioritisation frameworks for you to evaluate what you will move to.

Best of luck. If you are stuck with MoSCoW or decide to continue using it then just take into account the problems I’ve outlined when using it. At the end of the day outcomes, communication, progress and good decisions are the key not what framework you use.

F.A.Q.

A little appendix. I shared the article around with some knowledgeable folks and they sent me their opinions. I discuss some of the points they made below:

1. Feedback: “MoSCoW can and does have its place when you are looking for a binary decision of what is required to go live, or where to focus your effort when you have no data or other product framework”
   1. My reply: But then it’s not MoSCoW, it’s MW Framework or “Must Have, Won’t Have”. Or “Yes/No Framework”.
2. Feedback: MoSCoW is still useful when building products for internal teams.
   1. My reply: This is probably the one place where I can see it might have some value but even then I’m now doubting its use. MoSCoW does give stakeholders a way to be engaged in the process. However, there are other prioritisation frameworks that provide more value here, Buying a Feature and RICE come to mind. 
3. Feedback: “That’s a bit of a rant Scott. Maybe you could try to be more constructive about MoSCoW”.
   1. My reply: The more I worked through MoSCoW the more I realised it isn’t appropriate. I used to think it had a place but now I can’t see where it fits. 

---