Mentoring is one of the most important responsibilities of a head of product: helping your team to evolve. As I said earlier, between 10% to 40% of the head of product’s time should be focused on helping people on your team on their development.

People who know me know that I like clearly defined terms, so here’s Wikipedia’s definition of mentoring:

“Mentoring is a process of informal transmission of knowledge, social capital, and psychosocial support perceived by the recipient as relevant to work, career or professional development; mentoring involves informal communication, usually face to face and over a period, between a person who is perceived as having more knowledge, wisdom or relevant experience (the mentor) and a person who is perceived as having less (the mentee) ”.

From this definition, the unidirectional nature of mentoring is clear, that is, knowledge flows from the “mentor” person to the “mentee”.

I received and gave guidance throughout my career. Even when I was a student, I gave and received guidance. I think someone has received guidance since she was born. Since the beginning of my career, I have had the opportunity to give guidance to the people I lead and, more recently, I have been invited to guide entrepreneurs and product managers to help them in the next stages of their ventures and careers. I am very happy to know that I can help someone by sharing my experience.

A two-way street

However, my experience as a mentor has shown me that Wikipedia’s definition is incomplete. Wikipedia defines mentoring as the transmission of knowledge. My understanding is that mentoring is more than a transmission of knowledge. It is an exchange of knowledge. Even considering that one of the people involved in the mentoring process is more experienced in a certain aspect, topic, or area, the other person may have experience and knowledge in another aspect, topic, or area that can bring new insights. Or the other person can use her novelty in the topic she is being mentored to bring a new perspective that the mentor has missed.

Therefore, the next time you are in a mentoring situation, especially if you are in a mentor position, think of it as an exchange of knowledge, social capital, and relevant, useful, and valuable psychosocial support for both the mentee and the mentor. I have a feeling that you will enjoy your next mentoring session even more.

Summing up

  • Mentoring is one of the most important roles for a product head. It is through mentoring that a head of product helps his team to develop.
  • Mentoring is a two-way street. The person in the role of mentor should be open to new learning from his mentoring sessions with his mentor.

In the next chapter, we will understand a little more about culture, what values ​​are essential for a company to have successful products, and the role of the head of product in creating and maintaining the company’s culture.

Missing something?

So, did you miss something in this chapter? What else would you 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.

Leading under pressure

There is no work environment without pressure. I don’t know of any workplace where people say that goals are easy, that there is no risk in achieving the goals, or that the project will be delivered on time with 100% confidence. If the company is growing rapidly, people need to sustain or improve that growth rate. If the company is in crisis, people need to get the company out of the crisis.

And that’s good! In fact, this is the only way to do things! People need pressure to get things done.

What do leaders need to know about pressure? People, including leaders and the people they lead, receive pressure from outside (the objective, the expected delivery date, the lack of resources), as well as from within (motivation, drive, inner strength).

Think of people and teams as balloons

A good analogy that I like to use, especially when the external pressure increases, is that people and teams are similar to balloons. We need to balance the external pressure with the internal pressure, with some tendency to have a little more pressure on the outside to guarantee the best performance. If we put too much pressure on the outside, without providing people with the necessary tools to increase the internal pressure, the balloon will explode, that is, performance will decrease, people will be uncomfortable, sometimes they will even get sick (burnout) and will probably leave the company. Sometimes we can see some increase in performance right after an exaggerated increase in external pressure, but we should not be fooled by these initial results. They will not be sustainable if the internal pressure is not increased. This increase in performance will last for a few days and performance will decline to even lower levels than when we increased external pressure.

How can we improve internal pressure? No one can directly impact anyone’s internal pressure. This can only be done indirectly. Here are some tools:

  • We need to hire people with the right motivation, drive, and inner strength, and we must create the environment so that these people can maintain the right motivation, drive, and inner strength. Think about aligning objectives, vision, values, culture, and financial and non-financial incentives.
  • We must support the right balance between moments with and without pressure. We can do this by encouraging people to step away from pressure in the workplace and to do other things they enjoy, such as exercise, yoga, meditation, music, reading, spending time with loved ones, cooking, partying, etc. On the other hand, we should avoid working long hours, at night, on weekends and holidays. Note that working long hours is a tactic that can and should be used, but only when necessary. If this becomes the norm, rather than the exception, we are not supporting the right balance between moments with and without pressure.

The balloon analogy works for both individuals and teams. Too much pressure on a team without the proper internal pressure will cause the balloon to explode. In the case of a team, it will begin to malfunction, team members will begin to point fingers at each other and performance will drop. To increase a team’s internal pressure and help them deal with increased external pressure, we need to create an environment that promotes the creation of stronger ties between team members so that they are more effective in responding to external pressure, being more resilient, and more adaptive at the same time. More effective responses to external pressure require a combination of resilience and adaptation.

The balloon analogy is also good for explaining why the best people decide to leave a company. We can think of this situation as if there is more internal pressure than external pressure. If a person or team has more motivation, drive and inner strength than what the leader asks of them or the company’s strategy requires of them, they will inflate the balloon until it explodes. Then they will leave the company. Remember priority #1: people, always.

Summing up

  • There is no work without pressure environment. People and teams need external pressure (the goal, the expected date, the lack of resources) and also from within (motivation, drive, inner strength) to exist and do things, like a balloon.
  • The internal pressure and the external pressure need to be balanced with some tendency to have a little more pressure on the outside to have continuous improvement.
  • Under pressure, a person and a team explode or become stronger. It is the leader’s role to help the person or team to realize this and work together with them to support increased internal pressure.

In the next chapter I will talk about mentoring.

Missing something?

So, did you miss something in this chapter? What else would you 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.

Leading is like being a doctor

In February 2011 I underwent cervical spine disc replacement surgery. The doctor performed the surgery on February 25th. However, the healing process took months. According to the doctor, it could take a year for all the symptoms that motivated the surgery to disappear.

