There are a few that I consider important to set up (and refine) as you grow your team:
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!
Here's how I'd think about it:
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.
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 -
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 -
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:
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.
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.
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.