AMA: Volley Head of Product, Roshni Jain on Building a Product Management Team

This can be a challenging situation as there are many places the 1-2 PMs could add value. I would recommend taking two filters to the workload. First, categorize the priority of the existing multiple products across the three horizons: * Horizon 1: Strong current drivers of value that need to be actively maintained, but are not expected to drive future growth * Horizon 2: High-potential products that are expected to grow in impact over time through more investment * Horizon 3: Emerging products that could one day drive significant value, but currently have a limited contribution Then, based on the skills and interests of the current PMs assign their capacity against these tiers. An initial allocation of all the PM capacity might look something like: * 70% Horizon 1 * 20% Horizon 2 * 10% Horizon 3 As the PMs are able to spend time on the Horizon 2 and Horizon 3 areas, they will mature and show progress and build a more compelling case. The capacity could then shift to something like 50/30/20 through the addition of more PMs.

There are only particular instances when, in my experience, it can make sense to have multiple product managers within a team. If your engineering structure is a squad/pod model where there is a dedicated set of engineers along on a core mission with clear ownership, I would most typically have 1 dedicated PM to this team. Instances where you could consider adding a second PM include: * Wanting to train another person in a specific area so there is an opportunity for future transition. The addition of the 2nd PM would be temporary and often someone more junior to the existing PM working on the team * Where there is a very large team and a Principal or very Senior PM working with them, it's a great opportunity to upskill an Associate PM or early career PM. They can own specific features or projects within the broader scope of what the team is doing, get mentorship from the PM and provide the team with more help. Typically this would also be a temporary situation. * A similar situation is where you have 1 PM working across two teams that are working on related missions - for example a search experience team and a search infrastructure team OR an Android app team and iOS app team. In these cases, a second PM can help with many of the more execution-related streams of work, but ensure there is still strong coordination and a single strategy at work. * There is a brand new project or feature that the team will be working on that is very different from what they've done so far. A second PM with expertise in this type of work, more familiarity with the customer problem, business need, or other engineering teams involved could be a good choice to work with the team on this specific project

I would work on doing both. When you start out in a new role it's important to get quickly up to speed, create a plan and start adding value. Most likely you'll see many opportunities to make things better now that are a light lift. So, I would add these best practices (could be simple things like getting a new tool, email updates, adding a new ceremony to the team), while you figure out the ideal team composition and start filling those roles. A potential way to think about this might be to pick several best practices you can embed in the first 3-6 months and start on those while you work on hiring and building the team. Do that in parallel and hopefully within those 6 months you'll have some new additional people you can work with on this.

This varies a lot based on the size and stage of the company - so it's important to think about: * Which audiences you want to communicate updates to * What level of detail each audience needs * What frequency each audience needs * What existing mechanisms and forums exist where you can make these happen Once you do this analysis, I would recommend starting with the most detailed and frequent need (perhaps it is to the other teams in your pillar who need good detail every week). Then use this to create the content for the other audiences and forums. You can then build a communication calendar that might look something like: * Weekly updates to the pillar via email * Monthly updates to the full group as a segment in the group all hands * Quarterly updates to executives and full company via a memo and company all hands presentation

PM to engineer ratios can range wildly from 1 PM to every 2-3 engineers to something 1 PM to 15 engineers. This largely depends on the size of the company and the type of product. In a more entertainment context, like a gaming start-up, you might have leaner engineering teams with more PMs to develop the ideas and concepts for all of the experiences. In a scaled big tech company you might require many engineers and teams to work across all the platforms involved, so the ratio of a PM and product initiative to engineers might be 1:10 or more. That said, the most typical ratios I have seen are 1:5. More technical the teams and products will tend to have fewer PMs and the more customer facing and experience oriented the product will tend to have more PMs