Do We Need Product Owners?

May 3, 2011

David Anderson recently wrote a blog post Banish “Priority” and “Prioritization” noting that he found the words “priority” and “prioritization” no longer required with Kanban systems because, “They encourage roles/positions for people who do mostly non-value-added coordination work, and they add to the transaction costs of flowing work through the system.”

Jurgen Appelo followed up with a blog post of his own: Wasteful ProductOwners? In his post, Jurgen counters this thinking with the observation that “Managing stakeholders in a complex environment is a complex task. If we can replace the PO with a set of policies, then why not the ScrumMaster and Software Testers too? It is the ‘machine-thinking fallacy’ all over again. No wonder that some old-fashioned managers find the rhetorics of Lean thinkers appealing.”

Are Product Owners providing value, or are they unnecessary middle-men/women?

I believe that the real answer to this is a question in one of context.

For us, there is a lot of work required to define what goes into our software and establishing just what the priorities are. We’ve always got a large list of potential work, but market and industry analysis, customer input, stakeholder input, product roadmap and priority decisions are all complex, time-consuming, on-going activities that can’t be driven by policies alone.

I certainly wouldn’t want to burden development teams with most of this work! They’ve got enough to do bringing the product backlog to life, keeping up with technology and improving their own repertoire.

In general, we want to group and deliver a set of related features to the market (I work for a software company), not just one-off features. We’re usually looking to improve our product capability in some broad sense, to advance our products in tangible, meaningful ways. This means that we must discipline ourselves to making this happen by allocating people and giving them the dedicated time to transform ideas into working software. Scrum allows us to do this while eliminating a lot of overhead of traditionally managed software projects.

Based on our context, there is definitely value in having a Product Owner. Product Owners not only prioritize the backlog, they provide the team with insight on why content is prioritized as well as being available to work with the team in shaping the final delivery of the features (and being flexible enough to seize new opportunities by adding new features and changing priorities in the backlog). A good Product Owner keeps the team connected with the business to the benefit of all concerned, without bogging the team down with all that background work.

We’ve tested the waters with Kanban, partly because Scrum wasn’t working as well as we liked in one scenario: customer implementation projects. These situations are much more dynamic and fluid (priorities can shift daily). Teams can make decisions about what work needs to be performed because there is direct input from the customer that influences their decisions, along with rules or policies than can cover everything other than those exception conditions which always manage to surface. I can definitely see where Kanban is very useful for IT organizations that spend a great deal of time in reactive, support-type activities; likewise for software maintenance teams.

Product Owners can be optional in these situations, and in fact could drive up transaction costs of “flowing the work,” as David points out. (In case you were wondering, we’ve made use of Kanban’s limiting of WIP to drive collaboration and productivity of our Scrum teams as well. Cross-pollination of ideas doesn’t hurt, either.)

Context should determine the optimal approach to use; one size doesn’t fit all!