Build a product team with PMs instead of POs
Build a product team with PMs instead of POs
Empower your teams with access to clients
When we started building the ORFIUM Product Team back in 2018, a question came up. Do we need Product Managers (PM) or Product Owners (PO). My instinct said the former ones, and I insisted on that. For the first 2 years, as we were trying to hire Product people from the small pool of people in Greece, a question used to come from someone “Why don’t we hire Product Owners”?
If you want to have empowered product teams, the main thing you have to do is to give them access to the customers. By adding a gatekeeper between the clients and someone who manages the backlog, you have by definition mercenaries and feature teams.
Let’s provide a list of reasons why I don’t want to go with POs:
I hate the fact that the term Ownership is used for a job description so attached to a framework like Scrum. Many times that I talk about ownership, some other outside the Product team will ask me “but we have Product Managers, why do you talk about Owners”?
A PO-based company shouts that it has people (PMs) that control the client communication. The PMs should not go alone into meetings with clients but with their team, they need to explore, align, combine information, inspire and then lead a team of people. If you want to understand how you should read the “Continuous Discovery Habits” book. Especially in a B2B company, it’s tough to explain to business guys how they should collaborate with Product, adding an extra layer of communication between the clients and the teams doesn’t make things better.
Someone in a PO company decides that they will go Scrum no matter what. Scrumban, Kanban, Shape up, there are so many interesting alternatives out there. Agile is something beyond the frameworks, it’s about talking with the clients and building roadmaps instead of contracts that fail.
The product team is interested in getting certified employees, instead of building product leaders and investing in people development. As the PM role is so complex and tough to manage, someone wants to give a strict role delegation and job description. The PM role will change as the Product Life Cycle changes, so there is no single job description for a PM.
It’s preferable to invest in empowered people that find solutions instead of command receivers, and have more people that interact with the clients because you have fewer dependencies on people. Yes, it will take you some time to reach this point, but you have stability and continuity.
Does it mean that a company that has PMs avoids the traps above? The answer is no, it may also try to hide it.
Does it mean that what POs do is not useful? No, it is super useful but I think it creates the misconception that products are about delivery, and separated discovery and validation from delivery.
Did ORFIUM build a good product team just because we went with PMs? No, it has been a long ride with many bumpings. I will follow up soon with many details on how we scaled our teams, and the challenges we are currently facing.
What should we do to change that? The 2 roles should merge under the PM role, and the product team should discuss with the engineering team how the delivery process can be managed more effectively, together with Tech Leaders or Engineering Managers.
The company should emphasize empowering the teams, especially for the phase of discovery and delivery, and allow the PMs to have a flexible evolution based on the Product Lifecycle.
I will elaborate on how having flexibility for the PM role is feasible and why it is important in upcoming posts.