What is the most effective way to scale a Product Management team beyond the first Product Manager?

I have been a part of small teams, large teams, a PM consultant and an entrepreneur. I have yet to scale a PM team beyond the first PM but here are the things I would consider:

• Structure your team based on where the company will be in a few months/years—hiring should reflect the company’s vision and serve as a blueprint for where the business is headed.
• Ideally, each one of the identified goals above would have a subject matter expert (e.g. a retention PM, a growth PM, a localization PM, an Enterprise PM, etc). As the team scales, you'll be able to move away from hiring generalists and seek experts who have deep domain knowledge.
• Consider training young PMs through an internship program. This will give you the opportunity to mold your PMs and instill your preferred process early on.
• It’s never too early to define a set of guiding principles and establish a process. Shaping the product team’s DNA at the onset will pay dividends as the company grows and consistency is maintained.
• Hire with diversity, equity and inclusion (DEI) in mind: a diverse team means broad perspectives and creative ideas. It is not only the right thing to do, it also helps businesses innovate at a faster rate and reach financial success.
  

The simple answer is to hire PMs :) .  That said, I'm assuming you are asking more of how to structure the team to scale to the needs of the organization as you hire

• Define the discipline: Hire PMs that align with your definition of product management. You'll also need to setup the discipline (see my answer on establishing the function)
• Enable each PM to own their area of the product or business end to end as you set up the team.  This is crucial.  Often this means aligning PMs to specific personas or specific products that your company has.  I personally tend to avoid aligning an organization to the technology pieces, instead focusing on the end to end experience across all layers of the stack, so the value delivered is clear.
• Keep the team at an appropriate size: I like to see PM teams run lean.  This forces good prioritization and focus and prevents slicing the areas too much.  That said, lean does not mean stretching PMs so thin that they have no time to think ahead and become only reactive.
• Don't forget about design: Also start investing in the design organization so you keep the PM and design teams in balance.

This is a situation that our team went through last year, scaling from 2 PMs to 10 over 12 months. Before hiring any additional PMs, we first took the time to survey the teams that existed in our current state. We reviewed the tools they owned, their missions, their place in the lifecyle of the motion that we support (Quote to Cash), and made our decisions from there. Certain teams needed to be consolidated, others needed to be created, and some simply needed more structure.

With a plan in hand, we outlined our most critical hires; we focused on Senior Product Managers that could take our initial vision and existing teams forward. The goal was to stabilize core areas of the overall set of products that we owned first, which would buy us time to expand on that vision and thoughtfully set up the new structure. For areas that were lower risk, or that had established Engineers leading the team, we brought on PMs, knowing that they would have more room to figure things out. Finally, once SPMs had established stability over the teams they were brought on board to lead, we added APMs to ensure a healthy pipeline and create opportunities for those looking to break into the space.

Building with intent is key. As a first PM or TPM, you are often running a one-person show. You wear multiple hats and you tend to be scrappy, flexing to what the business needs you to do. That approach works wonders up to a certain scale but soon exposes its flaws. When you think about scaling out from there, here are a few things to consider -

• Understand your business (replace with org or product team) needs deeply, ideally the 1 to 2 year trajectory of where it is going. That’ll tell you what type of product person you need to hire next. Someone with augmenting skills (Growth PM to scale out in new markets) or complimentary skills (a Technical PM to build better platforms)?
• Hire strong leaders in advance. Some take the approach of waiting until the teams grow to a certain size, before they hire leads/managers. I’d suggest the opposite, for a few reasons -
• Strong Product leads think big picture and know how to design orgs for the future
• Coming in early gives them the opportunity to grow product expertise better. They get to be a part of the evolution of the product which is critical
• They are good at hiring too
• As much as I advocate for hiring strong leaders early on, promoting talent from within is equally important. Look into your cross functional teams to see if anyone might be a great fit for product roles on your team. One of the best Technical PMs on my team was a Data Scientist 4 years ago.
• As your Technical PM org grows, there will be overhead in terms of decision making, co-ordination, communication etc. Optimizing your org design to minimize such overheard to the best extent possible is useful.
• Aligning with your business structure and locations is an obvious one.
• Ensure diversity. This is often an area where orgs struggle. Hiring more of you is not a great recipe for success.