What caught my attention is that the surgeon only makes an intervention, but the entire healing process is done by the body. The same happens when a doctor prescribes a medicine, which is also an intervention, but, again, the body is in charge of the entire healing process.

Leading a team is very similar. The leader must make some interventions when necessary, but it is up to the team to do the work to achieve the goals.

Agile leadership

In one of my readings on leadership, I found an interesting comparison between leadership and gardening by Jurgen Appelo, author of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders:

I tend to compare managers to gardeners. An unattended garden is usually full of weeds, not beauty. From a biological perspective, there is no difference. Either way, the ecosystem in the garden is self-organizing. It takes a gardener (authorized by the garden owners) to transform an anarchist garden into something that the owners will enjoy. Likewise, a manager (authorized by the shareholders) is needed to lead the self-organized teams in a direction that adds value to the shareholders.

Even though I like this comparison, he considers that the gardener / manager must constantly interfere, which I do not believe is a suitable behavior for a manager. In my opinion, a manager’s interference should only be done when necessary and, after the interference, the team should work on its own to resolve things with little or no intervention from that manager. Hence my comparison with a doctor who interferes only when necessary, prescribing changes in habits, medicines, physiotherapy and / or surgery and who lets the body do the work and take responsibility for the healing process.

Summing up

The next time you are on a team, either as part of the team or playing the role of leading the team, think of the doctor’s leadership role and teamwork similar to the body’s healing process. It helps to understand the roles and responsibilities of the leader and the people on the team.

In the next chapter, we will understand how to lead under pressure.

Missing something?

So, did you miss something in this chapter? What else would you 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.

People: priority #1, always

Every company has its own culture and, within each company, every department also has its own culture. In addition, each person also has their principles and values ​​that guide their steps through life. In this part of the book, part 2 of 3, I will talk about the culture, values ​​and principles that I believe are mandatory to create successful digital products. Also, what are the 4 main values ​​that every product development team and, consequently, every company that has digital product development teams should have.

I’m going to start this part of the book by sharing my personal leadership principles. There will be five principles:

  • People: priority # 1, always
  • Leading is like being a doctor
  • Leading under pressure
  • Mentoring is a two-way street
  • How and when to delegate

I will talk about these principles throughout this and the next chapters, starting with the principle that people are priority #1, always.

People: priority #1, always

I often see companies claiming that company valuation, revenue, growth, profit, number of customers, or customer satisfaction is their number one priority. All are good priorities and each is appropriate for specific contexts in which a company can be. However, I argue that they should be priority number 2, 3, 4 and so on, because our number 1 priority should always be the people who are part of our team. Without the people who work with us, it will be very difficult, if not impossible, to achieve any other goal that we have.

People are people (source: Flickr)

We spend money and energy attracting the best people and convincing them to join our company to build what we intend to build to achieve the goal we have set. We pay these people to be with us throughout the construction process. We are usually upset when we lose people on our team, especially if they are really engaged and aligned with our goals. Therefore, the people on our team are like customers, we spend money and energy to acquire and retain them. But they are even more important than our customers, because without our team, there is no way for us to be able to deal with our customers and achieve our goals.

This does not mean that we need to be “nice” to our team, or that we should give everything they ask for. What we need to do is to balance external and internal pressures so that people can continually improve. If the external pressure is increasing, we need to create the environment and provide the tools for people to be more motivated, have more drive, and increase their inner strength. And if we have people or teams with excess motivation and energy, we need to give them more responsibilities and higher goals. In the chapter Leading under pressure, I will talk more about this balance.

Rotten apples

The term rotten apple, although quite strong, serves to describe a very delicate situation in the formation and management of teams. We call the person who negatively clashes with the rest of the team and who, with his behavior, may spoil the team.

