Understanding the Product Manager and the Product Owner Role
Both Product Owner and Project Managers are management roles, who work with the team to accomplish a common goal: Bringing the project across the finish line. The requirement of a Project Manager or a Product Owner depends on the structure of the project and the philosophy on which it. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer. I’m always speaking to people who use Scrum as a type of project management.
With the wide scale adoption of Agile methods amongst software development teams, understanding the difference between the Product Manager and the Product Owner role is a frequent discussion topic in our Agile training course. To begin to explain the topic requires some framing.
First, we will look at Product Manager and Product Owner as roles, not titles.
The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team. Project managers develop, plan, execute, monitor, and close a set of activities to achieve a particular goal, such as the delivery of a service or product. They typically manage projects that are temporary, with a defined scope and resources.
The responsibilities of Product Managers and Product Owners vary widely by title and are often historic artifacts of a company’s heritage. Thus, many Product Owners perform Product Management responsibilities and many Product Managers perform Product Ownership responsibilities. In fact, one can perform both roles simultaneously. We will not even get into Business Analyst and Project Managers whose jobs often overlap as well.
Second, for the purpose of this post, we will define the Product Owner role as described in Scrum and the Scrum Guide.
Product Owner is a defined role in the Scrum framework and has specific responsibilities and authority. The Product Owner is responsible for the success of the product by maximizing the output of the development team.
The Product Owner is the sole person responsible for ordering the product backlog, which includes:
- Clearly expressing the product backlog items
- Ordering the items in the product backlog to best achieve goals and missions
- Optimizing the value of the work the development team performs
- Ensuring that the product backlog is visible, transparent, and clear to all
- Shows what the Scrum Team will work on next
To be a Product Owner, one must fulfill all of the listed responsibilities. The Product Owner may also perform many more responsibilities than listed above, but at a minimum the Product Owner MUST perform those five.
In contrast, a Product Manager may perform any subset of tasks within the discipline of Product Management.
These include business case development; being the expert on the market and the customer; product strategy, roadmap development, and positioning; whole product definition; feature, schedule, and cost tradeoffs; and value delivery through the ecosystem.
There is, however, no single task that defines or is guaranteed to be shared between all Product Managers.
Product Owner Project Manager Scrum Master
Thus, unlike a Product Owner that needs to perform ALL responsibilities in a narrowly defined list to be performing a Product Owner role, a Product Manager may perform ANY of the responsibilities in a broadly defined list and still be considered a Product Manager.
Comparing the responsibilities, Product Owners are more inwardly focused, working in greater detail with the engineering team than traditionally done in Product Management especially around developing stories and acceptance criteria.
Likewise, Product Managers tend to be more outwardly focused on the business case, portfolio management, full competitive analysis, win/loss analysis, forecasting, and end of life.
The roles tend to overlap in the areas of visioning and roadmaps, persona development, needs and feature definition, positioning, and defect management.
Because of this, although both the Product Manager and Product Owner are responsible for the business success of the product, the Product Owner’s main “levers” of influence are features and the order in which they are developed. A Product Manager has the additional “business” levers, often considered part of the whole product such as bundling, pricing, training, service levels, and channel offerings.
A final and subtler point is the measure of success.
A Product Owner’s job is to optimize value created by the development team, and to ensure the features of the product meet the customer’s need. Product Managers are responsible for the business case and ensuring that it is realized.
Of the two, Product Managers are more likely to advocate for funding.
Their conversation with management is “if you give me this funding, I will deliver you this business result.”
The Product Owner is more likely to be working on an approved project.
Their conversation with management is “If you are going to spend that money, I will ensure you get the most for your engineering dollar.”
In closing, it is important to realize the full spectrum of responsibilities that Product Managers and Product Owners perform are necessary for product success and each must be “owned” by someone who has both the time and skill set to manage them.
Watch this video from our Agile Excellence for Product Managers and Product Owners Online Course.
Want to learn more about the Product Manager and the Product Owner role and how the two should interact together?
Check out our new training course: Agile Excellence for Product Managers and Product Owners, available in-person or as an online course.
Download the first two chapters of Agile Excellence for Product Manager here:
Meet the Author
Greg Cohen is a 15-year Product Management veteran with extensive experience and knowledge of Agile development, a Certified Scrum Master, and former President of the Silicon Valley Product Management Association. He has worked and consulted with venture startups and large companies alike, and has trained Product Managers and Product Owners throughout the world on Agile development.
Greg is the author of the 280 Group’s Agile course as well as the best-selling Agile Excellence for Product Managers book.
Senior Principal Consultant and Trainer
Business people and developers must work together daily throughout the project.
Find a Course:The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.
The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user’s needs and comply with the Definition of Done. For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams).
This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders.
The PO is the member of the Agile team who serves as the customer proxy responsible for working with Product Management and other stakeholders—including other POs—to define and prioritize stories in the Team Backlog. This allows the Solution to effectively address program priorities (Features and Enablers) while maintaining technical integrity. Ideally, the PO is collocated with the rest of the team, where they typically share management, incentives, and culture. But the PO also attends the relevant Product Management events for planning and Program Backlog/Vision refinement.
The PO fulfills the following duties:
Product Owner Project Manager Responsibilities
Preparation and Participation in PI Planning
- As a member of the extended Product Management team, the PO is heavily involved in program backlog refinement and prep for Program Increment (PI) planning and also plays a significant role in the planning event itself. Before the planning event, the PO updates the team backlog and typically reviews and contributes to the program vision, Roadmap, and content presentations.
- During the event, the PO is involved with story definition, providing the clarifications necessary to assist the team with their story estimates and sequencing. The entire Agile team, which includes the PO, also work together to determine their team PI objectives for the upcoming PI.
- Maintaining the team backlog – With input from System Architect/Engineering and other stakeholders, the PO has the primary responsibility for building, editing, and maintaining the team backlog. Consisting mostly of user stories, it also includes defects and enablers. Backlog items are prioritized based on user value, time, and other team dependencies determined in the PI planning event and refined during the PI.
- Iteration Planning – The PO reviews and reprioritizes the backlog as part of the prep work for Iteration Planning, including coordination of dependencies with other POs. During the iteration planning event, the PO communicates story detail and priorities and ensures the team aligns and agrees on a final iteration plan.
- Just-in-time story elaboration – Most backlog items are elaborated into user stories for implementation. This may happen before the iteration, during iteration planning, or during the iteration. While any team member can write stories and acceptance criteria, the PO maintains proper flow.
- Apply Behavior-Driven Development (BDD) – POs collaborate with their team to detail stories with acceptance criteria and examples in the form of acceptance tests. See the BDD article for more details.
- Accepting stories – The PO works with the team to agree on accepted story completion. This includes validating that the story meets acceptance criteria, that it has the appropriate, persistent acceptance tests, and that it otherwise complies with its Definition of Done (DoD). In so doing, the PO also assures a level of quality, focusing primarily on fitness for use.
- Understand enabler work – While POs are not expected to drive technological decisions, they are supposed to understand the scope of the upcoming enabler work and collaborate with System and Solution Architect/Engineering to assist with decision-making and sequencing of the critical technological infrastructures that will host the new business functionality. This can often be best accomplished by establishing a capacity allocation, as described in the Team Backlog article.
- Participate in team demo and retrospective – POs collaborate with their team and any other stakeholders in the team demo. They also participate in the Iteration Retrospective, where the teams gather to improve their processes and are active in the Agile Release Train’s (ART’s)Inspect and Adapt (I&A) workshop.
- Iterations and Agile teams serve a larger purpose; the frequent, reliable, and continuous release of value-added solutions. During each PI, the PO coordinates dependencies with other POs. This often occurs in weekly PO sync events (see the PI article for more information).
- The PO also has an instrumental role in producing the System Demo for program and Value Stream stakeholders.
Inspect and Adapt
- Teams address their larger impediments in the I&A workshop. There, the PO works across teams to define and implement improvement stories that will increase the velocity and quality of the program.
- The PI system demo is part of the I&A workshop. The PO has an instrumental role in producing the PI system demo for program stakeholders.
- To ensure that they will be able to show the most critical aspects of the solution to the stakeholders, POs also participate in the preparation of the PI system demo.
SAFe leverages a number of artifacts such as Features, Stories, Non-Functional Requirements, design artifacts, and so forth, to guide the ART in creating the solution. Program and Team Backlog(s) govern the prioritization of these work items. They are managed by the Product Manager and the Product Owner who provide the content authority of their respective backlogs. This is a highly collaborative relationship that works most effectively when Design Thinking and Continuous Exploration tools such as Personas, Empathy Maps, Customer Journey Maps, Story Maps, are used to promote insight and understanding.
Figure 1 provides some guidance on how to delineate the responsibilities across these roles. Depending on the solution’s size and architecture (and to some degree the organization’s culture), authority for these items can become more decentralized, shifting them to the right. For example, stable Agile Teams who become increasingly knowledgeable about the customer’s problems and the solution context are capable of directly contributing Features and Stories to Product Management (see SAFe Principle #9 – Decentralize Decision-Making).
Fan-Out Model of Product Manager, Product Owner, and Agile Teams
Successful development is, in part, a game of numbers in the Enterprise. Without the right number of people in the right roles, bottlenecks will severely limit velocity. Therefore, the number of Product Managers, POs, and Agile teams must be roughly in balance to steer the ART. Otherwise, the whole system will spend much of its time waiting for definition, clarification, and acceptance. Instead, SAFe recommends a fan-out model, as illustrated in Figure 2.
Each Product Manager can usually support up to four POs, each of whom can be responsible for the backlog of one or two Agile teams.
Product Owner Vs Project Manager
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 10 February 2021