Initially, I provided a brief introduction to the role of a Product Owner (PO) and described what is typically involved in the tasks and responsibilities. Then, I discussed how you can manage user needs and requirements, followed by some concrete tips on effectively managing the product backlog. Now, I want to delve deeper into how you, as a PO, can improve your communication and collaboration with various types of stakeholders. In this article, I will focus on the ongoing work of further developing the product.
Manage the product backlog and define clear measurable goals
A fundamental requirement for ensuring the product's development process is to have a prioritized product backlog with clear and measurable goals. I have previously touched upon how you can create and manage the backlog effectively, so I won't dwell on it here. Instead, I recommend you to refer to that post.
Now, let's talk about goal formulation... I discussed this in my series on assembling an effective development team. In the very first post of that series, I talked extensively about how you can gather the organization's requirements, needs, and desires, and how you can categorize and prioritize them to create a manageable list. Using that list, I then explained how you can establish clear, measurable goals, including the use of the SMART methodology.
Additionally, it would be helpful to supplement this approach by defining clear acceptance criteria for a story or feature. This makes it much easier to track progress, and as a PO, you gain control over the Definition of Done (DoD) and when you can mark something as completed.
Agile methods, techniques, and tools
There are numerous tools that facilitate product development work and make your life as a PO easier. Agile methods such as Scrum or Kanban help you organize and manage the ongoing development work. With the help of a Scrum board, you can easily categorize and organize all the tasks. Many choose to create four columns on the board to indicate the status of each task (story) and label them as "To Do," "In Progress," "Waiting," and "Done."
It may also be wise to add an additional column where you can include all the ideas suggested by the team or stakeholders that may not be scheduled in the near term. You can name this column "Ideas," "Funnel," or something similar. The purpose of this last mentioned column is to have a place where all ideas can be stored, regardless of whether they lead to something or not. This reduces the risk of the team forgetting something later on.
Remember to use the Scrum board during the team's collective meetings such as daily stand-ups, sprint planning, sprint reviews, and more. The board provides a visual and comprehensive overview of the team's work and a snapshot of the current status.
Communication and openness
As I mentioned before, openness and effective communication are fundamental to many aspects, including the product development process. Establish a consistent rhythm (cadence) for the team's meetings to facilitate everyone's participation in different ceremonies and meetings. Schedule your daily stand-ups to occur at the same place and time every day, so that everyone can easily plan for them in their calendars.
In addition to these meetings, there are sprint planning meetings, retrospective meetings, and more. As a PO, you must always be flexible and ready to adapt, both yourself and the product backlog. The important thing is to justify your decisions and be open about why you do things a certain way.
For example, if you are in a meeting with stakeholders and you agree to reprioritize certain items in the backlog or even within the current sprint, it is important to communicate this to the team and other stakeholders, explaining why this reprioritization has been made. Sharing the background of the decision and the consequences of not reprioritizing provides valuable information that helps the team feel more motivated to suddenly focus on something other than planned.
A dilemma for a development team can be finding something to demonstrate to other stakeholders during sprint reviews. Many team members may feel that there isn't much to demonstrate in a particular sprint, but the truth is there is ALWAYS something to demonstrate. It is good to showcase what the team has accomplished and provide other stakeholders with the opportunity to provide feedback and ask questions.
To facilitate the process of finding things to demonstrate, you can review all the items in the "Done" column on the board. Try to categorize all the stories into four or five different topics that may be interesting to showcase. You or the Scrum Master can then email these topics to the team and gather their opinions on what might be the most interesting. After the next daily stand-up, you can collectively decide what should be demonstrated to the other stakeholders.
Be flexible and iterative
Anticipate (as much as possible), accept, and manage changes, iterating continuously based on feedback, user needs, and changing circumstances. A classic problem in IT development is setting goals, staffing the team, allocating budgets, and then strictly following a predefined path. When conditions change, it takes too long to adapt, resulting in delayed delivery, higher costs than planned, and a product that doesn't fully meet the requirements, needs, or expectations.
As a PO, you are expected to be open to adjusting the backlog and goals as needed. By being flexible and responsive, you can ensure that the product evolves to best meet user needs and market demands. If you receive valuable feedback from users or stakeholders during a sprint, consider reevaluating the priority of certain tasks and quickly adjust the backlog to incorporate the new insights.
By applying these tips, you can effectively manage the ongoing product development process and ensure that the product evolves in the right direction, focusing on both customer needs and business goals. Every product and team is unique, so adapt these guidelines to your specific situation and evaluate what works best for your team and stakeholders.
Avoid rigidly adhering to methods or frameworks; instead, tailor them to your team and circumstances. I have seen too many cases where people read about what a particular role should do or what responsibilities should be taken care of, but the truth is that all roles adapt to the team and individual circumstances. The important thing is to focus on what needs to be delivered rather than how it's done.
I hope you try some of the tips I have described in this article. They can greatly benefit your daily work as a PO and contribute to making the team's work more efficient. Now that we have discussed how daily work can be performed, it's time for the next topic: how we measure and optimize the team's results and the product's development. More on this in the next blog post.
