What are the key processes you'd set up when expanding the PM team from 1 to multiple people?

I'm going to suggest a few processes, but please do scale each process to the size of the organization. Treat your processes like you treat your product - establish 2-3 internal customer problems that are actually worth solving, and solve them with an MVP of a process and iterate as you learn - don't try to introduce everything at once.

• Quarterly priorities: Getting into the habit early of writing down the plan for the quarter is a good muscle to build early in establishing the PM discipline even with only a handful of PMs.  Focus on articulating the big bets for that quarter and the value delivered, written in language that peers and leaders can understand.  A key aspect of this is establishing OKRs each quarter to ensure alignment across the team, and cross functionally to drive product and business success.  Incidentally WorkBoard is an awesome tool to enable this
• Specs: Writing things down avoids late churn.  It allows articulating the why and the what for a feature.  Engineering can start work in parallel with some details getting ironed out (not a waterfall process), but the why and success metrics should be clear up front
• Design / Experience walkthroughs: Notice I'm not calling these reviews.  Reviews indicate a level of red-tape that is not necessary on smaller teams, but it's still critical to get feedback early from stakeholders, leaders and customers, so start doing design walkthroughs earlier rather than later, and you can avoid major churn later in the product development cycle

Team meeting: Reserve some time each week (PM only or PM+Design depending on team size) to look at the tactical work happening, what's coming up, concerns/help needed as well as to celebrate small and large achievements.  As PMs we often forget to celebrate the good, so make space for this.

Expanding the team from 1 to multiple people comes with a set of pitfalls that I’ve learned the hard way. And many other factors such as Org culture, line of business, product lifecycle etc, have a telling effect on the type of pitfalls you’ll encounter, so take this with a grain of salt. Here are a few things worth considering -

• N degrees of separation: The larger your org grows, more layered your teams are (typically). Ensuring that you and everyone on the team feel connected to each other in a meaningful way is super critical. Here are a few tactical things you could do -
• Regular team meetings for sharing broader context
• Async modes of information dissemination (via ‘Top of mind’ type notes, ‘bite sized’ videos etc)
• Skip level 1:1s at a certain cadence to get a pulse on the ground (and also to get feedback about you)
• Curating culture: I recently read somewhere that team culture is nothing but ‘Behaviors you reward and behaviors you punish’. As your team grows you’d want to ensure that the culture or identity of your team is well understood and reinforced regularly. Coaching your managers/leads on that front should be top priority because they ultimately play a key role in sustaining that culture.
• Delegating decision making: When you manage a small team, typically a lot of the decision making (and tie breaking in terms of conflicts) comes to you. As your team grows there might be a tendency to follow the same approach which you should discourage. Empower your sub-teams and sub-team leads to take ownership. Have a clear sense of when you want to get involved. Here is the framework I use:
• Just inform me as FYI for X set of topics
• Seek opinion from me for Y set of topics.
• I’d like to be the approver/decision maker for Z set of topics (ideally this is a very narrow list)
• Goal mapping: As the org/team grows ensuring everyone’s work ladders up the org level goals is of paramount importance. In our roadmap templates we have a way to ‘map’ each team's goals to the org level goals. The teams articulate how their deliverable move the needle on the org level top line goals.

Here's how I'd think about it:

• Some planning cadence where strategy and roadmap can be reviewed at different levels of fidelity. (Annual, Quarterly etc.)
• Product review with key cross functional stakeholders that isn't viewed as a gate keeping exercise but a feedback process and of course has PMs giving each other feedback
• Experiment review where the focus is creating excellent hypothesis, treatment arms, and making sure you can measure what you need to
• Cross functional discipline review and the two most critical ones are UX review that is of course led by the UX team and Launch review

Now these are critical processes even if the PM team is just 1 but the importance of them just grows as you expand the size of your team and these are often the bedrock of how you keep the trains running on time.

The most important process you can set up is a retrospective of some kind. I talk about this in more detail in another answer, but as you add people, ensuring that you have ways of sharing and improving your processes is fundamentally important.