InfoQ ( talked a lot about the technically rotten apple theme, the under-performer, the one who is technically below the rest of the team, and how the team can help this person to improve.

What to do when we come across a rotten apple from a behavioral point of view? Someone who is technically good, but who has behavioral problems? Technically this person can have enough to contribute to the team but his behavior makes the team unable to have a good relationship with that person.

In such cases there are two paths to follow:

  • The simplest is to remove that person from the team. This is an easy solution for both the team and its leader. The tendency in such a situation is for the team to isolate the difficult person until he, by himself or by the leader’s decision, leaves the team.
  • The most difficult path, but which will certainly bring more benefits to the team, is to help this difficult person to belong to the team to the point where the person is no longer a bad apple.

It is easy to welcome people who are easy to deal with. The challenge is to receive a difficult person and help them join the team. The values ​​of the team must be stronger than the values ​​of the difficult person to the point that the values ​​of the team are absorbed and assumed by the difficult person.

Frank conversations with the whole team and with the difficult person are a good tactic. Transparency is essential. If there are goodwill and willingness from both the team and the “rotten apple”, chances are good that the situation will be reversed.

It is worth remembering that, in most cases, a rotten apple does not want to be a rotten apple. He may not realize that her behavior is harmful to the team. He may have had previous experiences where her behavior would be considered normal. So it is worth investing in helping the team and the difficult person to understand each other. However, it is not possible to try indefinitely to make things right. It is important to set a deadline to reevaluate the situation and, if it has not been resolved, there may be no other option but to make a more difficult decision: dismiss one or more people from the team.

Summing up

  • People are, and should always be, the #1 priority of any company. We spend money and energy to acquire and retain the best people. Having people as #1 priority is the key to achieving any other goal. This does not mean being “nice” to people giving everything they want, but that we must be able to balance the challenges that we give people with their abilities so that people can continually improve.
  • Rotten apples can drain and harm your team. You must help these people to fit into your team and, if that is not possible, you must make the most difficult decision: get that person out of the team.

In the next chapter, we will understand what a leader’s job should be like through the analogy that leading is like being a doctor.

Missing something?

So, did you miss something in this chapter? What else would you 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.

Leadership anti-patterns

An anti-pattern is a common but ineffective and counterproductive response to a problem. This term was coined by Andrew Koenig in 1995, inspired by the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich, Helm Richard, Johnson Ralph, and Vlissides John, who lists a series of software development design patterns that their authors found simple, succinct and effective for the most common problems.

The term was popularized by the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael Malveau, William Brown, Hays McCormick, and Thomas Mowbray, which extended its use beyond the software design field to refer informally to any bad solution to a problem.

Wikipedia anti-pattern page lists over 70 antipatterns. I will list below the anti-patterns that I have encountered most often in my career. These anti-patterns that I quote below happen when the company’s leadership does not have enough experience in digital product development and is advised by people who have been successful in managing software development in the past, but who have not updated themselves.

As I explained in the introduction, software development is a very new science, especially when compared to other sciences like astronomy, medicine, mathematics, chemistry, civil engineering, etc. The first time a computer stored software in memory and successfully ran it was at 11 am on June 21, 1948, at the University of Manchester, on the Manchester Baby computer. This means that software product development is in its infancy. If a professional does not keep up to date, the knowledge and experience that has made him successful in the past may not be the most suitable to make him successful in the future.


Excessive use of documentation will undoubtedly slow down the product development team. It is not for nothing that in the Agile Manifesto, written in 2001, we say that we value “Software in operation more than comprehensive documentation”. Unfortunately, for some leaders documentation is even more important than the product itself. Nothing can go into production if it is not properly documented.

The last time I wrote a PRD (Product Requirement Document or Product Requirements Document) was in 2005 right when I joined Locaweb. A very time-consuming job, where I documented in detail everything we needed to implement in the product. I passed to engineering and sometime later the implementation was made with many errors because the engineers ended up not understanding what was written in some parts and decided to implement it as they saw fit. From that, we started to decrease the use of extensive documentation and increased the interaction between product managers, product designers, and engineers.

Marty Cagan has a very cool article called How to write a good PRD where he comments at the beginning:

I provide this document here mainly for historical purposes. It was written in 2005 to reflect best practices from previous decades.

I have not advocated the use of PRDs for many years, starting around 2007. It is not that PRDs are so bad. However, if the product manager is spending his time writing the PRD, then it is unlikely that he or she is doing the actual product discovery work.

Recommended pattern: just follow the agile manifest, product in the hands of customers brings more value to customers and the company than comprehensive and detailed documentation.

Focus on data

It happens when the head of product and other leaders only make decisions if there is an abundance of data, reports, charts. There are two dangers with this anti-pattern:

  • time: sometimes it takes a long time to gather all the necessary data. It is the situation known as analysis paralysis. Nothing happens until the data is meticulously obtained and analyzed. Often, after a first analysis, more data is requested and more time is invested in the search for this new data, and this cycle can be repeated over and over again. And, while this cycle is repeated, no decision is made. Hence the paralysis of the analysis.
  • errors: when we rely solely and exclusively on data there is a great chance that we will incur errors. How can we be sure that we have all the data needed to complete the analysis? How can we be sure that the data is correct? It is common to hear that decisions must be data-driven, that is, based on data. However, as stated above, the data may be incorrect and / or insufficient to describe a particular situation. Thinking about it, more recently the concept of data-informed decisions has emerged, that is, decisions are based on data, but not only on data. They take into account qualitative information, previous experience, and intuition in addition to data.

Recommended standard: make decisions based on data, but always understanding that the data is incomplete, and always take into account qualitative information, previous experience, and intuition.

Big rewrite

Every company has legacy systems. Even a startup that was just created, in a few months will be able to look at its code base as a legacy and something that needs to be improved. At that moment we start to hear phrases like:

  • It is increasingly difficult to deal with the code.
  • If I were to do it from scratch, it would be much faster.
  • If we don’t rewrite, it will get slower and more dangerous to change the code.

And at that moment, the great solution of rewriting was born. And this major rewrite will, at some point, cause a product evolution freeze. Why write something for the legacy, if the new system will replace it? And there is also migration or transition. How will we go from the legacy system to the new one?

Normally, in the initial estimates, the rewriting will take about 2 or 3 months and when we move forward we realize that it will be a little longer, and may take years. At Locaweb we made the decision to rewrite the central system that managed customer data and collection. The original project was forecast to take 9 months and ended up taking more than two years. In addition, when the new system came in, our customer billing did not work for about 2 months and stayed for another 6 months running incorrectly until we finished all the necessary adjustments. That is, the rewriting that originally would take 9 months ended up taking 3 years.

Recommended pattern: avoid major rewrites at all costs. Most of the time, there will be ways to replace the legacy system gradually and progressively, without causing disruption to the company and customers.


When a new head of product joins a new company, it is common during the onboarding process, during the numerous conversations with people from various areas of the company, to hear a series of requests and complaints regarding the product that this new head will take care. To “score points” with these people, who will eventually give feedback on the head of product’s work, he may be tempted to build his list of what to do based on these reported requests and problems. It is the company’s “wish list”. Then, this product head will prioritize this list or even outsource this prioritization to a leader in the company’s sales or business area. I’ve seen situations where the product head collects the “wish list” and presents it at a meeting with leaders from various areas of the company and says “now I need you to prioritize what you want the product development team to do first “.

Although it is somewhat tempting because the “wish list” will actually help the head of product to score points with the leaders of other areas, this behavior will make the product development team become a mere order taker and feature factory, inhibiting the innovation potential that this team can bring to the business. When the head of product focuses the team on delivering the “wish list”, it ends up focusing the team on being an implementer of solutions that are given by other people, taking the team’s focus on the problems to be solved. It is the difference between the team that implements solutions that are already envisioned by other areas of the company versus a team focused on deeply understanding the company problems and then finding the best solutions to solve these problems. I’ll talk more about this in the part about principles.

Recommended standard: product development team works to understand problems and then evaluate possible solutions. So go find the list of problems to work on, not the list of things that other areas want the product development team to do.

Summing up

  • Anti-patterns are common but ineffective responses to problem-solving. There are many well-documented anti-patterns in the world of digital product development. The 4 most common anti-patterns in product development leadership are documentation, focus on data, big rewriting, and wish list.
  • Documentation, which should be kept to a minimum, for certain leaders is even more important than the product itself. Nothing can go into production if it is not properly documented.
  • Focus on data is when any and all decisions have to be made with data, without taking into account qualitative information, previous experience, and intuition.
  • Big rewrite happens when a new product head finds a system written some time ago and identifies that it will be better to rewrite a new system from scratch than to improve the current system.
  • Wishlist comes from the need for the new product head to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.

With this chapter, we finish part 1 on the Concepts needed to understand the roles and responsibilities of a product head. In the next part, we will see which Principles should guide the work of a head of product and his team.

Missing something?

So, did you miss something in this chapter? What else would you 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.

Developing the team and managing expectations

As I commented in the chapter Roles, responsibilities and seniority, in addition to defining and implementing the product vision and strategy, it is the responsibility of the head of product to develop his team and manage expectations. In the third part of this book on Tools, I will talk about several useful tools to help the head of product to fulfill these two responsibilities. However, before talking about these tools, I wanted to talk about three very important concepts for a head of product.

As I described in the book “Product management: How to increase the chances of success of your software“, the 7 main characteristics of a product manager are empathy, communication, time management, new technologies, business skills, keen curiosity, and product theme. As you can imagine, these characteristics are also fundamental for a head of product. However, I would like to highlight and remember 3 of them, since I consider them essential for the day-to-day of a head of product:


Empathy is the ability of a person to put himself in the shoes of another person to understand his expectations, desires, motivations, needs, and problems. This characteristic is important to understand the customers and users of the product, to know how they relate to it, and what problems they hope to solve or what needs they want to be met. This will help the product manager to better understand its user so that, together with UX and engineering, they can develop the best product.

However, empathy should not be used only with the customer or user. The product manager must also use it in his relationship with all areas of the company to help him understand what the expectations these areas have regarding the product, and what impact his product has on their work. Did legal problems increase due to some new functionality in the product? What is the impact for the sales, support, operations, finance and marketing team? Even in relation to the product team, engineers and UX designers, how does the product interfere with the work of these professionals?

Empathy is also very important so that the head of product can understand how he can help his team to develop. Which of the 7 characteristics mentioned above needs more attention at this moment and why? What is the best way to help this person develop this skill?

The head of product also needs to put himself in the shoes of the owners of the product, to understand their expectation about the product and the results it will bring to the company.


The ability to communicate is fundamental so that the head of product can manage expectations and help his team to develop. The head of product needs to communicate with people in the most different scenarios: in conversations one by one and in small groups, or making presentations to small and large groups of people, presentations that can be internal (within the company) or external (in conferences, user groups, etc.).

He must also be good at written communication (e-mail, blog, documentation, chat, social networks, etc.), and be able to discern which form of communication is most appropriate for each moment, audience, and means of communication; and to communicate in a way to be understood by different audiences: technical and non-technical. As if that were not enough, he also needs to be able to communicate with confidence and confidence in what he is communicating; after all, the head of product is not only the spokesperson for the product but also the most senior reference in the entire company for the product.

It is important to remember that communication is a two-way street, that is, the head of product must be very good at knowing how to listen and understand what others are saying, and understand their problems and needs; which has to do with the first characteristic, empathy.

Business skills

The product manager must be concerned with whether his product is meeting the business objectives, as the achievement – or not – of the business objectives is the main source of people’s expectations regarding the product. How will the product help the company to achieve its business goals? If the goal is margin, are revenue and costs under control? If the goal is only revenue, how is it growing? If the goal is the number of users, how is this metric evolving?

In addition, the product manager must understand how each area of ​​the company works and how the product affects those areas. How does legal work? How does the product impact the legal department? And how does the legal department impact the product? These questions can be repeated for all areas of the company: support, operations, finance, HR, marketing, sales, engineering and UX.

Summing up

  • To develop your team and manage expectations, the product head must have the 7 characteristics of a good product manager: empathy, communication, time management, new technologies, business skills, keen curiosity, and product theme
  • Three of these characteristics are essential for the work of the head of product. Empathy to understand where expectations come from and what elements need to be developed in your team. Communication to make you understand and make yourself understood when you are talking to the people of the company to manage your expectations and when you are developing your team. Business skills that will help the head of product understand the goals of the company that are important components of the expectations that people have regarding the product.

In the next chapter, we’ll look at the leadership anti-patterns we can find in product development teams.

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.

Team structure

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.


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.

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 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 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.


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 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.

Strategy and objectives

What needs to be done to get your product closer to the product vision? This is your strategy and product objectives. We are then talking about defining what to do, how to do it, in what order to do it, and what metrics tell us that we are going in the right direction once the why to do it has already been defined in the product vision.

The strategy and objectives provide a path to be followed and metrics that show whether or not we are in the right direction. Without a clearly defined strategy and objectives, it is very difficult to define the most appropriate team structure and what needs to be done to achieve these objectives.

Creating your product strategy

As you already have your product vision, you need to understand what you need to do to execute your product vision, that is, to get where you want to go.

Below are some tools that will help you create your product strategy:

Market analysis

As explained in my book “Product management: How to increase your software’s chances of success“, to create your strategy, you need to have a good understanding of your market in five aspects:

  • competitors: both direct and indirect, that is, those who compete for the time and attention of your users. For example, a competitor of physical activity is streaming services, which motivate its users to watch more and more videos.
  • potential and accessible market: how much market, that is, how many people could be your customers? In order to be your customer, are there any minimum requirements? For example, if you sell an online course to medical interns preparing for the assessment process to join a medical residency program, your potential market is all medical students in their final years of graduation. This is your potential market. And out of that total of people, how many people can you actually talk to and who will want to use your product? In the example above of the online course for medical students, how many can you talk to and show your product? This is your accessible market.
  • market growth: is the number of people with the potential to use your product growing, stable, or decreasing? And how many people can you talk to about your product? It is very important to understand if the market you see for your product is growing, stable, or decreasing, and if this movement is in the short or long term. Understanding how your market is moving is fundamental to help you define your strategy.
  • disruptors: as important as knowing your direct and indirect competitors, you need to know which products can disrupt your product, that is, replace the benefit that your product delivers in a better and more attractive way for your users. For example, people are using less and less email due to the communication options that direct messaging products like WhatsApp and Slack have offered.
  • regulation: is your market regulated? Do you know this regulation? Were there any changes in this regulation? For example, at the Conta Azul, we monitored tax and accounting regulations on a daily basis to ensure that the product was in line with those regulations.

This work must be coordinated by the head of product in conjunction with the marketing leadership. Probably this type of analysis has been done in a timely manner. My recommendation is to make market analysis a permanent discipline, that is, once the first version with the items above has been created, update monthly to ensure you have the most up-to-date information about your market.

SWOT Analysis

From your market analysis, the next step is to understand your product’s position in this market. Both the current position and the position you want to occupy when you have executed your product vision. A good tool to help with this understanding is to do SWOT analysis, which stands for Strengths, Weaknesses, Opportunities, and Threats.

SWOT analysis

Strengths and weaknesses are internal items (from your product development team, or your company) over which you, your team, or your company have some control, items that help or hinder your product to achieve your vision. Opportunities and threats are the elements external to the organization, that is, over which the organization has no control, and which can positively or negatively influence the achievement of the product’s vision. It has to do with the market analysis described above.

Filling in the SWOT should be a team effort. The heads of product must have one or more sessions together with people who can contribute to this analysis. Leaders of your team and other areas are the right audiences for this type of session. How to organize a SWOT analysis session:

  • Homework: ask everyone to complete a SWOT analysis. Limit to a maximum of three items per quadrant. It is common, especially in the weakness quadrant, for people to create a very large list of items, often with more than 10 weaknesses. When asking to limit by 3 items per quadrant, people will be forced to do a first prioritization.
  • Consolidation: combine all SWOT analyzes into one analysis. There will be some overlaps and some differences. Place items in each quadrant with the number of people who placed each item in their individual SWOT analysis. This amount can serve as the first indication of prioritization.
  • Final version: bring people together in a conversation to evaluate the consolidated version. The goal now is to make the consolidated version also have a maximum of 3 items per quadrant to force everyone to prioritize once again. Usually, a single session can be enough to build this final version.

Once you have your final version of the SWOT analysis, you have 12 items that can serve as the focus of your strategy. I say “can” because you don’t have to work on all the items at the same time. Here, once again, the ability to prioritize comes in. Bearing in mind that SWOT was designed to help us show the path that needs to be taken to achieve our product vision.

  • Strengths: how to keep them relevant? Do you need to do anything to reinforce them? Are any of your strengths more important than the others?
  • Weaknesses: How to reduce the impact of weaknesses? Which of these weaknesses has the greatest impact?
  • Opportunities: is it possible to explore opportunities? What can we do to explore opportunities? Which of the opportunities is most relevant to the execution of the product vision?
  • Threats: What should we do to protect ourselves from threats? How do these threats impact the execution of the product vision?

These discussions should also be held in groups, and can even be done in the continuation of the creation of the SWOT analysis. With these discussions, you will already have an alignment between the leadership of the different areas regarding the product strategy.


OKR means Objective and Key Results. It is a management tool that serves to align and monitor the execution of the strategy. This tool has been used at Google since its inception and was brought there by John Doerr, an employee of Intel, the company where this tool was created. Several technology companies today use OKRs, such as Locaweb, Conta Azul, Gympass, Linkedin, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix, and Spotify. OKR is a framework derived from a management technique called Management by Objectives, a term created by Peter Drucker in his book The Practice of Management, from 1954.

It is a very simple yet powerful tool. You define together with the team some objectives for a period – usually a quarter or a year – and define which metrics you will use to show that the objective is being reached. Each objective can address one or more items in your SWOT analysis or represent something that you want to execute from your vision.

For example, let’s say one of your goals is “Achieve record purchases per month in our website”. To achieve this goal, you can define the following key results:

  • Increase from 15,000 to 20,000 visits per week
  • Improve the conversion rate from 4.5% to 6%
  • Lower the bounce rate from 35% to 20%
  • Improve page load times to less than 2 seconds

The team should look at the OKRs every week to see if the metrics are moving in the right direction and understand if there are any impediments to be removed or something to be done to accelerate the achievement of the objectives. More frequent deliveries and measurements help to achieve objectives. If there are only monthly deliveries and measurements, the team will only have two chances in the quarter to test their idea of ​​how to move the metric. If there are weekly deliveries and measurements, there are 12 opportunities to evaluate and change course if necessary.

There, you now have your product strategy, the objectives you want to achieve, and the metrics that will tell you if you are reaching your objectives. Your next step will be to define the most appropriate team structure to execute your strategy and achieve your goals, a topic for the next chapter.

Reviewing your product strategy

Your product evolves as the team works on it and you get closer to your product vision. Much is learned about the users of the product, their problems, and needs. New alternatives may appear to help its user to solve their problems and needs. The owner of the digital product can also revisit his strategic objectives and, consequently, revisit the objectives defined for the digital product.

In addition, strengths and weaknesses can change over time, and opportunities and threats can appear or disappear. So it is important to understand that neither the vision nor the product strategy and objectives are written in stone. They can and should be revisited periodically.

My suggestion is that they be revisited annually, or when some relevant event happens, such as when there is a change in the company’s strategic objectives, or when an alternative appears that solves the user’s problem or need in a different way than yours. product, or when a crisis like the COVID-19 pandemic occurs.

For OKRs, my suggestion, as mentioned above, is that they are defined quarterly and reviewed weekly. This will give your team a good execution cadence.

Summing up

  • Product strategy is nothing more than the path you will take to arrive at your product vision.
  • To create the product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of this market, if there are disruptors, and regulation of that market.
  • Use SWOT analysis to help you define which points you will work on in your product strategy.
  • Use OKRs to help you define your strategic objectives and metrics that will tell you if you are on the right track.
  • Review at least annually, or when there are relevant events in the market, your strategy, and your product vision. The market changes, your product evolves, so your product vision and strategy must also evolve.

In the next chapter, we will see different ways to structure the development team in order to execute the product strategy in order to achieve the product vision.

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.

Product vision

Despite being only 10% of a product leader’s time, defining the product vision is the most important responsibility. Without a clear product vision, it is very difficult to work on any other product topic. What are the priorities? What product team structure is needed? Is this request from the sales team important? And this one from the customer support team? And that request from the CEO / Founder? Should we focus on having more customers or retaining the ones we already have? These questions are very difficult to answer if there is no clarity about the product vision.

When I join a new company, whether in a full-time role or as an advisor, my first concern is to understand if there is a product vision and if it is clear to everyone in the company. This is always my first focus, because from the product vision derives all product development work.

What is a product vision?

The product vision is nothing more than an understanding of what your product will look like in the future. By “the future” I mean mid to long-term, like more than 2 or 3 years. How will it achieve the objectives of the company that owns the product while solving problems and needs for its users?

Building the product vision is a collaborative work done together with several people inside the organization, as well as with input from outside people such as customers and non-customers, suppliers, competitors, market specialists, etc. This is a job led by the head of product, whether he is a VP or CPO, whether he is a GPM. If he is a VP or CPO, the vision will scope all products of the company or area, while if it is a GPM, the focus of the vision will be one of the products, or part of a bigger product, that this GPM takes care of. For the GPM to be able to build the vision, he needs to have a clear understanding of the company’s product vision.

In my book “Product management: How to increase the chances of success of your software”, I explained that to make the product vision it is necessary to be clear about the company’s objectives, as well as to deeply understand the problems and needs that customers have and that will be resolved by the product. Some examples of product visions I helped build:

Locaweb Email Product

During my time at Locaweb, we put together the following product view for the Locaweb E-mail product:

Locaweb’s E-mail product will be the most complete and flexible email solution ** in the Brazilian market.

CONTA AZUL product view

We created the Conta Azul product vision as an image, because with the image it was easier to explain all the elements that we saw as the future of the Conta Azul product.

Conta Azul product vision

Gympass product overview

Again, we prefered a picture over words. The saying a picture is worth a thousand words has a reason for existing.

Gympass product vision

Product vision creation process

Here is a step by step on how to create the product vision:

  • get the strategic company objectives: if you don’t have this information yet, go get it. Talk to company leaders, the CEO, the founders, the board. Of course, every company wants to grow and have more revenue and customers, but how? What are the company’s goals, and what is the strategy to achieve those goals?
  • get an understanding of customers’ problems and needs: if this is still unclear, there are several tools that help. In the chapter on Vision and Strategy of my book “Product management: How to increase the chances of success of your software” I mentioned empathy and personas as useful tools to obtain this information. There are several other tools such as observation, interview, research, job to be done etc. Anyway, there are several tools for you to obtain this information.
  • draw the first version of the vision: once you have both information, you can already make the first version of the product view. This is a creative job and is more productive if done alone. I already tried to do this work together with other people and the process ended up taking a long time and the result was not so good for having several people discussing something that didn’t exist yet. Based on my experience, it is more productive and produces better results when the head of product makes the first version and, from there, iterates to collect feedback and refine the vision.
  • iterate and refine: once the first version of the product vision is done, it’s time to iterate and refine the vision. First people to iterate are the people on the product development team. PMs, GPMs, designers, engineers. Listen to their feedback and refine the product vision based on that feedback. Then, present to the leaders of the other areas, managers, directors, c-level, founders, advisors, more feedback and refinement. I prefer to do these feedback and refinement sessions individually. Although it takes more work and time, it gives everyone the opportunity to speak.
  • communicate: after the iterations and refinements of the product vision in 1:1 sessions with stakeholders, the next step is to communicate this vision to the entire company and even outside the company. This must be done repeatedly. At every opportunity, remember the product vision. I usually use the product vision at all possible times. All-hands, product, board, onboarding meetings, etc. I even use it publicly in lectures and articles to explain how we see the future of the product in our company. I also use it in conversations with candidates, to help them understand what we are building and to encourage them to join us.
  • review: it is important to review the vision periodically, to check if all its elements still make sense and if something new needs to be included. My suggestion is to do this review once a year, or when something new appears, like a new competitor, or some change in the market.

There you go, the steps to make the product vision.

Summing up

  • Despite being only 10% of a product leader’s time, defining product vision is his most important responsibility. Without a product view all the product development work is much more difficult.
  • The product vision is nothing more than an understanding of what your product will look like in the future.
  • To make the product vision it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product.
  • The 6 steps to build a product vision are to obtain strategic objectives of the company, gain understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

In the next chapter, we’ll look at how to execute your product vision.

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 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.

Product management career

In my book Product Management: How to increase the chances of success of your software I comment on career progression starting with Business Analyst (BA) as the beginning of a career, with the responsibility of specifying what the product development teamwill build, then going to Product Owner (PO) which, in addition to specifying, must also prioritize what the product development team should do and, at the top of the career comes Product Manager (PM) who, in addition to specifying and prioritizing, must also define the vision and strategy of the product or piece of product that she takes care of.

BA, PO and PM

Another way that many companies have designed this career evolution is to consider the BA and PO phases as Associate Product Manager (APM), with the responsibility of specifying and prioritizing. It is the first step in a product management career.

APM and PM

Since product management is a role of great responsibility, I recommend that people entering the product career be people with some previous experience in other areas such as engineering, design, or marketing. I have also seen great product managers coming from operations, support, project management, financial, and even legal. Throughout my career I have noticed that people who have just left college do not have the necessary baggage to be able to be good product managers. It is important to have this experience in other areas to help you understand how your product impacts those other areas.

And then?

The question that remains is, what’s next? A person goes from APM to PM, then to Senior PM, but what is the next step in your product management career?

A minimum product development team is made up of a few engineers, usually starting with 2 engineers and reaching up to 7 engineers, one of whom is someone more senior, with a tech lead role, plus a product designer (PD) and a product manager (PM). When there is a need to create a second team to take care of another part of the product, there are two ways to make this team expansion:

  • expand engineers, divide and hire PM and PD: we can divide the team of engineers into 2 teams, each with a focus, and temporarily keep the product manager and product designer in these two teams until we are able to hire a second product manager and a second product designer. This model is used when the scope of work of the second team is very clear.
  • hire PM and PD to do discovery, expand engineers and divide: in this case we bring first a PM and an additional PD to work on the discovery of what we want to do with this second team. Meanwhile, more engineers are being hired to expand the first team. At a certain point in the discovery, already having some clarity of what this second team is going to do, then do the team division. This model can be useful when there is still no clarity as to what this second team will work on and it is necessary to do a work of discovery that does not fit in the day-to-day of the original PM and PD.

In both cases, if the original product manager is a more senior product manager, we can hire that second more junior product manager or even an associate product manager and give the more senior product manager the opportunity to help that junior product manager develop. It would be a first people management opportunity for this more senior product manager, if that is something she is looking for in her career. While she still takes care of a product or piece of product with the first team, she can begin to experience the leadership of another, more junior product manager.

After one to two quarters running in this configuration, it is possible to understand if the most senior product manager liked this new role, of helping a more junior PM to develop. If that role is something that makes sense to the senior PM, it is possible to think about adding more junior product managers to help her. At that point it will become increasingly difficult for this PM to manage a product or a piece of a product.

I am focusing on the career of product manager, but there is a similar path in both engineering and product design. The most senior tech lead may come to lead the other team’s tech lead, just as the most senior product designer can lead the other team’s product designer.

Group Product Manager

This is the moment when the senior PM becomes a Group Product Manager (GPM). This is the first step in a product leader career, when the product manager does not directly care for a product or a piece of a product and is responsible for helping other product managers to develop and manage their products. This usually happens when the person is leading 3 or more product managers and is responsible for a set of features or even an entire product. In some companies, this position is called head of product, or product director, or even product vice president.

At Conta Azul we had GPMs that took care of pieces of the product. A GPM was more focused on the product’s financial features such as financial reporting, issuance of bank slip, etc. while the other was more focused on accounting and tax functionalities such as registration of purchase and sale, inventory management, issuance of invoices, etc.

At Gympass we had product directors focused on each actor in our marketplace. One product director focused on gyms, another focused on our clients’ HR and a third focused on our clients’ employees.

In a small company, GPM can be the highest level of product careers. For example, in a company with up to 6 or 7 PMs, a single GPM to coordinate those PMs may be sufficient. When you go over that number, it may be interesting to have a second GPM, or even a CPO or VP of product that leads the GPM and some PMs.

In addition to leading PMs, the GPM also has the role of coordinating the definition of the vision and strategy of a group of products or features. For example, the HR product director at Gympass has to lead the PMs who work on pieces of the HR product, which we called the HR Portal, as well as to define the future vision of this HR Portal, that is, where we wanted to get with the HR Portal and the strategy, that is, the way to get there. And with PMs, he is responsible for executing this strategy.

Interim leadership

I imagine that you have already seen some situation in which the person is an excellent individual contributor, receives a promotion to lead people and, for not being prepared or even for discovering that he does not like to lead people, he ends up having a bad performance as a manager. But this person understands that he cannot go back, returning to a position as an individual contributor can be seen as a setback in the person’s career, as a failure.

An interesting tool to prevent situations like this is the concept of interim. Instead of the person already assuming a permanent position of GPM and leading one or more people, the concept of interim GPM can be used, that is, the person takes on this role temporarily, as a test for him to see if he likes and feels comfortable doing the role of leader. This tool can be used in any career, not just in the product management career. From engineer to engineer leader, from product designers to UX leader, etc.

This tool creates a safeguard, a safety net for people who have never led people and want to try this career option. With this tool there is room to go back if the person does not like it or does not feel prepared to perform this function. It is the famous concept of change rollback or undo that allows to undo a change and return to the previous version if we notice that the change made is not working as expected.

CPO or Product VP

The Chief Product Officer (CPO) or Vice President, Product is the highest product position in a company. Leads GPMs or product directors and is responsible for coordinating the definition of the vision and strategy of all the company’s products, as well as for the execution of this strategy, together with the GPMs and product directors. In some cases it may make sense for the UX area to report to the CPO. Ideally, given the importance of digital strategy in companies, the CPO position should report to the CEO and have access to members of the Board.

Product management career

The nomenclature can be a little confusing. Some companies call this position head of product, others call product director or product vice president or CPO. Although the nomenclature is confusing, the important thing is that the structure is clear to everyone inside and outside the product development team.

There are two models of leadership structure for product development teams, each with its pros and cons depending on the context where this team is:

Unique leadership

At both Locaweb and Conta Azul, I had the role of CPO with the responsibility of leading the entire product development team, that is, product managers, product designers and engineering.

Unique leadership works when you have senior people to help with engineering management as well as design and product management. At Conta Azul, the team had 130 people and I had an engineering head, 4 GPMs and a design head to help me. At Locaweb with a team of 100 people I had two senior engineering managers, 5 senior PMs and a UX head.

I like this configuration because I have always seen the product development team as a single team, with common goals of delivering the best product to meet the company’s objectives while solving problems and user needs. This configuration helps with alignment and this single team vision.

This type of setup works very well for small teams, up to 80 to 100 people. When it reaches that size, there is a risk of overloading this unique leader responsible for the entire product development team. It is a multitude of different themes, hence the importance of having senior people helping in leadership.

In some companies, instead of CPO, this unique leadership is called Chief Technical Officer (CTO) or Vice President of Product Development.

It may make sense to think of dividing the area into two leaders when the team grows to more than 100 people, with a CPO and a CTO doing the shared leadership. It is worth remembering that shared leadership, despite being beneficial in the sense of sharing responsibilities, can have harmful side effects if it is not well managed by the CEO.

Shared leadership

At Gympass we ran for 18 months with a CTO and two CPOs, one of which was for consumer productsand I focused on products for companies and partners. We opted for this configuration because we expected a considerable growth of the team. When the team was still with 60 people, we already saw growth of up to 400 people. Being able to share responsibility, especially when the team grows fast to numbers above 100 people, helps to put more attention and go deeper into the themes that each leader takes care of. This avoids the overhead that I mentioned above.

Product development leadership structure in Gympass

At Gympass, the UX team reported to the consumers CPO while I had, in addition to the product teams for companies and partners, a Professional Services (PS) team that was responsible for making customized integrations with gym and training systems. our customers’ HR systems. This professional services work is more project-oriented, with a clear definition of scope and well-defined deadlines, so we created a separate area to take care of these integrations.

At Conta Azul, when I left there in mid-2018, we were starting to think about dividing the roles between CTO and CPO. So much so that now in 2020 there is this structure with the shared leadership of the product development team.

Product development leadership structure at Conta Azul

Another possibility for shared leadership of product teams is to have head of engineering, products and UX.

Shared leadership has the side effect of the inherent risk of creating silos, that is, of having teams working in isolation and without the necessary collaboration. At Gympass, we had a strong concern to avoid this behavior. We sat 3 side by side and reserved at least three hours a week to talk about topics of the product development team, one hour between the three of us, one hour the three of us together with an HR business partner, and one hour with the CEO. In addition, we sought to set goals in a common way for teams and treated the budget as a single budget for the product development area.

However, despite our efforts, there were still situations of lack of collaboration between members of different teams. For this reason, I prefer configurations with a unique leadership of the product development team, despite the possible overload that this may cause in this leadership. One way to reduce this burden is to have senior leaders.


As I mentioned earlier, the product development area is a single area, with the common goal of creating the best product to tend to the company’s strategic objectives while solving customers’ problems and needs. Having two or more leaders for this area requires a lot of coordination between these leaders to ensure that the teams are collaborating and evolving in the same direction. The most common way to share this leadership is to have two people, CPO and CTO, to lead the product development team. While the CPO leads product and UX people, the CTO leads engineering people.

Division of responsibilities between CTO and CPO

The image above illustrates well the responsibilities of each leadership. The CTO takes care of the actual development of the product, that is, it has to be concerned with the quality of what is being developed, as well as with the speed of development. It also takes care of infrastructure and operational issues such as product stability, performance and availability.

The CPO takes care of the product from both the business and the customer’s point of view. From the business point of view, the CPO is responsible for defining the product vision in line with the strategic objectives of the business. From the customer’s point of view, he needs to ensure that the product solves a customer’s problem or need with quality and, for that, he needs to understand the customer’s satisfaction and engagement with the product.

Together, CTO and CPO must define and evolve the structure of the product development team, normally composed of product teams and structural teams (SRE, Data, etc) as we will see in a future chapter, as well as define and evolve the processes that this team will use in their day-to-day activities.

Y career

Career Y is the option given to people to choose the managerial career or to continue in the specialist career. Some senior PMs may not want to manage people, just products. Does this mean that there is no room for her to evolve in her career, since the path of progression seen above goes through the leadership of other PMs? Not necessarily. In companies with more complex products or even with a portfolio of more than one product, there may be room for a role little known in the Brazilian market, but that can help a lot in this context, the Principal Product Manager. This is a role that does not manage people but that, due to its seniority, has a relevant impact on the organization. Its main responsibilities are:

  • Help connect the work of GPMs: as the company grows and we have more than one product development team, each with their own GPM and often focused on the day-to-day life of that team, without looking a lot for what the other teams are doing. It is usually the role of the CPO to maintain the connection between the work of the different teams and their GPMs, but in some structures, it may make sense to have some very senior PM playing this role.
  • Ensuring synchrony and consistency between product teams: regardless of whether we try to structure product teams, there will always be situations in which a team will depend on the work of another team. An example in Gympass are the product teams for the gym and for the end user. The gym team makes a feature that allows the gym manager to create the class schedule, and the team focused on the end user needs to make that class schedule available in the app so that users can view and schedule classes. This coordination is usually done by the PMs of these two teams, but they can benefit from having a third person helping in this coordination. That third person can be a GPM, CPO or even a more senior PM, in this role of Principal Product Manager.

Note that these responsibilities are a subset of the responsibilities of a product head or even a CPO, without responsibility for the management and development of PMs, which can be attractive as a career progression for people who do not want to manage other people. This role is still new. Some companies see this role as just a very senior PM, but I think it makes sense to think about that role with a greater contribution than just a team.

Summing up

  • The product career has progressed from Associate Product Manager (APM) to Product Manager (PM) to Group Product Manager (GPM) to Chief Product Officer (CPO). There are some variations of nomeclature depending on the company and the country, but in general this progression follows. The important thing is that this structure and career progression is clear for the entire company.
  • When talking about the most senior product leadership in a company, there are two options with their pros and cons. One option is the ** unique leadership ** of the entire product development team (PM, UX and engineering) which works well for larger teams but can be overwhelming when teams of more than 100 people. The advantage is having the entire team aligned with a single leadership. The other option is ** shared leadership ** with CPO and CTO. It avoids overload in large teams but can cause a decrease in collaboration if there is not a good harmony between these two or more leaders.
  • For PMs who do not want to pursue a management career, it is important to give the Y career option, with the role of Principal Product Manager which helps in the integration and synchronization of the work of the different teams.

In the next chapter we will look at one of the main responsibilities of the product head, the creation of the product vision and strategy.

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 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.