Type your search query and hit enter:
All Rights ReservedView Non-AMP Version
Type your search query and hit enter:
Categories: Product Backlog
Prioritising a Product Backlog When Everything is Important
Listen to this article:
Step 1: Ensure that you know who the product is for and why people will want to use it
Ill 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 cant. 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 (lets 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:
Lets 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 dont 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 users 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. Whats required is a specific product 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 help the users understand their eating habits and acquire an initial user base. (Note that I have chosen a compound goal that captures the desired user and business 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 product 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 maybe even more importantly, it facilitates prioritisation.
If you believe that removing the product 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.
Next A Brief Guide to Product Discovery »
Previous « Common Product Vision Board Mistakes
Leave a Comment
Four Product Success Factors
Our ultimate goal as product people is to achieve sustained product success: to ensure that
2 days ago
Dealing with an Underperforming Development Team
As the person in charge of the product, you rely on the development team to
1 month ago
Seven Product Backlog Mistakes to Avoid
The product backlog is a simple yet powerful tool to capture and revise detailed product
2 months ago
Three Qualities of Great Product Roadmaps
The product roadmap can be an incredibly useful planning tool that aligns the stakeholders and
3 months ago
Product Vision FAQs
The product vision can be a powerful instrument to inspire and align stakeholders and development
4 months ago
Tips for Becoming a Head of Product
Becoming a head of product and managing a group of product people is a significant
5 months ago
All Rights ReservedView Non-AMP Version