Prioritising is deciding what comes first. It sits between scoping, which is what is in your product at all, and road mapping, which is knowing when everything is coming.

There are two frameworks worth knowing. MoSCoW is the easiest place to start. P levels are what I use.

MoSCoW

MoSCoW stands for must have, should have, could have, won't have. The O's do not count for anything, they are there to make it pronounceable.

You go through each feature and decide: does it have to have this, should it have this, could it have this, or is it not going to have this at all.

The rule that keeps the top two columns honest is that must and should should always correspond to the primary reason your product exists. If a feature is not serving that reason, it is not a must, however much you like it.

Could have is the same as nice to have. When I look at grandparent friend accounts for my nanny app, that is a really good idea, and I call it a could have. It does not have to be there, but it definitely could be.

Anything that lands in the could column needs a second pass afterwards, to decide whether it really could or whether it won't. Otherwise could becomes a place things go to avoid a decision.

If you are visual, you can do this by literally grouping the features the way you would in affinity mapping.

P0 to P4, which is what I actually use

It roughly maps to MoSCoW, but in my opinion it is more accurate and easier. By assigning a number I find it much easier to prioritise, because I get to look at two things and ask which of them is more important. If they are in the same column, are they equally important? If they are not, one of them needs to move.

P0 is table stakes. If it is broken on launch day you delay the launch. You are not launching this app without it. That maps directly to the must have column.

P1 is what you want to launch with. You would not hold the launch for one of them the way you would for a P0, and they all get built before anything in P2 does.

P2 is your upcoming stuff. Then P3 and P4 go further out, and after that there is out of scope, which is the won't have column.

There is a nice way this connects to what you are launching. Your P0s are your viable product, your MVP. Your P1s are your minimum lovable product. That is not always going to map directly, but as a thought framework it is a good one.

The test for whether something is really a P0

People over-assign P0. Here is the question that sorts it.

If you will not launch the product without those notifications, then they are P0. But if there is any world where you might conceivably launch without them, if they were broken and you said no, we cannot wait another week or two weeks, we are going to launch, then they are a P1. They are clearly not a P0 if it is possible to launch without them.

Know which problem each feature is prioritising

A feature might address multiple problems, and it probably will. A lot of the time our solutions, if we have come up with good ones, address multiple problems, and that lets us serve multiple users.

But in order to build it, you need to know which problem you are prioritising. That is what decides what the feature looks like when it is small.

The hard part is saying no to good ideas

It is really, really easy to have ideas. It is very hard to say no to one, especially when it is a good idea, and the work is evaluating whether that good idea is good or bad for you to say yes to right now.

I had to do this out loud on the Rivian app. Saying listen, that is not important, we are launching this product and it can only have important things in it, is not a comfortable sentence to say to people who have put thought into something. You still have to say it.

Here is the thing that makes it easier to say. If people love the app, they will put up with a missing feature for a long time before it frustrates them. And if people do not love the app, adding that feature is not going to magically make them love it.

Use it to handle other people

This is a really good way to get alignment with stakeholders, by getting them to help you do the prioritisation.

Someone tells you their feature is a should have. You do not think it is core to the product, so you would put it in could. Rather than argue about whether it belongs in the product, you hand them the columns and let the disagreement be about which one it goes in.

What I say out loud is: I agree, that is a pretty cool idea, let us put it in the could column, because I do not think it is integral to the product. People do not get their hackles up at that, because it is not a no.

Sometimes, unfortunately, P0s will be things you as the product manager do not want in your app, because marketing says it has to be there or somebody else says so. You lose some of those battles. Your job is to speak for and defend the user, and you will not win every time.

Keep reading

MVP vs. MLP: What's the Difference and Which One Should You Launch?

Now, Next, Later: Roadmaps for People Building Their First App

What Is a Minimum Viable Product and Do I Actually Need One?

Learn this with me

Prioritising is class 7 of From Passion to Product, my free six-week live course. MoSCoW is in it, so is the impact and effort matrix, so are my own P0 to P4 priority levels and when strategy should override the matrix entirely. You leave that class with your own feature list sorted.

I teach the same material to engineering teams as a one day workshop or a longer program, because a team that cannot agree what is in version one has the same problem a solo founder has.

Join the waitlist for the free cohort, get the workbook, or look at the team programs.