Team structure

20 min readSep 30, 2020

The product development team is the one who will execute the strategy and achieve the objectives to achieve the product vision. Therefore, an essential part of your strategy definition is to design and implement your team structure. In order to design the team structure, it is important to understand the different ways of organizing a product development team and to define which one is most appropriate for your strategy.

Product Teams

The minimum product development team that we saw in the chapter on Product management career is composed of a product manager, a product designer, and two or more engineers. This minimum team can also be called squad. This team should have a maximum of about 7 people. The larger the team, the greater the difficulty of coordination. At Amazon there is the famous rule of two-pizza teams, i.e., the maximum size of the team is one that can be fed by two large pizzas. The rationale behind the advantage of small teams is based on the same concept that I presented when I talked about platforms in the chapter “What is digital product and product management?“. The amount of interactions between team members increases rapidly with the size of the team, following the formula n * (n-1) / 2. Thus, while a team of 5 people has 10 possibilities of interaction between its members, in one of 7 people that number grows to 21.

When we join two or more squads we have a product team, which can also be called tribo.

This product tribe can have one, two, or three leaders. If it has one leader, he will be responsible for leading product managers, product designers, and engineers. If there are two leaders, usually one will lead product managers and product designers, and the other will lead engineers. If there are three leaders, one leads product managers, another leads product designers, and the third leads engineers. I have already had the opportunity to work in structures with one, two, and three leaders in each product tribe, and each one of these structures has its pros and cons, as I explained in the chapter on Product management career where I talk about unique leadership and shared leadership.

Product teams may also have some roles shared between the squads. Having them shared instead of dedicated per squad has three main objectives:

squad size: preserving the small squad is important to preserve the agility of this team. As explained above, the larger the team, the greater the need for coordination between team members.
ownership: as soon as you have a person in the squad with a specific role, that role is no longer the responsibility of the other team members. For example, if we have a person taking care of the quality, that topic becomes that person’s responsibility, and the other people in the squad will be less concerned with this topic. The exceptions are the three primary functions of a squad which are engineering, product design, and product management.
resource allocation: in addition to the squad getting big if we put these roles inside each squad, needing more coordination and having the risk of slowing the squad down, each squad will cost more. With smaller squads, we have the possibility to allocate the resources that you have available for product development in more squads that build products.

Examples of roles that may exist in a product tribe shared between different squads:

Agile Coach: helps the squads in their agile processes and culture. Instead of a scrum master per squad, there is an agile coach per tribe who helps the squads on this topic, but the processes and agile culture of each squad are the responsibility of each member of the squad.
Quality Assistance: just as processes and agile culture are the responsibility of each member of the squad, so does quality. Instead of a quality assurance per squad, we can have a quality assistant per product tribe, which will help each squad with quality issues.
Data Analyst: every squad generates a lot of data and needs to understand what that data means. Again, understanding what this data means is a squad’s responsibility. However, when the data structure is very complex, it may make sense to have one person per product tribe assisting your squads in the more complex data needs of each squad.
SRE: for products with a lot of integration with third-party systems it may be interesting to have a Site Reliability Engineer (SRE) per tribe helping the squads to define and implement stable, well-performing, and resilient architectures. At Conta Azul, as we had integration with banks and with the systems of the Secretaries of Finance of each state for issuing invoices, it made sense to have a person with this knowledge in each tribe.
User Research: this is the responsibility of the product designers, with support from the product managers of each squad. In some cases, it may make sense to have a research-focused person in the product tribe to help with each squad’s research.
Product Marketing: While the product manager’s mission is to build the product or functionality that solves users’ problems, product marketing’s mission is to tell the world about the product or functionality and the problem it solves. This “world” refers to both existing users of the product and new users that we want to bring in to use the product. Thia role is responsible for designing and implementing the product’s go-to market (GTM) strategy. In many companies, this responsibility falls to the product manager. This works in many cases, but it can take product manager’s focus off building the best product or feature.

There are other roles that can be shared but remember that the more shared roles you have, the more difficult it will be to coordinate the people of the tribe. My recommendation is to have a maximum of 3 shared roles. These shared roles can be led by the tribe leader(s) or by the structural tribe leader corresponding to their role.

