What does a product owner need to do?

This post is dedicated to my mother. I wrote it so she finally has something to point people to, whenever they ask her what my job is. 😅

Jokes aside, this week it’s all about “What does a Product Owner do?”. It’s the second installment of the series on the Product Owner. We have established what pain points the PO solves, why the role is needed in last week’s edition of The Backlog. After this week’s text, after explaining what a PO does, it will become even clearer how the PO role addresses those pain points.

By the way, even if you are not using Scrum, this post can still help. Giving project or team leaders using other methods of development the responsibilities of a PO will have the same benefits. I want to encourage you to give it a try.

Email address:

Leave this field empty if you're human:

The many jobs of the product owner

A PO has many responsibilities, too many to mention them all here. I will focus on the three that are in my view the most important.

• Defining the product
• Understanding users
• Stakeholder management

Defining the product 

If you are a PO I suspect that this is what most of your time is spent on, it certainly is for me. Maybe that’s not how it should be – one could make a good argument that most of the time should be spent on understanding users – but in my experience talking to other POs, it seems to mostly be the case. After all, the title of the role is Product Owner!

Defining the product entails a lot! 

Vision, strategy and roadmap

First and foremost the PO is responsible for creating a compelling product vision. This doesn’t mean that the PO necessarily has to create one alone.The development team, leadership, or other stakeholders and users can be heavily involved. However, he or she is the one making sure a vision is created and that this vision is informing product decisions.

Closely related, the PO is also responsible for the strategic plan. Most of the time, this will be in the form of a roadmap. If for nothing else the roadmap should be created out of self interest since it’s a very good tool to employ when explaining what is prioritized and what is not.

Backlog maintenance

Coming from the vision, through the strategic plan, all the way down to what the team is actually working on, the PO is responsible for maintaining the Product backlog. Again, usually the PO gets a lot of help from the team, the Scrum Master, and others. In the end though, it’s his or her responsibility to make sure the backlog is maintained and fitting the roadmap and vision.

Maintaining the backlog means first and foremost filling it, i.e. translating business and customer needs into requirements that can be implemented by the team. In the world of Scrum this is writing and refining user stories.

The PO is then the sole person who is responsible for prioritizing the backlog items. He or she decides which stories are the most important ones. He or she decides what stories or tasks should be included in the next product iteration. The PO is ultimately the one person that makes the decision on what gets developed, the one who defines the product and with that greatly impacts the effectiveness of product development. 

Story acceptance

While implementing the requirements, during the actual product development, I have found it very useful for the PO to accept stories before releasing them to customers. Now, it doesn’t necessarily have to be like that. The team can also test and accept stories themselves if they are completed according to a proper definition of done. 

However, I have found it very useful to have this final quality check from the PO. Personally, I usually do some random testing and many times have found some edge cases that were not covered. 

It is extremely important to note that this only works if the PO is available. We want to create value as fast as possible and it cannot happen that something is fully developed but not deployed for a week because the PO had a lot of meetings (or even worse because we only deploy stories after the review). The PO cannot be the bottleneck.

Decision maker

As with accepting stories, the PO is also at risk of being the bottleneck when it comes to decision making, the final and very important responsibility within defining the product. 

The PO is the final decision maker on all questions related to the product. Of course, the responsibility can be delegated and decisions can be taken jointly. However, in the end it is the PO that must decide. 

Very often during the sprint, the team may have some questions regarding specific use cases or unclear requirements. The PO must then be available to answer them and make the needed decisions.

Understanding users

Even though most of the time of a PO is likely spent on defining the product, the most important responsibility might be understanding the users of the product. This is the prerequisite for creating the stories, for prioritizing the backlog, for deciding what the product will be. 

The goal is here to understand the needs, pain points, and desires of the users. This understanding is then used to ensure that what is developed satisfies the needs. It is the process of creating value for the user.

There are many ways to do this – design thinking, continuous discovery, surveys, interviews to name a few – and if you are lucky you have a UX team that can help. I am not a huge fan of surveys or market research interviews where direct questions are asked since users often say one thing and do something completely different. But they are surely better than nothing. 

I tend to think it’s best to watch users, either when they interact with your product or prototype, or when they use whatever technology is state of the art when they go through the process that you are trying to optimize or replace. That is where you get the real insights. 

Regardless, understanding users is the single most important thing needed to make informed decisions on what should be developed, how the product should be steered.

Stakeholder management 

If you as a PO are not spending most time on defining the product, chances are you´re spending it here in stakeholder management. Or to put it in less fancy terms you are spending it in meetings, so many meetings.

It’s natural for the PO to be constantly communicating with all kinds of different stakeholders. After all, he or she is the initial point of contact in all things product. He or she is the one who gets contacted for any and all questions. The PO acts as the linchpin or liaison between business and the development team. It’s the PO´s job to constantly understand not just the users wishes but also those of all other stakeholders and make sure that they are taken into account. 

The PO must actively communicate what is going on with the product, share the roadmap, and maintain buy-in to the vision. There is no law that says this must happen in zoom calls but it seems to be the norm. The important thing is that stakeholders are – or feel – informed. This is particularly important when discussing the things that are not done. 

Most of the time, a PO will be saying No to requests nine times for every one Yes, since we generally have limited resources but seemingly endless options of things to implement. Saying no to requests is not at all easy but so important. Doing this in the right way provides some real benefits, though.

Connecting the why and what of the PO

In the previous edition of the backlog, we established why the role of PO is needed. It greatly impacts efficient and effective product development. The explanation of what a Product Owner does, makes it even clearer how he or she impacts this. 

Having the sole responsibility of the product requirements and their prioritization coupled with a deep understanding of customers’ needs, means the PO can greatly impact the effectiveness in product development. He or she ensures that the right things are developed at the right time to maximize the value the product brings.

With the PO being the single point of contact in all things product and constantly communicating with stakeholders, the team doesn’t have to do so. As such, they can focus on actually developing instead of being interrupted all the time. The team can efficiently create value for users. 

Cover Photo by Cookie the Pom on Unsplash