In the previous article, I provided a brief introduction to the role of a Product Owner (PO) and described the typical tasks and responsibilities involved. I also discussed how to handle user needs and requirements. In this post, I will delve into effective ways of managing the product backlog.
Understanding customer needs
As I mentioned earlier, one of the fundamental building blocks is understanding your customers' needs. For a detailed discussion on this topic, I recommend referring to my first post in the series on building the optimal IT development team.
I won't repeat everything I've previously mentioned, but there are some important points worth emphasizing. In the article, I describe how to gather all the needs and requirements, but another aspect is interpreting and understanding these needs, which is not always straightforward.
Keep in mind that users and other stakeholders often have a different perspective when expressing a need, and it can sometimes be challenging to translate this into goals, terms, and needs that can be realized by your development team. I've also noticed that some people tend to get caught up in IT systems in various contexts, but in many cases, IT support may not be the solution.
An example of this was when a colleague and I were on an assignment where the staff complained about not having enough advance notice when large groups of people arrived. Many immediately saw the opportunity to create a frontend for a booking system where everyone could easily access information about scheduled visitors.
However, not all employees had access to a computer, and some had very limited computer skills. So, we concluded that the specific problem could be best solved by using a traditional bulletin board to address the immediate need. Later, it was replaced with an electronic bulletin board directly linked to the booking system.However, the urgent need was resolved by acquiring a manual bulletin board for 100 kronor, which was installed in less than five minutes!
Another issue during needs gathering is that they can be too vague or ambiguous. Such needs can be quite challenging to implement and must be concretized before they become useful in practice. Sometimes, such needs slip into the product backlog, and then managing the backlog becomes much more complicated than you may have anticipated.
Personas and user stories
In my previous post in this series, I discussed how you can use personas and user stories to better visualize user needs and different scenarios. This applies significantly to the backlog, both when formulating items and during the regular review. If you go through the items in the backlog and notice something that sounds strange, lacks specificity, or any other issue that bothers you, try using personas and/or user stories to provide substance to the person behind the request.
By doing so, you can better understand the need and reformulate the story to make it clearer.
When you succeed in making the product backlog clearer, it also becomes easier to quickly develop prototypes or wireframes to validate your deliveries and allow users and other stakeholders to test and interact with new versions of the product or newly developed functionality. This way, you can gather valuable feedback and identify potential areas for improvement.
The test results can also be used to modify and clarify the items in the backlog. Continuously adapt these items to meet user needs and expectations.
I understand that it can be challenging to get a good overview of the backlog when there are hundreds of items in it, but try to structure them somewhat so that not all items are in the "to-do" status. Some items may be in the idea stage and not realizable for several years, and they will only clutter the backlog.
Consider lifting all longer-term items into a separate category so that you can easily filter the items that are currently relevant in the view you are working with.
Prioritizing items in the product backlog
Another crucial aspect, which I also mentioned in my initial post in this series, is prioritizing items in the backlog. As the PO, you have the primary responsibility for prioritizing items. No one else has the right to change the prioritization in the backlog. It is important that this is very clear to everyone. You will encounter situations where others want to alter the priority order in the backlog, and the only way to do that is to try to influence you as the PO to make the change.
I mentioned different methods to facilitate prioritization but perhaps didn't provide many concrete examples of how to use these methods. Let me provide a practical example of using the MoSCoW method.
Suppose you are a PO for a team that manages an e-commerce platform consisting of various components. Within these components, there are numerous items that need to be developed and therefore prioritized in the backlog.
"Must-haves" are features or functionalities that are absolutely necessary for the product to function and meet the most basic user needs. These could include features such as the login function, product catalog, shopping cart, payment function, and more. All these items are vital parts of the application, and without any of them, the application would be unusable.
"Should-haves" are items that are important for improving the user experience and meeting user expectations but may not be as critical as the ones in the previous category. This category may include features such as product search, filtering product lists, selecting shipping methods, choosing payment methods, changing the user interface, and more. These items should be included, but there is room for adjustments and reprioritization based on changing circumstances.
"Could-haves" are desirable features that can add value to the product and benefit users, but they can be postponed or removed without impacting critical functionality. Examples could be product reviews, personalized recommendations based on previous purchase behavior, social media sharing, SEO optimization, and more. These items can be included if there is room for them but not otherwise.
"Won't-haves" is the final category, and it includes features deliberately deprioritized for a specific reason. Such features could be enabling payments in different currencies, integrating the application with various business or BI systems, and more. Also, remember to carefully document why items end up in this category, as someone may question why a particular feature is placed here.
Last but certainly not least, I want to emphasize the importance of involving users in the prioritization process. It is crucial for them to feel involved from an early stage, as it helps build trust between the team and the users/stakeholders.
While I have touched on this topic before, in the next article, I will go through how you, as a PO, can communicate and collaborate with all stakeholders.
