Blog of Rob Galanakis (@robgalanakis)

What does your Product Owner own?

In a previous post, I came down hard on Agile leaders that don’t program. Now I’ll turn my sights to another part of the Scrum trinity: the Product Owner. I’ll raise some concerns for what I’ve seen it become in videogames, and suggestions for improving how we use the role.

Most product owners I’ve seen in the videogame industry are much closer to project managers than business owners. Their primary job is often the coordination, planning, and prioritization of the cross-team dependencies that the scaled-up nature of game development tends to create. I’ve seen designers and business/marketing in the PO role on occasion. It has sometimes gone very poorly.

I’ve always thought this situation strange, as the PO role most closely aligns with someone from the discipline of game design. We usually don’t have a problem with mapping a Creative Director or other core vision holder to the role of PO. After all, they are the product champion, and marry game design and business sense. A project manager clearly wouldn’t suffice here. But then other POs on the same project are all project managers. What gives?

There’s are some litmus tests for seeing how product ownership works in your organization.:

  • Do people “graduate” from Scrum Master to Product Owner?
  • Do the same people occupy both Scrum Master and Product Owner roles, concurrently or not?
  • Is your product owner leading and championing, or following orders (from above and from the team) and focused on execution (metrics, tracking)?

The skills between product owner and project manager are significantly different. There’s a problem if most people are seen as able to do both, and if POs aren’t coming primarily from design, business, and marketing.

There are lots of reasons things get this way. The important thing is to realize that the term PO isn’t a good fit for what most POs are doing. I see two options.

The first option is to commit to a Chief Product Owner/Area Product Owners structure (described in the footnotes*). Here, product ownership is seen as a distinct set of skills that bridge the business and design/creative side of development. If you have the right people (for example, POs for the overall/creative, technological, visual, and operational parts of the product), this can work quite well. I’d say this is a much better option, but frankly can be difficult or impossible to pull off if you do not have the right people or mindset.

The second option is to commit to having a single Product Owner, and having a project manager (Producer) on each team who is responsible for traditional project management duties and being a proxy for the real PO. They make few decisions of their own, but just act as dutiful middlemen. Usually the Producer will also take the role of Scrum Master, though I think this is a shame as their focus will be on traditional project management. This will make it difficult to make sure your teams are getting an ongoing Lean and Agile education.

Ultimately, the key is to acknowledge how product ownership in your organization works. If how people are fulfilling the role of PO does not seem to align with the literature, change something. You can choose option one, and change your organization to match the literature. Or you can choose option two, to abandon the literature, and find something that will work instead. In either case, do not continue the dissonance.

The core of Lean and Agile is continual improvement. If you are using confusing or inappropriate terms and organizational structures, you sow confusion. If you are confused and without direction, you cannot reliably improve.

*: Scaling Lean and Agile Development is the best book I’ve read about scaling Agile development methodologies. Regarding the role of the product owner, their recommendation is to have a single PO if possible, but to have a single Chief Product Owner and several Area Product Owners if one PO is impractical (which it often is in game development). Importantly, POs are tied to areas of the product, and not to teams (who can and should drift between areas of the product).

4 thoughts on “What does your Product Owner own?

  1. Craig says:

    Interested to hear what role you think producers should have on an agile game dev team.

    I know I’ve had a Scrum of Scrums with the producer as building scrum master before, it didn’t work out the best.

    1. Hi Craig. I am not sure. Clinton Keith’s Agile Game Development with Scrum has some ideas in the later chapters. Basically their options are Product Owner, Scrum Master, or Project Owner supporter (dealing with external partners, budgets, etc., I’d call this traditional Project Manager duties). It depends on the person’s passions and abilities.
      But IMO real transformations require shaking things at their roots. If programmers continue to work the way they were in a non-Agile environment, would you say Agile did anything different? Same for producers. If they have basically the same work day they had before these new practices, odds are the transformation is on the surface only and the producer needs to be forced into doing things differently.
      Also IMO I think there should be less Producers and non-value-adding positions (Lean term, not supposed to be insulting). If you are trying to be more Lean and Agile and *don’t* end up eliminating some producer roles, odds are you’re not doing it right either.
      So no really solid answer. Dislodging entrenched traditional management is a difficult subject.

  2. Dmitry says:

    Second option you’ve mentioned is widely used in Yandex. Seems to be, they are pretty successful with it

  3. Craig says:

    Thanks for the response, Rob.

    Keith is pretty thin on the ground when it comes to available roles, as you say.

    I completely agree with you on production needing to be subject to the same transformation as any discipline exposed to agile thinking.
    Especially as traditional producers tend towards line managers, and those then tend toward culture and practice shapers in a management sense.

    And no offence taken :)
    Everyone on the team should be adding Lean value, as you say, management (middle- or otherwise) no exception.

Leave a Reply