Organizational Structures for Product Teams
Structure determines function. Therefore, the organizational structure for a given product team changes the way in which it functions.
As product managers, we should be thoughtful about which organizations we seek to join, and whether it will suit our needs and our strengths.
We can analyze product teams across two different kinds of structure: macrostructures (where the product team sits in relation to other orgs), and microstructures (where individual product managers sit in relation to one another).
Below, I’ll dive into an analysis of the most common kinds of product team macrostructures and microstructures. Then, I’ll share thoughts on how to decide which kind of structure to join as a product manager.
Product team macrostructures
When most people think about product teams, they typically think of standalone product departments. In this structure, the head of product or chief product officer is a C-suite executive.
The benefit of having a standalone product team is that the head of product has a presence in the C-suite, which grants the product team equal footing with other departments like design, engineering, marketing, and sales.
In this structure, the product team typically has significant independence when it comes to setting the roadmap and the vision for the entire company.
And, with an independent product team, the product team gets to manage healthy tensions between the makers (design and engineering) vs. the business (sales, marketing, customer success, etc.). These tensions ensure that the company finds win-win solutions for the problems and challenges that it faces, rather than trying to play a zero-sum game across departments.
That said, this isn’t the only valid configuration for a product team; it has its own drawbacks and tradeoffs. One challenge with having an organization set up this way is that you need to have a senior product leader within the C-suite who is focused solely on product.
For small organizations, i.e. seed stage up to series B, it may not make sense to carve out the space for a dedicated top-level product executive. If you have only one or two full-time product managers within the organization, and you don’t have someone in senior leadership who has a product management background, then it may make more sense to have these PMs report to a different C-suite executive in the interim.
Speaking of which, another way in which product teams can be structured is that they are a part of an existing department. That is, product management isn’t a standalone function within that organization. Rather, it’s a part of a different function, where they report into a non-product executive. The three most common “subordinated product management” setups I’ve seen here are: product reporting into marketing, product reporting into sales, and product reporting into engineering.
One benefit of this structure is that it’s clear for the product team which stakeholder is the most important.
In a standalone product team, the product team needs to juggle the needs of different organizations. But, within this embedded structure, the product team can solely focus on the single stakeholder that matters. That increased focus enables them to deeply solve the pain for that given function, whether that’s engineering, marketing, or sales.
And, on top of that, a subordinated product function usually has very clear success metrics. As an example, PMs who are embedded in marketing are typically measured by the number of increased lead generation, increased lead conversion, and decreased churn. Because there’s only a single focus, PMs aren’t juggling dozens of conflicting metrics at once.
Since the product team provides significant value to a single department, that department is incentivized to provide legitimacy and backing to the product function. This is especially helpful when product management hasn’t yet been formalized within a company, and people are taking on the role of product management without the formal “product manager” title. Many times, these de facto product managers may be operating under titles such as IT managers, engineering delivery managers, or product sales specialists.
While this structure has its merits, it also has its fair share of tradeoffs. One drawback with leveraging this structure is that PM career progression isn’t clearly defined, because there’s no dedicated head of product who is driving talent growth.
Another drawback is that the product function becomes more of a support function rather than a strategic and proactive lever for the company, and they’ll typically be focused on the short term instead of the long term. This phenomenon appears regardless of which department is subordinating the product function.
As an example, product teams that report to the CTO typically will not be trying to break into new markets or conducting heavy user research and market research. Rather, they’ll position the new innovations that their engineering teams come up with, or they’ll focus much more heavily on technical refactors.
And, product teams that report to the CMO typically will not be investing significantly in engineering architecture or R&D. They’ll aim to move metrics upwards within the 1-2 quarter time horizon rather than the 3-5 year time horizon.
In yet other organizations, the product management organization is a fully-fleshed out department, but also contains another set of functions. Here, product management is the subordinating department.
The three most common subordination setups I’ve seen are: design reporting into product, engineering reporting into product, and analytics reporting into product.
One benefit of a structure like this is that the product team can draw more firepower from the function that is subordinated into the product team. Because the subordinated team reports to the product team rather than being a peer, the product team has significant say over resources, allocation, and promotions. This structure typically accelerates the product team’s delivery speed in the short run.
One problem with such a setup is that the subordinated function is typically disempowered to the point where it cannot meaningfully contribute to healthy debate. When too many people within the subordinated organization silently defer to the product team, it creates blind spots that can significantly damage the company later down the line.
As an example, a subordinated engineering team may not push back against product in building “quick and dirty” functionality, which then creates technical debt that becomes nearly impossible to pay off.
Or, a subordinated design team may not challenge the product team and may serve only as production artists, which causes designs to be less delightful and less intuitive for end users. That then causes the product to fall behind its competitors in the long run, because users react strongly and negatively to subpar designs.
In summary, there are three kinds of product management macrostructures:
Standalone product team
Product reports into another department (subordinated product team)
Another function reports into product (subordinating product team)
And, here’s a handy chart to visualize the benefits and the drawbacks of each:
Product team macrostructures, benefits, and drawbacks
Product team microstructures
There are many viable ways to split up responsibilities within a product team. Here are the 4 most common ways I see product management teams divvy up responsibilities:
By business line
By internal software services, functions, or architectures
By customer journey stage (e.g. AARRR)
By customer segment (e.g. enterprise vs. SMB, supply side vs. demand side)
Let’s discuss how these different microstructures affect the way in which product managers work within their product teams.
When you split up product managers by business line, you enable each product manager to become a subject matter expert within a given line of business.
The benefit of this structure is that each product manager becomes deeply knowledgeable about the business line that they have specialized in. Specialization then drives stronger customer trust and enables product managers to dig into complex, nuanced problem areas in a way that generalized product managers wouldn’t be able to do.
Structuring product managers by business line is particularly valuable when you’re tackling highly-regulated industries like fintech or healthtech, where regulations and processes are significantly different from one business line to another.
Another benefit is that each product line is essentially independent from one another, which means that each product line can be in a different stage of product maturity. As an example, you could have one product line be fully mature as an industry leader within its area, and a different product line be an upstart challenger product. In fact, many product teams grow their product portfolios by adding new business lines and assigning one product manager per business line.
One tradeoff that you’ll experience in this structure is that the engineering roadmap is not consolidated. Because each product line has its own roadmap, each product manager will focus on their own areas without full visibility into what the other product lines have built. In turn, that may cause duplicated work or reinventing the wheel, rather than more robust and scalable abstractions across the entire product portfolio.
On the other end of the spectrum, you can divvy up product managers by internal software services. As a lightweight example, consider a real estate search product like Redfin or Zillow. You might split up product responsibilities in this way:
One PM owns the iOS app
One PM owns the Android app
One PM owns the user registration and management module
One PM owns the property search module
One PM owns the service that populates property details
When you split up product managers based on internal architecture, you enable each one to become an expert within a given architectural domain by granting them visibility into every initiative that touches that domain. The benefit of this structure is that the software will typically be highly scalable.
The tradeoff with this structure is that balancing across business lines can be painful. Product managers have to compare apples to oranges in this structure - that is, they must decide whether to prioritize a more mature business line or a more nascent product line when it comes to deploying limited resources.
Another challenge is that in this structure, PMs wind up being perceived as blockers instead of drivers. When business line leaders identify initiatives, they will need PMs from each impacted service to prioritize and shepherd their work to completion. This level of coordination can be difficult and painful, and PMs can wind up feeling discouraged by the sheer pressure they get from their business line counterparts.
A third way to split up product managers is by customer journey stage, such as acquisition, activation, retention, revenue, and referral.
When you split up product managers by customer journey stage, you enable them to focus on a specific metric and on a specific conversion funnel, without being tied to a specific business line or customer segment.
The great thing about this structure is that each product manager has very clear metrics. Each customer journey stage is defined as a funnel from point A to point B, and so the product manager’s sole focus is to strengthen the funnel.
In turn, that means that each product manager gets to ideate and implement their own A/B tests to optimize the funnel. Many product managers enjoy seeing growth “happen before their eyes” as they iterate through a variety of UX flows to optimize their funnels.
But, one tradeoff with this structure is that PMs sometimes wind up working against one another. As an example, a PM whose focus is on acquisition may wind up bringing users that don’t wind up activating. Or, a PM whose focus is on revenue may cause users to not refer.
Because there’s no overarching charter that ties together the PMs, they will optimize within their own contexts without considering the impact on the overall organization. That creates sublinear returns on investment where the whole is less than the sum of its parts.
Another problem with this structure is that its focus is on optimizing what already exists, rather than on creating new “step-functions” of value that didn’t exist before.
In this microstructure, PMs are usually heavily disincentivized when it comes to launching new products or reaching new markets. By definition, trying to break into a new market takes time and effort, and new markets will typically underperform vs. established markets.
Therefore, when a PM is measured solely on the metric that they own, they will shy away from new markets because they don’t want to negatively impact the metric in the short run.
The fourth common structure we see is splitting up product managers by customer segment.
When you split up product managers by customer segment, you enable them to specialize on a specific set of customers and pains. Each product leader owns a specific market, and then product managers within can then be further split by business line or by customer journey stage.
This approach is quite valuable for tackling multi-sided marketplaces. For example, Airbnb’s product team is split between supply side (the hosts with the properties) and demand side (the travelers who want to rent). And, Uber’s product team is split between supply side (the drivers) and demand side (the riders).
This approach is also valuable for working with fundamentally different customer segments. Any time a B2B company is moving from SMB to enterprise, or from enterprise to SMB, they should consider separating the product teams because the measures of success are so different. In SMB, you want broad scale, but in enterprise your focus is on acquiring the largest logos.
By splitting up product managers by segment, you ensure that the PMs can specialize in a specific kind of customer, rather than splitting focus across multiple kinds.
The tradeoff here is that it can cause a lack of focus across the organization. As a unified product team, how do you tell a cohesive story to stakeholders when you’re tackling totally different markets at the same time? What is the overarching vision for the product when the team is set up to have multiple “mini-visions” at once?
Another problem that can happen under this structure is that it can cause zero-sum game behaviors. Supply-side product initiatives are regularly pitted against demand-side product initiatives, and SMB product initiatives are regularly pitted against enterprise product initiatives.
For example, say you’re working on a marketplace product for local crafted goods. The demand side is “local shoppers”, and the supply side is “small business owners and craftspeople.” Your focus is on the shopper side of the house.
You decide to launch a feature to entice shoppers by giving them the option to select in-store pickup, which means that they can get their products faster without having to wait for shipping.
But, by doing so, you’ve forced the small business craftspeople on the supply side of your marketplace to implement new processes to support in-store pickup, which increases their costs and reduces their margins.
Many of these small businesses might be operating out of their homes, and it might not be convenient or desirable for them to open up their houses to strangers to pick up their goods.
This approach creates friction in the supply-side product, and that then causes the supply-side product team to see an immediate dip in metrics. Small businesses might leave the platform entirely, or they may list fewer items on the platform.
Because each product manager is focusing solely on their side of the market, they may miss opportunities to create win-win scenarios for multiple sides at once.
To recap: there are many different ways to structure product managers within a product team. As with everything else in product management, product team structures involve tradeoffs.
The product team’s selected microstructure will naturally create both strengths and weaknesses, so it’s critical for product managers to understand what to expect from the organization that they’ll be joining.
Here’s a chart to visualize the benefits and the drawbacks of each product microstructure:
Product team microstructures, benefits, and drawbacks
How to decide which kind of product structure to join
The best products fit their markets, and product managers are products. Therefore, it’s crucial that we consider what kinds of markets we best fit. In other words, what kinds of product structures play best to our strengths and our needs?
To identify which market will fit us, we should first decide what attributes we want to prioritize when looking for a given structure, both at the macro level and at the micro level. Are we interested in mastering a specific business line, or in becoming significantly more technical?
Then, we should seriously consider the tradeoffs that we’ll incur by joining a specific product management setup. Are we comfortable with responsibilities being divided in that way? Do we understand the kinds of tensions that we’ll need to manage, and the kinds of cross-team coordination that we’ll need to lead?
Once you’ve identified a product structure that suits you, you can then consider this attribute as you look for a new product team to join. Of course, this attribute is simply one of many - you’ll also want to consider factors like work/life balance, total compensation, career growth trajectory, company mission, and other priorities.
Then, once you’ve joined the organization, reflect on your fit. You may find that it’s a more satisfying fit than you had originally imagined, or you may find that it’s not as satisfying as you would have liked it to be. You can then use this information to decide which skills to grow in, as well as what other career hypotheses you’d like to pursue and test.
Remember: it’s okay to pivot in the future. Product management careers are long-lived, so don’t be afraid to iterate towards PM fit! And, if you’re not sure what kinds of product teams are out there, check out our Product Teacher jobs board where we feature PM roles at compassionate organizations.
Thank you to Pauli Bielewicz, Siamak Khorrami, Goutham Budati, Markus Seebauer, Juliet Chuang, Shanthan Gangupantula, and Kendra Ritterhern for making this guide possible.