Finally be open to updating your org/team design as business and people grow.

The first PM hired into a company, or in a division of a company, will usually be an individual who can wear different hats on any given day. (see one of my favorite product management graphics: https://medium.com/@productboard/the-many-hats-of-product-managers-4692aab2fff) The decision to grow and scale the PM team beyond your first product hire is made after discussing needs and opportunities with stakeholders, but also by gaining important insight from the existing PM that's been working in the trenches. 

When deciding who the next hires should be, I've found it helpful to first validate the problem and opportunity landscape and map out the pillars of your product strategy, e.g. systems, tools, applications, infrastructure, data, end user touchpoints, etc. It's obviously challenging to add too many people at once, so you'll have to prioritize the first couple hires and balance need, impact and culture. Remember that your PM team in the early days is a reflection of you as a leader, you are essentially scaling and complementing yourself to expand the team's overall strengths. I can't stress culture enough in the early stages of building a PM team. An unhealthy culture can make or break your ability to establish cross-functional trust which is super important from day 1. 

I'm not sure it is the most effective because I've really only used one strategy, but it has been effective for me.

1. Grow your own scope, take on more than you can handle, do a good job of pitching the problem space and opportunity and get broad consensus that this work is critical and required.
2. Then make it clear and obvious that to succeed in this new problem space it will require you to drop a piece of your current scope that is critical
3. Hire for that role

In particular something I'll note is that the best thing to give up to grow a team is the thing you're closest too. The thing you know best. It'll be the hardest thing to give up, but in doing this you help guarantee that the person you hire is best set up for success and that you'll be a good manager/mentor for that person.

Contrary to popular belief, it's not about writing a job description as fast as possible and starting to hire! It's important to spend some time upfront thinking about the team you are trying to build:

1. Define your team structure: Think about how you want to set up your product team - what are the main product areas to be supported? What areas might grow down the line? What areas need specific skill sets? It's helpful to give each PM a clear focus, in terms of user they're focused on and problem they're solving rather than a clear feature. For instance, when I worked at Pinterest, we were much more interested in hiring a "Discovery" PM rather than a "Homefeed" PM. At Figma, we hired for a "Collaboration" PM rather than a "Comments" PM. You don't want your PMs attached to features, you want them attached to specific users and their problems. Features come and go, problems don't. 
2. Define your PM competencies: Think about the attributes you care most about as a PM. Is your company exceptionally data-driven, and therefore candidates needs to be analytically savvy? Is your company a B2B company and therefore candidates need to be business-oriented and able to interface with Sales? Factor in the skillsets you already have on your team - if your team is already highly technical, do you instead want to complement your team with more creatively-oriented PMs? What domain knowledge is necessary for each role? Write down the attributes you care most about, how they'd evolve for different levels of seniority and how you'll evaluate candidates on them. This is absolutely critical before you start hiring so that you have an objective and clear interview process.
3. Build your pipeline: Create your job posting, and promote it across LinkedIn and other job sites. Start to talk to candidates both formally and informally (reach out to interesting folks on LinkedIn and make connections). For senior roles, often times you need to keep conversations going with candidates for a until they're ready to interview. It's better to wait to get the right candidate than to make a hire decision in a hurry. Also, it's a good idea to get folks within your company to refer people in their network - amazing people often know amazing people! Create a referral program and spread the word.

Once you have these pieces in place, you can start interviewing to find the right candidates. I'd suggest that until you have a big enough team and enough confidence in specific PM hires who understand the business/role well, that you limit hiring responsibilities to a very small group to start so that you can maintain a strong and consistent bar for the type of talent you hire.

Setting up the right culture is what matters the most, rather than the numbers of product managers.

Product Management is a function, and you can find that other people in the team are actually taking care of tasks and scope even if there is no dedicated product manager. It's hence super critical to work on the culture and how you want to build products with engineers, designs, etc., as they will be the best help when you will actually need to hire more product managers.