The Product Owner in Practice

Maximizing value

The Scrum Guide (2020) makes the Product Owner accountable for "maximizing the value of the product resulting from the work of the Scrum Team", and adds that how this is done may vary widely. The Product Owner is also accountable for effective Product Backlog management: developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering them, and keeping the Product Backlog transparent and understood. The Product Owner may delegate this work, but stays accountable.

Two more rules from the guide shape the job. The Product Owner is one person, not a committee, who may represent many stakeholders. And for Product Owners to succeed, the entire organization must respect their decisions, which show in the content and order of the Product Backlog and in the Increment at the Sprint Review.

The examples follow the Portal team at Kestrel Energy, a fictional energy supplier. Isabel Santos is the Product Owner of the customer portal and app, Lars de Boer the Scrum Master, and Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters are the Developers.

What counts as a product?

The Scrum Guide describes a product as a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers. It can be a service, a physical product or something more abstract. That is close to the IT service management idea of a product: a combination of resources designed to offer value. Many practitioners take the same broad view: an internal HR platform, a network service or a data platform can each be a product with its own Product Owner.

Where you draw the boundary matters. If Kestrel defined "the login page" as a product, its Product Owner could hardly make decisions about value. "The customer portal and app" is a product: it has customers, a clear purpose and things to measure.

Product vision and Product Goal

A product vision is a short description of why the product exists, for whom, and what lasting change it should bring. It rarely changes, and it is the first thing to point at when a request does not fit. A product vision is a common practice; the Scrum Guide does not mention it, although Scrum.org's PSPO I focus areas include "Product Vision".

For Kestrel's household customers, who want to understand and
control their energy use without phoning us, the customer portal
and app are the place where they can see, change and fix everything
about their energy contract themselves, at any time.

The Product Goal, by contrast, is part of Scrum: the commitment of the Product Backlog. It describes a future state of the product the team plans toward, and the team fulfills or abandons one Product Goal before taking on the next. A good Product Goal is a step toward the vision that can be reached in months rather than years, and whose success is measurable.

Before the end of the winter, customers can handle an outage and a
meter reading entirely in the app: calls to customer service about
these two topics drop by at least 30% compared to last winter.

Each Sprint Goal should be a step toward this Product Goal. When stakeholders ask "why are you building this now?", the answer should be traceable from Sprint Goal to Product Goal to vision.

Stakeholders and saying no

A stakeholder is anyone with an interest in the product: customers and users, customer service, billing, finance, legal, operations. Isabel's stakeholders include Sanne de Vries (service owner of the portal), Nadia Saleh (business relationship manager) and Margriet de Wit (chief financial officer). Who needs which information is covered on Stakeholders, Risk and Communication.

Every stakeholder has good ideas, and there is always more demand than capacity. A Product Owner who says yes to everything has effectively handed the order of the backlog to whoever asks most often. Techniques that help:

• Point at the goal. "Does this help us reach the Product Goal? If not, it waits." Agreed goals turn a personal no into a shared decision.
• Say "not now" with a visible order. Show where the request lands in the Product Backlog and what sits above it. Stakeholders accept a transparent order more easily than a vague promise.
• Make the trade-off explicit. "Yes, if we drop the usage chart for it. Which do you prefer?" The capacity is fixed; the choice is real.
• Say no to the solution, yes to the problem. When Margriet asks for an export of all payment data, Isabel asks what she wants to learn from it. A monthly report built by the data team turns out to meet the need at a fraction of the cost.
• Test before building. A quick experiment, such as a survey or a fake button that counts clicks, can answer "do customers want this?" for almost nothing.
• Use the Sprint Review. It is the working session where stakeholders see the Increment and help decide what to do next, so they should hear about trade-offs there rather than in corridors.

Ordering for value and risk

Ordering the Product Backlog is where the Product Owner's decisions become visible. Value is the main driver, but not the only one. Early items often reduce risk (does the new outage feed really arrive within minutes?), create learning (will customers turn notifications on at all?) or unblock other work. Techniques such as cost of delay and weighted shortest job first (WSJF), and the practical side of refinement, are covered on Product Backlog Management.

Isabel orders the passkey login high even though customers barely ask for it: it removes a security risk and the stream of password resets that reach the service desk, which frees money for features customers do ask for.

Releasing early and often

Value is created only when the product is in the hands of users. The Scrum Guide says an Increment may be delivered to stakeholders before the end of the Sprint, and that the Sprint Review should never be considered a gate to releasing value. The guide does not say who decides to release; in practice the Product Owner usually makes that call, as part of maximizing value, together with the Developers, who know what is technically safe.

Frequent, small releases lower risk and shorten the feedback loop. They depend on technical practices: an automated pipeline (see What Is CI/CD?) and feature flags, which let the team deploy code without switching a feature on for everyone. In an organization with formal change control, the Product Owner may also need to work with change enablement to make frequent releases routine.

Minimum viable product

A minimum viable product (MVP) is the smallest version of a product or feature that lets a team learn, with real users, whether its main assumption holds. The term was popularized by Eric Ries in The Lean Startup (2011). The emphasis is on learning: an MVP answers a question, such as "will customers report meter readings in the app instead of on paper?".

The term is often misused as "version 1 with fewer features" or as an excuse for poor quality. An MVP built by a Scrum Team still meets the Definition of Done; it is small, not sloppy. For the outage notifications, the team's MVP sent a push notice for planned maintenance in one region only, to see whether customers turned notifications on before building the full feature.

Outcome over output

Outcome over output is the principle that a team should be judged by the change it creates for customers and the organization, not by the amount it produces. Output is what the team delivers: features, releases, story points. An outcome is what changes as a result: fewer calls, more self-service, happier customers (ITSM uses the same distinction between outputs and outcomes).

A team can ship twenty features in a quarter and change nothing for customers. The Product Goal above is written as an outcome (30% fewer calls), not as a list of screens, which leaves room for the team to find the cheapest way to get there and to stop when the outcome is reached.

Evidence-Based Management

Evidence-Based Management (EBM) is a framework from Scrum.org for measuring and improving the value an organization delivers, by setting goals, running small experiments toward them and inspecting evidence. The current English EBM Guide is the 2024 edition. EBM looks at value through four Key Value Areas:

The point is balance. A team that pushes Time to Market by skipping tests will see Ability to Innovate fall as defects pile up. Choose a few measures per area, track their trend rather than their absolute value, and use them to decide on the next experiment, not to rank teams.

The Product Owner and the project manager

Organizations that move to Scrum often rename their project managers "Product Owner". The jobs are different:

Scrum has no project manager accountability. The classic project manager's duties are spread across the Scrum Team: the Product Owner decides what and why, the Developers plan how and track their own work, and the Scrum Master improves how the team works. Many organizations still run projects around Scrum Teams, for example for budgeting or contracts; see predictive, adaptive and hybrid approaches.

Common traps

A fourth, quieter trap is the absent Product Owner who is too busy to answer questions during the Sprint or to attend Sprint Planning and the Sprint Review. The Developers then guess, and guesses are expensive.