Structuring Product Teams to Achieve Their Goals: An Introduction to Team Topologies

Welcome to this discussion on how to structure product teams to reach their objectives. In this document, we’ll explore a topic often referred to as "team topology." Whether you’ve read the book "Team Topologies" or are new to this concept, this introduction aims to provide both an overview and a deeper understanding of how to organize teams effectively.

Our agenda is divided into four parts: 1) The relationship between strategy and team topology, 2) How to create and form teams, 3) Real-life examples of team topologies, and 4) Allocating product team members. Let's dive in!

Strategy and Team Topology

The first thing to understand is that the structure of your product teams directly reflects your organization’s strategy and communication flows. This concept is famously captured by Conway's Law, which states that "Any organization that designs a system will produce a design that is a copy of the organization’s communication structure." In other words, how you organize your teams will shape the final product.

Consider Gmail, for example. Why are there separate areas for apps on the left side, the right side, and another menu at the top? This fragmentation is a result of different teams working on different aspects of the product. Each team, such as the Gmail team and the Calendar team, had to negotiate the integration of their work. Conway’s Law shows us that the communication structure—how these teams interacted—affected the product’s design.

A user, however, doesn’t care about the internal organization of your teams. They just want their needs met, seamlessly. This is why team topology is crucial—it helps ensure that your users experience your product as a cohesive whole, rather than as a disjointed collection of features managed by different teams.

Creating and Forming Teams

When structuring teams, one major consideration is to align team boundaries with meaningful user outcomes or business opportunities. One example of this approach can be found in healthcare. Imagine a patient visiting a hospital: their ultimate goal is "to get better." They may visit multiple specialists (such as a neurologist, oncologist, or gastroenterologist), but the hospital's organization and internal divisions should be invisible to them—all that matters is their recovery.

Similarly, product teams should be organized around "jobs to be done" for the user. Teams should be created in such a way that they work toward advancing the overarching product strategy without making internal boundaries a user concern. For example, a support team should help solve a user’s problem without redirecting them to other teams internally; they should act as the bridge that facilitates the solution.

Examples of Team Structures

Let’s consider an adapted example from a real-world company called Xerpay, whose mission was to help people organize their financial lives based on their salary. This mission was divided into three sub-opportunities:

1. Companies paying salaries.
2. Individuals receiving salaries.
3. Companies selling products and services to individuals.

Within the context of individuals receiving salaries, the financial aspects of life were further broken down into three categories: money inflows, money outflows, and investments. Each of these categories could be assigned to a specialized, cross-functional team or "squad." The idea here is to create squads that are neither too broad (leading to overwhelming scope and difficulty in prioritization) nor too narrow (leading to excessive focus on a small feature, which might hinder strategic innovation).

For instance, if a squad is dedicated to "salary advances," they can focus on managing and improving that particular flow. However, organizing teams too narrowly around features—such as creating a separate team for each payment method (e.g., "Pix payments," "credit card payments")—can lead to local optimizations and incremental improvements, but it may hinder your ability to drive broader, disruptive innovations.

Additionally, there are components and services—such as authentication, financial integrations, and design systems—that serve multiple squads and must maintain consistency across the product. These components require their own dedicated teams to provide coherence across the user experience.

Types of Teams in Team Topologies

According to the book "Team Topologies" (which is a key reference for this topic), there are four main types of teams:

1. Stream-Aligned Teams: These teams focus on a specific flow of work, often related to a particular business domain. Examples include onboarding teams or teams focusing on specific product features that directly deliver value to users.

2. Enabling Teams: These teams help stream-aligned teams overcome obstacles and identify missing capabilities. They may act as advisors, sharing expertise to help other teams succeed.

3. Complicated Subsystem Teams: These teams focus on areas that require specialized expertise, such as security, fraud prevention, or machine learning. They address complex problems that require deep technical knowledge.

4. Platform Teams: Platform teams provide internal services and infrastructure that accelerate delivery for other teams. They create tools and components that other teams consume to make their work easier and faster.

Allocating Team Members

Once you understand your strategy and the different types of teams you need, the next step is allocating your team members effectively. Imagine you have a mission like "organizing financial lives based on salary," and 20 engineers available. You might allocate three engineers to work on "employers," four on "individuals," and the rest across various critical components, such as authentication and financial services.

Prioritization is key—deciding where to allocate resources is about making trade-offs. Some parts of your strategy may have no team members assigned at all, at least temporarily, because focusing your resources where they can make the most strategic impact is more valuable.

Conclusion

Structuring product teams isn’t just about assigning people to different projects—it's a critical part of product strategy that shapes the final user experience. Using the right team topology, you can align your teams to user needs, drive innovation, and ensure that your product vision becomes a reality. By understanding different team types and applying these principles thoughtfully, you can create an environment where teams accelerate your business strategy and deliver exceptional user experiences.