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.