3 Practical Tips using MoSCoW Prioritization for your Roadmap

Moscow Prioritization: Prioritizing a Roadmap can be one of the most contentious exercises in building your product. In this article, we talk about using MoSCoW rule to prioritise your product roadmap. It gives you an objective mechanism to score various feature requests relative to each other so that stakeholder relationship management can be easier.

The purpose of Moscow prioritization is to ensure that the most important items/requests are not lost amidst other demands from your product. Following the principles of Minimum Viable Product Development, our focus is on developing a product that works with minimal wastage. This invariably means saying no to a few feature demands while developing the product.

As a product manager, your role is prominent as a gatekeeper to ensure that only validated requests form a part of your roadmap. Just like we define scope creep and expanding project timelines, you need to consider the impact of feature creep as well.

What is Feature Creep?

Feature creep is defined as a process where you design features for the sake of features. This normally happens when you don’t have strict control over the product features which are essential. As a product manager, if you try to satisfy everyone in the process, you are headed for a nosedive. Pleasing everyone is the quickest way for failure and this is imperative for Feature creep as well.

As a product manager, there is a constant demand from customers, the sales team and even the business for new features to be added. In such a scenario, how do you separate out the priorities and identify the most important features?

The solution lies in product prioritisation or time boxing product planning. The best way to manage this is to develop an objective process to plan items to develop in your Roadmap

Agile Planning for your Roadmap

A roadmap is a living, breathing document which benefits largely from the research involved by talking to the customers. Although you can never get 100% validated results, your ability to draw conclusions can make a phenomenal difference in developing your product roadmap.

The beauty of agile lies in delivery and time management. You are expected to make a delivery every sprint – whether it is 15 days or a month depending on your operational cycle. Since time is a fixed parameter, the other variable you have for the project is SCOPE. Moscow prioritization helps you fix this scope of development in the number of features that are an absolute Must for business requirements.

Knowing that your project is expected to provide a release in the next 15 days, you can only build ‘X’ number of features in this time span. Hence, it is very important that you note the most important features that go into a build.

How to use Moscow Prioritization for your Roadmap

Moscow prioritization relies on the ability of your business to objectively identify the key requirements from your product. I’ll call them the Must-Haves in your product development roadmap. Without these features, you’re easily looking at losing the ability of your business to engage existing customers. In the parlance of satisfiers/dissatisfiers theory, I’d classify them as dissatisfiers meaning that without these features, you will risk disappointing your customers heavily.

The 4 key parameters of Moscow prioritization are:

1.0 M – Must Have Features/Requirements

This takes the highest priority in product/project planning. Any item that falls under this category must be achieved. This parameter is reserved for the most important features which form the core of a product. Make sure that you differentiate between MVP and all-inclusive products. You don’t need all features to be working to make a release. Defining your definition of done plays a significant role while creating your Roadmap.

Any feature which a customer cannot live without or severely impacts the functioning of your product goes into this category

1.1 S – Should Have Requirements

Should Have indicated important features which are not immediately necessary. The product will survive without these features and you can continue development. These are not the most basic needs but are slightly advanced which can make a difference for you. These features are significant requirements as proposed either by the sales teams or areas in the product which can result in instability if not developed properly.

If there is time left in the project plan, the Should Have category takes next precedence

1.3 C – Could Have Features

Could Have referred to desirable features in your product. These are nice to have but not necessary. You can live without having these features built-in right at the start. They can be added on to later stages or updates of your product.

In practising Moscow prioritization, these features are nice to have – i.e don’t promise them but try to deliver. In other words, they are unexpected surprises that can elevate the quality of the experience but not define what they are.

1.4 W – Won’t Have priorities

Won’t have referred to features that all stakeholders agree are not most important at the time being. These features may or may not be developed. The features in this list are improvements that make a customer happy, but their absence doesn’t make a customer unhappy. (Related – Satisfier Vs Dissatisfier in product development)

Make sure that you take an objective stance while using won’t have prioritization. Most often people don’t like to convey the bad news that their proposal is not being developed. I’d argue that the Won’t have is as important as the must-have in Moscow prioritization so that stakeholders are very clear about what’s not being delivered.

3 Common Traps and Recommendations while using Moscow Prioritization

Although the prioritisation looks very simple, you need to be aware of traps in this process. The most noteworthy traps are

Decision of a single person

Moscow priorities are never the decision of a single person. This will need the involvement of all stakeholders. Typically in an agile sprint meeting before the start of a small project, you would discuss requirements. You will make a list of all probable features in this list and prioritise them.

Typically this will involve representatives from Sales and Marketing, Product Development, Customer Support and Product Specialist (non-technical). All stakeholders should agree on the priorities.

Avoid labelling everything as ‘Must Have’

There is a temptation to keep everyone involved happy. Avoid this temptation. As a product manager, you are the gatekeeper. Consequently, saying NO is more important than saying YES to features.

You must play the bad cop and ensure that only deserving features are labelled Must Have’s. Again, this discussion is not just that of a single person, but representatives of the stakeholders.

Reflect on Cost

At each stage of prioritisation, you will need to think about the cost. Cost in this situation refers to the time involved in the development, physical resources required and the opportunity cost of not being in the market. You will need to build a credible scoring based on the cost for each of these features.

The moment you are sure which feature to build or pursue, you will need to balance it w.r.t cost and assess feasibility.

Ultimately, the onus is upon you to deliver a successful product. If you are able to back up your choices and decisions with clear documentation, it is a great starting point towards good product development.