What Does a Product Owner Do, When, and Why?

How do product owners get everything done? What does their process look like before projects begin, quarterly, and during each sprint? Why do they even do certain things?

Recently, on the Agile Mentors Podcast, Brian Milner played host to guest Mike Cohn, with a plan to get Mike Cohn’s insights on just that–what does a product owner do, when and why?

Brian explained his plan to Mike and asked, “Does that sound about right, Mike?”

“That’s what we agreed to do, but it’s not what I’m going to do!” Mike replied, laughing.

Mike went on to explain that he actually wanted to turn the tables on the podcast and interview Brian for a change.

As the mastermind behind The Definitive Guide to the What and When of Product Owner Responsibilities, Brian found himself in the hot seat. And he was ready, explaining not only what product owners do, and when, but why they do it.

A Product Owner’s Work Is Chronological and Cyclical

The Definitive Guide to the What and When of Product Owner Responsibilities is organized, quite naturally, by timeframe, considering the chronological and cyclical nature of the product owner’s responsibilities:

Chronological: Most projects are at least somewhat time bound, constrained by dates or cost (or sometimes both). All sprints follow a specific order of events, from planning to the retrospective.
Cyclical: Most projects contain multiple sprints, as well as a cycle of "larger than one sprint" check-ins and research activities.

Product owners are part of the Scrum team and vital to the work itself. At the same time, they serve as communication conduits between teams and stakeholders. Product owner responsibilities are spread throughout the project lifecycle to support a healthy pace and offer the flexibility to tweak the plan to better meet customer needs. Pro tip: There will always be tweaks to the plan.

To understand how and when a product owner’s work occurs and recurs during projects, it helps to unpack why the work is important. The responsibilities of successful product owners can be organized into six actions–each one containing a “why” and key activities occurring at certain times and a regular cadence. Podcast quotes from Brian provide further insight into why product owners take these six actions.

6 Actions of Successful Product Owners

Good product owners know what to do and when to do it. Great product owners understand why their responsibilities exist in the first place. They keep these six actionable pillars in mind throughout the project, from before a first sprint to the final launch.

1. Product Owners Understand the Market

To deliver the best product for their customers, product owners must understand customer needs and wants, and how competitors are addressing them. They should prepare to encounter challenges to their initial beliefs, and changes to where they fit in this evolving landscape.

Before the First Sprint

Analyze market trends and competition, especially for outward-facing products. Pay attention to how this challenges assumptions and tweaks product vision.
Figure out who users are and set up the big picture with a story map. Remember that story maps are living documents, and subject to change as understanding evolves.

Quarterly

Choose the next product goal as a guide for what to deliver, and in what order to deliver it.
Check on established story maps to see what needs adjusting.

During Each Sprint

Suggest a sprint goal and the backlog items that will support an understanding of customers’
Speak to actual customers throughout product development, and keep an eye on what competitors are up to.

“There is some behind-the-scenes, standard product work that we don't really account for in Scrum: Things like market analysis and trying to understand the competitive landscape. There's a whole discipline of activity and work that goes on behind the scenes.” - Brian Milner

2. Product Owners Know and Engage Stakeholders

Before product owners take the vision and story map to the team, they must define them with the stakeholders and organization. That doesn’t mean everything is set in stone, but it’s important to start building that relationship at the outset.

Before the First Sprint

Identify stakeholders, and seek their support for the product vision and plan.
Conduct a few rounds of story mapping with stakeholders, openly discussing that certain aspects may change as the team moves forward.

Quarterly

Revisit relationships with stakeholders, refining collaboration strategies and keeping excitement.
Address significant changes to the road map, emphasizing the team’s commitment to the product, even when that means altering well-laid plans.

During Each Sprint

Regularly meet with stakeholders for their input, feedback, and buy-in.
Facilitate prioritization meetings ahead of backlog refinement, including stakeholders in sprint reviews and retrospectives.

“I want to check in with my stakeholders, especially my key stakeholders, on prioritization so that it's not a surprise to anyone… I really think of the sprint review as the product owner’s event… It gives the stakeholders a chance to speak up and say, hey, what about this thing that I had that was really important?” - Brian Milner

3. Product Owners Maintain the Product Backlog

The product backlog is a living, breathing document, subject to change as product owners’ understanding evolves. No formula can reveal exactly how much should be in it at the start of a new project–the important thing is that it adapts along with the project.

