Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Creating Product Owner Success

Creating Product Owner Success

This item in japanese


The role of the Product Owner in Scrum is powerful but can be challenging to apply: companies that succeed at it will benefit from a new and healthy relationship between customers (product management) and development, and are likely to experience a competitive advantage. This comes at a price: the effective application of the role often requires organizational changes. This article provides insights into how the Product Owner role can be applied successfully. It helps you understand what it takes to succeed as a Product Owner.

Super Glue

The Product Owner in Scrum plays an important part. Far from being a new name for an old job, the role redefines the relationship between business and development/IT. Requirements are no longer completely described at the beginning of the project, frozen and then handed over to development. The management of the project is no longer delegated to a project manager, with the customer representative disengaging from the process. Instead, the Product Owner communicates the customer needs, guides the release and collaborates with the team and the stakeholders on an ongoing basis. You could say that the Product Owner acts as the glue between end-customers, product management, development and stakeholders, creating alignment by making sure everyone is pulling toward the same goal.

Since the role is typically filled by a customer or product manager, the business has to embrace Scrum too, and make the changes necessary to adapt to it. This may be challenging, but results not only in a healthier relationship between business and development/IT but can also give you a competitive advantage: customer needs are effectively communicated; one person is responsible for defining the release goal and for taking delivery of it; the decision making process is speeded up, misunderstandings and misalignment are avoided.

Job Description

Let's have a look at the Product Owner responsibilities in more detail. There are three major areas: Customer needs, project success and collaboration.

The Product Owner in Scrum is responsible for understanding and communicating the customer needs. You can think of the Product Owner as an entrepreneur: Someone who develops and communicates the product vision together with the value proposition of the software. The Product Owner fills the product backlog and refines its contents on an ongoing basis: new requirements are added, existing ones are refined - typically just-in-time, before the next sprint planning meeting. Additionally, the Product Owner prioritizes the product backlog, ensuring that the most important requirements are always being worked on.

Project success is the Product Owner's second area of responsibility. This includes meeting the project goal and financial targets such as return on investment (ROI). The Product Owner decides on the functionality, the release date and the budget to maximize customer satisfaction and ROI. The Product Owner also creates and updates the release plan and the release reports.

Last but not least, the Product Owner collaborates with the team and aligns with the stakeholders throughout the entire release. Product Owner and team typically detail requirements together. The Product Owner also clarifies requirements when questions arise and reviews the work results using the agreed-upon “done” criteria. Finally, the Product Owner prepares for the sprint-planning meeting. This includes an exercise of progressively decomposing requirements prior to the meeting, thereby creating a smooth flow of work.

Filling the Product Owner role is typically a full time job, particularly when the project exhibits a higher degree of innovation or complexity. The role may be filled by an end customer, product manager, marketing employee or a customer depending on the nature and size of the project.

Common Pitfalls

Let's be honest: Filling the Product Owner role can be challenging. As a consequence, I see a number of common pitfalls in how the Product Owner role is implemented. Here is a selection of my favourite ones.

Some organizations find it difficult to fill the role with one person. To address the issue, the Product Owner responsibilities are spilt across multiple individuals, for instance, a product manager taking on the customer needs responsibilities and the ScrumMaster taking on the project success and collaboration responsibilities. I call this pitfall the Virtual Product Owner Syndrome. By falling into this trap, companies lose most of the power of the Product Owner role and miss out on a massive opportunity of changing for the better. Having several individuals practising product ownership does only make sense if multiple teams work on the same project. In this case, I tend to work with a team of Product Owners with one individual being in charge of the entire project (sometimes called the Chief Product Owner).

Another common pitfall is having an IT or development member filling the Product Owner role. This is often a sign that product management or the end customer is not willing to change and to take on the Product Owner responsibilities. The IT Product Owner is a mere go-between for the techies and the business. The original power of the role is lost; customer needs are no longer understood and communicated by one person. The changes necessary in the collaboration between the business and development/IT do not take place. The relationship is not improved. The business is likely to continue to hand over requirements and then disengage from the development process. (Having said this, if you run a multi-team project that employs a component team, having an architect fill the role of the Product Owner who looks after the component team may make sense.)

And finally there is The Bungee Product Owner (its name inspired by Dilbert, of course): a Product Owner who is hardly available and who just about makes it to the sprint planning and review meetings. Such a Product Owner will find it difficult to actively steer and guide the project. Many open questions will simply be answered by the the guesses or assumptions of the ScrumMaster or the team. Others will block project progress. No matter what the reason is - being overworked or having other priorities - a Product Owner that is not properly available negatively impacts the release.

The Success Formula

