What is a good product manager to engineer ratio to maintain as you scale?

The ideal product manager-to-engineer ratio can vary depending on the nature and complexity of the products being developed, the size and stage of the organization, and other factors such as the development process, company culture, and resources available. However, a common rule of thumb is to aim for a ratio of 1 product manager to 8-10 engineers.

This ratio provides enough product management oversight and guidance to the engineering team while allowing engineers to have enough autonomy and ownership over their work. As the organization scales, this ratio can be adjusted to maintain the appropriate level of oversight and support for the engineering team.

PM to engineer ratios can range wildly from 1 PM to every 2-3 engineers to something 1 PM to 15 engineers. This largely depends on the size of the company and the type of product.

In a more entertainment context, like a gaming start-up, you might have leaner engineering teams with more PMs to develop the ideas and concepts for all of the experiences.

In a scaled big tech company you might require many engineers and teams to work across all the platforms involved, so the ratio of a PM and product initiative to engineers might be 1:10 or more.

That said, the most typical ratios I have seen are 1:5. More technical the teams and products will tend to have fewer PMs and the more customer facing and experience oriented the product will tend to have more PMs

To me, this is less a question of literally number of PM bodies to engineering bodies; that depends on the company, its context, the complexity of its products, and many other factors. Instead, the way I think about this problem is mapping PMs to the number of logical domains within a company's product. A senior+ PM should be able to own a single domain, with its own KPIs, goals, and product strategy. Typically, this aligns a PM with an engineering manager over that domain, and underneath that EM can be multiple teams -- perhaps 2 or 3 pizza teams.

Then, what my engineering director/VP counterpart and I watch for is how the domains are scaling, and when they need to be subdivided because they are getting too complicated for a single PM/EM pair to handle. I do not make arbitrary staffing changes in PM without discussing it with my engineering peer, because otherwise it creates chaos and confusion.

I believe the most efficient teams are usually 10 people maximum, including engineers / design and PM.

So I like to have 1 PM for 7-8 engineers + 1 designer, to make a team of 10 people maximum.

This is not a strict ratio to respect, sometimes it can be a bit less or a bit more, but by experience this has worked well for me.

I'll share a few examples from my career that I've seen, with some context. In the end, PMs don't just do one thing, so their bandwidth will vary based on what the team needs from them and what support they have.

1. As a new PM at a ~200 people startup, I started by working with 3 engineers. We didn't have a designer on the team, and I had to do a lot of work to write very detailed product specifications, project manage delivery of initiatives, test solutions, etc.

2. As I became more senior at that same start up, got a designer on board, testers, etc. I scaled up to about 10 engineers. Towards the end of my tenure there, I was leading the efforts for 15+ engineers across 3 groups, but that was only possible because we were working on a few major initiatives with a lot of backend requirements (search ranking algorithm updates, etc.) that didn't require a lot of PM input. We had senior engineers and engineering managers that would translate the requirements into very difficult engineering projects so I was free to work on other efforts.

3. When I started working in a smaller team at Google, I started by running one team. I was one PM covering ~4-6 engineers. In that same team I later on moved to cover 2-3 groups, each of ~4-6 engineers. Again, though, this was only possible because I had a mix of teams, some with more backend heavy work that didn't require as much PM focus. Each of the engineering teams had very strong engineering managers, too, that owned delivery timelines, and a technical program manager that oversaw all major deliverables.

4. I then moved to a different team at Google, working first with 5 engineers, later on expanded to ~10 engineers. Half of the team, however, was focused on app reliability and performance and fixing old bugs.

5. The later examples keep repeating the same themes. I'd start with fewer engineers and expand over time, the longer I stayed on the role, but mostly covering a mix of heavy frontend work, rapid feature iterations, and some groups or engineers with heavily backend focused initiatives.

6. At GitLab, we aim for one PM per Group, each Group has ~5-8 engineers, an engineering manager, a dedicated designer, and support from quality and technical writing.

With all that in mind, I'd say: strive for 5-10 engineers per PM, taking into account what support the team needs.

1. If the team has a lot of lengthy projects and/or backend heavy initiatives, a PM can typically stretch to cover ~15 engineers.

2. If the team has a lot of frontend initiatives with fast iterations, the PM may be fully consumed with ~5 engineers.

3. However, if you have a strong UX designer and a good engineering manager that owns feature delivery timelines, a single PM can expand to cover 8-15 engineers worth of work.

4. The longer that a PM is on a team, the more groups/engineers that they can typically cover due to familiarity with the product area and established working patterns.