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.

Myth #4: The product owner is responsible for writing user stories

User stories are a popular technique to capture end-user functionality. But as product owner, you are not a user story scribe or a product backlog manager. Refining the product backlog and writing user stories is teamwork: The development team members should actively contribute to removing, changing, and adding backlog items, as well as breaking larger stories into smaller ones. You might even delegate some of the refinement work to the dev team, assuming that people are happy and appropriately skilled to take it on. 

But it is important that you don't neglect the product backlog work, as the following story shows. A few years ago, I worked with an organisation that has become a leading provider to hire trusted handymen in the UK like plumbers and electricians. Their product owner asked me for help telling me that the dev team would always over-promise and then under-deliver. After looking at the product backlog—which consisted of a collection of adhesive notes on an office wall at this time—I quickly realised why the team was struggling so much: The backlog contained only epics, big, coarse-grained user stories but no detailed, ready items. Development teams, however, need sufficiently detailed product backlog items to be able to create a realistic forecast for what can be done in a sprint and succeed in meeting the sprint goal. If the items are too big and coarse-grained, most teams will struggle. 

Therefore, strike the right balance between strategic and tactical work and spend enough time working on the product backlog together with the development team members. As the product owner, it's your responsibility that the work required to progress the product and reach the (next) product goal is adequately captured in the product backlog. Such a backlog has enough “ready” high-priority items to guide the work of the development team and to allow its members to create a “done” product increment—executable software that is tested and documented and that could be released.

Myth #5: It’s the product owner’s job to get the project delivered

Unlike traditional approaches to software development, Scrum does not offer the role of a project manager. It can therefore be tempting to view the product owner as a project manager substitute. But this would be a mistake. Project management is collectively practiced in Scrum rather than carried out by an individual. What’s more, the product owner is a product management role responsible for managing the product and achieving product success—not for delivering a project. This requires the product owner to look after the product on a continued basis and manage its life cycle—or at least large parts of it. To put it differently, you can think of the product owner as a product life-cycle manager, which encourages decisions that result in sustainable growth and consider the product’s longer-term impact on the users and the business. The picture below illustrates this concept.

The picture above shows how a product might create value over time together with three key events: launching the product, achieving product-market fit, and retiring the product (end of life). Only once it has achieved product-market fit (PMF) and entered the growth stage, has a product started to become successful. A product owner should therefore look after a product at least until PMF, preferably longer.

Contrast this with the job of a project manager who is responsible for delivering a project to an agreed scope on time and on budget. Once that’s been achieved, the project manager’s work is done, and the individual often moves on and works on another project, which might progress a different product. A project manager is therefore focused on a comparatively short-term effort instead of a longer-term outcome.

Therefore, avoid being a project owner but aspire to manage your product for an extended period, ideally for its entire life cycle. This does not imply, however, that you should not care about meeting a specific product goal in a realistic timeframe on an agreed budget. The opposite is the case: Use the release planning tools and techniques that work for you to track and guide the development progress. But create a continuity of purpose by working with a product roadmap like my GO roadmap that captures the specific outcomes the product is likely to create in the next six to twelve months.

Learn More

You can learn more about effectively applying the product owner role by attending my product owner training course and by reading my books How to Lead in Product Management and Agile Product Management with Scrum.