Creating great products isn't just about product managers and their day-to-day interactions with developers.
It's about how an organization supports products as a whole, the systems, the processes and cultures in place that help companies deliver value to their customers.
With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
Hello and welcome to another episode of the Product Thinking Podcast.
It's time for this week's Dear Melissa.
Every Friday, I answer all of your product management questions right here on the podcast.
If you have a question for me, go to dearmelissa.com and let me know what it is.
This week's question is all about how do we navigate multiple product managers accessing the same development team.
I think it's an interesting one, a very big problem I've seen in smaller companies.
Let's dive in.
Your dev team is shipping faster than ever, but your tools, they are still stuck in 2012.
Monday.com's dev platform changes that.
With Monday Dev, you get fully customizable workflows, real-time visibility across your development lifecycle and seamless GitHub integration without admin bottlenecks slowing you down.
Whether you're working in the platform or straight from your IDE, Monday Dev keeps your teams aligned, focused and moving fast, with AI-powered context built in.
Go to monday.com slash dev and see how your team can build without limits.
Dear Melissa, do you have any advice for a situation where there are multiple product managers accessing the same developer team?
We each have our own focus but are expected to share a developer team of seven.
From sprint to sprint, they rotate between our three areas.
Is this common?
My thinking is that the lack of consistency will slow down delivery.
Many thanks in advance.
This setup is unfortunately more common than it should be, especially in these smaller companies or during rapid growth phases.
So sometimes we've got all of these things we know we need to be working on, but we haven't hired enough developers to actually work on it.
You are absolutely right to be concerned.
Your instinct about delivery slowdown, it's completely spot on.
And this isn't just a product management problem.
It's an organizational efficiency problem that's going to affect everyone.
Because what's going to happen is that work's going to get delayed.
You're not going to have it out for customers.
And this is going to make it look like you can't deliver.
So...
What happens there?
A lot of times people come back and blame the product manager, because you're seen as owning that work.
In this case though, it is a classic case of context switching, and that is what is dragging us down.
So context switching is one of the biggest productivity killers for anybody, and especially for development teams.
So every time a developer rotates between these different areas, they're essentially rebooting or re-understanding the domain, the code base, the requirements.
They're going into different parts of code.
They have to get back up to speed on it.
Maybe somebody added a whole feature over there and now they have to go learn what that feature is about.
This is going to make them start and stop so much that you're losing all of this time to context switching.
So again, yes, is making you slow down.
It's not just about the technical context too.
We have to make sure that it's like the product context, right?
Developers have to understand the product context.
They have to understand the users.
They have to understand strategic reasoning behind things so they can go out and make decisions in the moment when they're coding.
You don't want to make it so that a developer comes back to you and ask you every tiny little, nitty gritty thing, because they don't have wider context.
So making the context this huge makes it really hard.
Think of it as asking a writer to like switch between writing a romance novel and then a technical manual and then a legal brief every like few weeks.
That cognitive load is just really enormous.
We've seen in research as well that it could take 15 to 25 minutes to fully refocus after switching tasks.
So then think about that with development work.
It could take hours or even days to get back up to speed on a different domain.
So you're probably losing like 20 to 30% of your team's productivity on just overhead here.
This is where quality will start to suffer too, because there's no ownership over the different areas.
And when you lack that ownership, you're not really looking at, can I make this better?
Can I make this more streamlined?
Can I make it simpler?
Can I fix these bugs?
There's more miscommunication too.
So what happens when you have a team of seven and you've got three product managers?
You ideally want dedicated teams focused on these specific areas for extended periods.
Now you've got this team of seven, but that doesn't mean that specific developers can't be dedicated to your different areas.
And this is where a great engineering leader really comes in.
So what an engineering leader should be doing is looking at the team and saying hey, I'm going to have these two people right over here, kind of focused on this work because it requires this much effort.
They're really good at these areas.
They can get up to speed.
Maybe their skills are a little more front end, let's say, and it's a front end thing.
These two developers over here might be working on this.
And they're proportionately supposed to be looking at how much effort it's going to be, how strategically important these different areas are, because not everything is created equal.
I'm sure out of the three PMs that you have in your company, some are working on super critical stuff.
Some might be slightly less critical.
That's what a great engineering leader should be looking at is how do I distribute the team appropriately that way?
And that's okay.
Even if you have two people fully dedicated, maybe there's something where, like somebody floats, I don't know to spike on something.
That's going to be way better than somebody, everybody switching everything all the time, right?
You don't want that.
You don't want that.
So with the clear ownership, it creates accountability.
It makes sure that they have deeper product thinking there.
They'll be able to make decisions on their own a lot better.
So that will free your time up there.
All of those things are going to make you go a lot faster.
It's going to be a lot smoother.
So even with just seven engineers, you can probably work this out.
Now, I want to say this as well.
You've got three product managers and seven engineers.
First of all, like a bigger issue here is that ratio is just way off, right?
That is not a typical ratio.
We typically would see one product manager to every, I'd say five to seven engineers.
Sometimes I see nine engineers.
Those we would typically split out into two teams, but they would be highly related to one more complex project or area.
That's highly related.
So maybe you have one product manager over those two teams, but typically they're going to be working like that.
Three to seven is like, that's an insane ratio.
That's just, you have way too many product managers for the amount of developers you have.
You should be.
If you have that much work that the product managers could be working on, you should hire more developers.
In the absence of that, you should be splitting out the developers so that we have ownership there.
So I would take that back.
There is literature out there about the good ratio of product managers to developers.
I would take that back to leadership too.
If you want all of these things done, we really need more people to be able to work on it.
That's a great way to put it too.
PMs make great investors.
If you're a product leader curious about angel investing, check out AngelSquad.
It's where over 2000 operators from Google, Meta and Apple learn to invest in high growth startups alongside hustle fund.
I've been a member for years and highly recommend it.
They've given me a few 30 day guest passes to share.
So head over to go.angelsquad.co slash Melissa and make sure to act fast as the passes are limited.
You can do all of this with your development lead as well.
I've worked with companies where we have tracked out how much time things wait in queues or how much time we lose to context switching as well.
And we've gone back to management and we've shown it to them.
We're telling a CEO of a startup like you need at least five more people if you want to accomplish these things on your list.
Otherwise we have to draw a line, right?
And I need them to be dedicated to one thing, or I need them split to these two things, but you can't have them all.
That's where you push back and that's where you have to use your product management sense and your negotiation tactics and your influence there to get them to see that not all of this can be accomplished with the size team that you have.
So I would really heavily lean on your development lead.
I'm sure they're not happy about you context switching like crazy.
And I'm not saying to you that your developers have to be completely dedicated to certain areas for the rest of their lives, but at least a year that would be good, right.
They might rotate a little bit on things that are adjacent, but usually you want teams around certain areas for at least a year to make meaningful progress.
In a startup.
Maybe it's a couple months to six months quarter that they'd be working on those areas.
But you want them to be able to go deep, right?
Without that, you're going to lose a lot of things to waste, right?
That's the cost of handoffs, transitions, getting back up to speed.
And if you're in a small company, you cannot afford that.
Startups win on speed, right?
That's what we're doing.
So track that cycle time.
Track your bug rates, track your delivery delays.
Start measuring the real cost of how you're operating right now.
Your development lead should be able to help you with that.
Document as well how long it takes the teams to get productive every time they switch.
Ask your developers if they even like it.
Have a conversation with them about this, right?
Look at velocity differences.
If you have an area where people are focused versus where they're switching, you can use that as well.
But recruit these developers to work with you, to build this case for the leadership team to say hey, This is not how we should be working.
We either need to hire or we need to re-scope down.
And it sounds like if you have two other product managers, you've got a lot of stuff in the pipeline.
It sounds like it's time to hire.
It sounds like it's time to bring more people in there, but present these options to leadership so that they can make the informed choice.
Present the trade-offs, present all of this stuff so that you can get the buy-in that you need because you are correct.
This context switching is definitely slowing you down.
So I hope that helps.
And again, if people are listening to this and you say hey, I got a question I would love Melissa to answer.
Go to dearmelissacom.
Let me know what it is.
We will be back next Wednesday with another amazing guest on the Product Thinking Podcast.
Make sure that you like and subscribe to this podcast so you never miss an episode.
We will see you next time.