Any process you introduce should have a strong reason for existing. While company breakpoints might point to the need for specific processes at an organizational level, within a small product team it's less prescriptive. But since you're product people, you have tools for this! As your team grows, start by identifying the problems. Once you've defined the problem, you can add process to address it. You don't need to reinvent the wheel on the solutions; someone else has certainly solved this problem before! But understanding the specific problem your team needs to solve is essential.

Quick reference list of processes you may need:

• RACI matrix
• Shared product definition documents (Product Brief, PRD, etc)
• Clearly articulated user stories for engineering
• Mocks/designs attached to other documents
• Cross-team/cross-functional standup meetings

Here are a few common examples problems that growing product teams experience, and possible solutions to them. 

Problem: Who Does What? When you're small, you can all just pitch in. As you add people, you need to add clarity about where one person's responsibility ends and another's begins. 

Solution: A RACI matrix is a good, simple tool to clarify roles and responsibilities. A quick meeting to agree who is Responsible, Accountable, Consulted and Informed can go a long way.

Problem: Cross-team visibility. With one PM, you have one person who knows everything that's being worked on. As you add more PMs, it can be hard to keep track of product activities.

Solution: There are lots, including buttoning up your roadmap. A "scrum of scrums" style meeting can also be great. This is a term borrowed from Scrum, where representatives of each team gather for a standup meeting on a regular cadence (usually once or twice a week). Keep it standing, keep it to 15 minutes, focus on what each team is doing now and where there are blockers. 

Problem: Decision tracking. So many decisions are made every day in software, and losing track of them is a huge pain point!

Solution: For a single project, a decision log can come in handy. But if your problem is that you don't know what decisions are made about the product direction or implementation, it might be time to review your documentation overall. Make sure that teams are creating and maintaining product briefs (or Product Requirements Docs), associating them with the latest design mocks, and reflecting that work in user stories/engineering tasks.

Adding every new member to the team adds friction and operation overhead increases. You will need to set up processes that allow the team to operate independently and work with each other effectively and efficiently. Your main job will be driving alignment within the team and across the organization, along with coaching and mentoring the team. 

You will need to make sure every team member has a clear area of ownership, can articulate product vision and strategy effectively, and understands product goals and objectives. You can achieve this by having a product operations framework in place. The product operations framework should have guidelines for gathering customer, data, and competitive insights, building and communicating a roadmap, and effectively working with the stakeholders from different parts of the organization to build, launch and iterate. Besides setting up these guidelines, you will need to set up some structure on how decisions can be made and what needs to be communicated by the product manager and how.

Make sure you have the following recurring meetings in place to give the product team the time they need from you as a product leader -

• Weekly or bi-weekly team meetings to share regular updates with the product team
• Weekly or bi-weekly product brainstorming meetings where discussions can range from strategic to tactical depending on the need
• Regular 1-1 with the team ideally weekly
• Regular meetings with product development leadership to discuss progress and blockers
• Quarterly product review meeting with stakeholders from GTM and leadership
• Regular meetings with the marketing team to share product updates and collaborate on launches
• Regular meetings with the design team to brainstorm new ideas and define research and validation plans

There are a few that I consider important to set up (and refine) as you grow your team:

1. Processes for top-down sharing: As your team grows, knowledge sharing becomes harder but also more critical. PMs can only do their best work when they have context about conversations and updates from across the organization. For instance, "context" could include new product updates, changes in company strategy, takeaways from executive conversations and board meetings. I'd explore ways that you can provide this context either synchronously (e.g., through a team meeting) and/or asynchronously (e.g., through a "here's what's top-of-mind" slack message or email
2. Processes for upwards sharing: It's important to also think through the best ways for your team to share what they're working on (product updates), but also for them to share feedback on how the team is operating (upwards feedback). This is necessary with a smaller team too, but in larger teams becomes more challenging to do this ad-hoc and 1:1 - additional processes like a recurring survey or a shared product launch calendar. Keep in mind that this is not just important for you, but for the entire PM team and XFN partners too, so be sure to do this in a transparent way.
3. Team-building processes: Often overlooked, these are important to increase the cohesion and connection that your PM team feels. I like to use a weekly meeting or a private slack channel to share wins, talk about product news, share personal updates. It should feel like a trusted space for your team to share their thoughts and get to know each other more personally. Also, in today's remote climate where team members can often feel more disconnected, you might want to think through team rituals (e.g., beginning of every meeting with a win, learn and a "smile" - something that made you smile in your personal life) and in-person bonding (e.g., as a team, we meet in person once a quarter).