How can you avoid the pitfalls sketched above and succeed in implementing the Product Owner role? There are three things that I have found to be crucial:

  1. The Product Owner must be empowered.
  2. The individual must have enough time to do the job, and
  3. The Product Owner must be properly qualified.

In my experience these factors are critical; I have observed a strong correlation between an empowered, available and qualified Product Owner and a successful and healthy Scrum project.

Empowerment means having the authority to make decisions and taking on responsibility for their consequences. It entails being able to make the relevant decisions quickly, without getting approval from management every time a decision has to be made. I frequently see companies underestimate the importance of the Product Owner role. As a consequence, the Product Owner is not granted enough authority. If the Product Owner leads an important project, the individual should be sponsored directly by senior management. Additionally, the Product Owner should be actively involved in setting the release goal. This allows the individual to be fully responsible for reaching the goal.

Poor availability ultimately impacts the project's productivity. Necessary prep work does not get done and decisions are delayed. As pointed out above, Bungee Product Owners that can only attend sprint planning and review meetings will find it difficult to answer questions promptly and thoroughly. They will miss out on a continued collaboration with the team and weaken their ability to steer and guide the project.

Having the right qualifications implies two things: A thorough understanding of customer needs, and a working knowledge of Agile and Scrum. The latter includes being able to implement relevant practices such as filling and refining the product backlog effectively, or describing requirements in the form of user stories. Product Owners need to be properly trained in Scrum to do their job well - just like ScrumMasters. Often, a combination of a Certified Scrum Product Owner™ course and on-the-job training/coaching works best.

To enable the Product Owner to do an effective job you may want to try the following: Ensure that management is clear about the importance of the role and carefully selects individuals as Product Owners. Additionally, allow the individual to spend most of his time being the Product Owner, freeing the person from other duties. Last but not least, embrace a longer-term perspective: develop Product Owners - invest in those individuals so that they are prepared to take on the Product Owner role. This may include building up an in-house training and coaching capability.

Old News

Being a Product Owner is a rewarding but often a challenging job. Developing individuals that can work as effective Product Owners is equally challenging. Interestingly, Toyota, Honda and other lean companies have employed a Product Owner role successfully for quite some time. In fact, Toyota has done so for nearly half a century. Toyota calls its Product Owner the “Chief Engineer” since the individual filling the role is a highly regarded senior engineer. The Chief Engineer shares most of the Product Owner responsibilities stated above but additionally is the chief architect of the development project. Even though being a Chief Engineer is even more challenging than being a Product Owner in Scrum, Toyota has so successfully used the role that it has become a cornerstone of its powerful lean development system. As Toyota's example shows, the Product Owner role can become a competitive advantage if a company is willing to make the necessary changes.


No doubt: Applying the Product Owner role can be difficult, but its proper application is a must to apply Scrum successfully. Resist the temptation to adjust the role, to weaken it so it can be easier applied. Rather, use any issues and impediments to drive the necessary organizational changes that help the enterprise to improve. Companies leveraging the role can gain a competitive advantage. Making all the necessary changes is likely to be hard work and may take some time, though. Unfortunately, I have not yet discovered the Scrum pixie dust that magically brings about change. I will let you know though, if I ever discover it. Promise.


James M. Morgan, Jeffrey K. Liker. The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006

Roman Pichler. Scrum - Agiles Projektmanagement erfolgreich einsetzen. dpunkt. 2007

Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004

Allen C. Ward. Lean Product and Process Development. Lean Enterprise Institute. 2007


