Photo courtesy of Rawpixel

Two Common Ways to Apply the Product Owner Role

Published on 25th October 2011 Last Updated on: 20 Feb 2023

Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when which option is more appropriate.

Option One: The Customer Plays the Product Owner Role

One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider–a member of the marketing group should take on the product owner role. For example, I play the product owner role for my company’s website, which is developed by an agency based in the south of the UK. This approach is illustrated by the following picture1:

Product owner and customer are the same person

Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs. I personally love being the product owner of

Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past (“IT never delivers”).

Option Two: A Product Professional Fills the Product Owner Role

Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who discovers the needs of the customers and users, and who listens to their ideas and requirements. But the product owner decides if and when a feature is released. The following picture illustrates this option:

Product owner role filled by a product professional

For commercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role. Note that picture above illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented.)

Advantages: Separating the customer and the product owner role helps create a product that addresses the needs of the entire target group. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively.

Challenges: Empowerment of the product owner can be difficult to achieve. Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners. (See my article Five Tips for “Introducing Product Management to Your Company” for more information.)

Post a Comment or Ask a Question


  • Paul Herwarth von Bittenfeld says:

    Hi Roman,

    we work with the second way as we are an agency and our teams work for different clients in a year’s time. They mostly are not able to provide a full time product owner. The big advantage of the second way is that we have skilled Product Owners that work very close with the team throughout the year. They build a real Scrum team and don’t have to restart the team building process with every new project. Like you said a big challenge is the empowerment of the Product Owner.


  • John Peltier says:

    Confusion about this leads to lots of problems, in my experience. Engineering wants a product owner who is present at most/all times, but for a product manager to fulfill that role and provide the vision and understanding required, they must be interacting with customers and can’t be sitting in engineering all day. Then you find a product manager working with a dedicated product owner, and there is more risk for communication gaps.

    Good way to point out the two models!

  • Stefan Roock says:

    I am not that happy with the wording “customer proxy”. My association is that such a PO would primarily collect what customers want and just prioritize the requested features. While I think listening to customers is crucial, just implementing what they request doesn’t create innovative products, or as Henry Ford stated it: “If I’d asked customers what they wanted, they would have said ‘a faster horse’.”

    • Roman Pichler Roman Pichler says:

      Hi Stefan, I don’t like the term customer-proxy either but I’ve used it for the lack of a better one. Is there a synonym with a more positive connotation? I completely agree that the product owner needs to have a vision of the future product – which should be validated by gathering customer and user feedback on early product increments / working software.

  • PM Hut says:

    Hi Roman,

    I like the way you are exploring the role of the product owner, and explaining who can embody the role…

    I would like to republish your post on PM Hut ( ), where a lot of project managers will benefit from it. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

  • Vin D'Amico says:

    I think that either approach can work and they share the same risk. There is always the chance that the Product Owner will get it wrong. The PO may misinterpret something the end users or stakeholders articulated. The PO may be biased in some way that leads the team down the wrong path.

    For these reasons, it is essential to deliver early and often so that the real users and stakeholders can see for themselves and offer feedback. If they are not available to do so, at least you made a good faith attempt to involve them.

    • Roman Pichler Roman Pichler says:

      Great point, Vin. I couldn’t agree more that early and frequent customer feedback is essential to develop the right product. I would add though that the product owner should have a vision that acts as the shared, overarching goal and that allows to evaluate the feedback received.

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.