Scaling Ownership Through a Product Owner Hierarchy

Definition

A single product owner can sustainably support only a small number of teams — the book's experience-based rule of thumb is no more than two — so larger projects need several product owners. Rather than letting this create a leaderless group, Pichler resolves the tension by nesting product owners under one chief (or "overall") product owner, the way a restaurant's chefs work together under one chef de cuisine. The chief product owner guides the others, ensures consistent communication of needs across teams, optimizes project-wide progress, and has the final say when consensus can't be reached.

In the Book

The book presents two hierarchy shapes. A simple hierarchy has a small group of product owners, one per team, with one of them also serving as chief — illustrated by a client running a web portal where four product owners, each owning one application, report to a chief product owner responsible for the whole portal. A complex hierarchy, based on Schwaber's work, nests multiple layers — illustrated with a mobile phone project where a chief product owner oversees product owners for Entertainment, Communications, Photo and Video, and Organizer, and the Entertainment owner in turn oversees separate product owners for MP3 Player and Games, down to individual games like Tetris and Chess. The book pairs this with a blunt warning: avoid large projects in the first place, start small, and scale organically one team at a time, because starting with too many people (per Conway's Law) tends to lock in an overly complex architecture. Choosing the right product owners for a hierarchy also depends on whether teams are organized as feature teams (around backlog items) or component teams (around the architecture).

Why It Matters

Authority that can't scale to one person doesn't disappear when the effort grows — it either gets nested under a single accountable point at each level, or it dissolves into a committee where no one is actually responsible (the failure mode named elsewhere as the Product Owner Committee). Any system needing to scale a single-point-of-accountability design faces this same choice: recursive hierarchy with one name at each level, or diffusion of responsibility as headcount grows.