Product Manager & Product Owner: Very Best Friends?

Product Owner Camp 2017 (#POCAMP) in Frankfurt, Germany, on August 25 and 26, was a great event where product owners (POs) met and shared experiences. On the first day, I offered and facilitated a session titled “Product Manager & Product Owner: Very Best Friends?”. This article summarizes the discussion results.

17082501I find it critical for the success of both product management and agile development that the two roles of product manager (PdMgr, or SPM for Software Product Manager) and PO are set up well, and that the individuals who work in these roles collaborate well with each other. So I wanted to provide an opportunity for discussing and sharing experience about these roles and their interactions.

We started the session collecting different role constellations of SPM and PO. About 20 session participants reported and discussed quite different cases and setups. The two photographs with the headlines “Konstellationen” list these cases and important aspects of role setup.

Some participants said that they only have the Product Manager role title in their organizations, others only have the Product Owner role title. But both have roughly the same tasks including backlog management for agile teams and customer-facing product management activities. Other organizations had of course both roles present, which then raised questions of how their tasks are separated, and how they interact.

17082502In one “pure SPM” case, the role had already been present before the first projects moved to agile. So the existing SPMs took over PO roles in agile projects. One of the “pure PO” cases was a young company that started out with a small agile development team and its associated PO. This person than also took over the emerging SPM tasks while the company continued growing.

This underpins that role titles Product Owner and Product Manager do not matter too much when trying to understand how an organization deals with its product- and requirements-related topics. What is more important: How are responsibilities and tasks separated and distributed? How do people enact (“live”) their roles and interact with each other? Concerning these questions, the discussion yielded the following constellations and aspects:

  • One SPM or PO is in charge of n products17082503
  • A group of SPMs or POs are jointly responsible for one product
  • Separation of different SPM or PO role setups along different types of products, for instance: SPM is responsible for “external” products delivered to customers, while PO is responsible of “internal” (sub-)products that establish the external customer product
  • Need for many POs for the same product because of large number of stakeholders
  • In some cases, PO has far-ranging responsibilities and competences. In other cases, PO is rather a service role for internal customer groups. In even other cases, PO is in charge of a wide range of non-development activities. While in yet another case PO is a developer during part of his time.
  • Some companies, typically in development of internal IT applications, distinguish between “Business PO” and “Development PO”. These Business POs focus on customer-related functionality. Development POs focus on how the IT solution shall be built.

The second half of the session focused on experiences and recommendations with role setups of SPM and PO (see photo titled “Erfahrungen/Empfehlungen”). The main topics and findings were:

  • Many session participants emphasized that good collaboration 17082504between SPM and PO were most important. Questions of organizational structure were viewed less relevant.
  • As far as organizational setup is concerned, some participants emphasized that the role definitions and their associated competences must be backed up by upper management.
  • Some POs reported that their role is perceived as a pure service job writing down customers’ user stories and forwarding them to development, without much room for own decisions. They experience difficulties to establish their PO role properly when interacting with business stakeholders and with development.
  • A participant raised the question what happens with middle management when an organization moves to agile and self-organized teams? For PO’s ability to establish itself properly, it is important how middle management reacts and how its position evolves during the agile transition.
  • Another participant mentioned that the tasks of a PO may vary considerably depending on the development team’s capability to manage customer interaction on their own. Where developers are empowered and capable to interact with relevant stakeholders (e.g., for clarifying user stories, or for obtaining early feedback on newly developed features), PO can contribute significantly more time to optimizing development’s overall delivered value.
  • A brief discussion during the session addressed PO’s specific tasks and challenges in distributed development: One approach to manage this is to have a group of POs, one in each location of a distributed development team, that coordinate closely on overall product topics.
  • This raised the question how collaboration between POs shall be organized. Some session participants work in hierarchical structures. Others rely on informal coordination among POs.

If you want to add impressions and experiences about SPM/PO constellation, I will be glad to receive your message via our contact form.