Decomposing Product Owners

Despite the title, this has nothing to do with a horde of zombie product owners shuffling through the streets in search of Scrum teams.  I want to talk a bit about how Scrum defines the Product Owner role and how this can differ from real-world product ownership.  Specifically, let’s look at the responsibilities of the Product Owner and think about how organizations might end up handing parts of the role to someone else, and what the effects might be.  Finally, I’ll talk about how we might influence an organization to move towards defining more by-the-book Product Owners, or failing that, how we might ensure that the people who together compose the role are at least working together effectively and presenting a unified face to their teams.

Wait … Who Is The Product Owner?

Several years ago I did some basic Scrum training for new Scrum Masters in an organization.  Scrum was up and running within the team, but I saw some possible dysfunctions, so I structured the training like this:   First, I would explain some role, ceremony, or artifact as I understood it, including the value added by it; then, I’d ask the new SM to compare that definition to what he or she saw within the team.  Was everything A-OK or were there differences?  For any differences, did they represent a conscious choice to improve the process a la the “ha” of “shu-ha-ri”, or were they problems to be solved?

We were chugging along and generating insights until … we got to Product Owner.  I talked a bit and presented a basic list of PO characteristics like this:

  • Owns the product backlog and works daily to refine it
  • Understands the market and where the product is going
  • Provides clarity of purpose to the team: sprint goals, release plans, etc.
  • Is available to the team on a daily basis
  • Respects the team’s focus during sprints

I should note at this point that the organization had classic Product Managers who had received some general Agile and Lean training and had been given the PO role, but retained the original PM title.  In addition, there were business analysts who worked in the backlog and did grooming with the teams, plus a Project Manager overseeing the various teams, functional managers, and a UX lead who had probably the most frequent and detailed contact with users (If you’re in a large company that started waterfall and then went Agile, this may sound familiar).

Anyway, at the end of this brief summary of the Product Owner role I asked a budding Scrum Master, “So, based on this, who would you say is our Product Owner?”

(pause … gears turn)

“Um … I dunno … [names Project Manager]?”

Well that’s not ideal, is it?  We had a couple of PMs who clearly owned the product and prioritization, and teams of developers and testers who were more than a bit fuzzy on how the various business-facing roles work.  As you might imagine, I observed quite a bit of churn around prioritization, requirements, and vision.  And not the good kind of churn: no homemade butter was produced.

All of the people in this story were smart and dedicated and had a pretty good relationship with each other, but somehow the teams were performing less than optimally.  They generally got the requested work done, but the creative spark and exuberant collaboration you’d hope to see in a Scrum team was not quite there.  So let’s look a bit more at how the Product Owner role can be delegated or diluted and what that might mean.

Product Owner vs. Product Manager

A lot has been written on this topic, so I won’t linger too long here, but I like to see Product Owners who operate close to the metal: They’re in the grooming meetings, they know the agile tools (JIRA, Rally, TFS), and they roll up their sleeves to rank a newly found bug against the upcoming stories.  The farther up the pyramid they are in the company, the less time they tend to spend rubbing elbows with the team, and that can lead to a “development versus business” mentality where the development teams feel like “they” pressure us into unreasonable commitments, and the product management organization feels like the team is not fully committed and is disconnected from the business’ needs (probably because they are!).

Just like some teams tend to place the Scrum Master hat on a tech lead, it’s tempting to give the Product Owner title to a relatively high-ranking person.  That’s not really necessary though; the PO just needs to have enough delegated authority to make priority calls as they arise.  Much more important is the physical and/or mental proximity to the team, and the ability and desire to rank work at the story and bug level.

Product Owner vs. Business Analyst

Product Owners have a tough job.  They’re expected to really understand customers and the market, which probably means flying to conferences, sitting in marketing calls and user feedback sessions, and the like.  But they are also supposed to show up for Scrum ceremonies, dig into the minutiae of the backlog, and keep up with the progress of the current sprint.  How is that possible?  I know that when I was a development manager and took on the PO role on top of that I spent at least 2 hours a day, every day typing stories into JIRA, writing acceptance criteria, and creating mockups … all before customer meetings, strategy sessions, and more.  I made myself very approachable to the development team, and they had questions.  Boy did they have a lot of questions.

