How to prioritise when everything is a priority
How to prioritise when everything is a priority
Plus an invitation to submit Q&As.
Welcome to the newest subscribers, and thanks for joining! It’s great to see more people signing up.
New content goes out on Mondays and Thursdays. Mondays are for multi-topic posts, whereas Thursdays are for “pure” product content. This is only a loose plan though. This week you also got a product post on Monday. Hopefully you don’t mind - after all, you probably signed up for product content anyway…
If you signed up recently, you might have missed Monday’s post. If so, here it is again:
Today, it’s all about prioritising.
How to prioritise when everything is a priority
The product backlog is meant to be an ordered list of items. Thus, the topmost item is the highest priority, then the next, and so on.
This forces you to choose a specific item to work on first.
If you have a field called “Priority” with values P1, P2, P3, P4, it means you’ll only ever work on the P1s – maybe some of the P2s. For anything below that, why is it on the backlog? Will you ever get to it?
But let’s say you have a project to deliver functionality across 30 stories. All the stories are of equal priority as they form part of the project MVP.
How do you prioritise those stories?
First, look for risks: areas where there is uncertainty, and that could trip you up if they are looked at too late. Picking these up sooner gets them out of the way and helps increase confidence in completing the remainder of the stories.
Next, look for dependencies: anything that can’t be started before other stories are completed. The priority can then be to work on stories that will allow others to be picked up.
Finally, look out for any big stories that may not fit into a single sprint. These shouldn’t be left until the end in case they are not completed in time. Splitting them up may be possible, but if not, starting them early gives a better chance of spotting issues sooner.
Even when everything is a priority, it’s still possible to prioritise within your top priority items.
Coming soon: Product Q&As
As early subscribers to my Substack, I’d like to invite you to submit product questions for a future feature.
They can be things you’re stuck on, areas where you’d like to find out more, or maybe topics where you’re interested to hear an alternative viewpoint.
Questions will be featured in a future Product Q&As section of the newsletter. Simply reply to this email with whatever you’d like to ask. Make sure to tell me how you’d like to be credited - whether just by your first name, full name, or with a link to your own site.
Help me title my Substack
I’m also looking for a title for my Substack - for now it’s named after me. Not very original.
My background is 20+ years of experience across multiple industries, with many of those years working as a developer. I’ve also been a tester, Scrum Master, and Product Manager.
I aim to publish tips and tricks in plain English, for PMs of any skill level.
One idea could be to reuse the “Quick Product Tips” title of the blog I published before joining Substack, though it’s a little bland - and the posts here aren’t all that quick.
Incidentally, I did ask ChatGPT what I should call my Substack…
I’m sure you can do better than that!
Until next time,
Ben