How to Be an Effective Product Owner in Agile Environments
In every single project that I’ve worked on, I’ve noticed one undeniable pattern – the product owner is the key person that can make or break the project. I’ve already covered the five most important product owner skills. In this post, I will focus on how to handle the most common situations that product owners in agile environments face.
Understanding and Picking the Right Product Owner
First of all, any project that has multiple product owners or C- or VP-level product owners is always going to be a challenge and will be more likely to fail than succeed. Why is having multiple product owners not effective? Because, if you have multiple product owners, who gets to make decisions? Who should stakeholders turn to? Who should developers and the ScrumMaster address their questions to? What happens if the product owners have two opposing views? What happens if they don’t get along? Who is really responsible and the real owner of the product? The more product owners you have in a project, the more likely you are to have assumptions and maybe even conflicting viewpoints. In addition, multiple product owners can cause unnecessary confusion when making decisions and defining best practices.
The “right” product owner should be available to take full ownership of the product and dedicate the majority of their time to it.
Why is a C-level executive, VP, or manager not effective as a product owner? While it is helpful to have a C- or VP-level product sponsor, people in these roles rarely make effective product owners. Their primary work function is to manage whole departments and multiple processes. They will not be able to zoom in on one specific project and product to make it successful. They will be expected to go to every meeting, be involved in the minute details of the project, and manage everything. These are unreasonable expectations, and it is unlikely that a high-level manager will have the time to do everything. A product owner should dedicate anywhere from 60 to 100 percent of their time and effort to a project in order for it to be successful. If the upper level manager takes ownership of a product, what will happen with their other duties and work? Instead, the upper management should carefully pick the product owner and empower them to make the right decisions.
The “right” product owner should be available to take full ownership of the product and dedicate the majority of their time to it. They must understand what needs to be built and have a vision of the final product. They must be willing and able to talk with all stakeholders and communicate clearly to the Scrum Master and developers. In addition, they should be able to prioritize features and functionalities while communicating the reasoning behind all decisions.
Understanding and Managing the Stakeholders
The most common challenge that product owners face is managing stakeholders and their expectations. In order for the product owner to be effective at representing the stakeholders to the development team, the stakeholders must trust and believe in the product owner. They need to trust that the product owner will represent their needs to the developers and will know what is “critical” to develop.
So, how do you gain the trust of the stakeholders? The first thing to do is similar to what the Scrum Master needs to do – listen and learn from the stakeholders. Do you know the stakeholders already? If so, you might already have their trust. If you don’t know them, then get to know them right away. Start with the first and easy step of introducing yourself, your role and expectations. The second step is to ask them questions about their job and their needs. Listen to their frustrations about and expectations for the new solution. People are more than ready to talk about their processes and share their expertise.
In order for the product owner to be effective at representing the stakeholders to the development team, the stakeholders must trust and believe in the product owner.
Sometimes, you will come across detractors, people who are against the new product and not willing to change and work with you. If you are already interacting with such people, stay tuned for my next blog post. For now, the most basic strategy in dealing with detractors is to go around them. However, if they have valid points that you should address, of course you should listen and take their feedback into consideration. Just make sure they do not distract you from your main mission, which is to build a successful product.
Understanding and Managing the Storyboard
The storyboard in Agile development contains your requirements and what the developers have to build. If the stories are confusing, unclear, or not effectively prioritized, the project won’t be successful. Thus, as a product owner, you should be focused on managing the product backlog and sprints. When stakeholders submit feedback, make sure to review each feedback item carefully. Only accept feedback that is clearly defined and has business value. All other feedback should be either reviewed or rejected. In order to get clean feedback and stories, show the stakeholders what great feedback and stories are supposed to look like. After the kickoff of a project, hold the stakeholders’ hands for the first few weeks. You should walk them through the story creation and the feedback process. At demo time, show them the link between their stories and what has been developed. As they become more familiar and adopt the process, you can start to take a step back and focus on improving the process further.
Keep Calm and Automate On
As a product owner, you have to manage multiple people and their expectations, in addition to the whole product backlog. This is a lot of work that takes a lot of time and effort. Thus, do not be surprised if at times you feel overwhelmed. If you do feel overwhelmed, take a break. Look at the big picture and enlist or ask others for help.
In addition, you should try and automate as many communication steps as possible. For example, you can either create templates in PowerPoint or use tools for the following project steps:
- Kick off the project and clearly define the goals
- Establish clear communication channels and meeting expectations
- Create a weekly template to showcase the status of the project to stakeholders
- Create a workflow and process for weekly or bi-monthly product demos and feedback gathering
Last but not least, ask for help when needed. Ask for support from higher management if you don’t feel empowered to make the necessary decisions. Ask the Scrum Master for help with the product backlog and in the whole development process. As a product owner, you have a lot of responsibility and work to do. But all the hard work will pay off when the project is done and the product is out.