The organization

The Product Owner

In Scrum, a single person decides the order in which the product will be built and is accountable for the value it brings: the Product Owner. Four patterns from A Scrum Book explain why this accountability is not shared, how the Product Owner gets help when the product grows, where pride in the product comes from and what changes when the team works for an outside client.

A committee that never decides

A small company publishes appointment booking software for physiotherapy practices. On the first Monday of every month, five managers meet to set the Developers' priorities.

The sales director opens the meeting: "We need the accounting export before the end of the quarter, two big clients are waiting for it." The head of support disagrees: "My advisers spend their days on calendar synchronization errors. That's where the urgency is."

After two hours, the committee produces a list of fourteen requests, all ranked "priority 1". In the following weeks, each of them drops by to see the Developers to push their own request forward. Three months later, the accounting export is half done, synchronization still fails and nobody can say who decided what.

The managing director then hands the list to Claire, a former physiotherapist who has been training clients for six years. Anyone can suggest a request to her, but she alone sets the order, and she explains her choices. Scrum calls this list the Product Backlog (the ordered list of everything that might improve the product) and the person accountable for it the Product Owner.

The Product Owner pattern: one person and an ordered list

A Scrum Book (2019) presents Scrum in the form of patterns: each describes a recurring problem, the opposing forces and a solution drawn from experience. The Product Owner pattern carries two stars there, the rating the authors give to solutions they believe a Scrum team will eventually need.

The problem. Team members need a single, ordered list to focus their work on what has value. Without it, the team may build features that nobody will use and that still have to be maintained, deliver at the wrong time or deliver nothing. So someone has to be responsible for this list, with enough domain knowledge and enough authority to rank it.

The forces. The first temptation is the committee, as in the scene above. Bringing several perspectives together is useful, but the book observes that such committees "too often represent internal corporate functions, disconnected from market concerns where the real value lies." They often lack authority, discussions turn into negotiations between departments and the final list is an incoherent compromise that arrives late.

The second temptation is to appoint a project manager. The book makes two criticisms. The organization is building a product rather than carrying out a project: when the project ends, the product lives on with its users. And the project manager is judged on deadline and budget and is rarely given responsibility for the value produced, which encourages short-term decisions.

The solution: "Get a Product Owner to order the Product Backlog and take responsibility for the vision of the product, and for the value that emanates from the delivery of that vision." Product Owners "have the final say over product content and delivery ordering", and they become the single point of contact for these questions. The book makes them accountable for the return on investment, that is, the ratio between what the product brings in and what it costs.

Anyone can offer an item for the Product Backlog, but it is the Product Owner who places it in the list. The Developers refer anyone who wants to change their priorities to the Product Owner. The Product Owner represents all the stakeholders, customers included: as the book puts it, "There is no customer in Scrum", in the sense that Scrum has no separate customer role. When several teams work on the same product, there is still only one Product Owner and one Product Backlog.

What the 2020 Scrum Guide says

The Scrum Guide by Ken Schwaber and Jeff Sutherland, in its 2020 edition, goes in the same direction with less detail. "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team", the whole team. They are also accountable for effective Product Backlog management: developing and communicating the Product Goal, creating and explaining the items on the list, ordering them and ensuring that the list is visible and understood. They may delegate this work, but they remain accountable.

The Guide adds that "the Product Owner is one person, not a committee", and that the entire organization must respect their decisions. "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner."

Three differences separate the book from the 2020 Guide. The book, published in 2019, still says "Development Team" and "ScrumMaster", where the Guide writes "Developers" and "Scrum Master". The book relies on the product Vision, whereas the Guide introduced the Product Goal in 2020. Finally, the book entrusts the Product Owner with the return on investment, the product roadmap and the release plan, which the Guide does not mention.

Product Owner Team: getting help without becoming a committee

After a year, Claire can no longer cope on her own. She has to meet practices, keep an eye on competitors, answer the Developers and prepare the items for the coming Sprints (the fixed-length work periods of one month or less that set the rhythm of Scrum). Items arrive poorly prepared and the Developers waste time guessing what is expected.

The problem addressed by the Product Owner Team pattern (one star, meaning a good solution but not necessarily the only one) is exactly this: "The Product Owner has more to do than a single person can handle well."

