How Product Ownership works in the Real World

Scrum continues to insist that a single person play the role of Product Owner on a development project. One person sets the team’s direction and priorities, defines what the system will do, manages the backlog of requirements and decides when work is done. But like many other organizations, we've found that this doesn't work.

There are too many functional and operational and technical details for one person to understand and manage, too many important decisions for one person to make, too many problems to solve, too many questions and loose ends to follow-up on, and not enough time. It requires too many different perspectives: business needs and business risks, technical dependencies and technical risks, user experience, supportability, compliance and security constraints, cost factors. And there are too many stakeholders who need to be consulted and managed, especially in a big, live business-critical system.

A Single Product Owner doesn't Scale

Roman Pichler says that one Product Owner can support one or at most two feature teams. What do you do on large projects, complex products with tens or hundreds of people involved? You’ll need to put together a product ownership team, with a hierarchy of product owners reporting up to a product manager or program manager. Or find some other way to spread the product owner’s responsibilities across more than one person, splitting up some of the work between a product manager and one or more business analysts to take care of the detailed work, or try Customer Pairing, or some other Customer responsibility pattern.

A principle of Agile development is that you get the best results from people working together: better understanding, better designs, better code. So why ask one person to make all of the important decisions about what needs to be built?

Who’s your Product Owner?

In our shop, each system has a sponsor: a business executive with day to day operational responsibilities and the authority to make strategic business and product decisions. The sponsor sets overall direction and goals for the system, and finesses any politics, arbitrating conflicting demands and priorities from different stakeholders: customers, partners, sales, ops, compliance, development. The sponsor makes go/no go decisions for major initiatives and trade off decisions on risk and cost when the stakes are high.

The other responsibilities are spread across development leads, developers, testers, customer service and other people in the organization.

Development leads take care of most of the work of managing the backlog and detailed planning and prioritization of features and fixes, working with the sponsors, developers and QA and ops and other stakeholders to set development schedules. This gives the development team more control over managing technical dependencies and technical risks in deciding how will work will be done and what work can be done together.

Development leads and developers fill in the requirements, writing and reviewing specs, building prototypes, holding workshops, discussing and arguing out alternatives and clarifying details, running experiments, working out the design. They know when to go to the sponsor or other stakeholders when they need clarification or other help. They can take care of this because everyone on the team has been working in this business area for 5, 10 or more years, and have the necessary insight and experience.

Dan North explains in “Accelerating Agile: Hyper-performing without the Hype” that the key to hyper-productive Agile teams is to have people who really understand the domain, so that everyone can contribute, fill in details, make suggestions, question assumptions, assess risks, and make decisions when they need to. Fill your team with people who have worked on the same kinds of systems before, get everyone training or hands-on experience if possible.

Deciding on Done

Deciding when work is done – which for us means that the code is ready to be released – is also shared across the team.

Developers write their own unit tests and test their own changes. All code has to pass the automated regression test suite and static analysis checking in Continuous Integration.

Development leads review all code check-ins for to make sure that the code is correct, safe and maintainable – that it is done properly.

QA engineers test each feature or change or fix, including integration testing and exploratory testing to verify that the feature or fix does what it is supposed to. They also review usability, bringing in other stakeholders like customer service or ops as they need to.

Before changes are released, our release manager (who is also the head of our QA team) checks that all of the reviews and demos are done and all tests are passing, assesses risk, decides which code is ready for release, and then calls a release meeting with the sponsor, development, ops and other stakeholders. The sponsor looks at all of the steps and checks that were done, reviews major changes (especially changes that have regulatory impact or carry operational risk) and gives the ok that the release can proceed.

This is how Product Ownership should Work

Having multiple people share product ownership responsibilities lets us get more work done. We also do a better job: more viewpoints and more knowledge and more opportunities to catch mistakes. It creates more opportunities for everyone on the team to participate and contribute back to the business. And all of this becomes self-reinforcing. The more that more people get involved in product ownership, the more that they will learn. The more that they learn, the better job that they can do and the more that they can contribute back. The organization gets better, the product gets better. Why wouldn’t you want that?