Product Owner

Introduction

The product owner is the pivotal role in enabling the seamless flow of development from value to product.

The product owner is the person who connects two key functions and associated groups of people: the ones who identify what value is needed (the business) and the ones who determine how and implement it (development team).

• To the development team, the product owner represents the enterprise business value and the needs of program/product level stakeholders, defining and prioritizing the team backlog, and continuously optimizing the user experience, in collaboration with all stakeholders..
• To the business, the product owner represents the development team: the value that has been realized and the needs they have.

The product owner is the proxy for the customer, the go-between for those who define value at the minimum business increment level, primarily product managers, and those who implement value into working software, the development teams. Seen this way, the product owner is like the transmission of a car.

• The engine of the car represents those who define the value. The wheels represent those who implement value. The transmission represents the product owner, the one who connects the engine to the wheels by answering the development team’s questions about the value they will implement.
• The product owner is the team’s primary source for insights into customer and stakeholder motivation. The product owner helps the team know what the end customer or the enterprise is expecting of their products or services, what is involved in realizing value from the product or service.
• The product owner facilitates conversation between the customers and stakeholders and the team, allowing feedback about implementation issues and technical alternatives, ways to simplify an implementation, progress and impediments they are facing, and so forth. 

A Note About Roles

As stated in People first: Roles in DAD,

• On a DAD team, any given person will be in one or more roles, an individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time.
• Roles are not positions, nor are they meant to be. For example, there may be many stakeholders of your project and none of them is likely to have a position of “stakeholder.”
• Agile de-emphasizes specialized roles and considers all team members equal – everyone pitches in to deliver a working solution regardless of their job description.

For information, see People first: Roles in DAD

Focus

The product owner provides the critical connection between those who define value and those who implement it. The product owner makes it possible for the teams to produce the value that the enterprise needs.

Responsibilities

The product owner role is responsible for the following:

• Be available to the team to answer questions.
• Help the team understand each story and its acceptance criteria.
• Manage and refine the team backlog as needed.
• Sequence the work on the team backlog to reflect value realization and priorities. (This is related to to managing the backlog but represents a different perspective.)
• Assess and accept work completed.
• Work with release management. The product owner attends to many aspects of release that are required for value realization and that are not usually part of the team’s responsibility including marketing, support, timing, priority, pricing, training, communication.
• Identify and gather needs and priorities from customers to guide continuous product improvement, providing ownership of product vision and translations of vision into tangible objectives that meet key performance indicators and metrics for the health of the application.
• Channels the voice of the customer to guide development teams in building software with highest value and customer impact.
• Facilitates decision-making and prioritization among the various stakeholders.

• Acceptance test-driven development
• Capturing functional requirements
• Controlling work-in-process (WIP)
• Daily coordination
• Decomposing a feature into stories
• Estimation
• Iteration demonstration and review
• Iteration demonstration and review (plan)
• Iteration planning meeting
• Iteration retrospective
• Operational metrics
• Unfinished work
• Visual controls

• Considerations for DAD teams
• Considerations for daily coordination
• Considerations for value streams 

• Evolve way of working
• Minimum business increments
• Roles in DAD
• Disciplined Agile Delivery (DAD)

• Agile metrics

In Disciplined Agile, context counts. Each organization and each team can have its own ways of working. Please treat the articles in this reading path as a starting point. Adapt the content to fit your context. Please provide your feedback if you have suggestions for how to improve them.