How do you structure your Product team? How big is it, what does everyone do? How do you measure success of each function/person?

My current product team has about 40 PMs (And we are hiring!). I would not dive into what each of the team does, but maybe talk about how we went about structuring it, which may be a more transferable skill.

When I first joined Meta my VP asked me if the current team structure is the right one. Naturally, I did not know the answer. Frankly, I don’t think it was the right question for me to answer at the time.

Instead, I engaged with the team on setting a 3 year plan - Write down what our strategy is, at a high level, and what are the key milestones that such a strategy would hit, if successful. This happened both at the org level and for the individual teams in the org. As the team presented the strategy to the stakeholders we started seeing some gaps in our org structure and the team leads started to raise a desire to organize differently. We recently re-organized the team accordingly.

Setting a direction was a critical prerequisite before talking about team alignment.

As for measuring success, it goes a bit to the first question I answered - I expect each team to define their own strategy, then set the milestones of that strategy. Our discussion can then be focused on the three elements I highlighted:

• Strategy: Was the team able to set a good strategy?
• Execution: Is the team hitting the milestone? If not, is it because the execution is not tight, or because the milestones are not achievable and we should pivot? This is a very important distinctions that some people are missing - A team can be executing really well and proving that the strategy is the wrong strategy. Being able to prove that point and move on without wasting years of struggles is a big win!
• Org health: Are we hiring well? Growing talent? Retaining talent? How is the cross functional relationships going?

Classic product management answer: it depends!

If you are talking about structuring a team of product managers, I've led teams where PMs were part of a cross-functional team dedicated to a specific product or PMs that were more platform focused.

One thing that I always want to make sure of is that my Product Managers is that they have end to end responsibility for a product or feature. PMs are measured by the outcomes that they achieve and not by their outputs. I therefore measure PMs by the desired changes in customer behaviour; doing more or less of a specific behaviour. 

I often think in terms of leading vs lagging indicators here: outcomes that product development can influence directly (leading indicators like customers successfully setting up a new product) and outcomes that they've got an indirect influence on (lagging indicators like revenue or profit).

My current product team consists of four direct reports who are all senior product managers. My job as a director is to create distinct areas of responsibility (AoRs) for these PMs to deeply understand customer problems, conduct discovery and research with their design and engineering (tech lead) peers, scope and propose initiatives, and then greenlight them to go on the roadmap only when we have sufficiently reduced the level of ambiguity that we know how such initiatives will move the needle on our product.

I measure PM success not only by the level of adoption of their initiatives but also how well they work cross-functionally to orchestrate their work. As the scope of a PM's responsibilities grow (i.e., they rise through the ranks), I naturally expect them to "touch" more functions across the organization, have larger and larger areas of responsibility, and at very senior levels, be able to propose new business or markets that we might enter, and justify this with generative research (finding their own domains rather than me needing to hand out domains).

I have several peer directors that work on other distinct, but related, areas of the product -- the org structure is very much a "reverse Conway maneuver" as described in Matthew Skelton's Team Topologies, to deliberately minimize the surface area of communication that is necessary with other functions. All of us report to a VP of Product for the product unit who is essentially a general manager over the group, including understanding P&L.

I have PMs who work on both horizontal objectives across the organization (e.g., observability, security across all products) and responsible for certain product verticals (e.g., the product/feature we sell). 

Most of my 10 member team is responsible for solving a customer problem through their product vertical. I have one PM responsible for a horizontal objective, though each of the others are also responsible for certain horizontals.

Success is measured both in terms of the quarterly goals they set and the impact on the organization

There is no one-size-fits-all structure for product teams as organizations have different setups based on their needs, maturity, customer segments and nature of products & services offered. Also fast growing companies often go through restructuring every 6 months with fluid org structures. Having said that, the question can be broken down into 2 aspects: 

1. Product org setup within the company: There are different variations of this:

   • Independent product org: Product managers report into a Chief Product Officer (CPO) or VP of Product who is part of the leadership team, typically reporting to the CEO

   • Product rolls into another org: Similar structure as above but the product org rolls upto another function like Sales, Marketing, or Engineering

   • Product has other functions reporting into it: Design, Analytics, Engineering, etc may report into the Product org with the head of product/area acting as the business lead or general manager

   • No independent product org: PMs/group of PMs are embedded within teams like Engineering or Marketing rather than being part of a separate department

2. Sub-teams within the product org:

   • By product lines: Common for larger organizations where each product or product line has product manager(s) reporting to the head of product of the product line. e.g. PMs support UberEATS, and Rideshare roll upto their respective head of products who in turn report to a CPO

   • By features or solutions: Complex products may have teams dedicated for specific product functions or features, with product managers assigned accordingly. e.g. PMs of iOS app, PM for Payments, etc 

   • By customer segment: Some organizations structure product teams around different customer segments, especially when serving diverse vertical markets. E.g. PMs on B2B segment, PMs focused on international markets, etc

   • By customer experience journey stage: Structuring teams based on specific metrics like growth, monetization, retention, etc

Remember, these are just examples, and the structure of product teams can vary widely. It's important to be adaptable and flexible as the organization's needs evolve.

I have led different sizes of product teams and single product teams or multiple product teams within an org.

My philosophy is to structure a team to make ownership and decision making very clear; I use the MECE (mutually exclusive, collectively exhaustive) framework to reduce as many inter-team dependencies as possible.

How do I do this? It depends on the type of team I'm leading.

For example - for customer facing products that my company sells, I first separate teams by the product on which they work. Then, I assign team members to discrete customer use cases for that product. For this to work, there have to be clusters of features that are clearly delineated to that use case. Try to organize by use cases that have as little overlap as possible so that one person can own a use case for a particular product and drive a roadmap for features that don't impact / have dependencies on other use cases.

For more shared services/platform oriented teams that probably enable multiple use cases (think backend services or data pipelines) and maybe aren't directly end user focused, it can get tricky. Some teams appoint owners of each backend service, but others can still structure ownership around a broader use case that could require APIs to be leveraged by multiple teams to enable a particular use case. A good example would be "Identity and Authentication" or "Dashboards and Reports" or "Product Telemetry." There are probably multiple services that drive each of these platform use cases that require a structured way/API with which multiple teams could interact. To the extent possible, even with platform service PM teams, try to organize ownership around clusters of features that are solely owned and managed by a single PM. It reduces complexity around decision rights and interaction points.