This is a short post inspired on a reflection I had while on holidays and some conversations during that period with some companies, related to the number of PMs that are required to manage products, and how often we tend to throw too many PMs to the problem.
This is not, under any point of view, a critic whatsoever to my previous gigs nor products. It’s more a feedback on when a PM can cover a wider scope and throwing more PMs into the equation could be a debatable decision.
Situation #1
This was my first real gig as a PM. Before I had spent some time being a Product Owner. At the time we were in charge of building a platform to handle multiple banking operations across the globe from many systems for one of the larges banks in the US.
The product had three different modules (to simplify):
This was the order we chose to build each module:
When I joined, the Calculation module was already in progress, and I had to took that over and kick-off the other two. Here is where we could have brought other two PMs to take care of the other two pieces. It could have worked, but to be honest, it would have slowed the entire development down. Why?
We would have been adding two levels of synchronization between PMs themselves and with the Director who was responsible for that platform and other products.
Also, since it was a entire flow that was well connected and “easy” to follow, it made sense that one person had the entire picture to move faster, connect all pieces, and then when the platform starts growing to incorporate more people. This was the picture when we start hiring:
When we decided to start building another product for the trading department that leveraged the data and capabilities of the platform already built. I moved to work on it, and we hired another person to oversee the entire platform.
As the only PM, I had to make sure that I was having a holistic view, while moving across the different components. Since the product has evolved incrementally, I knew what was required from the different pieces, which simplified the communication and development.
Situation #2
At Nexthink, since it was a quite complex and plenty of use cases, the story was quite different. Nonetheless, the story was a bit similar. At the Integrations teams when I joined we were organized in the following way:
Each vertical was covering a specific use case, and it has its own PM, which made a lot of sense. As you can see within the Integrations area, I owned the Outbound part, until the person running the Inbound and Platform left, and I had to be responsible for the entire Integrations’ scope.
Since that happened, I felt at east with the decision. I had to adjust a couple of dynamics. Moving from one team to three, could be difficult to manage if you don’t establish the right guardrails.
That change, helped to have a better view on the overall Integrations strategy. Thinking about the Inbound integrations triggered automatically the thinking of, how could this be also useful for other teams outside of Nexthink? And as a consequence, the common components we should build to support both types of integrations.
The same happened with the other parts of the entire product. It was easier to see the relationship of Integrations as a whole with the rest of the product, than just from the Outbound perspective (which was very limiting).
Situation #3
At Erudit AI, despite the small size, we had the similar situation. Our main goal was to reach PMF (Product-Market fit). This implies that you must acquire, activate, and retain users with your product. The structure look a bit like this:
At the time we were two PMs taking care of Activation and Engagement. I was responsible for the latter. Although both things were important at the time, ensuring a smooth activation and creating the habit to bring users back into the product, I had the strong feeling that one PM could have taken care of the entire experience.
I recall some situations where we had to coordinate to understand what has been done at the activation level, and see how that would be reflected in my area.
This structure resembled a lot to the previous two situations, where there was a clear flow with clear pieces that should fall, like a domino effect, to reach the expected outcome.
Counterintuitive
Someone might have argued that you need many people thinking on each of the phases, and it could be very complicated for one single person.
I strongly believe, that unless you have very different products or features, that require to change the way you think a lot, it is feasible to have the same PM covering the entire end-2-end.
Conclusion
Here are the common patterns I consider important for a single PM to run, which at first sight, could be a job for multiple PMs:
Clear accountability and shared responsibility among PM and engineers: One of the things that helped me in all situations to manage more than one area when I was a PM, was the support, seniority, and accountability from my engineer counterparts. I knew I can delegate some decisions and in some situations they did some “administrative” work, so that I could cover a wider scope.
End-2-End value stream: it makes a lot of sense that a single person has the overall idea of the entire workflow, if the product has this characteristics. If you have multiple use cases, it might be challenging to juggle between them.
It is more an art than a science: there is no a real playbook to know when one person can take care of a system that from an outside perspective. I felt in all situations that I was prepared, that I have all the context end-2-end to know what was required, and that the teams that I was interacting with were prepared for it.
Being there and done it, I’d resist the temptation to hire many PMs, just because you have multiple parts or areas for a specific product.
My advice is, if you really think you can cover the position without the need for hiring someone else, be outspoken with your boss, and establish a stopping criteria that would help you to avoid burnout and truly giving your best.