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.
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 tribe.
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:
Examples of roles that may exist in a product tribe shared between different squads:
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.
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.
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.
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.
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.
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.
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 business (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.
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:
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:
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.
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.
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.
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.
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 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:
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.
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.
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.
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.
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.
In the next chapter we’ll see a little more about developing the team and managing expectations.
So, did you miss something in this chapter? What else would like me to cover?
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.