I know this is not a new topic to discuss. Internet is littered with a lot of literature that covers this topic at length. That doesn’t stop me from writing nevertheless. I often write to either clarify my own understanding or resolving a challenge I am currently battling. So let me explain the premise of why I want to write on this topic.
Scrum Guide, which is hailed as the definitive guide to Scrum doesn’t mention the word “Product Manager”. It only recognises the word Product Owner. However, the reality is that in many organizations, both the roles exist and their responsibilities overlap in more ways than one. What doesn’t help is a lack of clear demarcation of their roles and as a result of the overlaps, it may give rise to incoherence and confusion in the team.
Why was there a split in the roles at all?
As product organizations grow, the responsibility of a product owner widens. It spreads across a wide spectrum from interacting with customers, validating product ideas in the market, identifying market needs, working closely with the product development team in sprints, managing the backlog and much more. After a product grows and matures to a certain degree, this is too much for a product owner to manage all by himself. You cannot expect a product owner to meet customers when he is expected to be always available to his team. Hence, the role was split into two clearly defined areas — outbound and inbound. Outbound is external interface with the market and customers. Inbound is about closely interfacing with the product development team.
However, even after splitting them, there are still overlaps in their responsibilities. Acknowledging and being aware of the overlaps, and defining clear working relationships is important for building an effective product team.
Definitions of Product Owner
Here is how a product owner’s role is defined by Ken Schwaber and Jeff Sutherland:
Overlapping of roles between PMs and POs
Since there is no official demarcation of the roles, I borrowed the definitions from the 280 Group (https://280group.com/)
This is the graphic that clearly demarcates the role and the overlapping between the roles.
Source: Rich Mironov
The following table comes from Scaling Software Agility
I tried to seek for opinions from some product management experts around me. Here is what I heard:
From John Cutler — An authority on product management (https://medium.com/@johnpcutler)
johnpcutler [8:15 PM]
… get in a room. Make it safe for people to speak their mind. Make the invisible work visible. Perhaps do a value stream mapping exercises. Make temporary working agreements visible, but always subject to negotiation. And then find a way to regularly inspect and adapt. In any rapidly changing context, roles and responsibilities will be in constant flux. How you work will be in flux. If they aren’t, you are probably over-optimizing on efficiency (unless you are in a very, very stable domain).
We often address the symptom … “if only we had clearer roles and responsibilities”. And then a consultant comes in a writes a bunch of bullet points. And the problems persist. Why? R/R weren’t the problem. Having the trust/safety to adapt and converse was the problem. Strict “contract negotiations” on bullet points broke in a matter of days.
the PO/PM overlap is always there, and will always be a work in progress.
johnpcutler [8:21 PM]
As a side note, the role of PM/PO is often highly dictated by the capabilities of the team and UX, and the needs of the larger organization. For example, many teams can function perfectly fine without a PO (and sometimes even a dedicated PM) if they have strong UX, the team is problem and solution focused, and they are self sufficient. So you might want to involve them in the discussion as well … as they will bear the brunt of any poor understanding.
From Shardul Mehta — An authority on product management and creator of Product Canvas (http://streetsmartproductmanager.com/about/)
shardulmehta [9:58 PM]
Hi. Thanks for asking. Agree with the points on creating a safe zone and trust. Generally, I’m not a fan of the PM/PO split. However, should that be the situation, then I draw the responsibilities in pencil not ink. One role is focused on market insights, strategic roadmap, driving long-term growth. The other is in the trenches working with engineering on the next release. Their coordination is super important and I make that crystal clear to them that that’s my expectation. They’re adults and I expect them to craft a healthy working relationship. The market-oriented PM should be keeping the technical-focused one updated on the direction of the roadmap. The latter should be keeping former updated on the progress of the next sprint/release. Both should be interfacing with customers/users, and be doing that a lot.
(All that said, generally I think this separation creates more organizational problems than solves them.)
I also tried to reach out to Roman Pichler but he is away on vacation. I will update this post once I hear back from him.
Defining the working relationship for a product manager in a product team
Understanding and acknowledging the difference in the roles is only the first step. The next step is drawing out clear working relationship for both the roles so that there is right expectations set in the team. Considering the above viewpoints, I have laid down the following working relationship for a product manager in a team.
Working relationship for the product manager in the project team:
PM is responsible for realizing the strategic vision of the project
PM is loosely tied to project teams he is responsible for
Has access to project teams but not committed to everyday meetings and decisions
PM never bypasses POs in team communication. They need to be closely aligned.
POs remains the single source of truth for the project teams
PM acts as the external stakeholder and should be free to share information to the team
Product Manager’s participation in project teams:
Defining the strategic intent of the project.
Collaborates with PO to define the project.
Participates in project kickoff.
Participates in Design Sprint — Ideation
Participates in Epic Backlog creation
Attends and contributes to sprint reviews.
Has a bi-weekly meeting with Scrum master, PO and UX
Interfaces with PO atleast twice a week.
Demos early designs and prototypes to customers and provides feedback to the team.
Additional Resources to read: