How is your product team structured?

I'm a Group Manager of Product at GitLab https://about.gitlab.com/job-families/product/product-management-leadership/#group-manager-product-gmp. I am a manager for the Product Managers for the Plan stage at GitLab. Each product manager on my team has engineering, UX, and quality counterparts that they work with to build their products. I also have leadership counterparts in Design, UX, and Quality. We all work together to steer the direction of a collection of teams. You can see all the details in our GitLab handbook https://about.gitlab.com/handbook/product/categories/#plan-stage . 

We divide up the team by domain area and then map existing features and area-specific outcomes to them as much as possible. Obviously, it's not always possible to create a MECE (mutually exclusive, collectively exhaustive) division of areas of responsibility (AoRs) among all PMs, but I am constantly examining the current org structure and AoRs and discussing with my engineering leadership counterparts as to whether we need to make any changes. I should also mention that we also align engineering teams to domains, not technical services -- although in the fullness of time, your technical architecture should increasingly be domain-driven if you adopt this model. Setting up both the engineering and product org structure this way creates accountability for long-term outcomes in the area, rather than a project-oriented focus.

Two books that are excellent for understanding the advantages of organizing teams in this way are Team Topologies by Matthew Skelton and Manuel Pais, and Domain-Driven Design by Eric Evans (the latter is more valuable for engineering leaders).

At Contentful, we are organized into three Product Lines (Core Platform, Apps, Ecosystem) that each own a specific set of products for a set of customers. 

Within each Product Line, we have a 2-5 year product vision that gets revised 2x a year with each PL leader (eng and product). From this strategy, we decide the level of investment to make across each PL, and the teams needed to achieve this vision. We then create charters for each team that provides direction to the team (PM, Designer, Engineers) on what they own, the objective they should achieve, the customer problems and outcomes to achieve.

I oversee 2 product lines, each composed of several product teams that own parts of these PLs. As an example, in the Ecosystem PL, we have an Integration team, Developer Experience team, Marketplace team, and Extensibility team. Each of these teams have a PM, Designer, and Engineers.

When organizing product teams, it's essential to set the charter/mission of the team, what they own, and the problem they are solving for customers. This creates focus and gives the team something to own and optimize over time. A helpful book on organizing product teams is Team Topologies.