[For Product Leaders] How to structure product teams?

We discover the most fundamental principal based on which product leaders at Spotify, Duolingo, Airbnb etc. take product team scaling decisions.

The Big Question

If you’re a Product Leader, this question might have crossed your mind at-least once in the past, or you might be in the middle of figuring out how to best go about structuring your teams.

Next, if you start figuring out product team structures at big tech or meaningful product companies, you will find some patterns. Mostly, product teams are structured around one of these:

1. Customer Type (Example: Seller, Buyer in an e-commerce and Rider, Driver in mobility)

2. Customer Journey (Signup → Search → Ride Experience → Payments in Mobility… or generically Acquisition→ Retention→ Monetization → Referral)

3. Business Value (Core Offerings/Processes, Growth, New Products)

4. Product Line or Feature wise (Feature 1, Feature 2… or Product Line 1 , Product Line 2)

and the product teams are distributed across four type of teams:

1. Stream-aligned teams (sometimes called customer-facing domain teams or experience teams)

2. Platform teams (internal applications and services to make it easier for stream-aligned teams to ship customer-facing products)

3. enabling teams (fill capability gaps for stream-aligned teams such as testing automation, deployment, experimentation platform etc.)

4. complex sub-system teams (team consisting of specialists that develop and maintain specific complex subsystems or components of a larger product or system)

---

Hey there! You’re reading the one free case study per month. But there’s lot more that happens in a month.😉

Last week, we published Part 1 of the course on Platform Product Management - available to all paid subscribers of Productify. Access it here. As paid subscriber, you get access to monthly courses and premium case studies such as: How OpenAI makes money? |How Duolingo gets your addicted ,|How Facebook does Product Management | All Product Strategy Frameworks you need and many other locked posts. You also get access to exclusive deep-dive product guides, templates and 1:1 access to Bandan. Consider upgrading:

---

However, this information only informs you WHAT do organizations mostly do, but not much about WHY these kind of product teams exist and HOW to decide when to create which kind of team and WHEN to decide to split them/scale them.

Let us reverse engineer this, and first learn how do top product companies structure themselves:

Product Team Analysis at top tech companies

Here are some examples of how Stripe, Airbnb, Uber and Duolingo structure their product teams. The details below are not extensive but aim to give you an idea about the broader structure.

1. Stripe:

   • Core Product Teams: Stripe organizes its product teams around core product offerings, with each team focused on specific aspects of the Stripe platform. These teams are responsible for developing and enhancing the core features and functionalities of the Stripe product.

   • Industry Vertical Teams: Stripe also has teams dedicated to specific industry verticals or market segments. These teams understand the unique needs and challenges of customers in those industries and work on developing industry-specific solutions and integrations.

   • Infrastructure Teams: Stripe has specialized teams focused on building and maintaining a robust infrastructure. These teams develop and optimize the underlying systems, architecture, and tools that power the Stripe platform, ensuring scalability, security, performance, and reliability.

   • Developer Experience Team: Stripe places a strong emphasis on providing an excellent developer experience. This team creates developer tools, documentation, and resources to make it easy for developers to integrate Stripe's services into their applications.

2. Airbnb:

   • Guest Experience Team: This team focuses on enhancing the guest experience, including search, booking, and reviews.

   • Host Experience Team: The host experience team is responsible for improving the experience of hosts, including listing management, pricing, and communication.

   • Regional Teams: Airbnb has dedicated teams focused on specific geographical regions. These teams address the local needs and requirements of each region and ensure a tailored experience for users in those locations.

3. Uber:

   • Rider Experience Team: This team works on enhancing the rider experience, including app design, navigation, and payment systems.

   • Driver Experience Team: The driver experience team focuses on improving the experience for drivers, including onboarding, earnings, and support systems.

   • Marketplace Team: This team concentrates on optimizing the supply-demand dynamics of the platform, including pricing algorithms and matching algorithms to ensure efficient and balanced marketplace operations.

   • Product Operations: Uber also has product operations teams that work closely with product managers, engineers, and data scientists to gather user feedback, analyze data, and identify areas for improvement. They collaborate with cross-functional teams to execute product strategies, launch new features, and monitor product performance.

4. Duolingo: (Source)

While all of the above product team structures can be defined or categorized into one (or two/hybrid) of the 4 product team types shared in the beginning, it still only answers the question of categorization, but not the WHY.

So, let us explore the more inherent fundamentals in place when choosing your product team structures.

Understanding cognitive loads to manage product teams better

Product teams are increasingly becoming cross-functional in nature and every team member in product teams deals with three kinds of cognitive loads on a daily basis:

1. Intrinsic Cognitive Load:

   • Intrinsic cognitive load refers to the inherent complexity and difficulty of a task or learning material that is determined by its nature and the skills required to perform it.

2. Extraneous Cognitive Load:

   • Extraneous cognitive load refers to the unnecessary cognitive burden imposed by external factors such as distractions, confusing instructions, or poorly designed interfaces that hinder learning or performance.

3. Germane Cognitive Load:

   • Germane cognitive load refers to the cognitive effort directly related to meaningful learning and problem-solving, involving deep understanding, creating mental models, and applying knowledge effectively.

Let us evaluate these cognitive loads for software developers:

1. Intrinsic Cognitive Load:

   • Understanding complex software requirements and translating them into technical solutions.

   • Analyzing algorithms and data structures to optimize performance and efficiency.

   • Learning new programming languages, frameworks, or technologies to adapt to evolving project needs.

2. Extraneous Cognitive Load:

   • Working with outdated or poorly documented codebases that require extensive effort to comprehend and maintain.

   • Dealing with constant interruptions and context switches that disrupt concentration and productivity.

   • Debugging complex software issues without clear error messages or helpful debugging tools.

3. Germane Cognitive Load:

   • Collaborating with product managers and designers to translate product requirements into technical specifications.

   • Architecting scalable and modular software systems that can accommodate future growth and changes.

   • Conducting code reviews, sharing best practices, and staying up-to-date with industry advancements to continuously improve coding skills and knowledge.

The aim of your product team structure should be to reduce Intrinsic and Extraneous Cognitive Loads and maximize Germane Cognitive Load

The bottom line being that we want product teams to solve for business problems (experience more of Germane cognitive load) by creating a knowledge base and expertise in the product/business area, and reduce intrinsic and extraneous load that leads to friction in their flow of work.

In case of software developer, it is more easily explainable:

Reduce intrinsic load: Less time thinking on problems like “Which Java class to define?” (hence need good skilled software developers)

Reduce extraneous load: Less time worrying about “How do I deploy the code?” (hence need strong platform teams to worry about this)

Maximise Germane load: More time worrying about “How do I solve this product problem?”

In case of a product manager: By reducing intrinsic and extraneous load, product managers can independently drive their product area and build expertise in it , without worrying about intrinsic and extraneous distractions coming from (for examples) organizational processes or politics.

Now, if we apply this at a team level and extrapolate it, it means that decide the product team’s area and structure in a way that:

• Minimize dependency on other product areas

• Minimize the need to build broader reusable/scalable modules by creating separate platform services

• Keep the team size small, and also long-standing (do not move around/change the teams often)

• Minimize the need for the team to communicate in general with many other product teams (low bandwidth communication with other teams)

• Maximize the ability of the product team to effectively solve for problems in their domain (for both PMs and software developers)

This is explainable when we look at the question: Why does Uber have Rider Experience team (by customer type)?

Firstly, it reduced Intrinsic and Extraneous Load:

• Intrinsic Load: The Rider Experience team's expertise in understanding rider behavior, preferences, and pain points reduces the intrinsic cognitive load for product managers and software developers to better comprehend the complex nature of riders' needs

• Extraneous Load: The team focuses on streamlining the rider experience, simplifying the user interface, and optimizing the booking process by reducing unnecessary complexities and eliminating distractions such as infrastructure topics, devops topics (they get taken up by platform teams)

  Secondly, it helps increase experiencing Germane Load:

  • The Rider Experience team, through user research and data analysis, provides valuable insights and feedback to product managers and software developers. This increases the germane cognitive load by providing them with a deeper understanding of riders' behaviors, preferences, and pain points.

  • With this enhanced understanding, product managers and software developers can develop more targeted and effective solutions that align with riders' needs. They can apply their knowledge more effectively, create better user experiences, and contribute to the development of features and improvements that address germane cognitive load.

Aim of any product organization structure is to reduce total intrinsic+ extraneous cognitive load for stream-aligned teams (also called experience/domain teams) so that they can focus on delivering strong customer experiences.

This is where platform teams come in. Many define platform teams as set of tools, APIs, services, knowledge base and support that creates internal tools for stream-aligned teams’ developers. But even simple definition of a platform team is that it reduces cognitive load for domain/experience teams.

With a strong platform teams, domain/experience teams have to not think about which reusable/extensible APIs to maintain, which infrastructure to take care, which deployment methods to use, how to automate testing and other topics. Organizations with great platform teams allow more time for domain teams to deliver meaningful experiences to customers. Let us look at this through an example:

• Platform teams can develop and maintain standardized frameworks that provide pre-built modules, libraries, and APIs for common functionality. This reduces the cognitive load for domain or experience teams by eliminating the need to reinvent the wheel for basic features, allowing them to focus on higher-level tasks specific to their domain.

• For example, a platform team at a software company may develop a UI component library that includes pre-designed and tested interface elements. This library can be easily integrated into different products, saving development time and cognitive effort for domain teams.

Here are some decisions product leaders can take by knowing cognitive loads of their teams:

1. Split a product team: If one product team is dealing with more than one domain or product area, then to reduce cognitive load (and increase germane load), split the product team into two areas with each product team able to independently deliver its own product area

2. Create a platform capability: If a domain/experience team repeatedly deals with a service that is also in use with another domain team, think of platformising that service so that the responsibility of maintaining it is no more with domain teams and they can instead focus on delivering customer experiences faster

3. Create enabling teams: Not all the time you need platform teams. For example, if your domain team is missing the capability to do rapid experimentation, you could setup a temporary enabling team that manages experimentation infrastructure so that domain teams can focus on doing A/B tests (reduce cognitive load, increase germane load) instead of setting up and maintaining experimentation infrastructure.

and many more. Bottom line is that you need to make the job of your domain/experience teams easier so that your customers get better and faster-iterated experiences. For this you need to minimize intrinsic/extraneous load of these teams, and that is what will help you decide whether you need to shut a product team, split a team, create a platform team and setup a kind of product structure that works for you.