Five Product Owner Myths Busted
The product owner is a role which is often misunderstood and frequently misapplied. In this article, I address five common product owner misconceptions. I explain why they are wrong and how the role can be effectively implemented.
🎙 You can listen to the audio version of this article at https://www.romanpichler.com/romans-podcasts/.
Myth #1: The product owner has to ensure that the stakeholders are satisfied
Stakeholders can be powerful and influential individuals. But the value a product creates is ultimately determined by its users: No product will be successful in the long run if it does not solve a specific user problem, create a tangible benefit, or help the users achieve a specific goal. While internal stakeholders such as marketing, sales, and support play an important role in successfully offering a product, it would be wrong to try to please them and to say yes to all their ideas and requests. In the worst case, you’d end up with a product that implements the stakeholders’ requirements but does not effectively address the user and customer needs.
At the same token, ignoring the stakeholders or excluding them from important product decisions is not helpful either. Instead, you should engage the stakeholders, leverage their expertise, and generate as much buy-in as possible, as I explain in more detail in my article “Stakeholder Management Tips for Product People.” But do not allow people to dominate and tell you what to do, and don’t agree to a weak compromise. As the product owner, then you should own the product on behalf of the company and be empowered to have the final say, particularly if no agreement can be reached.
Myth #2: The product owner is a tactical role focused on managing the product backlog
In Scrum — the framework that gave birth to the product owner — the role is responsible for maximising the value a product creates for the users and for the business. This requires full-stack ownership: having the authority to make strategic product decisions in addition to tactical ones. Consequently, a Scrum product owner should own a product in its entirety — from the product vision to the product details. The individual should carry out product discovery and strategy work in addition to taking care of the product backlog work.
But the situation is different for product owners in the agile scaling framework SAFe. The framework uses its own product owner role, which is different from the one in Scrum. The SAFe product owner is tactical in nature and focuses on working on the product backlog and guiding the development teams. The strategic work is taken on by another role, the SAFe product manager. Splitting product ownership and using a strategic and tactical role is a common scaling technique — although not necessarily the most helpful one, as I discuss in more detail in my article “Scaling the Product Owner.” The following picture summarises the difference between the Scrum and SAFe product owner roles.
Be therefore clear which product owner role you play and if you are a Scrum or a SAFe product owner, as your authority and accountability will significantly differ. I have always regarded the Scrum product owner as an agile product manager, and I find it an unfortunate mistake that SAFe use the same name for its tactical product role. This has created more confusion and increased the misconceptions of the role.
Myth #3: The product owner is responsible for the team performance
An agile development team does a good job if the memebers can reliably meet the agreed goals and create software that offers a great user experience and exhibit the desired quality. As such a team is a self-managing group, the members are expected to jointly plan the work, decide how it is carried out, track the progress, resolve any disagreements and conflicts, and practice sustainable pace to stay productive and motivated.
As it takes time for group of people to become an effective self-managing team and learn to make realistic commitments, the dev team needs a Scrum Master or agile coach who supports and advises them. This includes showing the dev team how agile processes can be applied and suggesting specific techniques, facilitating meetings, and teaching people how to constructively deal with conflicts. In other words, the Scrum Master is responsible for helping the team do a good job.
But as the product owner, you should focus on the product, not the team and the process. That’s usually challenging enough. Don’t make the mistake to cover the Scrum Master’s work over an extended period, as this will either cause you to neglect some of your core responsibilities or sacrifice your health — neither of which is desirable, of course. If you lack a Scrum Master, or if the individual is not sufficiently available or qualified, then consider what you can do to address this issue. Sometimes, it’s best to make the problem visible rather than carrying out some of the Scrum Master’s tasks and thereby masking the issue.
Additionally, don’t make the mistake to interfere with the work of the development team. For example, it’s a bad idea to tell people what to do in a sprint or to start assigning tasks to individuals. This damages the team’s self-management; it takes away ownership from the group; and it makes the dev team dependent on you as the person who sorts out their problems for them.
While you are not responsible for the team performance, you should, of course, care about the development teams you work with and offer helpful feedback and guidance. A great way to resolve any performance issues is to address them in the sprint retrospective. Dig down to the root causes of the problem and explore how you can help improve the situation. This might include involving the team members in continuous product discovery work, spending more time jointly refining the product backlog, or making yourself available to answer urgent questions and review finished workresults during the sprint.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/five-product-owner-myths-busted/
Learn More
You can learn more about effectively applying the product owner role by attending my Product Owner Masterclass and by reading my books How to Lead in Product Management and Agile Product Management with Scrum.
Source: https://www.romanpichler.com/blog/five-product-owner-myths-busted/