A helpful tip - carve aside 30 mins each quarter to also do some "housekeeping" of your team processes. Audit what's working and what's not, which meetings are useful vs. not, what are themes from your team surveys. Iterate on your team processes just like you'd iterate on a product!

More often than not, we are in scaling phase as a company/group when trying to expand from 1 PM to multiple PMs, I want to ensure that following is in place:

1. Clearly defined roles & responsibilities for PM

   • What outcomes we want to drive

   • what processes we want to develop

   • what skillsets are must have and nice to have for the PMs

   • Clearly defined interview / hiring process

   • Well-defined onboarding process

2. Clearly outlined process for PMs to add value:

   • Well defined product validation and product execution processes

   • success metrics for PMs

   • widely communicated and common understanding in the company on what PMs bring to the table

   • supporting orgs such as Product operations or data analysts ( if not clearly outlined expectations on what tasks PMs need to fill in because we are missing other roles )

I'd first focus on setting up a robust planning process so that no matter which PM other teams are working with, they know how to make requests and how they'll be handled. This includes:

1. A clear milestone planning process where each PM summarizes and communicates what their teams will be working on for each milestone.

2. A lightweight intake process for bugs and feature requests, so that requests are captured in the same place and with the same high-level information.

3. A consistent quarterly prioritization process such as OKRs.

While there are other key processes, I find that the most important at first is making it easy for other functions to work with product and these 3 cover a lot of ground around how to make an ask, how to know if it's been prioritized, and knowing what major things to expect to be delivered over a quarter.

First things first: work with your team to create processes. Much like a building a product, a product leader should interview their team to understand their pain points in the way the team is being run. Processes should be solutions to your team’s problems, much like your product is a solution to your customers’ problems.

The ones I have established and found most useful in the past for my PM team and myself are the below:

• PM team meeting: solves the problem of not feeling part of a team. Agenda-based for outstanding topics (eg « our annual conference is soon, are we all set?) + learnings from customer conversations about the entire portfolio + updates on everyone’s work streams/product areas. This helps with connectedness because PMs get to chime in on each other’s product areas and help each other with feedback and suggestions on next steps. Also it incentives customer conversations for each PM every week, and on the entire portfolio as opposed to on their area of accountability.

• Product experience review meeting: the agenda is a walkthrough of new experiences that are being built for customers, internal or external. Presenters are PM + their engineering and design counterparts. The meeting is ran by the PM manager with their eng and design managers attending and other stakeholders present. Wireframes, low-fidelity or high-fidelity prototypes are presented, discussed with leadership for feedback, information or decisions on options. This solves the problem of leaders not being able to attend every team meeting when the portfolio gets big. It also solves the frustration of PMs asked to backtrack late in the process when coding is ongoing.

• Quarterly planning meetings: a batch of 3 meetings over 3 weeks timeframe, weekly. First meeting is to discuss opportunities prioritized. Second meeting is to review a long-list of prioritized solutions, the last meeting is the exact list of solutions to be built during the quarter. This solves the pain of the team feeling lost on the path towards clear OKRs and it releases the pressure on the team because they are collaborating with leadership from the beginning.

Great question and I'll give the starting place because with each step function in growth comes another set of process challenges.

Leveling guide along with the competencies you're looking for so you can hire great PMs based on what you need. If you hire great PMs and set the right expectations with them then the rest of it is easier to work through as you learn about your team challenges.