Job stories, backlog items, workshop ideas, roadmap features… it’s easy to feel overwhelmed by the scale of potential directions you can take a product in. And it’s natural to want order in this chaos. Prioritisation is a core part of Product Management, and it’s the topic I most commonly get asked about by other Product Managers. But it can also cause a lot of stress – while prioritisation is important, too much emphasis is put on it.
I think you should keep the prioritisation process fast and flexible. This frees you up to focus on other crucial parts of your role, like gaining insights and actually delivering.
Part of the problem with prioritisation is the assumption that a “correct” order exists in the first place, and the myriad of prioritisation methods available feeds this myth. It implies that once you discover the perfect sequence of priorities you will magically arrive at a reliable and predictable roadmap for your product. Unfortunately reality is not so kind. Here are a couple of uncomfortable truths about prioritisation:
- A lot of the time prioritisation is based on hunches and guestimates
- You’ll probably only do one or two items from your beautifully manicured list before it changes
Take the Impact/Effort Matrix as an example. It falsely assumes we know in advance the specific value of each item and the time it will take to implement each of them. However, how can we know the impact that something will have before we put it in front of customers? And how many times has a project taken longer (or even shorter) than expected to deliver?
Underlying the prioritisation questions of “what order is best” and “which are the most important ones”, is the aim of discovering “what’s the fastest way I can reach my objective?” I think therefore you should put the focus on learning and rapid experimentation to quickly find the best path.
Story Awareness Set
Instead of an ordered list I prefer to imagine a pool of potential job stories and hypotheses: the Story Awareness Set. The more insights a story has to back it up, the nearer to the top it floats. As you learn more about your domain certain stories tend to bubble up. When you’re ready to start developing the next story just pick any of the ones near the surface. This allows you to be very flexible and agile.
Express each idea in the Story Awareness Set as a combination of a Job Story and Hypothesis:
When [situation/context], I want to [motivation], so I can [outcome].
Based on [quantitative/qualitative insight], we predict that [product change] will cause [impact].
This captures the situation the user is in, their motivation, their desired outcome, the change you’re proposing to address their need, and the predicted impact. Fundamental to this are the insights underpinning it, which is why they are explicitly stated at the beginning. Crucially we aren’t asserting a speculative impact upfront. Instead we’re making a hypothesis after interpreting observed qualitative and quantitative insights. Framing the hypothesis like this is also an important first step in designing a rigorous, trustworthy A/B experiment to test your prediction. The more you understand about the story, the more confident you can be in its value. If there are no obvious insights it is less of a hypothesis and more of an assumption. That’s OK, but it’s important to recognise the difference and make sure you’re testing assumptions in the smallest way possible to reduce their risk.
Seven Simple Steps to Stress-Free Prioritisation
Product management is beautifully messy and full of delightful uncertainty. Don’t let prioritisation suck the life out of it. Here are some steps to make prioritisation feel second nature:
1. Accept you can’t do everything
That’s OK, no one can.
2. Embrace the uncertainty
There is no perfect order, and that’s fantastic! We can be a lot more responsive now.
3. Pick an item and start working on it
It doesn’t matter which, go with your gut. It’s more important to do something and learn quickly from it rather than agonise over what to do. Put the focus on: what’s the most you can you learn in 24 hours? It may seem counter-intuitive but getting something rudimentary in front of your customers will actually make it easier to prioritise the larger story.
4. Ask probing, incisive questions about the other items in your Story Awareness Set
What problem will it solve? What will we learn from it? What questions will it answer? What will it tell us about our direction and strategy? What key assumptions will it address? How will we measure and evaluate it? And so on.
5. Identify insights for the items in your Story Awareness Set
Have you seen people struggle with this in usability testing? Is it raised a lot in Jobs to be Done interviews? Have you identified patterns or unexplained behaviour in your analytics data? Did a previous experiment highlight an unmet need or challenge existing assumptions? The more qualitative and quantitative insights you have to back up the item, the more you’ll understand its value.
6. Talk to your engineers and designers
Avoid asking them for estimates of time or effort. The answer is just a number. It won’t help you gain a deeper understanding. Instead ask questions to expose potential risks and identify known unknowns. Is it worth doing a technical spike (a small, time-boxed investigation into a specific technical issue)? Would more targeted user research or basic prototype testing give us a clearer direction? What are the potential technical, system or product complexities they can they foresee?
7. Start the next item and repeat
There should now be some clear candidates to pick up next. The ones whose backgrounds feel more fleshed out and are on more solid ground.
Keep thinking about the rest of the items in your Story Awareness Set. As you learn you’ll continue to see them in a different light and you’ll get smarter about which tasks to pick up next.
Comments 1