How should the product manager relate to different areas of the company? Engineering, UX, product marketing, project management, operations, sales, legal, finance, customer service, human resources, and general management.

Recalling what I said in the chapter Main characteristics of a product manager, the most important feature every product manager needs to have is empathy, that is, the ability to put oneself in someone else’s shoes to understand their desires, motivations, needs, and problems. This feature should be used not only with the customer of the product but also with people from different areas of the company.

As said, the product manager must understand the impact his product has on legal work: have legal issues increased due to some new features in the product? And what about the sales, support, operations, finance, and marketing staff, did the new product complicate their lives so much? And for the product team, the engineers, and UX analysts who are part of the product core team, how do your product decisions impact their functions?

This is what we will see in this and the following articles!

Engineering and product management

I will start by talking about the relationship between product engineering and product management.

Definition

Product engineering is responsible for developing the product and keeping it operating. With the business vision brought by the product manager, plus the solution design made by UX people — based on an understanding of the customer’s need or problem — product engineering “builds” the product.

To build it, they must not only do the programming but also define the technical architecture. That is, what infrastructure it will run on, which programming language is most appropriate, which database is most appropriate, and how to ensure the non-functional requirements of this product (response speed, availability, scalability, etc.). It is also important to validate with the product manager whether the cost of this infrastructure fits his business model.

The fact that the product manager is responsible for defining the product to be made may give the impression that product engineering reports to product management. However, this view is incorrect, and if areas behave in this way, the chance of product failure increases because those who perceive themselves as subordinate have less commitment to the outcome.

Product engineering, product management, and UX are one team, there is no subordination relationship between any of these groups. They should function as partners, each with their own expertise and responsibility, collaborating to produce the best product possible.

Innovation

In the previous diagram, product engineering brings the available technology. As I explained in the chapter Innovation: what is it? to innovate is not simply to know the latest technology. You need to know not only this, but all available technologies, and how to use them. This is the role of product engineering. The opportunity and potential for producing an innovation lie in knowing the technologies available and knowing how to use them to solve a problem or meet a need of a group of people.

Practical Tips for Product Managers

To make life easier with the product engineering team, here are some practical tips:

• Don’t get into the technical solution unless you have earned the right to meddle. A product manager should have some technical knowledge of your product, but this is not your area of ​​expertise. The experts are in the product engineering team. Therefore, avoid presenting technical solutions to the engineering team unless this team is open to receiving your suggestions, and even so, the more time you spend thinking and discussing the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your client’s problems and needs.
• Take engineers into conversations with customers and users. As part of your daily life as a product manager, you should always talk to your customers and users to understand how your product solves their problems or meets their needs, and how you can make your product look even better. Engineers love to go to these conversations very much. It is a very cool experience for them to see real people using software they have developed. They will be even more engaged in the mission of making a better product.
• Always make data-driven decisions. Whether it’s data from your product access and usage, or data from your customer and user conversations, use data to make your decisions and present it to the team. This will give more consistency to the items you will place on your product roadmap.
• Learn to take out the excess. Always look for the minimum product or the minimum feature, ie try to implement as little as possible to achieve your business objective.
• Be present. It is critical to be with the product engineering team or at least as accessible as possible to the team. During product development, doubts will inevitably arise and if you are not present, either the team stops, or they will implement as they think it should be, which may differ from what you had planned.
• Provide the team feedback about the product. You, as a product manager, know how your product is doing, how many users it has, what these users are thinking of it, and how this product is helping the company achieve its goals. Tell this periodically to the product engineering team. As a result, you will be giving context and purpose to the team.
• Negotiate the rewriting and maintenance of stories. The engineering team, if it is a good team — attuned to good software engineering practices evolution and always following what’s new in the software development industry — will always find better ways to implement each piece of the product. If it is dependent only on the engineering team, the product backlog will only have stories about technical improvement. This is good, it shows that you are working with a great engineering team. However, you should use the previous item to provide the team with product context, ie to show that there are certain definite goals for the product that you as a team have to achieve, and therefore you should always release new features in it. There must be a balance between maintenance and rewriting stories, and new features. I’ve read in many places something like: “define X% of the time for maintenance and rewriting stories”. I don’t like to make this suggestion because I believe that every moment of the product requires a different balance, and it’s up to the product manager and his engineering team to talk and mutually agree on this appropriate balance at each stage. Remember the importance of finding a good balance, as this will avoid the famous technical debt that, as it grows, will slow down the product engineering team.

We can’t stand it, we need to rewrite everything…

I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.

At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and managing non-relational databases, as the database grew, the system became slower and slower.

So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, and allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.

However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver the new feature to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.

If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject:

• New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite the software.
• Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.
• If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner? Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:
  • What will this rewrite look like?
  • While rewriting is going on, will new features be delivered?
  • How will the new system coexist with the old system?
  • When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
  • When can new clients be installed on the new system?
  • When will existing customers be migrated to the new system?
  • If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
  • If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?

There you go, some considerations about software rewriting, a very important topic for any product manager.

Oh, and there’s one more thing!

Some product engineers end up becoming great product managers. It’s important to be able to figure out when an engineer is looking for “something else to do” and give him that career choice.

At Locaweb, we have (and had) great product managers who were product engineers. In some cases, they became product managers of the product in which they were engineers. On the other hand, there are some product engineers who have tried product management and disliked it.

For those who are used to measuring their productivity by features delivered, it may be strange at first to lose that productivity benchmark. As we have seen, a product manager’s day-to-day life is made up of a lot of talk with the various people involved in it, and that lot of talk can “scare” the engineer who is used to working focused on feature development. So, you have to leave the door open so that she can be a product engineer again, without any harm to her career.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Como o gestor de produtos deve se relacionar com as diferentes áreas da empresa? Engenharia, UX, marketing de produtos, gestão de projetos, operações, vendas, jurídico, financeiro, atendimento, recursos humanos e administrativo.

Relembrando o que falei no capítulo Principais características de um gestor de produtos, a caraterística mais importante que todo gestor de produto precisa ter é a empatia, ou seja, a capacidade de se colocar no lugar de outra pessoa para compreender seus anseios, motivações, necessidades e problemas. Essa característica deve ser usada não somente com o cliente do produto como também com as pessoas das diferentes áreas da empresa.

Como dito, o gestor de produtos deve entender o impacto que seu produto tem no trabalho do jurídico: será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? E quanto à equipe de vendas, suporte, operações, financeiro, marketing, será que o novo produto complicou muito a vida deles? E em relação ao time do produto, os engenheiros e os analistas de UX que fazem parte do core team do produto, como as suas decisões em relação ao produto, qual o impacto em suas funções?

É o que veremos neste e nos próximos artigos!

Engenharia e gestão de produtos

Vou começar falando sobre a relação entre engenharia de produto e gestão de produtos.

Definição

Engenharia de produto é responsável por desenvolver o produto e mantê-lo operando. Com a visão de negócios trazida pelo gestor de produto, mais o desenho de solução feito pelo pessoal de UX – baseado no entendimento da necessidade ou do problema do cliente –, a engenharia de produto “constrói” o produto.

Para construí-lo, ela deve não só fazer a programação como também definir sua arquitetura técnica. Ou seja, qual é a infraestrutura onde ele rodará, qual a linguagem de programação mais adequada, qual o banco de dados mais apropriado, como garantir os requisitos não funcionais desse produto (velocidade de resposta, disponibilidade, escalabilidade etc.). Deve também validar com o gestor de produtos se o custo dessa infraestrutura cabe no seu modelo de negócio.

O fato de o gestor de produto ser responsável por definir o produto a ser feito pode dar a impressão de que a engenharia de produtos está subordinada à gestão de produtos. Entretanto, essa visão é incorreta e, se as áreas se comportarem dessa forma, a chance de fracasso do produto aumenta, pois quem se sente subordinado tem menos comprometimento com o resultado.

Engenharia de produtos, gestão de produtos e UX são um time, não há relação subordinação entre nenhum desses grupos. Eles devem funcionar como parceiros e sócios, cada um com sua especialidade e responsabilidade, colaborando para produzir o melhor produto possível.

Inovação

No diagrama anterior, a engenharia de produtos é quem traz a tecnologia disponível. Como expliquei no capítulo Inovação: o que é inovação?, inovar não é simplesmente conhecer a última tecnologia. É preciso conhecer não só esta como também todas as tecnologias disponíveis, e saber como usá-las. Esse é o papel da engenharia de produtos. A oportunidade e o potencial de produzir uma inovação estão em conhecer as tecnologias disponíveis e saber como utilizá-las para resolver um problema, ou atender a uma necessidade de um grupo de pessoas.

Dicas práticas para gestores de produto

Para facilitar o dia a dia com o time de engenharia de produto, aqui vão algumas dicas práticas:

