The Product Owner - The Orphan Agile Role

April 2017

By John Ruzicka, MC&R Inc., State of Michigan, PMP, SPC4, CSM, CSPO

I was recently reading a document which noted “… the Business Owner (aka Product Owner) …” at which point the alarms started to go off: bad idea – bad idea. Why? Well the goal of this article is to raise some discussion around that.

But first let’s level set. The Scrum Master is the team’s servant-leader trying to work themselves out of a job.[1] The Product Owner owns the backlog. Now that was simple enough wasn’t it? Or … was it?

The definition of the Scrum Master albeit brief is a true job description covering the person’s role and responsibilities. It provides who they are and what they do. And the role has in the last decade become reasonably mature. Just note how CSM’s outnumber CSPO’s by 5 to 1 with the PSPO’s trailing even further behind. And as to a job description of “owns the backlog”: this does not begin to say who the person is or what they do.

So here is what a Product Owner should be

Back to basics – dig out the Manifesto: we value: customer collaboration over contract negotiation. And arguably that is where the Product Owner steps in. Going further the Product Owner should have as their job description two of the Manifesto Principals mildly redacted:

My highest priority is to satisfy the customer through early and continuous delivery of valuable software.

I (as a business person) and the developers must work together daily throughout the project.

If you ask me this sounds like a go-between. But this go-between is not just a message carrier; rather here we have an empowered go-between who senses as much as knows how to get the best out of both sides of the deal for the good of the organization.

And that backlog the Product Owner owns had better contain lots of good stuff to satisfy the customer through … delivery of valuable software. With that the Product Owner needs the same level of knowledge about their organization and the client as the Business Owner and senior executives. And to meet the sense of early and continuous deliverythe backlog that the Product Owner grooms needs to show that knowledge and the roadmap needs to be well maintained and well agreed.

Origin of the Persona

Another “problem” with the Product Owner role is that there is no clear career path into or beyond the role. For the scrum master there is in a proto form with the project manager gone agile or the agile team member who gets the servant-leader bug. I am not saying all Project Managers make good Scrum Masters or are even suited to make the transition but those that do or the team member that does form a pool for Scrum Masters. And from their they can go on to being an uber Scrum Master heading the Scrum of Scrums and other power positions after the servant bit wears thin.

Maybe this is the point. The Project Manager’s job is to run a business that delivers product, service, etc. They sit around all day thinking about how that is going well or not. They may go agile or they may not. But the Product Owner? Where do they come from and where do they go? There are some examples but those are few and far between in the typical organization[2]. And for those who are in a Product Owner role is not easy and certainly not part time. Some organizations do see it as easy, part time or with no power. In my experience, when an organization thinks as such the Product Owner effort fails completely or mostly. And the latter is the most egregious as the organization does not even know what they have fallen short of.

A Job Description for a Product Owner

We might fill out the bits we took from the Manifesto to begin to shape a Product Owner job description as follows.

  • A full time job of owning (that’s owning – not simply managing) the backlog (that’s product backlog not sprint backlog).
  • Is cognizant of the line between owning the product backlog and owning the sprint backlog and respects not crossing it.
  • Creates and maintains a roadmap based on a shared organization vision.
  • Fills an authority (but not a command and control) position and is empowered to do so.
  • Is a supreme negotiator on both sides of the coin: vision on the senior management side and delivery on the team development side.
  • Skilled and knowledgeable in both the business of the organization and the technology to support it.
  • Takes communication as 70% of their job and understands that the majority of that is real or virtual face-to-face.
  • Owning the backlog means the Product Owner is accountable for the return on investment as the Business Owner and senior management would define it and takes that role far beyond simple caretaker. The role requires the person to understand what the accountability for the return on investment means, how to achieve it and where impediments will arise.

Can the Business Owner fill this role? The Business Owner certainly understands the “what” of the return on investment. But the how and the where? Not in my experience – at least not typically. It simply is not in the personality. And it is not in the Business Owner’s job description. How to achieve the return takes up a great deal of time and dealing with all of the issues that arise takes up even more. These two when the Business Owner is the Product Owner are left not done simply for lack of time to do them.

The roadmap is often the most dynamic artifact in the Product Owner’s world. High level milestones may not vary considerably in time or scope as they encapsulate the vision; at least let’s hope they don’t. At the other end: the current sprint backlog is locked. But the roadmap for the parts of the backlog between those two can be changing day to day and those are the majority of the backlog. With that the Product Owner needs the time, skills and acumen to flow with these changes through a clear roadmap. Do you think that’s easy? You have fixed end points with everything between moving but need to match up to those end points. Try it for a few months and live the eternal flux of the Product Owner’s roadmap.

Now as the supreme negotiator: it is so easy for the Product Owner to fall short at this one and adding any number of new grey hairs to the head. For a start try walking from a senior management meeting where all problems are your problems to a team meeting where you are the barely tolerated authority figure. Can you make this a win-win game? For moments yes. But then there is the next moment and the next and you just have to try to win as many moments as possible for the organization. The Product Owner is the supreme negotiator trying to satisfy the customer and work together with the team. Am I being melodramatic? On average probably; in specific instances – oh no, not even close.

The final step in delivering the return on investment is realizing the return with the release of the product increment that the backlog epics and stories has produced. The job description calls for a Product Owner who leads in the name of the Business Owner deciding what is “Done” and when the software should be shipped. This continues the negotiations. It also raises for the Product Owner “well you signed off on it, didn’t you check if first?” Not a question a Product Owner wants to hear but a question every Product Owner has heard more than once.

The Real Life Product Owner

Of course that sub-title begs the question: whose real life: mine, yours, or whose? After all Product Owner qualifications will vary greatly across organization culture, organization type and level of scaling. To completely oversimplify the world let’s take two examples:

  1. Flat organization with a single product and a team or two
  2. Large multifaceted organization where several products are under consideration that are running across perhaps a half dozen teams.
  3. The flat organization with a single product and a team or two is likely to be an example of most organizations embracing agile today. This article is meant to be most immediately applicable to this case. Here the real life Product Owner ideally has broad authority and control to coordinate organization vision and goals into a roadmap and backlog for the products for which they are accountable. For the personality that looks for this degree of freedom with its accompanying risk the position works well. It tends to be a busy day with that 70% communication mostly in negotiation. Organizing, refining, reporting will take the other 50%. All of it is more or less to keep a healthy well-groomed backlog moving on a clear road map that delivers, as close as possible, to the organization vision and works, as close as possible, to the team cadence.

In the second example on the large scale, the life of the Product Owner can be the same and very different. As a concrete example let’s consider the role of the Product Owner within the SAFe framework. As example A begins to scale structures of the Release Train and Program Increments begin to form. Now the example A Product Owner will find themselves on a team of Product Owners led by a Release Train Engineer and a Product Manager with the latter essentially being an uber Product Owner. What’s the same in this example? Owning a backlog. Working and negotiating between more senior levels and the team. Working through backlog grooming with the team. That 70% in communications. What’s different? The divide from upstream management to team is much less steep. The backlog being a piece of the Release Train backlog is much more structured and groomed particularly coming out of the Program Increment Planning Session. Working as part of a team of Product Owners under the immediate direction of the Release Train Engineer and Product Manager creates a much less freelance environment. A clearer career path across Trains and up the management in a Train and, perhaps more than anything else, the intensity in all of the events of working through a 2-day Program Increment Planning Session.

[1] As in: a mature team should be self-managing.

[2] Particularly an organization that has not scaled.