The product backlog is an essential product management tool: It captures detailed product decisions and directs the work of the development team. The latter requires it to be prioritised or ordered. But how can you prioritise a product backlog when everything seems equally important? This article shares my answer. It recommends taking four steps to get to an effective, prioritised product backlog.
Step 1: Ensure that you know who the product is for and why people will want to use it
I’ll never forget the day when I suggested to the product manager of a brand-new healthcare product to prioritise its features. The individual looked at me slightly bewildered and replied, “I can’t. They are all high-priority.”
Prioritisation requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction, and there is only a slim chance of creating a successful product.
A common root cause of not being able to prioritise a product backlog is a lack of understanding of who the users of the product are and what specific value it should create for them. I find it not uncommon that features are added to the product backlog because a senior stakeholder demands it (HIPPO syndrome) or someone thinks it is a good idea (“let’s brainstorm some user stories”). But a product exists to generate value for the users and for the company providing it. If it is not clear who the users are and why they would want to interact with the product, it will be hard to decide which items should be in the product backlog and how important they are.
To mitigate the risk of adding the wrong items to the product backlog, ensure that you have a validated product strategy in place, no matter if you look after a brand-new or as an existing product. Such a strategy should clearly state the following:
- The users and customers of the product so that it is clear who will benefit from it and who won’t;
- The main problem the product should address or the primary benefit it should offer, or the main goal users will want to achieve with it;
- The three to five features that will make it stand out from the crowd;
- The specific benefits it should create for the business.
Let’s look at a brief example and say that I want to create a product that helps people eat healthily. Then I could choose to address middle aged men who suffer from unhealthy eating habits and who don’t exercise enough. The benefit might be to reduce the risk of developing type-2 diabetes. The standout features might be to measure food sugar levels, analyse the user’s eating habits, and integrate with leading smart scales. The business goals, finally, might be to diversify my company and open up a new revenue stream.
Additionally, you should be confident that your strategy is correct, and you should have data to support your view. In other words, you should have addressed the key assumptions and risks in the product strategy, and you should have carried out the necessary validation work. A tool like my product vision board helps you capture and validate your product strategy.
Step 2: Describe the outcome or benefit the product should create in the next few months
Having a product strategy in place is great, but it is not enough to effectively prioritise a product backlog. What’s required is a specific, midterm goal that is connected to the strategy and creates the right context to decide which backlog items are more important and which ones are less.
To create such a goal, ask yourself which outcome or benefit your product should achieve in the next, say, three to six months. What are the desired user and business benefits you want to create? Make sure that this goal is in line with the product strategy and that it helps create the desired user and business benefits. An example based on the sample strategy above would be “acquire an initial user base and help the users understand their eating habits.” (Note that I have chosen a dual goal that captures the desired business and user benefits.)
I like to take this idea further, derive several product goals from the product strategy for the next 12 months, and capture them on a product roadmap. This puts the goal chosen in context and communicates how the product is likely to evolve over a longer period. If you have a product roadmap, then ensure that it implements the overall product strategy. Consider reworking it so that it clearly states the desired outcomes your product should achieve.
Step 3: Remove all items from the product backlog that do not support the desired outcome
Next, use the goal you have chosen to delete all items from the product backlog that do not serve it. While this approach might sound radical, it ensures that your backlog becomes concise and focused. It avoids having items on the backlog that are speculative and may not create value, and it facilitates prioritisation.
If you don’t want to lose any items, then you might introduce a corresponding feature on the product roadmap–assuming that there is a goal that the new feature supports. Do not add too much detail to your product roadmap, though, to keep it a high-level plan. Alternatively, you can move the items to the bottom of the backlog and mark them as currently not relevant. But be aware that this can lead to the creation of “Zombie items” that permanently stay at the bottom of your product backlog and clog it up.
If you think that removing the backlog items is going to be very difficult, if not impossible, then this may indicate that you lack the necessary empowerment and/or that the stakeholders do not buy into the overall product strategy and the specific product goal you have chosen. Involving the individuals in the decision-making process can help address both issues. This allows the stakeholders to voice their ideas and concerns, and it makes it more likely that they understand and support important product decisions.
If you plan to decide together with the stakeholders, then invite them to a meeting. Carefully prepare the session and choose a decision rule, for instance, consent. Additionally, ask your Scrum Master or another skilled facilitator to help run the meeting so that everyone is heard, and nobody dominates. (I offer more advice on securing stakeholder buy-in and decision-making in my book How to Lead in Product Management.)
Step 4: Prioritise the remaining product backlog items
Now prioritise the remaining product backlog items. I recommend that you prioritise a new or significantly changed product backlog initially by risk, taking into account the user, technology, and business-related risks. Assess all backlog items together with the development team and move those to the top that carry the highest risk. This approach accelerates learning and it avoids failing late when there are less options to change course.
Finally, ensure that the high-priority items are “ready“, that the development team and you have a shared understanding of them, that the team can implement them in the next sprint, and that they are testable.
The Moral of the Story
You might be wondering what was up with the healthcare product I mentioned earlier. The prioritisation difficulties were indeed rooted in the lack of a clear and agreed product strategy and the absence of a clear, focused goal for the initial version. Consequently, the offering launched was more like a maximum viable product than a minimum one. Unsurprisingly, it pretty much bombed, which resulted in the company losing significant market share and people leaving the enterprise.
As this story shows, it is crucial to have an overall product strategy in place before you decide which functionality your product should offer and in which order it should be implemented. In other words, make sure that you create an effective product strategy first before you worry about the product details and that you systematically connect the product backlog to the strategy.
Published on Java Code Geeks with permission by Roman Pichler, partner at our JCG program. See the original article here: Prioritising a Product Backlog When Everything is Important Opinions expressed by Java Code Geeks contributors are their own. |
