Structuring effective product development teams

This article is part of my latest book, “Digital Transformation and Product Culture.” It is another excerpt from the chapter on team structure, where we will see how to organize product teams.

Product Teams

The minimum product development team we discussed is com- posed of a product manager, a product designer, and two or more engineers. This minimum team can also be called a squad and should have a maximum of about seven people. The larger the team, the more challenging coordination becomes. At Amazon, there is the famous “two-pizza team” rule, which means that the maximum size of a team should be one that can be fed by two large pizzas.

The rationale behind the advantage of running with small teams is based on the same concept I presented when discussing platforms in the chapter on Business Models. The number of interactions be- tween team members grows rapidly with the team’s size, following the formula n*(n-1)/2. Therefore, while a team of 5 people has 10 possible interactions among its members, in a team of 7 people, this number grows to 21.

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

Product team

This product tribe can have one, two, or three leaders. If there is one leader, they will be responsible for leading product managers, product designers, and engineers. If there are two leaders, typically, 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 had the opportunity to work in structures with one, two, and three leaders in each product tribe, and each of these structures has its positives and negatives. The advantages of shared leadership include avoiding overload and allowing for greater leadership specialization. On the other hand, it can contribute to forming silos and requires more coordination effort. Single leadership has the advantage of discouraging the formation of silos since it is a single person leading. However, the drawback is the leader’s overload, who will have to be knowledgeable in a broader range of topics beyond their natural domain.

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

• Squad size: Keeping the squad small is essential to preserve the agility of the team. The larger the team, the greater the need for coordination among team members.
• Ownership: Once you have a person in the squad with a specific function, that function ceases to be the responsibility of other team members. For example, if we have someone taking care of quality, that responsibility becomes theirs, and other squad members will worry less about the 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 becoming larger if we place these roles within it, requiring more coordi- nation and risking slowing down, each squad will cost more. With smaller squads, we can allocate the available resources for product development to more squads building products.

Examples of roles that can be shared among squads in a product tribe:

• Agile Coach: Helps squads with their agile processes and culture. Instead of one scrum master per squad, there is one agile coach per product tribe who assists the squads in this matter, but the processes and agile culture of each squad are the responsibility of each squad member. Quality Assistance: Similar to agile processes and culture, quality is the responsibility of each squad member. Instead of one quality assurance per squad, we can have one quality assistance per product tribe, assisting the squads with quality issues.
• Data Analyst: Every squad generates a lot of data and needs to understand what this data means. Again, understanding what this data means is the responsibility of the squad. However, when the data structure is very complex, it may make sense to have one person per product tribe helping their squads with each squad’s more complex data needs.
• SRE (Site Reliability Engineer): For products with extensive integration with third-party systems, it may be interesting to have one Site Reliability Engineer (SRE) per tribe helping the squads define and implement stable, high-performance, and resilient architectures. In Conta Azul, as we had integration with banks and the Finance Secretaries’ systems of each state for invoice issuance, it made sense to have one person with this knowledge in each tribe.
• User Research: This is the responsibility of product designers, with support from product managers in each squad. In some cases, it may make sense to have a person focused on research in the product tribe to assist in each squad’s research.
• Product Marketing: While the product manager’s mission is to build the product or feature that solves user problems, Product Marketing’s mission is to tell the external and internal world about the product or feature and the problem it solves. This “external world” refers to both the product users and the new users we want to attract. The “internal world” includes all company personnel, including support and sales staff. Product Marketing is responsible for designing and implementing the product’s go-to-market (GTM) strategy. In many companies, this responsibility falls on the product manager. This works in some cases but can quickly become an overload and, consequently, harm product performance.

There are other roles that can be shared, but remember that the more shared roles there are, the more difficult coordinating the tribe members will become. My recommendation is to have a maximum of three shared roles. They can be led by the tribe leader(s) or by the structural tribe leader corresponding to their function.

Organizing product teams

Conway’s Law was created by American computer scientist Melvin Conway and was first published in April 1968 in a well-known Information Technology magazine called Datamation. Conway’s Law states:

Conway’s Law

Organizations which design systems are constrained to pro- duce designs which are copies of the communication structures of these organizations.

For this reason, the organization of product teams has a significant impact on the chances of success for your product.

There are four possible ways to organize product teams:

