The product owner: the single-person bottleneck

In the early years of this century I was asked to perform an audit on a large project at an international bank. Over two-hundred people seemed to work on the project. And it was a waterfall project of course.

During the introductory rounds at the bank it appeared that the teams housed in a number of large rooms alongside a corridor. First, we passed two large rooms crammed with developers, next we passed a room with functional analysts and a smaller room with testers. Then we passed the software architects’ room, and lastly, the project management team – yes, really, there was a team of project managers – was given a more spacious room at the end of the corridor.

The simplicity of Scrum
After having spent some days at the bank, I soon realized that none of these teams actually communicated with each other face-to-face, so I organized some multi-disciplinary workshops. Although these people had been in the same project for over a year, during the first workshop they actually shook hands and introduced themselves. This project definitively needed some agility. Although back then there were many agile approaches and philosophies, after some years Scrum became the most popular one. Probably because of the simplicity of the framework, and maybe also because of its clear roles. There’s the development team with everyone in it who contributes to releasing the product. Then there’s the scrum master role to help the team reach their goals in an agile manner. And last but not least, there’s the product owner. Typically, the product owner is responsible for the product, and hence for the product backlog. According to the official Scrum guide, the product owner is the sole person responsible for managing the product backlog and he or she is accountable for the product. Seems fair, doesn’t it?

Mapping roles
Now imagine that you are the CEO of the large international bank I mentioned earlier. Slowly you will begin to realize that your large waterfall projects are not performing as expected. Also, you will recognize that this agile thing isn’t going away and moreover, it seems to help organizations performing more efficient. Chances are that you will start implementing agile and Scrum as well as your fellow competitors. Happy to have found the solution for your failing projects, you initiate an agile transformation program, coached by expensive hipster agile coaches. Really soon, an interesting issue pops up. That of mapping roles. On the one hand, the traditional one, you have operations, testers, developers, analysts, architects and project managers. And on the other hand, the agile one, there’s only the team, the scrum master and the product owner. How does this map? Over the years, I’ve witnessed quite a few of these agile transformation programs. Some are more efficient and more successful than others, but all of them have had this mapping issue. When it comes to operations, testers and developers, it’s fairly easy. They always end up in the teams. And in most cases pretty soon the team will learn how to pick up the scrum master role as well. The real issue is how to fill-in the product owner role. In most organizations where I’ve witnessed this mapping issue, the primary candidates for this role will be either the former project managers of the former analysts. Given that agile teams strongly focus on building software, neither of these roles seem to have a place in the team. Therefore, most product owner roles are filled-in by either traditional project managers or the traditional functional analysts.
Cross-functional and self-organized
In my opinion, agile teams have the responsibility of building the right product in the right way at the right time. The best teams I’ve worked with are those that have commitment, and are capable of making their own decisions, handle their own workflow, and are cross-functional and self-organized – which by the way is very different from being fully autonomous. These are teams that usually don’t need much guidance, but will ask for guidance if and when they need it. When an organization moves towards such responsible teams that continuously improve and extend the company’s products, the role of product owner seems to mitigate or even contradict. Often coming from a more traditional background, the product owner gets entangled in “managing” the project, “managing” the team, writing weekly progress reports, facilitate all sorts of meetings, maintaining the Jira boards, exclusively interacting with the customers, writing the user stories or testing the product.

The single-person bottleneck
This is typically the work a traditional project manager or a traditional analyst would do, independent of they have product owner title. Even in recent times, on a project that was nearing its deadline, I noticed the product owner spending at least one day per week on delivering progress reports in Excel. I’ve seen too often that this single-person interface becomes a bottleneck for the speed, the motivation and even the quality of a team’s work, Micromanaging activities that really the team should do, you create little isolated fiefdoms in your organization, and take away the feeling of teams being responsible. I’m not sure every team should even have a product owner – just because the Scrum guide says so. The team has ownership, not the single-person bottleneck.

The team is key
In my opinion, most of the work product owners do is actually the team’s. Let your teams decide how and when to manage boards. Allow the team talk to the customer – yes, developers and testers can actually communicate with clients. The team is responsible for the product. Stop writing all these progress reports. If people in your organization want to know how good the progress in a team actually is, why don’t they come talk to the team? Rest assured I’m not saying that since I dispute the role of product owner, I think we needn’t think about our products. Thinking about and discussing our products is always crucial. But I do feel that most, if not all the work done by product owners can and rather should be handled by the team, and not by the one-person stronghold that is the traditional product owner. The team is accountable. The team is ke