The Product Owner

The Product Owner (PO), is a position created during the early years when Scrum was conceptualized. The role and responsibilities materialized out of a reaction to heavy, big, up-front, rigid requirements gathering within traditional, heavily predictive, “waterfall” project management frameworks.

It is one of three main roles within Scrum: Development Team, Scrum Master and Product Owner. And, the role can be used within other Agile team frameworks (XP, Kanban, etc.).

The interesting thing about the PO is the intentional vagueness many use when describing who typically fills the role and what the PO actually does.

Over the next few blogs we will examine the details of what POs do, what skills they need to do their job well, how the PO role fits into the bigger picture of Product, Program and Portfolio management, and how the PO position may vary based on public vs. private sector, big vs. small organizations. Finally, we will spend some time comparing and contrasting the PO role to Business Analysts, Project Managers and other positions.

We will begin by taking a closer look at the name of the role: Product + Owner.

Product

A “product” is a good idea, method, information, object or service created as a result of a process and serves a need or satisfies a want. It has a combination of tangible and intangible attributes (benefits, features, functions, uses, etc.) that a seller offers a buyer for purchase. It addresses a problem or provides a benefit to a group of people. It is used as long as it proves to be useful (or profitable).

Products are not projects.

A project is a planned set of interrelated tasks to be executed over a fixed period and within certain costs and other limitations. Projects have a fixed duration. 

Why is this differentiation important? Because most state and federal agencies think of building software, systems and solutions as projects. This is evidenced in two ways:

  1. First, how the product, system or solution is treated at the beginning of an initiative is very telling. There is very little Product Management thought applied. What is the vision for the product? What are the goals for the product? What are the business objectives the product should deliver? What are the people, product, operational, and business metrics and KPI’s that tie the goals and objectives to value delivery?
  2. Second, how the product system or solution is treated at the end of an initiative is also interesting. Someone builds it, then hands it off to Maintenance and Operations with little thought about the potential benefits of ongoing learning and development–increasing the ROI. Designated ownership of the system is lacking. The system just exists with little effort to improving its value.

This evidence is juxtaposed with that software, system or solution being in existence for as long as it proves useful or as long as it provides value–that the product will continue to be improved, adding value to the users and organization.

POs by virtue of being product focused, are motivated by the responsibility and empowered with the accountability to maintain a constant long-term vision of how the product can and should deliver value to system users and the organization–regardless of whether the initiative is in the public or private domain.

Owner

The “owner” is a party that possesses the exclusive right to hold, use, benefit-from, enjoy, convey, transfer, and otherwise dispose of an asset or property. Furthermore, the owner can be an employee or executive who has the principal responsibility for a process, program, or project.

The PO “owns” the product on behalf of the organization. They should be EMPOWERED with the responsibility and accountability to make all product decisions (What’s that? No Change Control Board?). They can have strategic responsibilities (product strategy, roadmap, backlog, stakeholder relationships, financials, etc.) as well as tactical ones (backlog grooming, story writing, development team support, review and acceptance of stories completed by the team, etc.).

The image below (Pragmatic Marketing Framework) illustrates the general scalability of Product Management Responsibilities and how challenging it can be for POs to juggle because in many cases, depending on the size and type of the organizations, POs may be tasked with most or all of these responsibilities.

Product Management Responsibilities (Pragmatic Marketing.com)

However, most POs typically only execute a subset of these responsibilities (due to a number of factors). The responsibilities highlighted in gold are where most team-oriented POs focus their attention. Broadly speaking, it should be clear that the PO position likely morphed out of the Product Management role and not Business Analyst or Project Management.

At any rate, the PO role is extremely important within Agile team development because they own the product decisions and therefore are responsible for all scope, quality, risk and cost decisionsat least theoretically. And the PO responsibilities tend to be driven by the needs of clients, system users and management of stakeholders, allowing for less focus on executions and operations.