You won’t find any rocket science here. Instead, you’ll know a technique that is really helpful for product building. But first things first (we are talking about the priorities, huh?). It’s called MoSCoW and has really nothing to do with the capital of Russia:D

Purrweb specializes in building performant stable products and MVPs. Wanna test out one? Let’s discuss it together! To come up with an execution plan, reach out to us via hello@purrweb.com!

In the startup environment, MoSCoW is a way to prioritize stories, features, tasks or requirements. That system makes you break all your features down into 4 categories.

The technique works well for both large and small projects with either fixed or tight deadlines and is good for helping product managers:

1. Manage project goals, resources and time.
2. Distinguish ‘wants’ and ‘needs’. Prevent feature requests juggling
3. Figure out if a business idea is worth further investments.
4. Meet market needs.
5. Communicate project priorities with a project team (for teams that work on a contract basis).
6. Retain core user base and release version 2.0.

Now you already know what MoSCoW prioritization categories are. The names below speak for themselves, although let’s figure out together what each of them stands for.

Must-have initiatives

Something that is really crucial for a project’s delivery. By saying ‘crucial’, I mean that :

1. It’s impossible to deploy the app on the intended date without this.
2. It’s unsafe or not legal to build the app without this.
3. You fail to deliver the Business Case without this initiative.

Should-have initiatives

Shoulds are more likely to be working on the app but are less critical than musts. For MVPs, it means that the first version will function without should-have features (these can be slated for a future release, though).

For contract development, shoulds are the last requirements to get cut if cuts need to happen.

Could-have initiatives

Tasks that are neither crucial nor necessary to be released, but might be ‘nice to have’. Coulds can be added to project sprints when timeframe and cost permits. You can differentiate shoulds from coulds in terms of their importance — stuff that has a higher business impact belongs to shoulds.

When time or budget concern arises, coulds are the first ones you can cut from your backlog out.

Won’t-have (this time) initiatives

Least-critical stuff that can easily be slated for the next product version. Despite these requirements are determined as not valuable for your MVP version, they can eventually be re-prioritized to real Must Have’s — in the next phase of development. Put them down, because one day a real user might come to you with the suggestion that you were considering as ‘Won’t have’.

Let’s see how it all works

To see how MoSCoW works, take a look at some feature requests for a project we had been working on earlier — it’s a platform that allows photographers to earn money by selling photos to clients.

Actually, the app’s set of features is bigger than you can see below, but that would be enough to get the idea. Let’s focus on the customer’s user scenario only. Possible features here are:

First off, let’s figure out the ‘Must have’ features. The shortest scenario here will be like: a client goes to the app, searches for his photographer and chooses photos he likes. We also need to let him pay for the photos the way he prefers and, finally, let him download them.

Based on that, the bare minimum features will be:

Then we should determine won’t-have features. Here our client didn’t share the requirements we could easily pull out of the MVP version. Which is why there are no real won’t have’s to share with you:) Although, possible examples might be ‘Dual language support’ or ‘Payment with bitcoins’.

Next, we can go further and switch to shoulds. Here I’d look at using billing address, promo code, paying with credit card and the ability to register via social networks. Despite these requirements are important, they aren’t critical for the core user scenario.

Now our prioritization looks like:

Finally, the last thing to prioritize is the ‘Could have’. All the rest of the features are Could have’s by default, heh:)

Now take a look at the whole picture:

Instead of wrapping up:

To finish, I’d like to share a few things to consider while prioritizing product requirements:

1. If some scenario has a workaround, even if it’s manual — it’s not Must Have anymore and can be determined as Should Have or Could Have.
2. If someone insists a story is a ‘Must’, ask him ‘What happens if we release the app without that?’. You could hear something like ‘People will die’ or ‘We risk being shut down’, or ‘It makes the app data insecure’. Anything less important is a reason to switch this ‘Must’ to ‘Should’ or ‘Could’.
3. Prioritize quickly. Wasting weeks for that isn’t a good idea. A couple of hours is enough.
4. Priorities may change between releases. It means that a feature that was ‘Should’ in MVP may easily turn into the must-have for version 2.0.
5. Prioritization isn’t the destination. Review your priorities throughout the project to ensure they’re still valid.
6. Regardless of what you prioritize, do this not to prove your point, but to communicate with targets and see where you’ve made mistakes.

Please hold down that 👏🏼button below a few times to let other product managers see this post. And feel free to reach out to us to identify features your app requires and determine the order in which they get sent to sprints.

Go follow Purrweb on Instagram | Like us on Facebook or Twitter OR LinkedIn

Hugs and meows ♥