Organizing product teams

There are 4 possible ways to organize product teams, by product or feature, by user type, by user journey, or by objective. It is also possible to use two different types of organizations thus creating a hybrid organization. I will describe each of these forms of team organization below.

BY PRODUCT OR FEATURE

This is one of the most common ways of organizing product teams. For each product or feature, we have a tribe. At Locaweb we had a product team for each product, Email Marketing, Virtual PABX, Cloud, Website Hosting, and so on. At Conta Azul, we also used this model, with a team called Spartans focused on features related to financial management and the other team called Underground focused on tax and accounting features. At Lopes, when I joined, we had a team focused on the Portal, another on the CRM used by real estate agents and franchises and a third focused on the app for real estate agents.

The main advantage of this form of organization is that the part of the product that is the responsibility of the tribe is very clear, but on the other hand, with the focus on the product, we may lose the perspective of the person(s) for whom the product solves problems.

BY USER TYPE

This is a very useful model in marketplaces and platforms. Each tribe focuses on one actor of the platform. For example, at Gympass, where we had gyms, HR, and employees, we had 3 tribes, each focused on these three marketplace actors. At Conta Azul we had two tribes focused on the owner of the small business and two focused on the accountant.

The advantage of this organizational model is that the focus of each team is well defined, aiming to improve the experience and solve the problem of each actor on the platform. If the systems architecture is closely coupled, there can be a lot of dependency between the teams. Another point of attention is that some journeys can be divided between two tribes. For example, at Gympass there is a journey to check in at a gym. This journey happens when the user goes to the gym, checks in and the front desk validates that check-in. In a team organization by user type, both the gym team and the end-user team are responsible for this journey and must coordinate themselves to make changes in this part of the product.

BY USER JOURNEY

In this model, teams are organized according to each user’s journey. Searching, buying, scheduling classes and so on are journeys that your user can go through when using your product. I confess that I have never seen a team 100% organized by user journey, but I have seen teams that are organized by product or type of user who have one or more tribes focused on some journey. For example, at Conta Azul we had a team called Hubble that took care of the user’s journey until he could use financial features, taken care of by Spartans and tax and accounting features, taken care of by the Underground team. At Gympass, in addition to the company’s employee, gym and HR teams, we had a team, called Cross Features, which took care of registering each of the marketplace participants (users, gyms, and HRs) and receiving payment made by HRs and users, and for calculating the payment to the gyms. At Locaweb we created the central systems team, later renamed to enterprise applications, responsible for the customer center, where Locaweb customers can view and manage all their products.

The main advantage of this structure is that the focus on a journey increases the chance of providing a great experience in that specific journey. On the other hand, normally one squad is enough to take care of a journey so you may end up with many one squad tribes.

BY OBJECTIVE

An organization based on objectives means that the tribe focuses on a specific objective. Conversion, retention, usage experience, etc. I don’t know any team 100% structured only by objectives. At Gympass we used this mode of organization in the end-user team, where we divided it into two tribes, one focused on growth, which aimed to ensure that Gympass customers’ employees downloaded the app, created a free account and became subscribers, and another focused on digital experience to ensure that users use and get the most out of the app, ensuring user satisfaction and retention.

In this type of organization, the main benefit is the focus on where you want to get, the objective. The drawback is that you may have two squads with different objectives tackling with the same area of the product, which may cause a weird experience for the user. Another drawback is that If the systems architecture is closely coupled, there can be a lot of dependency between the teams.

HYBRID

These different ways of organizing product teams can be used together. They are not exclusive. Actually, I’ve never seen a product development team using exclusively one type of organization. Teams are structured in hybrid organizations. Here are some examples of hybrid organizations.

At Locaweb we had teams organized by product (Hosting, Email Marketing, Cloud, etc.) and a team focused on the customer journey (Customer Center)

At Conta Azul we used organization by functionality. One team for the financial management of small businesses (Spartans) and another for tax and accounting management (Underground). One for the tax, accounting, and payroll management of the accountant’s clients (Area 42) and another for the management of the accountant’s clients (Babilônia). We also organized by type of user (teams focused on the business owner and the accountant) and by journey (Hubble).

