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.

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.

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.

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.

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.

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.

CPO and CTO

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.

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.