1. By product or feature;
2. By type of user;
3. By journey;
4. By objective.

Now, let’s delve into each of these forms in more detail.

1. By product or feature

This is one of the most common forms of organizing product teams. For each product or functionality, there is a tribe. At Locaweb, we had a product team for each product: Email Marketing, Virtual PABX, Cloud, Web Hosting, and so on. At Conta Azul, we also used this model, with one team, Spartans, focusing on features related to financial management, and another team, Underground, focusing on fiscal and accounting features. When I joined Lopes, we had one team focused on the portal, another on the CRM used by brokers and franchises, and a third focused on the app for brokers. In a bank, it’s common to have teams organized by financial products, such as current accounts, investments, credit, etc.

The main advantage of this form of organization is that the part of the product that is the tribe’s responsibility is very clear. However, on the other hand, with a focus on the product or functionality, there is a bit of a loss of perspective on the person(s) whose problems this product solves.

2. By user type

This is a very useful model in marketplaces and platforms. Each tribe focuses on a specific actor. For example, Gympass interacts with gyms, the HR departments of companies, and the employees of companies. Therefore, we decided to have three tribes, each focused on one of these three actors in the marketplace. At Conta Azul, we had two tribes focused on small business owners and two focused on accountants. At Lopes, we designed a structure in which we had one tribe focused on property buyers, another on sellers, and a third focused on brokers who facilitate the transactions.

The advantage of this organizational model is that each team’s focus is well-defined, aiming to improve the experience and solve the problem for each actor in the platform. However, if the system architecture is highly coupled, there may be significant dependencies between the teams.

Another point of attention is that some journeys may be divided between two tribes. For example, in Gympass, there is the journey of checking in at a gym, which occurs when the user goes to the gym, checks in, and the reception validates it. In an organization organized by the type of user, both the gym team and the user team are responsible for this journey and must coordinate to make changes in this part of the product.

3. By journey

In this model, teams are organized according to each user journey. Search, purchase, class scheduling, and so on are examples of journeys that your user may go through while using your product. I confess that I have never seen a team 100% organized by journey, but I have seen teams organized by product or by type of user have one or more tribes focused on a specific journey.

For example, at Conta Azul, we had a team called Hubble, that took care of the user journey until they could use financial features, handled by Spartans, and fiscal and accounting features, managed by the Underground team. In Gympass, in addition to user, gym, and company HR teams, we had a team called Cross Features, which took care of registering each participant in the marketplace (users, gyms, and company HRs) and also received payments made by HRs and users, calculating payments for gyms. At Lopes, we decided to create, in addition to the teams for buyers, sellers, and brokers, a team called Leads, which takes care of interactions between buyers and brokers. Later, this team joined the broker team, and we created a team called Central Systems, responsible for generating and managing purchase and sale contracts for real estate. At Locaweb, we also had the central systems team, later re- named enterprise applications, responsible for the customer portal, where Locaweb’s customers could view and manage all contracted products.

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

4. By objective

Organizing by objective means that the tribe focuses on a specific goal. Conversion, retention, user experience, etc. I’m not aware of any team structured 100% based solely on objectives. At Gympass, we used this mode of organization in the user team when we divided it into two tribes: one focused on growth, with the goal of ensuring that clients’ employees downloaded the app, created a free account, and became subscribers; and the other focused on digital experience, to ensure that users used and maximized the app, ensuring their satisfaction and retention.

In this type of organization, the main benefit is the focus on where you want to go — the objective. The disadvantage is that you can have two squads with different objectives dealing with the same area of the product, which can create a strange experience for the user. Another drawback is that, if the system architecture is highly coupled, there may be a lot of dependency between teams.

I’ve seen situations where a product development team is organized in parallel with business areas, with one team focused on customer service needs, another on the sales team, another on finance, and one more on marketing, and so forth. I don’t recommend this type of structure because it diminishes the focus on the customer and makes product teams subservient to other teams in the company — and in the chapter “Focus on the Problem,” we saw that this is not the way of working that extracts the most value, innovation, and results from the product development team.

Looking at these different ways of organizing a product team and their pros and cons, the question arises: what is the best way? The answer is: the hybrid approach.

