Allocating Pods to Product Managers
Product organizations fluidly shift to enable the business to tackle new opportunities and to serve new kinds of customers. In other words, product organizations are organic entities that evolve over time, so every product manager should expect to experience multiple reorgs over the course of their careers.
While this change is both necessary and valuable, some organizations perform better than other ones when it comes to reallocating their product managers. In this essay, we’ll explore one particular aspect of product reorgs: how product managers are staffed to product pods, and which kinds of staffing drive the most value for companies.
But, before we dive in, let’s first define what a product pod is, and why most pods are set up in the same way.
What is a pod and why is it structured this way?
A product pod is an empowered team of one product manager, one tech lead, and one designer, with multiple engineers on the team. This empowered team charts its own course, and has the ability to spin up or kill off any initiative that they deem appropriate.
The product manager, tech lead, and designer make up a product trio that will tackle a given business problem. The three of them are co-leaders and co-creators, and they have joint decision-making responsibilities.
The product manager is responsible for driving viability. That is, they’re the ones who decide whether the proposed functionality is solving the right business problem for the right kinds of customers, and whether the proposed functionality will likely drive the highest return on investment (ROI) for key metrics.
The designer is responsible for driving desirability. Their job is to ensure that users are happy with using the new functionality, and that they’re motivated to switch away from the old processes that they currently employ. Designers also need to ensure that the new functionality doesn’t detract from the rest of the existing product, and that the overall product looks and feels like a cohesive whole.
The tech lead is responsible for driving feasibility. Their job is to determine how to best build out the proposed functionality without causing issues to the rest of the code base. They’ll provide estimates on how much work the initiative will take, and they’ll identify possible solutions for accelerating the work or for ways to cut engineering effort without significantly sacrificing either scope or designs.
Of course, the three of them alone - product manager, designer, and tech lead - cannot possibly build out the entire product on their own. All of these features require software engineers to turn the idea into reality.
So, every pod usually has between 2-8 engineers to execute on the work. Once you have more than 8 engineers on a pod, it starts to become unwieldy to plan initiatives and to get the full team’s involvement in sprint kickoffs and retrospectives. Any fewer than 2 engineers, and you won’t be able to make enough progress on work to meaningfully move the metrics.
Now we know why most product pods are structured the way they are. But, how do product managers map to pods?
How should product managers be allocated to pods?
Product managers and product pods should map 1:n. That is, a product manager should have at least one pod, and a product manager can lead multiple ones (ideally no more than 2-3). But, a pod should never have more than 1 product manager at a time.
Since product managers should map to at least one product pod at a time, organizations should aim to have more pods than PMs. That said, it’s okay for some pods to have no product managers at the helm - many times, these PM-less pods have interim leaders (e.g. biz dev or engineering) who are in charge of the roadmap.
Any time the company decides to launch a new initiative, it should spin up a new product pod to tackle that opportunity.
I’ve seen too many companies try to put multiple focus areas into a single pod, but that’s a recipe for disaster. In other words, pods and initiatives should map 1:1.
A single initiative should never map to multiple pods, and a single pod should never map to multiple initiatives. When a single initiative has multiple pods, ownership becomes unclear and pods trip over one another. When a single pod has multiple initiatives, it can no longer focus and drive value.
When does it make sense to have a PM lead multiple pods, given that there will be fewer PMs than pods? Well, as long as that secondary pod takes no more than 10% of their time, product managers can stretch in to lead the pod part-time while they manage their primary focus.
This framework is particularly valuable for kicking off exploratory work for the business. That is, if we’re looking to leverage a new technology, spin up a new business line, or try out a new business model, we can allocate a fraction of PM time towards these efforts.
Since hiring a PM can take many months, we shouldn’t block the exploration of a new initiative solely based on PM headcount, or else our company will miss out on the opportunity to act. Rather, we can ask one of our more senior PMs to stretch in.
Of course, when we ask them to make this sacrifice, we need to set reasonable boundaries so that they can continue to drive their core product forward. Set the explicit assumption that the secondary pod will take no more than 10-20% of their bandwidth, and ask them to monitor that time allocation. Then, we monitor that bandwidth consumption.
Once the initiative has demonstrable traction and starts taking more than 20% of the PM’s time, we can then start to hire a new full-time PM to take over this work. From there, the stretched PM can then return to 100% focus on their primary pod.
Need help growing and strengthening your product management organization? Product Teacher offers workshops for product teams to grow and succeed in all stages of product maturity and organizational maturity.
The downside of having multiple product managers in a single pod
Many times, product leaders might be tempted to put multiple product managers on a single product pod. After all, spinning up dedicated pods takes time and effort, whereas moving product managers onto an existing pod takes much less time.
But the problem is that each product manager is going to have their own focus area. They will have their own charters, and their own objectives and key results (OKRs) that they seek to achieve.
That then forces them to compete with each other in securing resources from the shared pod, and this competition causes the pod to have to deal with the significant overhead of repeatedly switching contexts.
I speak from firsthand experience - having a single pod work across multiple product managers is a recipe for thrash. Engineers will have to bounce from initiative to initiative, and they won’t be able to consolidate their knowledge for a given user problem or a given business area.
When multiple product managers are staffed to the same pod, it violates the assumption that each pod will only work on one thing at a time.
But let’s say that you really do only have 6 engineers to staff against 3 product managers, and these 6 engineers were part of a single pod.
You could always split the pod into 3 separate pods, staffed with 2 engineers each. The pods that are split off will inherit the working processes and culture of the original pod, and so it’s not so bad to spin it up. And, now each pod has a dedicated charter because only one product manager is leading each pod.
It’s far more important that each pod has only a single product manager, rather than trying to maintain a particular number of engineers within a pod!
The downside of having product managers with no pods
Another kind of reorg that causes issues is when product managers don’t have pods to work with.
This can happen for a variety of reasons. One way that a product manager might be podless is if they’re tackling exploratory work to see whether we can spin up a new business line. Another reason might be that there aren’t enough available pods for the number of product managers on the team right now.
When a product manager tries to conduct exploratory work without a pod, they will get stuck. I speak from firsthand experience - when you don’t have engineers or designers to work with, you aren’t able to identify whether your idea will work or not. It’s nearly impossible to test a hypothesis, validate a spec, or even come up with a mock design to talk to customers with.
Even once I had spun up a case for increased investment in my product, we weren’t able to fund it because we didn’t have evidence. And, we had no evidence because no one had built anything, because there was no one available to build anything.
So, if you’re going to kick off an exploratory initiative, it’s okay to have no engineers on the pod (since there’s nothing tangible to build yet), but you still need to have a pod with a tech lead and a designer.
In our other scenario where the product organization has too many PMs and not enough pods, it doesn’t make sense to spin off a PM and have them do analytics work or product operations work.
This kind of work isn’t product management, and you’re doing them a disservice because they’re no longer able to hone their product craft.
If this happens, you have better alternatives. You can take one of these three courses of action:
Split up a pod so that the PM still gets to work with a very small pod
Seek a new home for the PM within the broader product management organization
Formally transfer the PM’s title, role, and responsibilities to analytics / product ops
If you don’t take any of these actions, your PM will regress in their skill sets and they will become dissatisfied at your organization over the long run. It’s far better to rip the band-aid off and provide clarity to everyone involved, rather than asking someone to carry out product management responsibilities with no pod.
Closing thoughts
Product organizations need to be able to shift to stay on top of customer needs and business priorities. But, not all reorgs are created equal.
The product reorgs that succeed are the ones where:
Pods are led by a single product manager rather than multiple ones
Product managers are in charge of at least one product pod
Every product manager is clear on when to ask for additional headcount so that they can focus
The product reorgs that inevitably cause issues are the ones where:
Pods are being led by multiple product managers
Product managers no longer have pods to work with
By ensuring that we keep these best practices in mind, we can empower our product teams to deliver value.
Closing thoughts
Succeeding as a product manager means proactively jumping into new spaces. Exhibit the best of yourself and your work ethic by showing interest, knowledge and initiative in committing to pre-application research.
Even if you don’t get this particular role, you’ll have gained extensive knowledge in a short period of time, which helps you build confidence for other kinds of PM roles.
Over time, as you exercise these skills, you’ll become an expert at analyzing open roles and companies, which will then improve your odds of standing out as a PM candidate!
Thank you to Pauli Bielewicz, Siamak Khorrami, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
