By Roman Pichler
When I met Paul, a first-time product owner on a new project, the first thing he asked me was, “What do I really have to do and how much time will it require?” Even though Paul had attended a Scrum introduction a few weeks back, he wanted to double check his responsibilities. He was worried about the time commitment he had to make and the support he would get from his boss.
Helping product owners like Paul getting started is rather the norm for me. In most organizations that I have worked with, product owners are strapped for time, are often not aware of their responsibilities, and are unsure how they should best transition into their new role. Sadly, I have also met many product owners on Scrum projects who resembled more a business sponsor briefly stopping by at the sprint planning and review meeting or an on-site customer interacting more frequently with the team but leaving it to the ScrumMaster to guide the team.
So what is the product owner in Scrum supposed to do? The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.) In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out. I have experienced that having a strong, empowered, and present product owner is a key success factor for Scrum projects – just like a strong, empowered team is. Most projects I have come across that had product owners who were not properly available or empowered suffered, and the projects never reached their maximum velocity.
I have found three things particularly helpful for product owners: a thorough understanding of the customer needs, an active stakeholder management, and a basic knowledge of how software is developed and deployed.
Thoroughly understanding the customer needs and how the product will satisfy those needs allows the product owner to describe, prioritizes, and communicate the requirements that really matter and answer all related questions. The product owner should express what value-added is from a customer perspectives and focus the development efforts toward providing that value.
Proactive stakeholder management is particularly important in larger organizations, where the stakeholders include not only customers but also internal functions, such as production support, service or sales, as well. Taking into account and prioritizing the various interests early on and involving stakeholders regularly, for instance in form of user story writing workshops and sprint reviews, is crucial to ensuring that the software can successfully work in its target environment.
Knowing (at least roughly) how good software is developed makes it easier for the product owner to closely communicate with the team. This kind of knowledge helps product owners to better understand how the team works and how important quality and the related agile technical practices are to sustain a high velocity across releases.
This broad skill set implies that ideally, the product owner would be a hybrid: someone who is able to look outward, understanding the end customer needs, and someone who looks inward, managing the value stream that transforms the customer needs into software ready to be used by the customer. Toyota’s Chief Engineer role very much resembles such a hybrid product owner: The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s.
So what did I tell new product owner Paul? Well, I took him through the key activities a product owner has to perform on a Scrum project, from hosting estimation workshops and prepping for the sprint planning meeting to giving feedback to the team and accepting or rejecting work results in the sprint review meeting. I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available. We scheduled the first user story writing workshop with the team and stakeholders, and we set up the first effort estimation workshop. I also volunteered to talk to his manager about Scrum and to explain why it is so important for a product owner to spend enough time with the team every day and to be able to make decisions on the spot.
Being an effective product owner is not easy – nor is being a good ScrumMaster. To get started, be aware of the core responsibilities the product owner has and make sure that the product owner firmly sits in the driver’s seat – all the time.
