Question about org structures - what does your PM team org structure look like?

Today, our org structure follows the ethos of "Small, autonomous teams". In this structure, we generally have a PM paired with a Technical Lead (Eng), somewhere between 3 - 5 Engineers, and a Business Systems Analyst to focus on operational and analytical tasks. Some teams have a Design/UX representative as well, where applicable. 

Hierarchically, we have these teams organized into Pillars, with a shared broader mission/remit. Pillars are led by a triad, with a Senior PM, Product Lead, or Group Product Manager aligned with an Engineering Lead (above TL) and a BSA Lead or Design Lead where relevant. Finally, those Pillars roll up into Groups, where the Director level can provide guidance to the respective teams. 

The main thing to note about these structures, though, is that they take time to mature; where we are today is a step function change from where we were last year. Eventually, I do hope to land in the formation outlined above, but we will continue to transform as individuals grow in their roles or are brought on board over time. 

I've noticed a trend in the tech industry for product organizations to follow a structure that Spotify helped craft over the years, in which a company is organized into business sub-orgs that roll up into their own respective product and engineering leads. And those leads oversee various squads that make up the product areas within that sub-org. At CookUnity we call the product areas "zones", in which a product lead exists to drive the product strategy and manage the PM team. In smaller companies (<500), those product leads are likely the direct leadership team for the Head of Product. 

You can follow this model at any size company, you'll just see a different scale of how many and how big the sub-orgs are. 

Let me give some guidance here on how I think about it. 

1. It's critical to have a strong vision, strategy, roadmap, and success metrics for a team
2. Your org structure should be organized to support the pillars of your strategy
3. Beyond this there optionality to organize your team functionally the way that engineering teams are organized or strategically that maps more to your success metrics or some hybrid of both
4. Most critically though you need to have as clean as possible swimlanes for PMs. Giving them a problem area to solve gives them a runway to grow and build a visions, strategy, roadmap, and success metrics for themselves. Don't give them projects, give them problems.

To directly answer your question though I organize my team strategically tackling the strategy pillars we've set out to solve and my engineering and ux counterparts map our squads to each other based on the most logical function overlaps. But this does mean that one PM may be interacting with several engineering leaders to get their work done.

There's no single right way to structure any team. Some essential ingredients to creating an effective org are to create a structure that:

• Supports cross-functional work
• Aligns teams to customer problems
• Encourages knowledge sharing
• Provides for growth

Your org structure will need to change as the company grows. And you will always need to account for silos, especially once the company grows beyond about 20 people. No matter what your org structure looks like, there will be silos, and you'll need to create and support communication channels to bridge between them. Some silos are better than others - I would always recommend that Product Managers be part of a cross-functional team, along with design, engineering, and other disciplines. Creating a silo between PMs and designers or engineers is going to create far more headaches than a silo between a teams that work together to build particular pieces of the product.

At Aurora, our product team structure is designed around our customers' problems; specifically, around the lifecycle of our customers' projects. Putting customer problems at the heart of your org design helps to ensure that your teams continually focus on solving those problems.

Gitlab, my current company, the product organization is kind of unique. We have several product directors over each major products section which roles up to a VP of Product Management. Under each of those product directors, there can be a staff product manager, the highest level product manager when it comes right individual contributors, as well as several group managers, which are the managers of a particular product stage that owns a specific domain within the GitLab product. Individual contributors at Gitlab look like intermediate project managers all the way to principal product managers and most rarely the Senior principal product manager, which is the highest level you can reach in project management individual contributor, and there’s not going to be very many of those inside organization, but they still exist. Each product manager will own 4 to 5 categories which roll up to a stage under a group manager. Altogether the product management organization, GitLab is very focused on domain and being able to successfully execute on a market domain of the DevOps platform lifecycle.

And other companies we didn’t have a platform-based way of looking at product organization, so it was not domain-focused, and more business unit-focused. In this case, there was a chief product officer, and then under the chief project officer was a Director over each of the business units. Each of the directors would have two or three group managers based on the number of product managers that rolls up into their business unit and often times they were also program managers that would roll into this director's role.

There are many different ways to create an effective PM org structure. It really depends on the company, their strategy and values.

At Gitlab, PM team organization led by CPO. VP of Product reports into CPO. Directors and Sr. Directors report into VP. Group Managers report into Directors/Sr. Directors. IC PMs report into Group Managers or directors. Highest level of IC is Sr. Staff Product Manager. CPO has Technology, Revenue, Sales and HR counterparts in the C-level who all report into the CEO.

Product Teams are organized based on DevSecOps life-cycle stages meaning each team is responsible for a stage ( Create, Plan, Manage, Secure etc.) within devSecOps life-cycle. This allows us to dive deep into the painpoints of that stage and focus on ensuring user experience is unparalleled in comparison to competitive products.

GitLab is quite transparent, so you can find our structure defined pretty publicly here.

We have the overall product that we divide into sections, stages, groups and categories.

This is how it makes sense for us to organize our work since GitLab is a product that supports many different feature areas across the software-development lifecycle, which we use as the foundation to set up the org structure.

We have section leaders (typically Director/Senior Directors), stage leaders (often a group PM or Director), and each stage has multiple groups, each led by a product manager (intermediate, senior, principal or senior principal). Each group has a dedicated R&D quad (PM, design, engineering, and quality) that is in charge of multiple product categories or feature areas.

With this organization the various PMs working on feature areas that belong to the same stage all report to the same stage leader. Those stage leaders in turn roll up to section leaders who in turn roll up to the Chief Product Officer. The UX department is similarly structured, also rolling up to the chief product officer, but each UX designer reports to a UX design manager, etc.

I don't believe there is one org structure that looks better than an other. so my answer here about my current team PM org structure is irrelevant but I can tell you a few things about it

1. My current org structure will change with various business priorities. And it could/will change a lot. And that's ok

2. Your last "reorg" isn't your last one. It's your most recent one.

3. Optimize your teams by problems they are solving, not by solutions they are providing

So many more advice I would be happy to give that heavily depends on the level of maturity and size of the organization so i'll refrain from giving more until I hear more...!