Given all this, some companies hire business analysts to handle the detail work of breaking features into stories, writing out acceptance criteria, and the like. But the BAs typically don’t have authority to prioritize the work or make calls on functionality.  If they are the ones doing grooming sessions with the teams, that means there’s a lot of “let me get back to you on that” or “I’ll run that by [product owner].”  This doesn’t have to be game-breaking, but it’s a slower feedback loop than direct PO-to-team discussion, so it’s something to watch.

Product Owner vs. True Power

By “true power”, I mean “who really makes the calls?”  Is it the VP of Product Management?  Senior Product Owner?  Someone in the development organization?  Sales?  One of the Product Owner’s key jobs is to manage directional push coming from anywhere inside or outside the organization.  Unless the PO is also the CEO (not likely), that means he or she needs to absorb all those wants and needs and make sure the backlog paints a true picture of what is most likely to be coming up next.  If those with true power are going around the PO and setting other priorities for teams, it creates confusion and disorder.  It’s up to the PO to manage stakeholders and keep that from happening.

Out of Many, One

Let’s finish up by going back to the anecdote of the budding Scrum Master who couldn’t point to a single person who met the criteria of Product Owner.  What could we do to fix this? It might not be feasible to snap your fingers and realign the job responsibilities of the PO, BA, UX, and/or project manager, but small changes can make things a bit more clear.

The Product Owner should articulate the product vision to the team every sprint.  If the PO isn’t available every day, he or she should show up to sprint planning with a compelling story about what the team is building and why.  This shouldn’t take long and provides the purpose the team needs to get energized.

The Product Owner should delegate some authority.  An engaged development team has a constant stream of questions for the Product Owner.  If the PO can’t commit to same-day responses on most questions, he or she can delegate (to a BA or other proxy) to give the team a better contact point.  But this person needs to have some true power to make decisions that won’t get revoked as soon as the PO is back in the office.

The Product Owner should review stories for the current sprint early and often.  I’m assuming here that the PO shows up for planning and the sprint review – if that’s not happening it certainly needs to.  But the sprint review or demo is too late for clarification.  Even a globe-trotting PO should be able to VPN into the test environment from the road and play around with features that are under development, so that small corrections and clarifications can be made in flight.  The team can facilitate this by adding “Product Owner has had the chance to review the work” to the story-level Definition of Done and proactively notifying the PO when stories are up and working.  Note the wording– “has had the chance” means the team offered the work for review, not that the team waits for the review to close the story.  If the PO doesn’t get to it and gets a nasty surprise at the sprint review, well … revisions go in the next sprint.

Present a united face to the development team.  This is the most important.  A PO who has other people helping to guide the work for the team owes the team clarity on how all the roles fit together.  This means frequent repetition of whatever arrangements have been made:  “Hey everyone – I’m going to be at the Business Success Summit next week; I’ve asked Susan to handle any UI questions or priority calls.”  Ideally the PO and friends also appear together at key points.  It might be obvious in the PO’s head, but standing in front of the team along with the business analyst/project manager/whoever and saying “yes, this is the vision; yes, we are all in agreement” can be very powerful.

In Closing

I hope this has been helpful.  I truly believe having a single product owner who ticks all the PO boxes is the best and simplest arrangement, but I realize that in the real world the PO is sometimes decomposed into several individuals.  Think about whether any of the tensions and variations above match your current situation, and what you might do to move things back toward the ideal.  There’s power in realizing that problems exist, and if you can see them, it’s a good bet that others do too and that you can rally together to overcome them.

One thought on “Decomposing Product Owners

  1. Jeff R.

    Great insight, John. I especially like the mentioning of the Product Owner should articulate the product vision to the team every sprint. That is very helpful to the team members.


Leave a Comment