Getting the green light to hire product managers is almost always a good sign. It means your company is growing, maturing, or diversifying its offering. It means more firepower is required, as the current team (or lack thereof) is no longer able to adequately handle product management as is. This moment also represents an opportunity to determine what an ideal product team would look like. A key question here is: what is the ideal product team size?
Even if you can’t hire everyone right away, having a vision for the structure, responsibilities, and desired experience and expertise you’d ultimately like to put in place is a worthwhile exercise. This way—despite the possibility that you can’t hire them all now—you know what you’re striving for. You can look for the right kinds of people that can both help immediately and long-term.
But what should your optimal organizational chart look like? Here are some factors to consider.
One for every “x”
A common tactic for sizing up the ideal product team structure is to look at what your company is building and assign a different product manager to each “thing,” with those things being each individual product, component, core function, etc.
Of course, engineering teams are also often divvied up along these lines, and each team should have a product manager working with them so they’re actually building what’s needed where it also aligns with the product strategy. That’s not a bad starting point, but some caution should be taken before blindly hiring and assigning a product manager to each and every dev team. For one thing, product development might have created its teams based on somewhat arbitrary elements, like personalities and egos of the engineers.
Also, there may be some engineering teams that simply don’t need a full-time product manager assigned to them. There’s only so much a product manager can add to a team working on “infrastructure” or “performance, “so you don’t want to put someone into a role where they will get bored or don’t have enough to do. For example, at Shopify, product managers typically manage two to three products instead of just one, focusing on building strong foundations for the engineering teams to jump off from instead of managing every single detail.
While it would be great to use this opportunity to reconsider whether development teams are properly constructed and allocated, that’s outside the scope of this exercise, but it is something important to consider before taking this approach. And even if your development teams aren’t organized along the business and functionality lines you’d prefer, there’s nothing stopping you from mapping things out that way within your own product team, even if it’s not a perfect match with the technical organization.
The product manager-to-developer ratio
Another method for deciding how many product managers a company needs is to base it on the number of engineers working on the company’s products. In 2007, Marty Cagan of the Silicon Valley Product Group said you need one product manager for every 6-10 developers, and today the “seven, plus or minus two” mentality is fairly pervasive (which makes sense given the Agile model).
This is really a Goldilocks-style conundrum: if the ratio is too small, the developers won’t be able to code fast enough to keep the product manager busy, and they’ll just be adding items to an ever-increasing backlog; and if the ratio is too large the product manager may not be providing enough details and interaction with the engineering team to properly guide its work.
But, like most things, it depends. “A functionally limited but technologically complex product will command a higher product engineers to product managers ratio than a functionally broad product that relies on simple technology,” says Gabriel Steinhardt of Blackblot. “Therefore, attempting to search for or calculate the recommended or optimal ratio between product engineers to product managers will always prove to be an elusive task.”
The product’s maturity is also a key factor; when you’re still trying to prove product-market fit and test hypotheses, a smaller ratio—maybe even 1:1—might make sense, while a well-established product with a solid customer base and set of functionality could support a much higher ratio.
Keying off revenue
While annual revenue is highly dependent on a company’s industry, solution, and target market, there are some basic trends that can inform product team size.
Not surprisingly, companies with the least amount of revenue tend to have smaller teams, with companies making less than $50 million most often fielding product teams with nine or fewer members. This makes sense, as these companies are smaller and don’t have as much money to spend on headcount.
When company revenues exceed $50 million, the size of the teams tends to jump, with more than a third of the companies boasting product teams with 10 to 30 members. As these companies are experiencing rapid growth, there’s a clear need for scaling and specialization.
But, once companies are truly established and are making more than $500 million per year, product teams actually tend to get a bit smaller. Since the product is mature and product-market fit has clearly been established, there’s simply less innovation required and the company can get by with a smaller, but still substantial product team.
Outgrowing the player-coach model
As a product management team gets built out, in the early stages the leader of the team usually still has day-to-day product management responsibility of some part of the product in addition to their team management responsibilities. But at a certain point, team management will become a full-time job and the player-coach will have to officially move into a management-only role.
Again, there’s no magic number of product managers that demand a full-time boss, but teams with lots of diversity in their individual responsibilities—not to mention those with more junior product managers—will need a dedicated manager sooner rather than later.
Figuring out this timing—along with determining if you’re ready to give up actual product management for, well, “management”—is a personal decision. And it’s one that should be considered relatively early on to ensure your part of the product isn’t being given short shrift and your new, expanding team doesn’t run off the rails.
Less can be more
When constructing your ideal product team, it’s best to play it safe and not bite off more than you can chew (or in this case, not hire more product managers than you truly need).
“In most cases, having too few PMs is better than too many,” says Ken Norton of GV. “It forces difficult trade-offs, streamlines decision-making, and avoids randomizing the engineers.”
Getting the most out of the talent you have, upgrading talent when necessary, and constantly assessing how everyone is using their time are just as essential as adding headcount to the product team. Particularly since product managers are often viewed as a luxury or expendable, you want to ensure everyone is in a position to succeed and being fully utilized.
Making an ROI case
Justifying additional headcount is always an uphill battle unless you are flush with fresh VC cash. It’s even harder for product teams, since product managers don’t fulfill a particularly quantifiable role. That’s why the business case for growing the team can often be made by starting with the costs.
Not having enough product managers can cause problems in several ways. First, if you don’t have enough people looking at how the business goals, market conditions, and product functionality intersect, you might end up building the entirely wrong thing. Second, if you don’t have enough product management resources, you can also be creating a huge bottleneck that leaves your developers idle or “winging it” based on an incomplete understanding of project goals.
But with appropriate staffing of the product team, everyone works together better. “Engineering will have their efforts optimized. The entire sales team, probably twice as big as the engineering group, will be able to shorten the sales cycle and generate revenue sooner. The support organization, under decreased load with be able to reduce new hiring. And, finally the customer base, who get their jobs done faster and are increasingly happy with the vendor, may decide to purchase more of that vendors product sooner than previously planned,” says Saeed Khan of On Product Management. Who says just a few extra product managers “will optimize the efforts of several hundred individuals, will increase revenue and decrease overall expenses.”
Staffing up for diversity
Finally, when designing your ideal product team size, you should also consider what types of people that team should consist of. Just like every soccer team doesn’t have 11 goalies on the field, you want a mix of industry experience, product management experience, business sense, technical savvy, marketing sensibilities, and sales orientation… which you’re not going to find all in the same person.
Hiring people with a diverse professional background will only increase the perceived value of your product team, since you will collectively bring that much more to the table. Additionally, your ideal team should also be diverse when it comes to age, gender, race, and cultural backgrounds, with a specific focus on making sure some of them look like your actual customers when possible.
Supporting a business, not building an empire
To some people (and in some company cultures), how many people you have reporting to you is a signal of your importance. But product managers especially understand the job of every employee is to support the strategic goals of the company.
That’s why, regardless of your product team’s size, it should be optimized to support the needs and goals of the business, not to pad your resume or as bragging rights. Managing people might be enjoyable at times, but it’s also a time-consuming drag in other moments.
So build out a team that fills needs and makes your overall organization more efficient. And once you’ve filled those slots, don’t get too attached… as the business matures and strategies change, the ideal team size may grow OR shrink. It all depends…
