Inside the Product Team Structure
Who you work with and what you own
We’re covering two critical concepts for every product manager: who you work with (your cross-functional team) and what you own (your product area).
It's fascinating stuff. Ok, no, organizational design is kinda dull in general, but how this is done for product development teams is actually fascinating.
This post is part five of my five-part Product Management Crash Course, and it’s all based on my recent guest lecture at MIT.
The Product Manager role is unique
The Product Manager role is a unique position in tech companies. Product Managers keep technical teams focused on what is most important to the customer and the business to deliver a great product. I have more details in my post, “What is a Product Manager?” but here’s the takeaway:
The product manager’s job is to figure out what your team should build with limited time and resources, and you have to do whatever it takes to make your product great.
But who is “your team,” and what is “your product”?
Great questions. We’re here for those answers.
But first, some background info
In tech companies, product managers are usually part of the technical side of the business. Functions in the business are often split into two sides, with names like “GTM” and “EPD.”
GTM
The GTM, or go-to-market, functions are all the customer-facing roles that help get your products into customers' hands. This side of the business includes functions like Marketing, Sales, Sales Engineering, Customer Support, and Customer Success. These functions will typically all report to a leader with a title like CMO (Chief Marketing Officer) or CRO (Chief Revenue Officer).
EPD
The technical side of the business often has a name that is some combination of the letters “E,” “P,” and “D”—for Engineering, Product, and Design. We’ll call it “EPD” here, but I’ve seen every combo of those three letters. The EPD side of the business includes all your technical functions, including Product Management. You’ll often find your Data Analyst, Data Science, and UX Research functions here too. The EPD side of the business typically reports to a CTO (Chief Technology Officer), a CPO (Chief Product Officer), or a combination of the two.
The gist
Product Managers are part of the technical side of the business and, on a day-to-day basis, are most closely aligned with the other technical functions: Engineering, Product Design, Data, UXR, etc.
Note: I know, I know, I’m leaving out Finance, Operations, and other core business functions here. This is just illustrative, so imagine there are more circles in the drawing above to represent the whole company.
Who do product managers work with?
As a product manager, you’ll usually have two groups who you will spend most of your time with:
A cross-functional team
Other product managers
Cross-functional teams
Most PMs will work with a cross-functional team, a small group of people from different departments with different specialties. Usually, this team consists of a Product Manager, a Product Designer, a Tech Lead or Engineering Manager, and at least two engineers. This cross-functional group works closely together towards a shared mission and goals. Everyone brings a unique skill set necessary for designing and building a product. These cross-functional teams are often called a “product team,” “squad,” or “pod.”
The leads in the group (Product lead, Design lead, and Eng lead) are often called the “Product Trio.” This trio will lead the team, aligning user, business, UX, and technology requirements. The Product Trio often does Discovery work together to figure out what the team should focus on.
You may have a bigger cross-functional team with additional specialists to help. Other roles you can often find in these teams include UX Researchers (UXR), Data Analysts, Data Scientists, and Product Marketing Managers (PMM). I’ve been super lucky to have even more folks on my teams in the past, like Site Reliability Engineers (SREs), Quality Engineers, and Technical Writers.
Reminder: You are no one’s boss in this setup. You are in charge of product decisions, but usually, no one on your cross-functional team will report to you. You’re not their manager. You’re all partners.
📚 Build that skill 📚
Influence without authority is a critical product manager skill you’ll need to get buy-in from your team. If you’re new to Product or an experienced PM struggling to influence, check out my course, Product Influence, to build that skill.
📚 📚 📚 📚 📚
You will have a shared focus area and product goals as a team. You’ll work together to learn about your users, discover their problems, and design and build solutions.
How your cross-functional team is structured usually depends on two things:
The specialties your product area needs to be successful. For example, if your cross-functional team is focused on backend services and has no user interface, you probably won’t have a Product Designer on your team because you don’t need that skill set for your product area.
Your company’s staffing. If your company doesn’t have many people in a particular specialty, that role will not be “embedded” in cross-functional teams. For example, if your company only has one person in the UXR role, that person will probably work with many cross-functional teams and not be dedicated to just one team.
Why do these cross-functional teams even exist? There are pros and cons to this type of setup.
The upside
Ideally, you’ll have faster innovation. The small team size makes it possible to make decisions quickly and build things faster.
These teams also have a dedicated area of the product they are responsible for. (More on product areas later.) They are focused on a smaller portion of the product so that they can become experts in that space. Because they are the experts, they may have more autonomy over the strategy and roadmap for that part of the product.
More autonomy plus quick decision-making, ideally, leads these small teams to build, learn, and innovate faster.
The downside
Many small teams can lead to a product that lacks cohesion and feels like patchwork to end users if there is no centralized group looking out for consistency across your product. You can also end up with communication silos, where teams feel like they don’t know what’s happening with other teams. To avoid patchwork products and communication silos, you will also collaborate with other product managers.
Other product managers
As a product manager, you’ll also work closely with the other product managers in your company. The other PMs have their own cross-functional teams, but you’ll all come together as a Product org to talk about things specific to product managers, like career development in this role and processes that you all need to follow. It’s also fun to meet regularly with other PMs in the trenches like you. You can vent to each other and learn from each other’s experiences.
A critical reason for PMs to rub elbows is to align their plans. Product managers need to compare notes to ensure no conflicts exist in their strategies, goals, and roadmaps and to handle any dependencies across teams.
What do product managers own?
I recently asked Chat GPT to give me a list of common misconceptions about product managers. One of the responses hit home for me:
“Product managers know everything about every product in the company.”
As a Product Manager at a B2B company selling to enterprises, I often had to meet with customers to present our roadmap and discuss what our entire Product team was working on.
I’d get so nervous because I felt like customers expected me to be an expert on every part of the product, but I was only truly an expert in my area. I knew the entire product well but couldn’t get into the nitty-gritty details and edge cases of another PM’s product area.
Product managers have specific areas of responsibility, their “product area.” Ideally, a PM’s product area is a clearly defined boundary around a set of functionality and user experiences for which the PM is responsible. And that responsibility is shared with their cross-functional team.
Here’s an example of how cross-functional teams at Spotify mapped to product areas circa 2012. The Spotify app no longer looks like this, but this is still a helpful illustration. You can see how different cross-functional teams (called “squads” at Spotify) are responsible for different parts of the user experience.
In the example above, there are squads assigned to (1) the mobile experience, (2) playlists, (3) recommendations, and (4) the music player.
When cross-functional teams “own” a product area, they are usually responsible for defining a mission statement, a strategy, some goals, and a roadmap. The team owns the long-term success of the area, and because they are dedicated to the area, they become the experts over that part of the product.
How are product areas defined?
This will depend on your company, its goals, and how your technology is architected. The boundaries around product areas are often determined by business goals, user experiences, or technologies. (Or, more likely, some combination of all three.)
Here’s a totally made-up example based on real teams I’ve seen. Let’s imagine you’re a product manager at a company that has a two-sided marketplace. The company’s product has users who match a “buyer” persona (people who buy stuff on the marketplace) and users who fit a “seller” persona (people who sell stuff on the marketplace). There are 10 product managers at this imaginary company. The product managers and their associated cross-functional teams could be split across your product like this:
PM 1: Buyer Experience team
PM 2: Seller Experience team
PMs 1 and 2 work with teams focused on the two primary user types. User experience boundaries define their product areas.
The product area for the Buyer Experience team is all the features that Buyer users need to use the product. The Buyer Experience team will have a mission statement, strategy, and goals to make Buyer users successful.
The Seller Experience team will do exactly the same for Seller users.
PM 3: Payments team
PM 4: Search team
PM 5: Messaging team
PM 6: Mobile team
PM 7: Core Services team
PMs 3, 4, 5, 6, and 7 work with teams focused on centralized technologies. Technology boundaries define their product areas. Instead of focusing on a single type of user, they focus on how all users interact with a specific technology within the product.
For example, the Payments team has a product area that covers all features related to how a user makes or receives a payment in the marketplace.
The Search team has a product area with all the features allowing users to search within the marketplace.
When a product area has boundaries based on the technology in use (e.g., payments tech for the Payments team, search algorithms for the Search team), the team and the PM typically need some prior knowledge and experience with that technology. You’ll often find PMs with domain expertise in these types of teams.
PM 8: Growth team
PM 9: Moonshots team
PM 10: Internal Tools team
PMs 8, 9, and 10 work with teams focused on specific business goals. Business goal boundaries define their product areas.
The Growth team’s product area will cover all the features and experiments to drive new customer acquisition. The Moonshots team could be focused on entirely new product innovation to drive net new business. And the Internal Tools team could have a product area that includes all the internal products needed for the efficiency of the company’s internal operations.
Fun fact: To understand what is important to a company, look at how the company maps its product managers and cross-functional teams to product areas. Assigning a team to a product area is an investment in that part of the product. Bigger or more skilled teams assigned to a particular product area signal a more significant investment.
As a Product Manager, your product area is your scope. It’s the realm of responsibility where you can exert ownership and make an impact. When you start as an Associate Product Manager, your scope will be small. As you grow in your Product career, your scope will grow. If you’re trying to promote, taking on a bigger scope and doing well in that larger scope can be helpful.
Not one size fits all
If your Product organization doesn’t look like this, that’s ok too! My intent here is to describe a popular way that companies organize to illustrate the concepts of cross-functional teams and product areas because these concepts are not well-understood by folks new to Product Management.
It’s important to remember that every company has unique needs, so their organizational structure will vary. Here are a few things leaders need to consider when designing their organizational structure:
the business goals (they need to staff the most important product areas),
the skills and strengths of each team member (to align people to areas where they can make the most impact), and
the career aspirations of each team member (to place individuals in roles that will help them achieve their career goals).
Change is normal
When Spotify published how they structure their cross-functional teams in 2012 (Scaling Agile @ Spotify), many tech companies followed their lead and structured their teams similarly. More than ten years later, it’s unsurprising that Spotify has evolved and no longer works exactly this way.
Gustav Söderström of Spotify recently went on Lenny’s Podcast and discussed how Spotify is organized now at a much larger scale. Check out the chapter “(28:27) How Spotify organizes product teams” in the video below.
Org structures change over time. As your company changes, your organizational structure will also need to change. That is totally normal. It’s even normal for companies to make minor adjustments in how teams align to product areas more regularly as priorities shift in the business.
Now you know all about cross-functional teams and product areas; you got this!
Dive Deeper 📚
Want to learn more about this topic? Check out these additional resources. Happy learning!
[Product Talk] Core Concept: The Product Trio by Teresa Torres
[Atlassian] The Spotify Model for Scaling Agile by Mark Cruth
Referenced in this post
[Spotify] Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Henrik Kniberg & Anders Ivarsson, Oct 2012