Setting priorities on features or user stories is one of the most fundamental practices of solid product management. A great product manager masters prioritization and gives the team a very clear plan for success using these priorities.
The usual disfunction of prioritization.
The vocabulary of prioritization is pretty straight forward… P1, P2 & P3 features. But all too often, here is what usually happens. It’s early in product planning. Almost everything looks really important. There is pressure from all sides to get features in, people are dreaming big. Almost everything gets labeled a P1. There are a bunch of P2s and almost no P3s. Then as the team progresses into product development, it becomes clear that the time and cost to develop all these features is way beyond what anyone has an appetite for. So in order to hit deadlines, the PM starts changing P1s to P2s and P2s to P3s. Not only this is inefficient and disruptive… Wouldn’t it have been great for the team to have known the real priorities upfront so they could work on the most important stuff? But it undermines a PM’s legitimacy and the teams ability to trust them.
How to do it right.
So here is a simple and effective approach to get prioritization right. Let’s start with definitions.
P1 is a ‘Must-have’ feature. This means you will not launch without this feature. You will delay launch dates. It is a true launch blocker.
P2 is a ‘Nice to have’ feature. This means it is a feature you want to include in launch, but you would not move launch for the feature.
P3 is a ‘Future’ feature. This means there is no intent to include it in launch. But it might come in the future.
Notice these are very specific and clear. There are no blurry lines between what is P1 v P2 v P3.
And here is the real power of this approach. When someone pushes for a feature to be a P1, ask the following question…
“Would you delay launch for this feature?”
If the answer is YES it is may be a P1. If it is not, it is a P2 or lower.
With this approach you should get a tight set of real P1s and a long list of P2s and some P3s. And you should have very little change within your P1s.
Now the magic is prioritizing within the P2s. You should stack rank them. And the goal should be to get as many of them into launch as possible. But when push comes to shove and you need a way to hit a date, you remove P2 features.
Building Trust with Development and Stakeholders.
This approach creates a strong trust between product management and product development. Now there is clarity on P1s and it has real meaning. And the team has a clear view of prioritized features that aren’t launch blockers. But for this approach to work, it requires that the team launches more than just the P1s.
You’ll get nervous reactions from stakeholders that only P1 features will get delivered and the launch will be emaciated. After all, they are likely used to not getting even all the P1s. So in order to develop trust with stakeholders, the team needs to develop a track record of delivering against some P2s.
P3 features are those great ideas that you might want to do in the future. You definitely don’t want them now. You don’t want any time wasted on them now. But you want to capture where the product might go in the future. This gives everyone greater context and is a little investment in future proofing, without a lot of pre-optimizing.