At Gympass we created teams by type of user (end-user, gyms, and HR), but we also use the organization by user journey to create the Cross Features team, responsible for registering each participant of the marketplace (users, gyms, and HRs) and getting paid by HRs and users, and for calculating the payment to the gyms. We also used the organization by objectives when we broke the end-user team into two tribes, one for growth and the other for digital experience.

It is important to note that these examples are from the time I worked at these companies. As the product vision, strategy, and objectives evolve, the team structure must also evolve.

Organizing squads in a product team

These forms of organizing product teams serve both to define the tribe organization, as well as the organization of a tribe’s squads. Some examples:

Hosting (Locaweb): Within the Locaweb hosting team we had 3 squads, one focused on Windows hosting, another on Linux hosting, and a third as a focus on the hosting management control panel.
Gyms (Gympass): In the team focused on Gympass gyms we had squads focused on APIs for integration with gym management systems for integration of the check-in process in gyms and for booking classes and squads focused on the experience of the gym manager so that he could have access to reports and configure how his gym would appear in the user’s app.
Financial (Conta Azul): In the team focused on the financial management of Conta Azul, we had a team focused on integration with banks to receive bank statement data from customers, another focused on the financial management interface, with reports and a system for categorizing the entries of the bank statement and a third one focused on a feature that had its own name, the Easy Collection (Receba Fácil in Portuguese), a bank slip issuing system.

Structural Teams

Structural teams are teams that work in the necessary structure for product teams to be able to do their job.

Some types of structural teams needed in the development of digital products:

SRE or DevOps: SRE stands for site reliability engineering. This area, sometimes called DevOps, is responsible for the infrastructure where the product will be hosted and served to customers. Also responsible for monitoring the product and the infrastructure where the product is hosted to ensure that it operates with optimal performance.
Data: here we usually have 3 disciplines that need to be taken care of by the data team. First, a data engineering team is needed to take care of the necessary infrastructure for managing the company’s data. Then a data analysis team is required, responsible for generating reports and dashboards based on the data and for showing the product performance. Finally, it is interesting to also have a team of data scientists able to take insights from the data and eventually create machine learning algorithms that can evolve as more data is collected and analyzed.
Architecture / Tools / Foundation: a team that helps product teams to define software architecture standards. This team can also work on topics that are common to all teams, such as authentication and authorization, and API infrastructure.
Design Ops: central design team that takes care of creating and maintaining the Design System, library of components, and interaction patterns. This team can also take care of the operational efficiency of the designers, giving them tools, empowering the managers and leaders to evaluate designers’ performance, helping with the onboarding. This team can also have user research and UX writing professionals.
Information Security: responsible for all aspects of information security, such as GDPR, PCI certification, ISO 27001 certification, BYOD (bring your own device) policies to allow employees to use their own devices for the job.
Internal Systems: responsible for taking care of third party systems, such as Google Suite, Office 365, Slack, etc., as well as the company’s equipment.
Sales Engineering: this area makes a lot of sense in companies that develop products for other companies. It is a team with technical knowledge capable of discussing details of the implementation and integration of your product with the customer’s systems.
Professional Services: If the implementation and integration needs of the new client deviate from the standard, or the client is not prepared to make this implementation or integration, it may be interesting to have a professional services team that does this job. It is recommended that this team be very lean and use third parties as required to do the implementation and integration work.
HRBP and hiring: As seen above, product teams and their structures are complex, with a lot of collaborative work and matrix structures. It is essential to have an HR team nearby to help manage the team, with two focuses. HRBP, or human resources business partners helps in the day-to-day activities of teams and leaders in all matters related to HR. Hiring, or talent acquisition is responsible for the entire process of attracting and hiring people for the team.

Implementation

The implementation of the product structure that was designed can happen in two ways. You are either creating a structure from scratch, or you are adjusting an existing structure.

CREATING A NEW STRUCTURE

When you create a structure from scratch, you have the opportunity to grow as needed. You can start with a single squad, then create the second squad, and so on. It is important to keep in mind where you want to go with this structure. Will you have structural teams? Which ones? What product teams do you intend to have? I also recommend starting to assemble these teams by their leaders, so that they can have the opportunity to hire and form teams according to their needs, as long as they are aligned with the vision you have designed.