The forces. Asking the Developers to do this work shifts the burden and reduces their capacity to build. Hiring specialists around the Product Owner creates handoffs in which understanding of the customer gets lost. Yet a single point of accountability must be kept, or the committee comes back.

The solution: "Create a Product Owner Team, led by the Chief Product Owner, whose members together carry out product ownership." The Chief Product Owner keeps final authority over the ordering of the Product Backlog. The other members help prepare the items and break them down with the Developers. The book insists on one point: some may call these members "Product Owners", "but these people do not own anything", and the Chief Product Owner remains the single Product Owner. It also recommends that this small team work in the same place.

So Claire brings in an interface designer and a support adviser, present two days a week. They prepare the items with her, and the order of the list remains her decision. The Scrum Guide does not know the title of Chief Product Owner, but it allows delegation as long as the Product Owner remains accountable for the result.

Product Pride: pride in the product

The Product Pride pattern (one star) opens with a well-known story. A passer-by asks three workers on a construction site what they are doing. The first replies that he is laying bricks, the second that he is building a wall and the third that he is building a cathedral.

The problem: "Team members need to know their work matters and have a say in how it's done."

The forces. Pressure from the market or from management pushes the team to deliver quickly. The team then takes shortcuts, quality drops and rework piles up. A team that delivers below its own standards loses pride in what it does. The Product Owner may also be part of the problem: if they have no direct contact with customers or no authority to decide, the Vision becomes blurred and the team saves its energy for side projects.

The solution: "Create a climate that enables Autonomy, Mastery, and Purpose", the three sources of motivation described by Daniel Pink in Drive (2009). The book specifies that "no one can either impose or bestow Product Pride", and that it emerges when these conditions come together. In practice, the team has a hand in setting each Sprint Goal, brings together the skills needed to finish its work and receives feedback from the market on what it has delivered. Product Owners are the first carriers of this enthusiasm, and "part of their job is to make it infectious."

Development Partnership: when the team works for a client

The Development Partnership pattern (one star) deals with the case where an organization entrusts the development of its product to another, whether an outside vendor or another department of the same company.

The problem. Boundaries between organizations do not match the way the product is built. Each side keeps its own procedures, requirements pass from hand to hand, developers are torn between their employer and their client, and mistrust leads to fixed-scope contracts that almost always leave someone unhappy.

The forces. The central question is who should employ the Product Owner. The client has the domain knowledge and should stay in control of the content, and the vendor wants to manage its profitability. The usual answer is to place a Proxy Product Owner on the vendor side, who answers questions in place of the real one. The book judges this arrangement costly: "development becomes two one-way communications instead of one two-way communication", and this stand-in cannot decide anything.

The solution: "Create a partnership between clients and vendors that breaks down walls between the organizations." The initial agreement sets out the rules of engagement: working in the same place as far as possible, equitable risk sharing, ongoing adjustment of the definition of what will be delivered, and the aim of a long-term relationship. The Product Owner works for the client, because they need to be as close to value delivery as possible. Ideally the team settles on the client's premises. Failing that, the Product Owner spends a large part of their time with it: the book cites as successful arrangements "at least six hours a day, four days a week, or four hours a day full-time", and rules out a mere appearance at a daily teleconference.

Limits and pitfalls

The most common pitfall is the Product Owner without authority. If every decision has to go up to a management committee, the person who holds the title passes messages along, and the committee from the opening scene still exists under another name.

The second pitfall is the absent Product Owner. Someone who combines this role with a senior management position does not answer in time, and the Developers guess or wait.

The third is the opposite excess: a Product Owner who decides alone, without listening to the Developers. The book specifies that the Product Backlog ideally "reflects a consensus view (particularly with respect to the Development Team's perspective)", and that the Product Owner's final word comes to close this discussion.

The solution itself has a weak point: everything rests on one person who must know the business, understand the technology, have the authority to decide and remain available. This profile is rare, and the authors admit as much. Return on investment is also a convenient criterion for a product that is sold, but it fits a school, a hospital or a charity poorly. The Scrum Guide, for its part, speaks of value without reducing it to a figure.

Finally, these patterns come from practitioners' experience. The stars express the authors' confidence, with no measurement behind them. The article Criticism and the state of the evidence reviews what is known about the effectiveness of Scrum.