Article
UX product owner: User-centric product development
Product Owner, User-Centered Product Owner, UX Product Owner: Do all three terms describe the same role, or are there differences? What benefits does a user-centered approach bring to the product, and what challenges have we encountered along the way?
Here, we’ll look at the different variants of the role, share our experiences, and discuss the added value of a user-centric approach in the role of Product Owner (PO).
User-centric: What does that mean?
It’s not just those involved in UX who know that software depends on acceptance by its users. Agile teams, in particular, have long been using user stories and similar tools to keep user needs in mind even during the development phase. However, it’s just as common in our day-to-day project work for these very tools to become empty rituals. We’re increasingly encountering user-focused product owners or requests for such roles. Over the years, we’ve come across three distinct variations of this role:
Product owner: the official definition
Scrum.org defines the Product Owner as the person responsible for maximizing a product’s value:
“A Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”
What this definition lacks, however, is a focus on users and how to address their needs. Scrum is meant for software in general, not just software with a user interface. And that doesn’t necessarily require a user-centric perspective.
This definition gives us a very broad perspective and does not prioritize one expert role on the team over another. We’ve found that tech-savvy POs, in particular, tend to align closely with this approach. Especially with software that doesn’t involve user interaction, goals can be achieved very efficiently.
In our day-to-day project work, we often find that products are completed but aren’t necessarily user-friendly. “Value” is assigned to user interaction rather hesitantly. We encounter this particularly when there is no hard metric at the end, such as “the user pays for something.”
User-centered product owner
“Being a user-centered product owner means advocating for the interests and needs of users. In addition, the product owner should be able to understand the technical implications of their product decisions. User acceptance plays a major role.”
When creating and editing tasks, the question “What value does this add for the user?” is always at the forefront of the discussion. This perspective enables the team to test features directly with users. Features start as hypotheses: some work for customers, while others need refinement before they are implemented.
We believe it is important to ensure that the conceptual, design, and technical processes are integrated and maintain an active dialogue with one another. The more the user-centered PO is interested in learning about users, the more the product, and thus the user, benefits.
We have also found that a duo consisting of a product owner and a UX designer can form an effective team when they collaborate.
User experience product owner
“A User Experience Product Owner possesses a solid set of UX skills. They also demonstrate a deep understanding of business, technology, and users. A UX PO is able to independently navigate the balance between user value and technical feasibility.”
Right from the start of a ticket, we as UX POs strive to prioritize the value created for users. If the value to the user is unclear, steps are taken to clarify it. This ensures that we do not use any expertise, including UX, to create product features that are unnecessary for the user.
As a UX PO, you’re not “just a UX person wearing a PO hat.” You identify blind spots in the user perspective, gather insights, and incorporate them into tickets and the backlog. Of course, this also means making compromises where necessary.
Choosing the right type of product owner for the task
Our experience shows that a PO who makes decisions based on user needs generates greater value for the project and the product:
- Tickets can be described in greater detail using findings from user testing.
- User feedback makes the value of individual tickets more tangible and measurable.
- The team works together as a whole toward creating a usable product.
- The final product meets the user’s needs and is accepted.
Although the idea of assigning a UX PO to every project is appealing, we’ve learned that the decision should be highly context-dependent. For example, if you want to enable the existing PO to take on the role of UX PO in the future, it makes sense to provide a sparring partner. This person supports the team as a UX designer and, at the same time, helps the PO make better decisions going forward.
In complex projects involving many teams, it can be challenging to fulfill dual roles: both developing concepts and managing the backlog. In such cases, we often recommend assigning an additional UX designer to the project.
There are different variations of the “Product Owner” role, but it is fundamentally important to us that the user has a say in decision-making.
About the expert
Jan helps companies establish UX frameworks. After several years working at Berlin-based startups, where he gained experience with rapid, iterative product development and international teams, he is now bringing his expertise in UX architecture, e-commerce, and user behavior analysis to the German market.