• Não se meta na solução técnica, a não ser que você tenha conquistado o direito de se meter. Um gestor de produto deve ter algum conhecimento técnico sobre seu produto, mas essa não é sua área de especialidade. Os especialistas estão na equipe de engenharia de produto. Por isso, evite apresentar soluções técnicas para o time de engenharia a não ser que esse time dê abertura para isso.
• Leve engenheiros nas conversas com clientes e usuários. Como parte do seu cotidiano como gestor de produto, você deve conversar sempre com seus clientes e usuários para entender como seu produto resolve os seus problemas ou atende às suas necessidades, e como você pode fazê-lo ficar ainda melhor. Os engenheiros gostam muito de ir a essas conversas. Para eles, é uma experiência muito bacana ver pessoas reais usando um software que eles desenvolveram. Eles ficarão ainda mais engajados na missão de fazer um produto melhor.
• Sempre tome decisões baseadas em dados. Quer seja dados de acesso e de uso do produto, ou dados de conversas com clientes e usuários, use dados para tomar suas decisões e apresente-os para o time. Isso dará maior consistência aos itens que você vai colocar no roadmap do seu produto.
• Aprenda a tirar o excesso. Busque sempre o produto mínimo ou a funcionalidade mínima, ou seja, procure implementar o mínimo possível para atingir o seu objetivo de negócio.
• Esteja presente. É fundamental estar junto com o time de engenharia de produto ou, pelo menos, acessível ao time o máximo de tempo possível. Durante o desenvolvimento do produto, inevitavelmente surgirão dúvidas e, se você não estiver presente, ou o time para, ou vai implementar como eles acham que deve ser, o que pode ser diferente do que você havia planejado.
• Dê feedback para o time sobre o produto. Você, como gestor de produto, sabe como o seu produto está indo, quantos usuários tem, o que esses usuários estão achando dele, como esse produto está ajudando a empresa a atingir seus objetivos etc. Conte periodicamente sobre isso para o time de engenharia do produto. Como isso, você estará dando um contexto e um propósito para o time.
• Negocie as histórias de reescrita e de manutenção. O time de engenharia, se for um time bom – antenado na evolução das boas práticas de engenharia de software e acompanhando sempre o que há de novo no desenvolvimento de sistemas –, sempre vai descobrir formas melhores de implementar cada pedaço do produto. Se depender do time de engenharia, o backlog do produto só terá histórias de melhoria técnica. Isso é bom, mostra que você está trabalhando com um ótimo time. Contudo, você deve usar o item anterior para dar o contexto do produto para o time, ou seja, mostrar que há determinados objetivos definidos para o produto, que vocês têm de atingir e que, por isso, vocês devem sempre colocar novas funcionalidades nele. Deve existir um balanço entre histórias de manutenção e reescrita e de novas funcionalidades. Já li em vários lugares algo como: defina X% do tempo para histórias de manutenção e reescrita. Eu não gosto de dar essa sugestão, pois acredito que cada momento do produto requer um equilíbrio diferente, e cabe ao gestor de produto e ao seu time de engenharia conversar e definir de comum acordo esse equilíbrio apropriado a cada fase. Vale lembrar da importância de encontrar um bom equilíbrio, pois isso evitará o famoso débito técnico que, à medida que cresce, fará com que o time de engenharia de produto fique cada vez mais lento.

Não dá mais, precisa reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão que normalmente tem frases como: está cada vez mais difícil mexer no código; se fosse fazer do zero, seria muito mais rápido; se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb, tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de e-mail marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade de armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que essa base crescia, o sistema ficava cada vez mais lento.

Por isso foi necessário reescrever o produto para usarmos PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes. Isto é, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho.

Entretanto, durante esses seis meses, o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso, conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado na reescrita. Se essa opção não existisse, teríamos de encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza de que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrevê-lo, o time deixa de fazer coisas novas para o seu usuário, como mostrei no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio, o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso gostaria de tecer algumas considerações sobre o tema:

• Tecnologias novas e melhores vão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (model, view, controller) separando o código do software em camadas de acordo com sua função. Mais recentemente, foi criado o conceito de microsserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs e facilitando a manutenção. Se a cada nova tecnologia que aparecer formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
• Reescrever software tem de ter uma motivação clara de negócio, ou seja, de alguma forma deve atender aos objetivos estratégicos da empresa que é dona do software como deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
• Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, isto é, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
  • Como será essa reescrita?
  • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
  • Como será a coexistência do sistema novo com o sistema velho?
  • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
  • Quando novos clientes poderão ser instalados no sistema novo?
  • Quando os clientes existentes serão migrados para o sistema novo?
  • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
  • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicada?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Ah, e tem mais um ponto!

Alguns engenheiros de produto acabam se tornando ótimos gestores. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa para fazer”, e dar a ele essa opção de carreira.

Na Locaweb, temos (e tivemos) ótimos gestores de produto que eram engenheiros de produto. Em alguns casos, acabaram se tornando gestores do próprio produto em que era engenheiro. Por outro lado, existem alguns engenheiros de produto que experimentaram a gestão de produtos e não gostaram.

Para quem está acostumado a medir sua produtividade por funcionalidades entregues, pode ser estranho no começo perder essa referência de produtividade. Como já vimos, o dia a dia de um gestor de produto é composto de muita conversa com as várias pessoas envolvidas nele, e esse monte de conversa pode “assustar” o engenheiro que está acostumado a trabalhar focado no desenvolvimento de funcionalidade. Por isso, é preciso deixar a porta aberta para ele poder voltar a ser engenheiro de produto, sem nenhum prejuízo para a sua carreira.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis

In the chapter about team structure from my book Digital Product Leadership, I gave some real-life examples of team size from Gympass, Conta Azul, and Locaweb. However, one thing that is not in that chapter is how we defined the ideal team size. So here’s an article focused on this topic, which I believe can be helpful not only in regular times but also now that VCs funding seems to be slowing down at lower valuations.

Benchmark

When I joined Gympass in 2018 the company already had 800 people but the product development team, i.e., product managers, designers, engineers, and data people, were only 32 people, i.e., 4% of the company which seems quite low. Soon after I joined the company I had to present to the board my plan to increase this team and I decided to include a slide with a benchmark of some well-known tech companies.

I used Linkedin to get some estimates of the product development team size of these companies compared to the total number of employees. The majority is having between 24% to 40% of their workforce in the product development team. The exception is Apple, with 20%, but we need to consider that they own all of their stores, so all the sellers in the stores are their employees as well. Conta Azul, Locaweb, and Lopes are from my past experiences. Lopes, a traditional real estate company working on its digital transformation had around 11% of its workforce in product development. At Gympass we were able to bring from 4% in mid-2018 to 18% by the end of 2019.

What to do vs how much to invest

However, we can not define ideal team size only by benchmarking. We need to consider other inputs, from within the company:

• what to do: from the company objective and the understanding of the user problems, we create our product vision and strategy. Having this clear helps us define what we need to do to execute this strategy, what are the expected results and objectives, and the team we need to execute this strategy. For instance, at Gympass, we deliver products for gyms, clients’ HRs, and employees, so we decided to have teams dedicated to each of the players in our marketplace. Besides that, we needed tools to manage payments from HRs and employees, and to the gyms so we also had a team focused on that. Those were product teams, that generated results for Gympass such as more users and less manual operational work. Besides the product teams, we had also structural teams to take care of topics such as SRE, Tools to make product teams more productive, and Data and Security, as I explained in the article about team structure. These product and structural teams had their own visions and strategies aligned with the global vision and strategy and based on that they proposed their own team structures. For instance, at Gympass, the employee-focused team decided to break it down into two teams, one focused on growth, i.e., helping employees get to know that the company offers Gympass, making employees download the app, creating an account, and subscribing to the service. The other team was focused on digital experience, i.e, helping the employee get the most out of Gympass by finding and using suitable gyms, activities, and wellness apps. So, what to do is one of the drivers to define the team structure and the team size.

• how much to invest: onde the other hand, we need to know how much we are planning to invest in this team. Putting together a product development team costs money. Suppose that based on what we defined we want to do we created a product development team structure that requires 15 people. Let’s consider U$ 3,500 as the monthly average salary of the people of this team. So the total monthly cost of this team is U$ 52,500 or U$ 630,000 per year. It’s a lot of money. This team will bring results to the company, but sometimes the results may take longer to be generated. In all new products that we build and launch, while we haven’t launched and started to collect some revenue, this team will only generate costs. Do we have the cash to invest each month to pay the salaries of this team, while this team hasn’t generated the results? Please note that I’m only considering a monthly salary, without an annual bonus and stock options grants.

So we need to know how much we can invest and what we need to do in order to define the ideal size of our product development team.

Team size in a crisis

Some time ago we had the COVID-19 crisis and now we are facing an economic crisis that is making VCs funding slow down and generate lower valuations than we had prior to 2022. Many startups are having to make layoffs because of this situation. Even companies like Google, Meta, and Apple mentioned that they will slow down hiring.

So, what should be the product development team size in a crisis? Well, how much to invest is the input to be considered. Do we need to reduce how much we invest in our product development team? By how much? What is the impact of this reduction on what to do and the results that could be generated by this team? Having fewer people will make the team drop some balls, i.e., a decision needs to be made on what to stop doing. Some objectives and results should be de-prioritized since we will have to lay off some people and will have a smaller team. Is that simple. Less money implies in a smaller team, which implies fewer things this team will be able to do and, consequently, fewer objectives and results can be prioritized.

Summary

• Benchmarking is a good way to understand product development team size. Through Linkedin, we can get good estimates of the number of people in product development teams compared to the number of employees for many companies.
• However, we must also look to internal factors to define the ideal product development team size. How much we have to invest and what we need to do are the two internal factors to be considered.
• In crisis situations, we may need to decrease the investment in the product development team, which may cause the team size to shrink. Less money implies a smaller team, which implies fewer things this team will be able to do and, consequently, fewer objectives and results can be prioritized.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

This is a somewhat controversial question.

I’ve been seeing some interesting debates on this topic on Linkedin and WhatsApp groups in the Brazilian product management community so I want to share my experience on this topic. I have already shared it as part of the chapter “Feedback and performance evaluation” from my book Digital Product Leadership, but maybe it can be helpful as a standalone article to add another perspective on the topic.

Let me start with a disclaimer. The fact that 2 people disagree doesn’t necessarily mean that one them is wrong.