CHANGING AN EXISTING STRUCTURE

When you arrive to lead an already formed team, it is important to be clear about the product vision, the current structure, and the people who are part of that team. You will need to make several conversations to better understand these three aspects before proposing changes to the current structure. As soon as you design the first version of your proposed new structure, present it as work in progress to some people to collect feedback and adjust your proposed structure. Once the new structure has been agreed, coordinate with the team members to make the change. It may be that some teams that are going to be mixed up are finishing doing some things, so it is important to align with these pending tasks to allow a smoother transition from the current structure to the new structure.

What is the best ratio between Eng, UX, and PM?

We can find many articles from different product development teams around the world showing Eng:PM and UX:PM ratio benchmarks. There is a recent article by Ken Norton, a partner at Google Ventures and a former product management leader at Google and Yahoo!, where he shares the results of an informal survey he run on Twitter:

A significant majority of tweets recommended something in the range of 5 to 9 engineers for every PM. There were reasons why people recommended going higher or lower, but it seems like a sweet spot. Thinking of my own experience, my best performing teams also fell into this range.
When it comes to designers, I prefer a 1:1 ratio with PMs for user-facing products. Product teams work best when the dedicated triad of PM, designer, and technology leader forms the core.

Therefore, it appears that the general recommendation is 5 to 9 engineers per PM and 1 UX per PM. Here, when we count engineering people, we must also consider people from structural teams.

SOME REAL-LIFE NUMBERS

At Gympass, we worked to increase the number of engineers per product manager. In our efforts, increasing the team from 32 to 85 people in 5 months has already increased the Eng / PM ratio and also the UX / PM ratio. Our plan was to reach the end of 2019 with almost 200 people on our product development team, with even more engineers per product manager and a better balance between UX designers and product managers, as it turned out.

All benchmarks are clear when they explain that each product manager must be paired with a UX, especially for customer-oriented products. In the case of Gympass, there are 3 different types of customers (end-users, gyms, and corporate customers), which reinforces the need to maintain the recommended ratio of 1 product designer per product manager.

At Conta Azul we had a good Eng:PM ratio when I joined in August 2016. However, the UX:PM ratio was below market standards. Especially if we take into account that one of the 4 fundamental values of the Conta Azul is to deliver Wow to customers. For this reason, we worked to increase the ratio of user experience designers to product managers so that we can increase the Wow delivered to customers.

At Locaweb, many of the products we built were for software engineers. Website hosting, database hosting, SMTP, Cloud servers, and dedicated servers. For this reason, the number of engineers per product managers is greater than that of Conta Azul and Gympass. It is even higher than the recommended upper limit of 9 engineers per product manager. However, we can see an interesting fact in the ratio of UX designers to product managers. As seen in the August 2015 figures, a higher proportion of Eng:PM forces an increase in UX:PM compared to the recommended 1:1 ratio. When we look at the numbers for July 2016, we have more engineers per product managers, reaching almost 12 Eng:PM, which increased the UX PM ratio to almost 2:1. We had to assign 2 UX designers to each product manager so that they could handle all the discovery work that needed to be done so that engineers could build the right product. Considering engineers as responsible for delivery and UX and product managers responsible for discovery, this shows us that we had about one person from discovery for every 4 people from delivery.

Conway’s Law

Conway’s Law was created by Melvin Conway, an American computer scientist, and published for the first time in April 1968, in an Information Technology magazine well known at the time called Datamation. Conway’s Law says that:

*Conway’s Law
Any organization that develops a system will produce a system whose structure is a copy of the organization’s communication structure.

I have already seen situations in which a product development team is organized in parity with the business areas, that is, a team focused on the needs of customer service, another focused on the sales team, another focused on the financial, plus one focused on the marketing, and so on. I do not recommend this type of structure, as it reduces the focus on the customer.

Tuckman’s stages of team evolution

Bruce Tuckman, an American researcher on group dynamics, proposed in 1965 4 stages that a group of people going through when they begin to work together, and how these stages impact on the effectiveness of that group.