These different forms of organizing product teams can be used in combination; they are not exclusive. In fact, I have never seen a product development team exclusively using one type of organization. Teams are structured in hybrid organizations. At Locaweb, for example, we had teams by product (Hosting, Email Marketing, Cloud, etc.) and a team focused on the customer journey (Customer Hub):

Locaweb product teams in 2016

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

Conta Azul product teams in 2018

At Gympass, we defined teams by user type (end user, gym, and HR), but we also used the organization by journey to create the Cross Features team, responsible for registering each participant in the marketplace (users, gyms, and HRs), receiving payments made by HRs and users, and calculating payments for the gyms. We also used the organization by objectives when we split the end- user team into two tribes, one for growth and another for digital experience.

Gympass product teams in 2019

At Lopes, we also defined teams by user type (end customer, developer & owner, broker & franchisee) and established a tribe focused on the journey between the customer and the broker, which we called Leads.

Lopes product teams in 2020

It’s important to note that these examples are from the time when I worked at these companies. Just as the product vision and strategy evolve, the team structure should also evolve.

Organizing squads into a product team

These forms of product team organization apply both to defining the organization among tribes and the organization of squads within a tribe. Some examples:

• Hosting (Locaweb): Within the Locaweb hosting team, we had three squads — one focused on Windows hosting, another on Linux hosting, and a third with a focus on the hosting
  management control panel.
• Gyms (Gympass): In the team focused on gyms at Gympass,
  there were two squads. One focused on APIs for integration with gym management systems, facilitating the check-in process for users and class reservations. The other squad focused on the gym manager’s experience, allowing them access to reports and the ability to configure how their gym appeared in the user’s app.
• Financial (Conta Azul): In the team focused on financial management at Conta Azul, there were three squads. One focused on integration with banks to receive bank statement data from customers, another focused on the financial man- agement interface with reports and a categorization system for statement transactions, and a third team focused on a feature with its own name, Receba Fácil, a system for issuing bank payment slips.

How to define the structure of the product team?

The input we need to define the product structure is what we covered in the two previous chapters: the product vision and strategy. These two pieces of information help us determine the best product team structure to assist us in achieving our objectives.

Locaweb offers digital products (Hosting, Email, Virtual Store, etc.), so a structure organized by product makes the most sense. At Conta Azul, we have financial and accounting products, as well as two actors: the small business and the accountant. These were the elements that guided the definition of the team organization. In the case of Gympass and Lopes, the focus was on looking at the marketplace actors: gyms, HRs, and employees for Gympass; for Lopes, it includes property buyers, property sellers (developers or property owners), and intermediaries such as brokers and their franchises.

When I joined Lopes in mid-2020, the teams were organized by product. There was a Portal team responsible for the portal where users search for properties, a CRM team, and another for the broker’s app. In the chapter on Problem Focus, I mentioned the broker’s app — an “MVP” that had been in development for a year and had not yet been launched. The team organization has a direct impact on how team members will solve problems. When we have a Broker’s App team, the only way this team knows to solve problems is by implementing features in that app. When we switch to teams based on marketplace actors, the Broker team gains the freedom to explore different solutions to deliver value to brokers. It could still be the app, but it could also be an SMS notification, a chatbot, a process change, or any other creative solution. The change in how the team organizes itself can enable the team to be more efficient in the solutions developed and, consequently, in the results achieved.

In the next article, we will learn about another type of team, known as structural teams, also known as platform teams, which are the teams that work on the structure necessary for product teams to be able to do their work.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
• Chapter 1: The so-called digital transformation — Project and Product
• Chapter 2: Uncertainty and digital transformation
• Chapter 3: Types of company
• Chapter 4: Type of company vs digital maturity
• Chapter 5: Business models
• Chapter 6: Agile, digital and product culture
• Part 2: Principles
• Chapter 7: Deliver early and often — Measuring and managing the productivity — Case study: Dasa Group — Case study: Itaú Unibanco
• Chapter 8: Focus on the problem — O Famoso Discovery de Produto — Why the “business demands => IT implements” model does not work — Case study: Magazine Luiza
• Chapter 9: Result delivery — Outsource or internal team? — Case study: Centauro
• Chapter 10: Ecosystem mindset
• Part 3: Tools
• Chapter 11: Product Vision — Product vision examples
• Chapter 12: Product Strategy
• Chapter 13: Team Structure

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products