Roman Pichler works as a management consultant specialized in Lean Thinking and Scrum. He is the author of the book “Scrum - Agiles Projektmanagement richtig einsetzen” (dpunkt 2007). Roman has been working with Product Owners for many years. He offers dedicated training and coaching for Product Owners including Certified Scrum Product Owner courses. See for more information.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Having an IT team member as the PO

    by Richard Cowin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In the article you state that having an IT team member fulfill the PO role is a common pitfall, however in the exemplar case of Toyota, the PO is an engineer. Is this not contradictory?

    I work in a very small IT team in a small enterprise, and we often double up on roles. Personally I work as PO, SM architect and developer - though not so much of the latter.

  • Re: Having an IT team member as the PO

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Richard,

    The Product Owner role has similarities with Toyota's Chief Engineer (CE) but the two roles are not identical. At Toyota, the CE is sponsored by senior management and given the authority to lead the project and create alignment across the different departments involved in product development. It is not the case that product management or marketing writes up a spec, hands it over to the CE and the CE executes the project. On the contrary: The CE is involved in market research and creates the product concept.

    If it works for you to combine the ScrumMaster, Product Owner and architect role in one person, great. More often than not, I find it problematic to have a Product Owner from IT particularly when the company has a separate product management or marketing group: It shields product management/marketing from the necessary changes. It results in product management/marketing continuing to carry out market research and describing high-level requirements that are handed over to the Product Owner. The consequence is a broken value stream with lots of waste and overburden. You may want to think about how you take the Product Owner role forward as your company grows.

    Best regards,


  • IT is reinventing the wheel over and over ...

    by Michael Planchart,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The role you describe is precisely that of a project manager.

    Before we start creating new roles and titles why don't we look into well proven methods that are field neutral from both IEEE and PMI?

    It's just like the software architect role. This is also a renaming of the well-known software designer role.

    I have no problem in embelleshing titles and roles with new adjectives, but let's not create a whole school or movement around them.

  • Re: IT is reinventing the wheel over and over ...

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Michael,

    Unfortunately, you have not understood what the Product Owner role is all about. Must be my poor writing :-) The Product Owner is a hybrid of a traditional product manager/customer representative and a project manager. The Product Owner creates the product vision, defines requirements and is responsible for making the release a success.

    There is no project manager in Scrum. This does not mean, though, that the individuals who used to work as project managers are no longer needed. The opposite is true: Former project managers often become good Product Owners or ScrumMasters.

    Best regards,


  • Re: IT is reinventing the wheel over and over ...

    by Cedric Bertolasio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ok, I get the role of the product owner. Great article, by the way. My question is this... "Should the product owner ever define more than one common goal for the sprint?"

    When our product owner defines the goal for our sprint, they often create a composite theme / goal : "e.g. Enhance feature X, and implement new feature Y". IMO, this creates silos and breaks up the direction of the team.

    What are your thoughts?

  • Re: IT is reinventing the wheel over and over ...

    by Michael Planchart,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I understand your writing. You are very clear. I've been noticing that our industry is trying to redefine traditional techniques. The product owner that you mention on the customer side is the primary stakeholder. But the customer has more than one stakeholder and usually there are positive ones, those for the project, and negative ones, those against the project. The project manager should account for this and manage it accordingly.

    Maybe Toyota merged two different corporate cultures and came up with unique names for the roles. Here in the US we have traditionally followed the PMI and IEEE models which have been proven to be excellent tools.

    I think we should be careful in not revamping our models as we do our methodologies. Of course, if we are introducing something new and great may that be welcome.

    Like I said before. Everybody in our field decided to be an architect. We have a clear role for what they say an architect should do and that is a software designer. Now, even if you are an excellent designer you won't get heard unless you start using the myriad of buzz words that surround it.

    Michael Planchart

  • Re: IT is reinventing the wheel over and over ...

    by Michael Planchart,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Is your book available in english?

    I was attempting to order it but I couldn't find it.



  • Re: IT is reinventing the wheel over and over ...

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My book is not yet available in English unfortunately. You can order it at

    Best regards,

  • Re: IT is reinventing the wheel over and over ...

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I don't think there is one right answer to your question. It depends on the context :-) My preference would be to have one common goal for the entire team as you suggest. This creates focus and alignment and fosters collaboration. It avoids task switching and the creation of sub-teams.

    Sometimes it makes sense though to ask the team to wok on a few different items, for instance, implement new functionality and carry out maintenance work or explore new, uncertain requirements.

    Here is something you may want to try: Ask your Product Owner to discuss the goal he has in mind with the team prior to the sprint planning meeting. This allows the Product Owner to modify the goal and re-prioritize the product backlog if necessary. It enables the team to influence the goal and increases buy-in and ownership.

    Best regards, Roman

  • Empowerment

    by Lars Hammer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great article.

    I have a question regarding empowerment of the Product Owner. When I have a project steering committee, I always ask 3 empowerment questions:
    Can they stop the project?
    Can they change the budget?
    Can they change the scope of the project?

    Do you have similar demands you can put on a product owner?

  • Re: Empowerment

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Lars,

    Let me ask you a question to answer yours: What needs to be done to enable your Product Owner to maximize customer satisfaction and return on investment (ROI)?

    Here are some criteria for Product Owner empowerment:

    • Is the Product Owner involved in shaping the product vision?

    • Is the Product Owner involved in setting the release goal?

    • Can the Product Owner decide on the priority of the product backlog items?

    • Can the Product Owner steer the release by making trade-off decisions between functionality/scope, time and budget?

    Best regards,


  • Re: IT is reinventing the wheel over and over ...

    by Bachan Anand,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    + 1 , today I spoke to a Project Manager who successfully transitioned to Product Owner

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p