forming: at this stage people in the group are getting to know each other, understanding common objectives, and looking for ways to work together.
storming: then there are some confrontations when the group starts to discuss how the work will be done. It is time to define the role and responsibilities of each member of the group.
Norming: this is the moment when the group members define the work process and the roles and responsibilities of each team member. In this phase, the team members already know each other and respect each other’s skills.
Performing: this is when the team actually starts to produce and deliver results. The team already knows each other well, the work process is clear and agreed upon by all team members.

There is no better way to structure a product team. There is one that makes the most sense for the strategy and objectives defined to achieve the product vision. Therefore, the team structure is not written in stone, if there is a need, due to a change in objectives or strategy, it may make sense to change the team structure. However, I don’t recommend doing this very often, due to the time it takes for a newly formed team to go through the Tuckman stages. I heard certain people commenting that they work for companies that changed the product development team structure every 3 or 6 months. It is not enough time to go through Tuckman’s stages.

Business units

In some situations, instead of having separate product teams within the same organization, it may be interesting to create reasonably independent business units. In business units, we have not only a separate product development team but also all the areas necessary for the business to happen independently, such as marketing, sales, customer service, etc.

At Locaweb, we opted for the model of independent business units when we acquired companies. Tray was an e-commerce solutions company that became part of Locaweb’s product portfolio. As Tray already operated as an independent company, we chose to keep it that way, only having the areas of office management, finance, and HR in common. This is a very common way of creating business areas, through acquisitions of companies.

At Gympass we saw the opportunity to create a new product called Gympass Wellness, which offers wellness services such as workout, nutrition, and meditation apps for employees of Gympass customers. We chose to start this new product as a business unit, with a product, marketing, and sales teams independent from Gympass, aiming to give greater autonomy and agility to this team.

At Lopes we have CrediPronto, a business unit that is a joint venture between Lopes and Itaú Bank to offer credit to real estate buyers. Due to the nature of the business being completely different from the main business of real estate transactions and also because we have a new partner, the business unit model was chosen.

What makes a group of people behave as a team?

It’s not enough to organize people in the teams structure described above for them to behave as a team. In order for them to perceive themselves as a team and start acting as such, they need common objectives.

A very common issue I see in product development teams is that, even being very well organized into tribes and squads, with structural tribes and product tribes, and right people with the right roles in each team, the objectives are set per function. Product managers have a set of objectives that is different from product designers objetives that is different from engineers objectives. That simply doesn’t work, because each person will focus on his objectives.

If we define all objectives as being common to all members of the team, they all work together to achieve the objectives. Even if the objective seems more related to one of the aspects, like more business related (product manager) or more user experience related, or more engineering related, all members of the team must have the same objectives.

So, the short answer to the question “What makes a group of people behave as a team?” is common objectives.

Summing up

Product development teams are organized into minimal teams, also called squads, composed of engineers, product designers, and product managers. It is important to keep these teams as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.
There are 4 ways to organize product teams: by product or functionality, by type of user, by user journey, or by objective. It is also possible to use two different types of organizations thus creating a hybrid organization.
There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering, and Professional Services.
The implementation of the designed team organization can be done either by creating a new structure or by adjusting an existing team. In both situations, it is important to know the product vision, strategy, and objectives in order to design and implement a team structure aligned with that vision.
The most suitable ratio between people in engineering and product managers is 7 +/- 2 engineers for each product manager. And a product designer for each product manager.
Two important concepts in the design of your team structure are the concepts of Conway’s Law, which says that organizations tend to create systems that are a copy of the company’s communication structure, and Tuckman’s 4 stages of team evolution, forming, storming, norming and performing.
It is also possible to organize product teams by business units that have other functions besides those included in a product development team, such as marketing, sales, and customer service. The motivations for creating business units instead of product teams may be due to the acquisition of a company, or to give more agility to the new business, or even because it is a new product line completely different from the original product.
What makes a group of people behave as a team is common objectives.

In the next chapter, we’ll see a little more about developing the team and managing expectations.

Missing something?

So, did you miss something in this chapter? What else would like me to cover?

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.