Having said that, the short answer to this question is it depends! (=

The need to understand the product domain

The need for a product manager to code depends on the product domain, i.e., the product topic. If what the product manager takes care of is a more technical product it is very important that the product manager has a technical background. Some product examples from Locaweb that are technical and needed a product manager with technical background are Website Hosting, Cloud Server and SMTP. However, even companies that do not sell technical products can have a part of their product with a more technical bias. At Conta Azul, we had APIs, integrations with fintechs (Iugu and Stone), and integration with the government finance systems in order to issue invoices, and at Gympass we had integration with gym management systems and HR systems. For these parts of the products, it is important to have a product manager with technical knowledge, since the main user of the product will be a technical person and the product objective is a technical objective.

On the other hand, a product like Locaweb’s Virtual Store, Gympass’ user app, or Lopes’ property search portal are products made for consumers in general. In my experience, it is not essential that the product manager has technical knowledge if she manages non-technical products. At Conta Azul we also had product for accountants. In this case it was quite important that the product manager understands accounting, to the point that some of our product manager were accountants and the ones that weren’t needed to go through courses to learn about accounting. Some of the product managers in my team that built product for accountants went to Accountants College and even used to work as accountants prior to make the career change to product management.

So this is key, a product manager must, let me repeat this, MUST understand about the domain of the product she will manage. If it is a technical product, a product for coders, it will be very beneficial that the product manager if she knows how to code. If it is a product for accountants, the more she knows about accounting, the better.

The need to understand coding

If the product is not for coders, as I mentioned earlier, it is fine if the product manager does not know how to code. She can be an amazing product manager, achieve amazing results both for her users as well as for the company that owns the product without knowing how to code.

However, it can be helpful. Technical knowledge helps a product manager understand how the product is made, and most probably can help her to be a better product manager. It helps a product manager understand the work done by the engineering team and can be useful in many decisions about the product, including prioritization and scope. Here goes two analogies that can help to better understand the benefit that knowing how to code brings to a product manager:

• A good Formula 1 racer doesn’t need to know how the car works, but if he does, he can certainly use that knowledge to be a better driver.
• Likewise, a guitar player does not need to know how to sing or play bass, drums, or piano to be a good guitarist, but most probably, this additional knowledge can help her be a better guitarist.

The additional knowledge can bring interesting insights to the product manager when she is taking care of her main responsibilities.

This does not mean that the product manager needs to be a coding expert. If she has no knowledge of coding, it would be interesting to take an introductory course in programming logic and experiment with making her first app. This experience will only benefit that person’s career.

What about knowing SQL?

If the product manager doesn’t already know, she must learn SQL. Access to data is increasingly democratic in companies and knowing SQL is essential so that the product manager can enjoy the data independently, without having to ask others to create their charts and dashboards. When we put Metabase as a data democratization solution at Conta Azul, I was so excited that I spent a whole week going to sleep at 2:00 am, because I was creating charts and dashboards to better understand how Conta Azul products were used. It was so fun! (=

Summing up

• The fact that 2 people disagree doesn’t necessarily mean that one them is wrong.
• The product manager MUST understand about the domain of the product she manages. If it is a technical product, a product for coders, it will be very beneficial that the product manager if she knows how to code. If it is a product for accountants, the more she knows about accounting, the better.
• If the product is not for coders, it is fine if the product manager does not know how to code. She can be an amazing product manager, achieve amazing results both for her users as well as for the company that owns the product without knowing how to code.
• However, technical knowledge helps a product manager understand how the product is made, and most probably can help her to be a better product manager. The same way that a Formula 1 race drive doesn’t need to know mechanics, but can benefit from this knowledge during his races.
• If the product manager doesn’t already know, she must learn SQL. Access to data is increasingly democratic in companies and knowing SQL is essential so that the product manager can enjoy the data independently, without having to ask others to create their charts and dashboards.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Esta é um tema um tanto controverso.

Tenho visto alguns debates interessantes sobre este tema nos grupos do Linkedin e WhatsApp na comunidade de gestão de produtos, então quero compartilhar minha experiência sobre este tema. Já compartilhei como parte do capítulo “Feedback e avaliação de desempenho” do meu livro Liderança de Produtos Digitais, mas talvez possa ser útil como um artigo separado possa adicionar mais foco sobre o tema.

Deixe-me começar com um “disclaimer“. O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.

Dito isto, a resposta curta a esta pergunta é depende! (=

A necessidade de entender o tema do produto

A necessidade de uma gestora de produto saber codar depende do tema do produto que ela cuida. Se o que a gestora de produto cuida é um produto mais técnico, é muito importante que ela tenha uma formação técnica. Alguns exemplos de produtos da Locaweb que são técnicos e precisavam de uma gestora de produto com formação técnica são Hospedagem de Sites, Cloud Server e SMTP. No entanto, mesmo empresas que não vendem produtos técnicos podem ter uma parte de seu produto com um viés mais técnico. Na Conta Azul tivemos APIs, integrações com fintechs (Iugu e Stone) e integração com os sistemas do governo para emissão de notas fiscais, e no Gympass tivemos integração com sistemas de gestão de academias e sistemas de RH. Para essas partes dos produtos, é importante ter uma pessoa gestora de produto com conhecimento técnico, pois a principal usuária do produto será uma pessoa técnica e o objetivo do produto é um objetivo técnico.

Por outro lado, um produto como a Loja Virtual da Locaweb, o app do usuário do Gympass ou o portal de busca de imóveis da Lopes são produtos feitos para o consumidor em geral. Na minha experiência, não é essencial que a gestora de produto tenha conhecimento técnico se ela gerencia produtos não técnicos. Na Conta Azul também tínhamos produto para contadores. Nesse caso era muito importante que a pessoa gestora de produto entendesse de contabilidade, a ponto de alguns de nossas gestoras de produto serem contadoras e as que não eram, precisavam passar por cursos para aprender contabilidade. Algumas das pessoas gerentas de produto da minha equipe que construíram produtos para contadores fizeram Faculdade de Contabilidade e até trabalharam como contadores antes de fazer a mudança de carreira para gestão de produtos.

Então isso é fundamental, uma gestora de produto deve, deixe-me repetir isso, DEVE entender sobre o tema do produto que ele irá gerenciar. Se for um produto técnico, um produto para desenvolvedores, será muito benéfico que a gestora de produto saiba codar. Se for um produto para contadores, quanto mais ela souber sobre contabilidade, melhor.

A necessidade de saber codar

Se o produto não for para desenvolvedores, como mencionei anteriormente, tudo bem se a gestora de produto não souber codar. Ela pode ser uma gestora de produto incrível, alcançar resultados incríveis tanto para seus usuários quanto para a empresa dona o produto sem saber escrever uma linha de código sequer.

No entanto, saber codar pode ser útil. O conhecimento técnico ajuda uma pessoa gestora de produto a entender como o produto é feito e, provavelmente, pode ajudá-la a ser uma gestora de produto melhor. Esse conhecimento pode ajudar uma gestora de produto a entender o trabalho feito pela equipe de engenharia e pode ser útil em muitas decisões sobre o produto, incluindo decisões de priorização e escopo. Aqui vão duas analogias que podem ajudar a entender melhor o benefício que saber codar traz para uma gestora de produto:

• Um bom piloto de Fórmula 1 não precisa saber como o carro funciona, mas se o fizer, certamente poderá usar esse conhecimento para ser um piloto melhor.
• Da mesma forma, um guitarrista não precisa saber cantar ou tocar baixo, bateria ou piano para ser um bom guitarrista, mas provavelmente esse conhecimento adicional pode ajudá-lo a ser um melhor guitarrista.

O conhecimento adicional pode trazer insights interessantes para a pessoa gestor de produto quando ela está cuidando de seu produto

Isso não significa que a gestora de produto precisa ser uma especialista em programação. Se ela não tem conhecimento de programação, seria interessante fazer um curso introdutório de lógica de programação e experimentar fazer seu primeiro aplicativo. Essa experiência só beneficiará a carreira dessa pessoa.

E precisa saber SQL?

Se a pessoa gestora de produto ainda não sabe, ela deve aprender SQL. O acesso aos dados está cada vez mais democrático e conhecer SQL é essencial para que a gestora de produto possa usufruir dos dados de forma independente, sem precisar pedir a terceiros para criar seus gráficos e dashboards. Quando colocamos o Metabase como solução de democratização de dados na Conta Azul, fiquei tão empolgado que passei uma semana inteira indo dormir às 2h, pois estava criando gráficos e dashboards para entender melhor como os produtos da Conta Azul eram usados. Foi tão divertido! (=

Resumindo

• O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.
• O gerente de produto DEVE entender sobre o domínio do produto que gerencia. Se for um produto técnico, um produto para codificadores, será muito benéfico que o gerente de produto saiba codificar. Se for um produto para contadores, quanto mais ela souber sobre contabilidade, melhor.
• Se o produto não for para codificadores, tudo bem se o gerente de produto não souber codificar. Ela pode ser uma gerente de produto incrível, alcançar resultados incríveis tanto para seus usuários quanto para a empresa que possui o produto sem saber codificar.
• No entanto, o conhecimento técnico ajuda um gerente de produto a entender como o produto é feito e, provavelmente, pode ajudá-lo a ser um gerente de produto melhor. Da mesma forma que um piloto de Fórmula 1 não precisa conhecer mecânica, mas pode se beneficiar desse conhecimento durante suas corridas.
• Se o gerente de produto ainda não sabe, ele deve aprender SQL. O acesso aos dados está cada vez mais democrático nas empresas e conhecer SQL é essencial para que o gerente de produto possa usufruir dos dados de forma independente, sem precisar pedir a terceiros para criar seus gráficos e dashboards.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.

O seu produto de software pode ter chegado aqui por três caminhos diferentes:

1. O crescimento do seu produto desacelerou, e você fez todas as análises e testes descritos no capítulo anterior para ter certeza de que ele, de fato, chegou à fase da maturidade.
2. Ou,então,vocêlançouoseuprodutoenãoestáconseguindo cruzar o abismo que existe no fim da inovação, a primeira fase do ciclo de vida de seu produto de software.
3. Ou ainda, você optou por uma maturidade programada, planejando o fim de vida da versão atual de seu produto de software em função de uma nova, que foi desenvolvida e lançada.

Independente do caminho seguido – maturidade não programada, não cruzar o abismo ou maturidade programada –, você eventualmente chegou ao que é conhecido como o fim de vida do produto. Em inglês, usa-se um termo mais elegante, o sunset do produto.

Assim como todas as fases anteriores, essa também terá de ser gerenciada. Engana-se o gestor de produtos que acredita que, quando um produto chega ao fim de vida, termina-se o trabalho de gestão de produtos. Ao contrário, essa fase requer tanta atenção quanto as anteriores.

O primeiro passo é reconhecer que chegou ao fim de vida, e um ótimo indicador é avaliar se o custo de manter o produto é maior que o retorno que ele dá. Se isso acontecer, existe um forte indicativo de que ele está entrando nessa fase.

A decisão pelo fim de vida de um produto não é científica. Os números ajudam bastante nessa decisão; porém, como explicado no capítulo Considerações sobre métricas, além das métricas, é preciso usar outras informações como a experiência, a intuição, o julgamento e as informações qualitativas para se tomar a decisão de fim de vida do produto.

Cada um dos três possíveis caminhos que seu produto pode ter feito para chegar ao fim de vida vai trazer consigo fatos e considerações específicas para essa tomada de decisão. Normalmente, ela feita em comitê, com as pessoas que trabalham com o produto e os executivos da empresa.

Caso seu produto tenha de fato entrado no fim de vida, o gestor de produtos precisará gerenciar essa fase. A decisão e seu gerenciamento dependem do caminho seguido por ele para chegar a ela, e é isso que vamos ver nas próximas seções.

Fim de Vida por Maturidade não Programada

Esse é o pior dos casos pois, além de não planejado – como é o caso do fim de vida após a maturidade programada –, é uma situação difícil de identificar. Antes de decretar que é o fim de vida do produto, é preciso ter certeza de que isso não é só temporário. O mais comum nesses casos é deixar o produto dormente por um tempo.

O que significa dormente? Significa não investir em seu desenvolvimento e marketing, e observar como ele se comporta. Ele parou de crescer? Ou ele cresce muito devagar? Faz sentido parar de vendê-lo? Ou pode-se deixar o produto sendo comercializado por mais algum tempo? Após algum tempo dormente, deve-se reavaliar se vale investir novamente nele.

Esse foi o caso do produto PABX Virtual da Locaweb, que decidimos deixar dormente por uns 3 anos, sem nenhum investimento de marketing e de desenvolvimento, para podermos investir em outros produtos. Mesmo sem nenhum investimento, a quantidade de clientes não diminuiu. Inclusive, em certos momentos, houve até um crescimento. Esse crescimento, quando acontecia, era bem pequeno, mas não deixava de ser um crescimento. Por esse motivo, decidimos voltar a investir no produto.

Outro exemplo, já comentado no capítulo anterior, foi o caso do produto Hospedagem de Sites da Locaweb que, por nos focarmos demais em métricas e desconsiderarmos nosso conhecimento empírico, acabou entrando em uma situação de não crescimento que, felizmente, pôde ser corrigido. Não era o fim da vida útil da hospedagem na web. Foi uma desaceleração do crescimento que causamos ao produto.

Por isso quero dizer novamente para se ter muito cuidado para não tomar uma decisão precipitada, pois o fim de vida por maturidade não programada é extremamente difícil de ser identificada.

Se você realmente tiver certeza de que seu produto chegou mesmo ao fim de vida, você precisará gerenciar essa fase. A primeira decisão que você deverá tomar, junto com o comitê que mencionei – composto por pessoas que trabalham com o produto e executivos da empresa –, é se você vai descontinuar o produto ou deixá-lo dormente. Essa decisão será baseada no retorno que ele estiver dando para a empresa e no custo de mantê-lo.

Se o produto ainda der um retorno considerável, é provável que vocês decidam por mantê-lo e façam esforços para reduzir o custo de manutenção. O gestor de produtos será o responsável por coordenar os esforços de redução de custo de manutenção, e por avaliar se esses custos estão menores do que o retorno que o produto dá.

Por outro lado, se o retorno desse produto for pequeno, ou seus custos operacionais forem muito grandes e não passíveis de redução, é provável que vocês optem por descontinuá-lo. Nesse caso, o gestor deverá coordenar todos os passos necessários para descontinuar o produto, que incluem:

1. Definir a data de fim de vendas e executar;
2. Verificar se há um substituto no portfólio de produtos da empresa ou no mercado;
3. Se houver substituto, definir como um cliente poderá migrar para este substituto;
4. Preparar a comunicação com os clientes, definindo prazos para o fim do produto;
5. Testar essa comunicação com um grupo pequeno de clientes para avaliar impacto e fazer os ajustes necessários;
6. Executar a comunicação com toda a base de clientes;
7. Acompanhar e agir pontualmente, quando necessário.

Fim de Vida por não Cruzar o Abismo

Se seu produto entrar no fim de vida por não cruzar o abismo, apesar de essa não ser uma situação desejada pelo time de desenvolvimento, é uma situação importante que precisa ser identificada rapidamente, e o gestor de produtos tem papel fundamental para detectar isso.

Essa situação é mais fácil de ser detectada, pois o produto não cresce. Ele conquista alguns poucos clientes, os early adopters, e depois para de crescer. Nesse ponto, você deve avaliar junto com o gestor de marketing se a estratégia de comunicação do produto está sendo eficiente e se está atingindo as pessoas que têm o problema que o seu produto se propõe a resolver.

É importante também entender com os possíveis clientes se o produto não só resolve o problema como também como eles estão dispostos a lhe remunerar por esse produto. Sempre é possível fazer ajustes no produto e no seu modelo de comercialização para adequá-lo aos seus clientes.

Contudo, se mesmo após avaliar essas questões e tentar fazer ajustes no produto e/ou no seu modelo de comercialização, você não estiver conseguindo fazê-lo crescer, é hora de decretar seu fim de vida. Quanto antes você chegar a essa decisão, melhor, para não perder tempo e investimento em um produto que não vai vingar.

Nesse caso, como o produto tem uma base pequena de clientes, as opções de mantê-lo dormente por ter uma receita considerável não faz sentido. Sendo assim, a única decisão viável é descontinuar o produto. Como no caso do fim de vida por maturidade não programada, aqui também o gestor de produtos deverá coordenar todos os passos necessários para descontinuá-lo, que são os mesmos descritos anteriormente na seção Fim de vida por maturidade não programada.

Fim de Vida por Maturidade Programada

Essa é a melhor das três opções para o dono do software, mas é a que dará mais trabalho para o gestor do produto. No caso de software instalado, isso acontece quando novas versões são lançadas. Para software online, isso ocorre quando o time de desenvolvimento opta por reescrever o produto por algum motivo, e decide lançar uma nova versão. Essa decisão por reescrever um produto online deve ser muito bem pensada, pois o tempo gasto em reescrever seu produto é tempo não utilizado em sua evolução do ponto de vista de quem o usa.

Pode acontecer que seu produto não tenha sido devidamente planejado do ponto de vista técnico e agora você esteja em um ponto em que: ou reescreve, ou o produto não poderá mais evoluir. Entretanto, cair em uma situação como essa deveria ser exceção, e não parte normal do ciclo de vida de um produto online.

Resumindo: Para software instalado, o fim de vida por maturidade programada é intrínseco ao modelo de negócios, enquanto para software online, o fim de vida por maturidade programada deve ser sempre exceção.

Como esse tipo de fim de vida pode ser programado, o gestor de produtos deve, em conjunto com UX e engenharia de produtos, desenhar como será essa fase, sempre visando ao mínimo de impacto para os clientes. Na Locaweb, no nosso produto de e-mail marketing, chegamos a um ponto em que tivemos de mudar o banco de dados. Usávamos MongoDB que, por problemas de projeto, não estava sendo capaz de aguentar o crescimento do produto; por isso, decidimos por mudar a base de dados para PostgreSQL.

Desenhamos essa reescrita do produto de tal forma para que o cliente não fosse impactado negativamente quando a nova versão com o PostgreSQL fosse implementada. Nada mudou na forma dos clientes usarem o produto. O único impacto percebido por eles foi que o produto estava com performance melhor, o que era esperado por nós.

Este é o ponto mais importante a ser pensado em relação ao fim de vida programado: o que vai acontecer com os clientes que estão na versão atual, que passará a ser a versão “velha”, quando lançarmos a nova? Isso tem de ser pensado com muito cuidado, e o foco tem de ser sempre em um impacto mínimo para o cliente.

É lógico que, quando a nova versão tem interface e interação diferentes da versão antiga, o cliente será impactado. É muito importante fazer testes com alguns deles para medir o impacto antes de forçar a mudança para toda a base de clientes. Em algumas situações, você pode até decidir por manter a versão antiga por algum tempo, dada a dificuldade de trazer os clientes para a versão nova. Mas, não se esqueça, o foco é sempre fazer seu cliente sofrer o mínimo possível.

Concluindo

Vimos em detalhes nos capítulos anteriores todo o ciclo de vida de um produto de software, passando por todas as suas fases: a inovação, o crescimento, a maturidade – que pode ser programada ou não –, e o fim de vida – que pode vir após a maturidade ou quando o produto não cruza o abismo que separa a fase da inovação da fase do crescimento.

Para concluir esse tema sobre ciclo de vida, vamos falar agora sobre a diferença entre startup e gestão de produtos de software; diferença esta, que tem muito a ver com o ciclo de vida de um produto de software.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis

After the innovation phase, assuming your product made it through the abyss, it came to growth. But there will come a time when your product will enter the maturity phase. This is inevitable, we just need to review the S curve of technology adoption in several practical cases:

This chart was created and published by Peter Brimelow in the article “The Silent Boom” in Forbes, July 7, 1997 issue. I did a quick search but couldn’t find an updated version. Most likely Internet, PC, and mobile have already reached 100%. Perhaps what is growing now is Artificial Intelligence and I believe that what is in the initial phase is NFT and metaverse, which seem not to have crossed the abyss yet.

Why does it happen?

There are three reasons for a product to reach the maturity stage of its lifecycle:

• Market exhaustion: This is the case for the TV in the previous figure. The TV market matured some 30 years after television was invented, that is, 100% of the addressable market that could buy a TV already had one. What was the solution that your manufacturers found to get out of maturity? In fact, they didn’t get out of maturity and eventually entered the last phase: the end of life. The solution they found was to create new TV products that could go through the entire lifecycle again. Today, television technology lifecycles are much faster, and the next technology starts its growth phase even before the previous technology leaves the same phase. Currently, TV manufacturers no longer wait for market exhaustion to create a new TV. They already use innovation as a way to force the current product to maturity and enjoy the growth phase of the new product.

• Disruptive innovation: It is an innovation that helps create a new market and a new perception of value, and that eventually completely changes an existing market and its perception of value (over a few years or decades), rendering old technology obsolete ( https://en.wikipedia.org/wiki/Disruptive_innovation). This is the basis of the book The Innovator’s Dilemma, mandatory for all people who work with technology, by Prof. Clayton Christensen, Harvard professor and innovation consultant. Disruptive innovation is what happened to film cameras, with the arrival of the digital camera; or with cell phones that only made voice calls, with the arrival of smartphones; with traditional encyclopedias, with the creation of Wikipedia; and with CDs and DVDs with the launch of audio and video download and streaming services. Sometimes, disruptive innovation can be created by the same industry, as a strategy to defend against the maturing market. This is the case of the TV industry, which is launching SmartTVs, and the cell phone industry, with the launch of smartphones.

• Programmed maturity: There is also a situation where the product owner, instead of waiting for maturity to happen, actively manages it. This is the case of TV manufacturers who barely launched plasma TVs, soon launched LCD TVs and then LED TVs, not allowing time for the market to saturate and anticipating maturity with the new version. This also happens in software product, mainly in installed software like Windows, MySQL, Nginx, Asterisk and several others. Anticipating the obsolescence of your product, your manager is already planning the release of new versions and the end-of-life process of previous versions. This process is usually very slow and, in many cases, traumatic. This is the recent case of Windows Server 2003, released in April 2003. It entered a state of programmed maturity as soon as the next version of Windows Server, Windows Server 2008, was released in 2008. As of 2008, it has lived in the of maturity; in 2010, it stopped being sold; July 14, 2015 was the date set by Microsoft to no longer support the product, that is, it decreed the product’s end of life. For online software products, scheduled maturity doesn’t make much sense, as the product is updated frequently and the user usually doesn’t suffer from updates. Of course there are exceptions, even for online products. There are cases where the product development team chooses to rewrite the product, for some reason, and decides to release a new version. In this case, it is important to understand that you will be putting the current product in a state of scheduled maturity and you must manage it as such. That is, you must plan the entire maturity and end-of-life cycle of that version, including thinking about what to do with existing customers of the version that will enter scheduled maturity and how to migrate them to the newest version of your product. This is something that should be discussed as one of the factors that can influence the product development team’s decision whether or not to go and develop a new version of their software product.

When does it happen?

It’s not too hard to tell when you’re coming to the maturity phase. If it is a programmed maturity, you will define when it will happen. If it is not programmed, just look at the growth of your product and notice that it is growing more slowly. Another point that happens is that growth; when there is, it will always be organic, that is, there is no point in investing in advertising and marketing as you will not have new sales no matter how much you invest.

It’s a little unsettling to enter the product maturity phase, especially if it’s not a scheduled maturity. At that time, nostalgic phrases like “in the good times…” begin, but the important thing is not to get discouraged. First of all, you need to make sure that your product has really reached maturity, or if there is some other reason for the slowdown in growth. To make sure your product has reached maturity, you should ask yourself a few questions:

• Are we still focusing on the problem? As we saw in the Innovation: Focus on the Problem chapter, every product exists to solve a problem, and it is essential that the product manager never lose sight of this. When a product enters the growth phase, the focus often shifts from the problem to be solved to how to accelerate that growth. When this happens, the main tool that can help accelerate growth, which is the focus on the problem, is lost. When the product manager and product development team lose this focus, the chances of product growth starting to slow are very high, giving the impression that it has reached maturity. For years, we have had strong growth in Locaweb’s Website Hosting product. As I told you in the previous chapter, in 2012 we brought in a consultancy specializing in pricing, which after a lot of research and analysis, suggested changes to our hosting plans to optimize and increase our revenue and profit. The changes were in the limits of the plans and in the services included. Their suggestion was to reduce the number of sites per plan (there were already rare cases of customers who hosted more than one site per plan) and, to compensate, to offer included services such as WebChat, for chat service. As I said before, these changes ended up having no effect on revenue and profit at all, and we ended up wasting a lot of time and money on analysis to make these innocuous changes. But that wasn’t the worst. With the changes made, our Web Hosting product has gone further from addressing our customers’ problem. They came to feel that the product had less of the core feature and that we put in the additional services that made the product more expensive. Our customers ended up finding better solutions on the market. This affected our product, which slowed down considerably in 2013. As a result, we decided, more empirically, to do what we call a repackaging of the Website Hosting product, changing the limits based not only on data but also on our knowledge of customers. and your problems, and on all of our 15 years of experience with the product. With the change we made, which cost us much less time and money in its planning phase, it grew back at its old pace. Therefore, it is important for the product manager and his development team to never lose focus on the problem he solves, and to ensure that he is solving it in the best possible way. This example illustrates well what I said in the previous chapter when I said that in addition to metrics, you need to use other information, such as experience, intuition, judgment, and qualitative information, to make product-related decisions. The consultancy made us look exclusively at metrics, making us disregard all our empirical knowledge of the product.

• Is the market slowing down? This is a second very important point to be analyzed when one observes a slowdown in growth. How are your competitors doing, are they also slowing down? And is the market as a whole slowing down? Are there any economic issues in your country or state that may be impacting your market? All of these issues should be evaluated when you start to notice a slowdown in your product’s growth.

As can be seen in the domain registration curve, from mid-2013 onwards, there seems to be a slowdown in the number of .br domains registered per year. At that moment it was a little early to be sure that there was a slowdown happening, but this information already gave indications. This overshadowed us a bit when we analyzed the slowdown of Locaweb’s Web Hosting product. So even if you evaluate the market and come to the conclusion that it is slowing down, you and the product development team can never lose focus on the problem it solves and on ensuring that it is solving it in the best way possible. Even with the market slowing down, it is possible to have growth if your product is an excellent solution to the problem of a group of people.

Between 2016 and 2017 the deceleration seems to have become very clear, doesn’t it? What in mid-2013 seemed just a possibility is clearly confirmed. However, care must be taken not to confuse circumstantial deceleration with deceleration due to maturity. As you can see in the real-life S-curve image, some technologies such as the telephone, the automobile, and electricity have had circumstantial slowdowns before reaching maturity. Economic crisis scenarios can impose a circumstantial slowdown or a circumstantial acceleration. See below what happened during the pandemic crisis, when several businesses had to digitize:

• Is there a disruptive substitute? This is the third point to consider when a product begins to show signs of slowing growth. Is there a different product category on the market that replaces yours? In the case that I mentioned about the slowdown in the growth of Locaweb’s Web Hosting, there was also a product category with strong potential to replace ours; were the website builders like Weebly, Wix, and SitePX. Since the first website building services, we have always been aware of this potential, which is why we launched our website building product to compete directly with Website Hosting as a solution to the problem of people who wanted to have one. There is also another problem that Web Hosting solves, which is the need to host and run web applications with a database. To solve this, there are application hosting solutions on the market today, such as Heroku and Google App Engine. With that in mind, we also launched our application hosting solution, called Jelastic Cloud. It is worth noting that disruption does not only exist in the technology used by the product. Business model is also a form of disruption. Locaweb launched its first Cloud version in 2008. We chose to maintain the same business model as Web Hosting, including disk space and transfer in the price and charging a monthly fee for the package. In 2009, AWS (Amazon Web Services) started to become well known for its Cloud Computing services, which were very similar to the technology that Locaweb offered. The big innovation came in the business model. Amazon chose to charge the services by the hour and to charge for disk space and transfer separately. Despite being a more complex way of charging, it had the attraction of charging only for what was used. When we launched Locaweb’s Jelastic Cloud, we also opted for this business model.

In short, before accepting that your product has really reached the maturity stage, it is very important to be sure of this. In the example I gave of Locaweb, it is clear that there was still room for growth if we focused on the customer’s problem.

Assuming that it is not a programmed maturity, that you have carried out the analysis shown, and that, even turning the focus of the product manager and the development team to the problem that your product solves, you have not managed to resume growth: this is the time to accept the situation and begin to reduce the investment in development and marketing of your product.

You may also decide to move your development and marketing efforts to another product in your portfolio. We’ll see more about product portfolio management and how to allocate investments to different products in that portfolio in Part IV – Product Portfolio Management of this book.

Another important point is the need to reduce operating costs. You can’t have a mature software product that costs a lot to operate. The operating cost typically comes in the form of human labor, i.e. cost to fix problems and customer service costs. Ideally, from the growth stage, your product has a very low operating cost, with low rates of problems and service costs.

To make such a product, the product development team must ensure the quality of the product being put into operation, both from the point of view of technical quality and concern of the engineering team and from the point of view of ease of use and concern. from the UX team.

Once you make these divestments in development and marketing, probably by allocating them to another product in your portfolio and lowering operating costs, your product can still have a long life in maturity. It all depends on whether the software product still gives back to its owner while continuing to solve the problem for existing customers.

This situation can be sustained for months or years. Even if there is no more investment in development, it is necessary to maintain a minimum investment in maintenance, which should make sense within the analysis of the return of your product. This minimum investment in maintenance must be coordinated by the product manager. He should assess his situation and decide to invest effort only when bug fixes and updates are needed.

It is worth remembering that by maintaining the product in this way, you will be periodically shifting the focus of the development team, which is now focused on another product. Therefore, such maintenance should be kept to a minimum. The need for maintenance is likely to increase over time due to the aging of the code that makes up the software, and over time this can make the cost of maintaining that product greater than the return.

Next phase

If you eventually get to the point where the cost of maintaining the product no longer outweighs the return it gives, it’s most likely time to prepare for your next phase: the end of life, the subject of our next chapter.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Depois da fase da inovação, supondo que seu produto conseguiu passar pelo abismo, ele chegou ao crescimento. Só que vai chegar uma hora em que seu produto entrará na fase da maturidade. Isso é inevitável, basta revermos a curva S de adoção de tecnologia em vários casos práticos:

Este gráfico foi criado e publicado por Peter Brimelow no artigo “The Silent Boom” na Forbes, edição de 7 de julho de 1997. Fiz uma pesquisa rápida, mas não consegui encontrar uma versão atualizada. Muito provavelmente Internet, PC e mobile já atingiram 100%. Talvez o que esteja crescendo agora seja Inteligência Artificial e acredito que na fase mais inicial poderíamos colocar NFT e metaverso, que parecem ainda não terem cruzado o abismo.

Por que isso acontece?

Existem três razões para um produto chegar à fase de maturidade de seu ciclo de vida:

• Exaustão do mercado: Esse é o caso da TV na figura anterior. O mercado de TV amadureceu uns 30 anos depois que a televisão foi inventada, ou seja, 100% do mercado endereçável, que podia comprar uma TV, já tinha uma. Qual foi a solução que os seus fabricantes encontraram para sair da maturidade? Na verdade, eles não saíram da maturidade e, eventualmente, entraram na última fase: o fim de vida. A solução que eles encontraram foi criar novos produtos de TV que pudessem passar por todo o ciclo de vida novamente. Hoje, os ciclos de vida de tecnologia da televisão são bem mais rápidos, e a tecnologia seguinte já começa sua fase de crescimento antes mesmo de a tecnologia anterior sair dessa mesma fase. Atualmente, os fabricantes de TV já não esperam mais a exaustão do mercado para criar uma nova TV. Eles já usam a inovação como forma de forçar o produto atual a ir para a maturidade e poder gozar da fase de crescimento do novo produto.

• Inovação disruptiva: É uma inovação que ajuda a criar um novo mercado e uma nova percepção de valor, e que eventualmente muda por completo um mercado existente e sua percepção de valor (ao longo de alguns anos ou décadas), tornando obsoleta a tecnologia antiga (https://en.wikipedia.org/wiki/Disruptive_innovation). Essa é a base do livro The Innovator’s Dilemma, obrigatório para todas as pessoas que trabalham com tecnologia, do Prof. Clayton Christensen, professor de Harvard e consultor sobre inovação. Inovação disruptiva é o que aconteceu com as câmeras com filme, com a chegada da câmera digital; ou com os telefones celulares que só faziam ligação de voz, com a chegada dos smartphones; com as enciclopédias tradicionais, com a criação da Wikipedia; e com os CDs e DVDs com o lançamento de serviços de download e streaming de áudio e vídeo. Às vezes, a inovação disruptiva pode ser criada pela mesma indústria, como uma estratégia para se defender do amadurecimento do mercado. É o caso da indústria de TVs que estão lançando as SmartTVs, e da indústria de telefone celulares, com o lançamento dos smartphones.

• Maturidade programada: Existe ainda uma situação em que o dono do produto, em vez de esperar a maturidade acontecer, gerencia-a de forma ativa. É o caso das fabricantes de TVs que mal lançaram as TVs de plasma, logo lançaram as de LCD e, em seguida, as de LED, não dando tempo de o mercado saturar e antecipando a maturidade com a nova versão. Isso também acontece em produto de software, principalmente em software instalado, como Windows, MySQL, Nginx, Asterisk e vários outros. Antevendo a obsolescência de seu produto, seu gestor já planeja o lançamento das novas versões e o processo de fim de vida das versões anteriores. Esse processo costuma ser bem lento e, em vários casos, traumático. É o caso recente do Windows Server 2003, lançado em abril de 2003. Ele entrou em estado de maturidade programada assim que a versão seguinte do Windows Server, o Windows Server 2008, foi lançado em 2008. A partir de 2008, ele viveu na fase de maturidade; em 2010, ele deixou de ser vendido; 14 de julho de 2015 foi a data definida pela Microsoft para não dar mais nenhum suporte ao produto, ou seja, decretou o fim de vida do produto. Para produtos de software online, a maturidade programada não faz tanto sentido, pois o produto é atualizado frequentemente e o usuário normalmente não sofre com as atualizações. Claro que existem exceções, mesmo para produtos online. Existem casos em que o time de desenvolvimento de produto opta por reescrever o produto, por algum determinado motivo, e decide por lançar uma nova versão. Nesse caso, é importante entender que você estará colocando o produto atual em estado de maturidade programada e deverá gerenciá-lo como tal. Isto é, deverá planejar todo o ciclo de maturidade e de fim de vida dessa versão, incluindo pensar o que fazer com os clientes existentes da versão que entrará em maturidade programada e em como migrá-los para a versão mais nova de seu produto. Isso é algo que deve ser discutido como um dos fatores que podem influenciar na decisão do time de desenvolvimento de produto sobre partir ou não para desenvolver uma nova versão de seu produto de software.

Quando acontece?

Não é muito difícil perceber quando se está chegando à maturidade. Caso se trate de uma maturidade programada, você mesmo vai definir quando ela vai acontecer. Se não for programada, basta olhar o crescimento de seu produto e notar que ele está crescendo mais devagar. Outro ponto que acontece é que o crescimento; quando houver, será sempre orgânico, ou seja, não adianta investir em divulgação e marketing que você não terá novas vendas.

É um pouco perturbador entrar na fase de maturidade do produto, principalmente se não for uma maturidade programada. Nessa hora, começam frases nostálgicas do tipo “nos bons tempos…”, mas o importante é não desanimar. Antes de mais nada, você precisa ter certeza de que seu produto realmente chegou à maturidade, ou se há algum outro motivo para a desaceleração do crescimento. Para ter certeza de que seu produto chegou à maturidade, você deve se fazer algumas perguntas:

• Ainda estamos com foco no problema? Como vimos no capítulo Inovação: foco no problema, todo produto existe para resolver um problema, e é fundamental que o gestor do produto nunca perca isso de vista. Quando um produto entra na fase de crescimento, é comum o foco mudar do problema a ser resolvido para como acelerar esse crescimento. Quando isso acontece, perde-se a principal ferramenta que pode ajudar a acelerar o crescimento, que é o foco no problema. Quando o gestor de produtos e o time de desenvolvimento de produtos perdem esse foco, as chances de o crescimento do produto começar a desacelerar são bem grandes, dando a impressão de que se chegou à maturidade. Durante anos, tivemos um forte crescimento no produto de Hospedagem de Sites da Locaweb. Como contei no capítulo anterior, em 2012 trouxemos uma consultoria especializada em precificação, que após muita pesquisa e análise, nos sugeriu mudanças em nossos planos de hospedagem para otimizar e aumentar nossa receita e nosso lucro. As mudanças foram nos limites dos planos e nos serviços inclusos. A sugestão deles foi diminuir o número de sites por plano (já eram raros os casos de clientes que hospedavam mais de um site por plano) e, para compensar, dar serviços inclusos como o WebChat, para atendimento via chat. Como eu já disse, essas mudanças acabaram não afetando em nada a receita e o lucro, e acabamos perdendo um monte de tempo e dinheiro em análises para fazer essas mudanças inócuas. Mas isso não foi o pior. Com as mudanças feitas, nosso produto de Hospedagem de Sites ficou mais longe de atender ao problema de nossos clientes. Eles passaram a considerar que o produto tinha menos da funcionalidade principal, e que nós colocamos os serviços adicionais que encareciam o produto. Nossos clientes acabaram encontrando soluções melhores no mercado. Isso afetou nosso produto, que desacelerou consideravelmente em 2013. Em função disso, decidimos, de forma mais empírica, fazer o que chamamos de reempacotamento do produto de Hospedagem de Sites, mudando os limites baseados não só em dados como também em nosso conhecimento dos clientes e de seus problemas, e em todos os nossos 15 anos de experiência com o produto. Com a mudança que fizemos, que nos custou muito menos tempo e dinheiro na sua fase de planejamento, ele voltou a crescer como no ritmo antigo. Por isso, é importante o gestor de produtos e o seu time de desenvolvimento nunca perder o foco no problema que ele resolve, e garantir que ele está resolvendo-o da melhor forma possível. Esse exemplo ilustra bem o que comentei no capítulo anterior, quando falei que, além das métricas, é preciso usar outras informações, como a experiência, a intuição, o julgamento e as informações qualitativas, para tomar decisões relacionadas ao produto. A consultoria nos fez olhar exclusivamente para métricas, fazendo-nos desconsiderar todo o nosso conhecimento empírico com o produto.

• O mercado está desacelerando? Esse é um segundo ponto bem importante a ser analisado quando se observa uma desaceleração do crescimento. Como estão seus concorrentes, eles também estão desacelerando? E o mercado como um todo, está desacelerando? Existe alguma questão da economia do país ou de seu estado que podem estar impactando o seu mercado? Todas essas questões devem ser avaliadas quando você começa a perceber uma desaceleração do crescimento do seu produto.

Como dá para ver na curva de registro de domínios, a partir de meados 2013, parece haver uma desaceleração na quantidade de domínios .br registrados por ano. Naquele momento era um pouco cedo para ter certeza de que havia uma desaceleração acontecendo, mas essa informação já dava indícios. Isso nos ofuscou um pouco quando analisamos a desaceleração do produto de Hospedagem de Sites da Locaweb. Por isso, mesmo avaliando o mercado e chegando à conclusão de que ele está desacelerando, você e o time de desenvolvimento do produto nunca podem perder o foco no problema que ele resolve e em garantir que ele está resolvendo-o da melhor forma possível. Mesmo com mercado desacelerando, é possível ter crescimento se seu produto for uma excelente solução para o problema de um conjunto de pessoas.

Entre 2016 e 2017 a desaceleração parece ter ficado bem clara, não é verdade? Aquilo que em meados de 2013 parecia apenas uma possibilidade está claramente confirmado. Contudo, é preciso tomar cuidado para não confundir desaceleração circunstancial com desaceleração devido à maturidade. Como se pode ver na imagem da curva S na vida real, algumas tecnologias como o telefone, o automóvel e a eletricidade tiveram desacelerações circunstanciais antes de chegarem à maturidade. Cenários de crise econômica podem impor uma desaceleração circunstancial, ou uma aceleração circustacial. Veja abaixo o que aconteceu com a crise da pandemia, quando vários negócios tiveram que se digitalizar:

• Existe substituto disruptivo? Esse é o terceiro ponto a ser considerado quando um produto começa a apresentar sinais de desaceleração do crescimento. Existe no mercado alguma categoria de produto diferente que substitui o seu? No caso que contei da desaceleração do crescimento da Hospedagem de Sites da Locaweb, existia também uma categoria de produto com forte potencial para substituir o nosso; eram os de criação de site, como o Weebly, Wix e SitePX. Desde os primeiros serviços de criação de site, sempre estivemos cientes desse potencial e, por isso, lançamos nosso produto de criação de sites para concorrer diretamente com a Hospedagem de Sites, como solução para o problema das pessoas que queriam ter um. Existe também um outro problema que a Hospedagem de Sites resolve, que é a necessidade de hospedar e rodar aplicações web com banco de dados. Para resolver isso, existem hoje no mercado soluções de hospedagem de aplicação, como o Heroku e o Google App Engine. Pensando nisso, também lançamos a nossa solução de hospedagem de aplicações, chamada Jelastic Cloud. Vale notar que disrupção não existe somente na tecnologia usada pelo produto. Modelo de negócio também é uma forma de disrupção. A Locaweb lançou sua primeira versão de Cloud em 2008. Optamos por manter o mesmo modelo de negócio da Hospedagem de Sites, incluindo espaço em disco e transferência no preço, e cobrando um valor mensal pelo pacote. Em 2009, a AWS (Amazon Web Services) começou a ficar bastante conhecida por seus serviços de Cloud Computing, que eram muito similares à tecnologia que a Locaweb oferecia. A grande inovação vinha no modelo de negócio. A Amazon optou por cobrar os serviços por hora, e em fazer a cobrança de espaço em disco e transferência de forma separada. Apesar de ser uma forma mais complexa de se cobrar, tinha o atrativo de cobrar apenas pelo que era usado. Quando lançamos o Jelastic Cloud da Locaweb, optamos também por esse modelo de negócio.

Resumindo, antes de aceitar que seu produto realmente chegou à fase de maturidade, é muito importante ter certeza disso. No exemplo que dei da Locaweb, fica claro ainda havia espaço para crescimento se nos focássemos no problema do cliente.

Supondo que não seja uma maturidade programada, que você tenha feito a análise mostrada e que, mesmo voltando o foco do gestor de produto e do time de desenvolvimento para o problema que seu produto resolve, você não conseguiu retomar o crescimento: esta é hora de aceitar a situação, e começar a diminuir o investimento em desenvolvimento e em marketing do seu produto.

Você pode também decidir mover seus esforços de desenvolvimento e marketing para outro produto de seu portfólio. Veremos mais sobre gestão de portfólio de produtos e como alocar investimentos em diferentes produtos desse portfólio na Parte IV – Gestão de portfólio de produtos deste livro.

Outro ponto importante é a necessidade de diminuir custos de operação. Você não pode ter um produto de software na fase de maturidade que custe muito para operar. Custo de operação vem normalmente na forma de trabalho humano, ou seja, custo para corrigir problemas e custos de atendimento ao cliente. O ideal é que, desde a fase de crescimento, seu produto tenha custo de operação bem pequeno, com baixos índices de problemas e custos de atendimento.

Para fazer um produto assim, o time de desenvolvimento de produto deve zelar pela qualidade do produto que está sendo posto em operação, tanto do ponto de vista de qualidade técnica e preocupação do time de engenharia quanto do ponto de vista de facilidade de uso e preocupação do time de UX.

Uma vez que você faça esses desinvestimentos no desenvolvimento e marketing, provavelmente ao alocá-los para outro produto de seu portfólio, e diminuir os custos de operação, seu produto pode ter ainda uma longa vida na maturidade. Tudo vai depender se o produto de software ainda dá retorno para o seu dono enquanto continua a resolver o problema dos clientes existentes.

Essa situação pode se sustentar por meses ou anos. Mesmo não havendo mais investimento em desenvolvimento, é preciso manter um mínimo de investimento em manutenção, mínimo este, que deve fazer sentido dentro da análise de retorno de seu produto. Esse mínimo de investimento em manutenção deve ser coordenado pelo gestor do produto. Ele deve avaliar sua situação e decidir investir esforço somente quando houver necessidade de correções de bugs e de atualizações.

Vale lembrar de que, ao manter a manutenção do produto dessa forma, você estará periodicamente mudando o foco do time de desenvolvimento, que agora está com foco em outro produto. Por isso, essas manutenções devem ser mantidas ao mínimo. É provável que a necessidade de manutenção aumente com o tempo, devido ao envelhecimento do código que compõe o software e, ao longo do tempo, isso pode fazer com que o custo de manter esse produto seja maior que o retorno.

Próxima fase

Se eventualmente você chegar ao ponto em que os custos de manter o produto não compensam mais o retorno que ele dá, muito provavelmente estará na hora de você se preparar para sua próxima fase: o fim de vida, tema do nosso próximo capítulo.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis

It’s very difficult, if not impossible, to be a complete leader. And that’s ok!!!

Just to be clear, by complete I mean good at everything that a team needs a leader to be good at.

That’s not to say that a leader shouldn’t always strive to be a better leader, but being a better leader doesn’t mean being good at everything. Means understanding weaknesses and having a clear plan to address the weaknesses. This plan can be either some skill development plan or having someone in the team that can address the weakness or, my preferred option, a mix of both.

When I joined Lopes, the biggest real estate company in Brazil that I joined to lead the digital transformation process, one of my first focuses was team structure design. During this process we envisioned a team focused on franchises and brokers. I had a few options as Group Product Manager for this team. I could bring someone from outside of the company, with product management leadership experience. I could bring someone from the product development team, that already know the company and the systems. I could bring someone from the business side.

I decided to go with one of the least obvious options. There was one Lopes leader who was at the company for more than 12 years and had worked in sales operations, was a partner of one of Lopes franchises for a few years, and was now working in franchise management. He was also working on some of the digital initiatives, very hands-on, together with the digital team. He had business experience, leadership experience, Lopes experience, and a lot of interest in digital initiatives, to the point that he worked on these initiatives in addition to his day-to-day job. For this reason, I decided to offer him the opportunity to become the Franchise and Broker Trybe Group Product Manager even though he did not have any formal product management experience. He sort of had some informal experience in the digital initiatives he participated but I could certainly find in the market more experienced product managers leaders. However, this person had the business experience and company experience that would be very beneficial for his role. He then took training on product management and we hired product managers and product designers with experience in product development to join his team. And this was clear to everyone, including the experienced product people joining the team, that they were joining a team where the GPM was very experienced in the business and the company, but not so much on product management, and that we were counting on the more experienced product people to level up the overall team product experience.

Common CTO blindspots

CTO, Chief Technology Officer, and all similar heads of technology and engineering positions are very well-known positions in the tech market. Normally people occupying this position came not only from a technical background but from being a hands-on developer. In tech startups, it is common that the tech founder who wrote the first lines of code of the product becomes the CTO. This person normally knows a lot about technology and writing code but, more often than not, this person has little to no experience in other important areas of leadership that may be needed as the team and the company scale:

• business: connecting the technology to the business, its objectives, and its customers. A tech leader needs to be able not only to understand this connection but also to explain this connection to the product development team and use this connection as the context for every new step that the team will give. I common way to overcome this is to bring a head of product to the organization that could report to the CTO or be a pair to the CTO reporting to the CEO.

• people: leadership is all about people. Understanding people, what motivates each person in your team, what are her weaknesses and strengths, and how you can help her improve even more in her strengths while getting better in her weaknesses.

• process: another common blindspot of CTOs and heads of engineering is process, i.e., the ability to define and track a set of metrics to measure the product development process and then define what needs to be improved. Are we delivering better software? Are we delivering software faster? Are we delivering software aligned with business results? Are we improving in these metrics?

When I joined Gympass there were already 2 very good heads of engineering. We still needed to hire another 2 heads of engineering for our team, so we were actively hiring. When I discussed the candidates’ profiles with the 2 existing heads of engineering, the common feedback I heard was that the candidates were not technical enough. Then I asked them, “but aren’t you quite technical?” They agreed they were quite technical and could provide the needed tech leadership. We then discussed that maybe we should look for other leadership qualities, like people and process leadership to add to our team of leaders. That’s when we started to analyze candidates through this perspective and brought a very good tech people leader and a very good process leader to join our leadership team.

My weak spot

I’ve had the opportunity to lead amazing product development teams. From my own startup back in the 1990s to Locaweb, Conta Azul, Gympass, and, most recently, Lopes digital transformation. Even though I have some technical background and used to write code at the beginning of my career, the more I entered into leadership and product management the more distant I got from the technical details of the products built by the teams I led, and that’s my weak spot. I cannot help much when conversations go too technical. Fortunately, I always had very good technical people in my teams taking care of the technical aspects and I could focus my energy where I’m a bit better, such as helping people evolve, setting and communicating vision and strategy, organizing team structure, and defining processes.

It is very important that a leader and her team know what are her weak spots and her strengths so she can build a team with people that can help her and the entire team in all aspects of product development including the ones that are her weak spots. Weak spots should not be hidden. They must be known by everyone in the team so they can properly deal with them.

Summary

• It’s very difficult, if not impossible, to be a complete leader. And that’s ok!!! Just to be clear, by complete I mean good at everything that a team needs a leader to be good at.
• A leader should always strive to be a better leader, but being a better leader doesn’t mean being good at everything. Means understanding weaknesses and having a clear plan to address the weaknesses. This plan can be either some skill development plan or having someone in the team that can address the weakness or, my preferred option, a mix of both.
• Heads of engineering normally came from a strong technical background and may lack some other important leadership skills such as business, people, and process. It’s important to map these possible blindspots and design plans to address them.
• I’ve had the opportunity to lead amazing product development teams. My own startup, Locaweb, Conta Azul, Gympass, and Lopes. Even though I have some technical background and used to write code at the beginning of my career, the more I entered into leadership and product management the more distant I got from the technical details of the products built by the teams I led, and that’s my weak spot.
• It is very important that a leader and her team know what are her weak spots and her strengths so she can build a team with people that can help her and the entire team in all aspects of product development including the ones that are her weak spots. Weak spots should not be hidden. They must be known by everyone in the team so they can properly deal with them.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

É muito difícil, se não impossível, ser um líder completo. E tudo bem!!!

Só para ficar claro, por completo quero dizer bom em tudo que uma equipe precisa que um líder seja bom.

Isso não quer dizer que um líder não deva sempre se esforçar para ser um líder melhor, mas ser um líder melhor não significa ser bom em tudo. Significa entender seus pontos fracos e ter um plano claro para lidar com esses pontos fracos. Esse plano pode ser algum plano de desenvolvimento de habilidades, pode ser ter alguém na equipe que seja bom nesses pontos fracos ou, minha opção preferida, uma mistura de ambos.

Quando entrei na Lopes, a maior imobiliária do Brasil, onde entrei para liderar o processo de transformação digital, um dos meus primeiros focos foi o desenho da estrutura de equipes. Durante esse processo enxergamos a oportunidade de criar uma equipe focada em franquias e corretores. Eu tinha algumas opções como Group Product Manager para esse time. Eu poderia trazer alguém de fora da empresa, com experiência em liderança de PMs. Poderia trazer alguém da equipe de desenvolvimento de produtos, que já conhecesse a empresa e os sistemas. Eu poderia trazer alguém da área de negócios da empresa.

Eu decidi por uma das opções menos óbvias. Havia um líder na Lopes que estava na empresa há mais de 12 anos e que trabalhou com operações de vendas, foi sócio de uma das franquias da Lopes por alguns anos e agora trabalhava no time que fazia a gestão de franquias. Ele também estava trabalhando em algumas das iniciativas digitais, muito hands-on, junto com a equipe digital. Ele tinha experiência em negócios, experiência em liderança, experiência em Lopes e muito interesse em iniciativas digitais, a ponto de trabalhar nessas iniciativas além do seu trabalho do dia-a-dia. Por esse motivo, decidi oferecer a ele a oportunidade de se tornar o Group Product Manager do time de Franquias e Corretores, mesmo que ele não tivesse nenhuma experiência formal em gestão de produtos. Ele tinha alguma experiência informal nas iniciativas digitais que participou, mas eu certamente poderia encontrar no mercado líderes de gestão de produto mais experientes. No entanto, essa pessoa tinha a experiência de negócios e a experiência da empresa que seriam muito úteis para sua função. Ele então fez treinamento em gestão de produtos e contratamos gestores de produtos e designers de produtos com experiência em desenvolvimento de produtos para se juntarem à sua equipe. E isso ficou claro para todos, inclusive para o pessoal de produto experiente que se juntou ao time, que eles estavam se juntando a um time onde o GPM era muito experiente no negócio e na empresa, mas não tanto em gestão de produto, e que estávamos contando com as pessoas de produto mais experientes para aumentar a experiência geral em desenvolvimento e gestão de produto da equipe.

Pontos cegos comuns do CTO

CTO, diretor de tecnologia e todos os cargos semelhantes de liderança de tecnologia e engenharia são cargos muito conhecidos no mercado de tecnologia. Normalmente, as pessoas que ocupam essa posição não vêm apenas de uma formação técnica, mas também de terem sido desenvolvedores. Em startups de tecnologia, é comum que o fundador de tecnologia que escreveu as primeiras linhas de código do produto se torne o CTO. Essa pessoa normalmente sabe muito sobre tecnologia e código, mas, na maioria das vezes, essa pessoa tem pouca ou nenhuma experiência em outras áreas importantes de liderança que podem ser necessárias à medida que a equipe e a empresa escalam:

• negócio: conectar a tecnologia ao negócio, seus objetivos e seus clientes. Um líder de tecnologia precisa ser capaz não apenas de entender essa conexão, mas também de explicar essa conexão para a equipe de desenvolvimento do produto e usar essa conexão como contexto para cada nova etapa que a equipe entrará. Uma maneira comum de suprir essa necessidade é trazer uma pessoa head de produto que pode se reportar ao CTO ou ser um par do CTO reportando-se ao CEO.

• pessoas: liderança tem tudo a ver com pessoas. Compreender as pessoas, o que motiva cada pessoa em sua equipe, quais são suas fraquezas e pontos fortes, e como você pode ajudá-la a melhorar ainda mais em seus pontos fortes enquanto melhora em suas fraquezas.

• processo: outro ponto cego comum dos CTOs e chefes de engenharia é o processo, ou seja, a capacidade de definir e acompanhar um conjunto de métricas para medir o processo de desenvolvimento do produto e então definir o que precisa ser melhorado. Estamos entregando um software melhor? Estamos entregando software mais rápido? Estamos entregando software alinhado com os resultados do negócio? Estamos melhorando nessas métricas?

Quando entrei no Gympass já havia 2 heads de engenharia muito bons. Ainda precisávamos contratar mais 2 heads de engenharia para nossa equipe, estávamos contratando ativamente. Quando discuti os perfis dos candidatos com os 2 heads de engenharia existentes, o feedback comum que ouvi foi que os candidatos não eram técnicos o suficiente. Então eu perguntei a eles, “mas vocês já não são muito técnicos?” Eles concordaram que eram bastante técnicos e poderiam fornecer a liderança técnica necessária. Discutimos então que talvez devêssemos buscar outras qualidades de liderança, como liderança de pessoas e processos, para agregar à nossa equipe de líderes. Foi quando começamos a analisar os candidatos por essa perspectiva e trouxemos um líder de pessoas de tecnologia muito bom e um líder de processo muito bom para se juntar à nossa equipe de liderança.

Meu ponto fraco

Tive a oportunidade de liderar equipes incríveis de desenvolvimento de produtos. Desde minha própria startup nos anos 1990 à Locaweb, Conta Azul, Gympass e, mais recentemente, a transformação digital da Lopes. Apesar de ter alguma formação técnica e de escrever código no início da minha carreira, quanto mais eu ingressava na liderança e gestão de produtos mais distante ficava dos detalhes técnicos dos produtos construídos pelas equipes que liderei, e esse é o meu ponto fraco. Não posso ajudar muito quando as conversas ficam muito técnicas. Felizmente, sempre tive líderes técnicos muito bons em minhas equipes cuidando dos aspectos técnicos e pude concentrar minha energia onde sou um pouco melhor, como ajudar as pessoas a evoluir, definir e comunicar visão e estratégia, organizar a estrutura de equipe e definição de processos.

É muito importante que uma líder e sua equipe saibam quais são seus pontos fracos e seus pontos fortes para que ela possa construir uma equipe com pessoas que possam ajudá-la e a toda a equipe em todos os aspectos do desenvolvimento de produtos, incluindo aqueles que são seus pontos fracos. Os pontos fracos não devem ser escondidos. Eles devem ser conhecidos por todos na equipe para que possam lidar adequadamente com eles.

Resumindo

• É muito difícil, se não impossível, ser um líder completo. E tudo bem!!! Só para ficar claro, por completo quero dizer bom em tudo que uma equipe precisa que um líder seja bom.
• Um líder deve sempre se esforçar para ser um líder melhor, mas ser um líder melhor não significa ser bom em tudo. Significa entender os pontos fracos e ter um plano claro para lidar com os pontos fracos. Esse plano pode ser algum plano de desenvolvimento de habilidades ou ter alguém na equipe que possa endereçar os pontos fracos ou, minha opção preferida, uma mistura de ambos.
• Os heads de engenharia normalmente vêm de uma sólida formação técnica e podem não ter outras habilidades importantes de liderança, como negócios, pessoas e processos. É importante mapear esses possíveis pontos cegos e desenhar planos para endereçá-los.
• Tive a oportunidade de liderar equipes incríveis de desenvolvimento de produtos. Minha própria startup, Locaweb, Conta Azul, Gympass e Lopes. Apesar de ter alguma formação técnica e de escrever código no início da minha carreira, quanto mais eu ingressava na liderança e gestão de produtos mais distante ficava dos detalhes técnicos dos produtos construídos pelas equipes que liderei, e esse é o meu ponto fraco.
• É muito importante que um líder e sua equipe saibam quais são seus pontos fracos e seus pontos fortes para que ela possa construir uma equipe com pessoas que possam ajudá-la e a toda a equipe em todos os aspectos do desenvolvimento de produtos, incluindo aqueles que são seus pontos fracos. Os pontos fracos não devem ser escondidos. Eles devem ser conhecidos por todos na equipe para que possam lidar adequadamente com eles.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.