Before the First Sprint

Establish the product goal, have a story-writing workshop, and create a product roadmap.
Write a backlog, but don’t get so caught up in it that there’s a delay getting started on the project itself.

Quarterly

Update the product roadmap, if necessary.
Know that some people will become attached to the existing backlog and roadmap, and struggle with changes. Reiterate that fluidity is vital and changes are healthy.

During Each Sprint

Ensure the backlog is up to date before refinement meetings with stakeholders.
At the review, look ahead at what’s coming up in the backlog in preparation for the next sprint.

“Maintaining a product backlog requires a series of activities. You might have multiple meetings that need to take place here… If I'm going to have the stakeholders come in and help me prioritize… I've got to have the stuff that's ready to go prior to that meeting. I can't just show up and go, let's see what we got in our backlog, and we'll just kind of wing it.” - Brian Milner

4. Product Owners Build Trust

Product owners need to prioritize trust with team members and stakeholders at every step and turn of a cycle.

Before the First Sprint

Set realistic expectations–it’s better to exceed them than to fall short.
Use tools like story maps and roadmaps to promote visibility into what the team’s creating and what might not make it into the final product.

Quarterly

Check in to see if the current plans reflect the current reality.
Track product economics and communicate them with the team and stakeholders.

During Each Sprint

Check in with the stakeholders on priorities, plans and progress.
Ensure that stakeholder input is reflected in the backlog.

“The story map is a living, breathing document.. It's constantly adapting and changing as we add new feature areas, as we understand differently how our users would interact with the product. We're going to adjust and change it. I want it to always reflect reality.” - Brian Milner

5. Product Owners Behave as Good Teammates

Product owners certainly have their own set of accountabilities that set them apart from the rest of the team. That said, product owners are definitely part of the team. It’s vital that they are present and participate with the team, not at them.

Before the First Sprint

From the beginning, involve future teammates, inviting at least some of them to estimating and story writing before the official launch.
Set a precedent of sharing a calendar, as appropriate, so team members can plan for important check-ins. Consider offering a guaranteed daily or weekly block of time when teammates can bring questions and concerns.

Quarterly

Work alongside the team in writing new stories and refining product goals and roadmaps.
Check in with and update team members on significant shifts in projects.

During Each Sprint

Participate in sprint planning, daily scrums, and sprint retrospectives and host sprint reviews.
Be available to refine backlog items, answer questions and highlight progress.

“Product owners are not somehow separate from the team. They are part of the team. So product owners have the same goal as everyone else, and that's to deliver as much value as possible to customers. On an ongoing basis, they need to touch base… Ask how are things on your end? How are things on my end? And how can we help each other to kind of achieve our goals here?” - Brian Milner

6. Product Owners Start Where They Are and Improve with the Process

Good product owners don’t get caught up in perfectionism. It’s better to start with the intention to improve than to delay getting started until every possible detail is set in stone. Product owners who take it one step at a time and walk alongside their team will get where they need to go.

“You typically know where you need to start. You know, there's a million things you could do. But when you have a big idea for a product and you're starting fresh and you're starting new with it, at least in my experience… I always know where I'm starting. And that's what I would encourage you to do is just get it out there, get it started. Even if you don't have all the different features and aspects of it thought through, that's OK. You just want to start making progress so you learn.” -Brian Milner

The Definitive Guide to the What and When of Product Owner Responsibilities. For a more complete look at all the sprint events, regardless of role, What Happens When During a Sprint is also available as a free download.

What Should a Product Owner NOT Do?

Mike’s final question to Brian might be the perfect way to wrap up the advice for product owners:

Mike: “What's the one thing you would tell product owners to not do?”

Brian: “Understand the boundary between the what and the how, and really try to stay out of the how. We're in charge, as product owners, of the what side of the equation. What is it that we're going to be doing? What are we focused on?

“The developers are in charge of the how. How do we accomplish this? What's the best way to deliver this?

“As a product owner in my past, I've always struggled with that balance of, yeah, but I've got a vision in my head of exactly the way I want it to play out. And I have to rein myself back in… My role is not to explain exactly how the page is going to need to look and exactly how this feature plays out. If there's not a legal reason or compliance that I've got to do it one way, then I want to, as much as possible, stay out of the house so that the developers really get to exert their expertise.”