Product Owner Role and Responsibilities

What is the Role of Product Owners in Scrum?

What is a product owner? The role of a product owner in Scrum is to work with stakeholders to create a vision of the product they wish to create and communicate that product vision to the Scrum team and stakeholders. It is one of the key roles in Scrum, along with the Scrum Master and the cross-functional product development team.

Product owners have many responsibilities/accountabilities. Inside the Scrum framework, one accountability of the product owner is creating and maintaining the product backlog, which is an evolving list of desired features for the product, typically ordered by priority and often written as user stories. Others can write stories, split stories, and suggest new product backlog items. At the end of the day, however, the product owner's job is to manage the product backlog, ensuring it reflects the current understanding of what the end product should be.

Product Owners Order the Backlog & Create the Product Roadmap

One activity the product owner engages in, therefore, is to keep the product backlog in order and always be looking a few sprints ahead to ensure the product backlog items are ready for the team to bring into a future sprint.

They also collaborate with the team and stakeholders to create a product roadmap, a developing and changing picture of what will be delivered, and when. This roadmap helps remind everyone of the strategic destination, so that they don’t get lost in the day-to-day details of a project.

Free Product Owner Resources

No Matter the Job Title, Product Owners Are Empowered

Product owners sometimes carry different titles in their organization depending on their other responsibilities, such as management roles (e.g., no need to debate product manager vs product owner). But no matter their job title, they must be empowered to make decisions (in collaboration with their stakeholders) so that the team always knows they are building the right thing, for the right people, at the right time.

Product Owners Decide What, Not How

On agile projects, the product owner is responsible for product strategy: what gets created, and in what order.

Product owners are not, however, responsible for the development process (how the features are created)–the team has that accountability–or exactly how much work the team brings into each sprint. (They can make some architectural decisions, however,)

As part of release planning, and as an ongoing part of product backlog refinement, the team estimates the effort required to create each feature, and uses that estimate to help determine how long it will take to release some set of value to the customer.

During sprint planning, the team selects the amount of work they believe they can do during each sprint. The product owner does not get to say, "We have four sprints left, therefore you must do one-fourth of the product backlog this sprint.

Product Owners Set Clear, Elevating Goals

A key component of the role is to motivate the team with a clear, elevating goal. In fact, it’s essential for being effective. They are also responsible for describing the what and why of each feature to the team during formal and informal conversations throughout the sprint. That's why it's so important that they are readily available to their teams: their quick answers and clarifications help the team inspect and adapt in real time to ensure they are building the right thing.

In return for the Scrum team's commitment to completing a set of product backlog items each sprint, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint.

Once the team starts on a sprint, it remains maniacally focused on the goal of that sprint.

How Do You Become a Product Owner?

Who is a product owner and how do you become one? Historically, the product owner is a project's key stakeholder. They might be a lead user of the system or someone with a marketing, product development, or user experience background. In essence, they can be anyone with a solid understanding of users, the marketplace, the competition, and future trends for the domain or type of system being developed.

This, of course, varies tremendously based on whether the team is developing commercial software, software for internal use, hardware or some other type of product. The key is that the person in the role needs to have a vision for what is to be built.

Product Owner Requirements

The product owner role requires an individual with certain skills and traits, including availability, business savvy, and communication skills. (Some also have technical skills, but it is not a requirement.)

• Product owners need to be available to their team. They show commitment by doing whatever is necessary to build the best product possible–and that means being actively engaged with their teams.
• Prodcut owners need to be business savvy. The agile PO must understand the market, the customer, and the business in order to make sound decisions regarding what features the product will have.
• POs need to be good communicators. They work closely with key stakeholders throughout the organization and beyond, and the news they have to share isn’t always what the stakeholders want to hear. As such, they must be able to communicate different messages to different people about the project at any given time.

Scaling the Product Owner Role

The role is a big job, with competing inward-facing and outward-facing needs. For this reason, some larger organizations create product owner teams, or hierarchical layers, including a chief product owner.

Product Owner Training

Most new POs (and many who have been doing the role for some time) find role-specific training to be helpful in learning how to be successful.

At Mountain Goat Software, we offer the Scrum Alliance Certified Scrum Product Owner^® certification (CSPO^®) and the Advanced CSPO.

We also offer live onliine and video training in specific PO skills, such as writing better user stories, estimating with story points and agile estimating and planning.

You can even get coaching on user story-writing workshops.

Training for Product Owners

Product Owner vs Project Manager

Some POs and Scrum Masters come from a project management background. Project managers who want to make the transition to product ownership need to keep a few differences in mind.

• A project manager sits outside the team. A product owner is a member of the Scrum team.

• A project manager is responsible for the success of the project. The entire Scrum team is responsible for the success of a product.

• Some project managers have direct management responsibility of team members. Product owners typically do not have direct reports on the Scrum team.

• Project managers determine project plans and deadlines, and assign work accordingly. POs rely on their teams for accurate estimate ranges, and communicate the range of functionality that the team will deliver by a certain date, based on their current understanding of the product.

• Project managers attempt to deliver a predefined project by minimizing changes. POs inspect the product at the end of each sprint and adapt product features and plans based on what they learn.

Project managers can make good product owners if they are willing to forgo some of their traditional responsibilities and empower the team more than in a traditionally managed project.

Product Owner vs Scrum Master

The primary difference between a product owner and a Scrum Master is that product owners are focused on the product; Scrum Masters are focused on the process the team uses to create that product. Product owners should not be Scrum Masters; and Scrum Masters should not also be POs. Those roles should remain distinct from one another.

Product Owner vs Business Analyst

Product owners are often busy as the role can be time consuming. The most common way of augmenting their capacity is by adding one more or business analysts or system analysts to the team.

POs often delegates to the business analyst responsibility over the functionality in one or more areas of the product.

In tax preparation software, for example, the business analyst may be tasked with understanding new laws around depreciation. The analyst would research the topic and write the necessary product backlog items. In most cases, the product owner will retain authority over prioritizing work identified by the analyst.

Business analysts sometimes make the transition to product ownership; others prefer to be team members, where they can use their backgrounds to help split user stories and uncover hidden requirements.

Should Teams Designate a Technical Product Owner?

A common mistake on agile projects is having both a regular, business-oriented product owner and a so-called technical product owner. The theory is that a technical PO would be consulted on all technical issues, and a business PO would be consulted on all functionality issues.

But teams rarely encounter issues that are entirely technical or entirely functional. Most issues blend technical and functional considerations.

Most importantly, though, the product owner is the owner, not the co-owner. There cannot be two; only one.

Agile projects should not have two people in one role. To do so dilutes the authority of the one rightful PO and creates confusion in team members, who are left wondering which person to talk to about various issues.

What then is the correct role of the would-be technical product owner? They should be considered a stakeholder. A stakeholder is any person or group who has the right to influence a project or is affected by the project.

By that definition, an architect or senior technical person is really a stakeholder. And it’s vital that a product’s one and only product owner considers the opinions of all stakeholders, including those of architects or senior technical people

The Whole Team is Responsible for a Product's Success

I occasionally hear two statements about product owners that I strongly disagree with. These statements are that they are "the single wring-able neck on the project” or that they are “the one throat to choke.”

These each mean the same thing, that in an agile project, the product owner is the person ultimately responsible for the success of the project. This is wrong, however.

On an agile project—as well as in many other cases—there is no single, wring-able neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.

From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” However in agile project management the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.

Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? Is it the coach, the owner, the star player?

Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wring-able neck.

Consider a non-sports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.

The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.