About Joca

I've been helping companies succeed in the digital era by guiding them on how to create and manage successful digital products that connect their strategic objectives with the problems and needs of their customers.

Como e quando delegar

Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém, normalmente com menos senioridade do que a pessoa que está executando o ato de delegar. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades. Parece um ato bastante simples mas tem vários aspectos importantes a serem considerados para aumentar as chances de sucesso.

Jurgen Appelo, autor do já mencionado livro Management 3.0: Leading Agile Developers, Developing Agile Leaders, comenta que delegar não é uma decisão binária em que você delega ou não delega. Existem outros níveis de delegação entre esses dois extremos e cada um desses outros níveis deve ser usado dependendo do contexto, ou seja, do problema a ser resolvido e de quem vai trabalhar nele. Segundo ele, são sete níveis:

  • Dizer: você toma decisões e as anuncia ao seu time. Na verdade, isso não é delegação. (=
  • Vender: você toma decisões, mas tenta “vender” sua ideia para sua equipe.
  • Consultar: você convida seu time para comentar e pondera suas contribuições.
  • Concordar: você convida seu time a participar de uma discussão e a chegar a um consenso como um grupo. Sua voz é igual às outras.
  • Aconselhar: você tenta influenciar o seu time dando-lhes conselhos, mas deixa que eles decidam o que fazer com sua opinião.
  • Perguntar: você deixa o time decidir. E depois você pergunta sobre suas motivações, ou pede que eles o mantenham ativamente informado.
  • Delegar: você deixa inteiramente para o time lidar com o assunto, e você nem mesmo precisa saber quais decisões eles tomam.

Confesso que no meu dia a dia não penso sobre que tipo de delegação estou fazendo em cada situação, é algo mais intuitivo do que pensado, mas é bom conhecer e relembrar essas diferentes formas de delegação. Tenho a impressão que entre “dizer” e “delegar” há mais do que 5 opções. Navegamos entre essas opções de forma fluida de acordo com a senioridade do time, a experiência específica do time com o assunto em questão e o quanto o tema em questão implica em riscos.

O conceito de delegação anda de mãos dadas com o conceito de microgestão:

Microgestão

Microgestão é o estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários. A microgestão geralmente possui uma conotação negativa.

Fonte: https://pt.wikipedia.org/wiki/Microger%C3%AAncia

A microgestão mostra a incapacidade de delegação do líder. Normalmente há duas razões para um líder microgerenciar seu time:

  • Insegurança: o líder é inseguro, preocupado em fazer tudo certo, por isso ele quer acompanhar cada detalhe de tudo o que está sendo feito. Em alguns (muitos) casos, esse líder fará o trabalho de uma pessoa de seu time para garantir que esteja sendo feito “do jeito certo”. Esse tipo de líder costuma criar muitas regras e procedimentos para garantir que as coisas estejam sendo feitas do jeito que ele entende como certo.
  • Personalidade: é da personalidade do líder ter prazer em ver as pessoas sofrendo sob pressão. Esse líder tende a ser abusivo no dia a dia com a equipe. Ele não fará o trabalho de ninguém, mas acompanhará de perto todos os detalhes para vê-los desconfortáveis sob esse constante escrutínio.

O mais comum é encontrar líderes com insegurança, normalmente pessoas que estão liderando pela primeira vez, mas que eventualmente acabam entendendo seu papel e exercendo a delegação. Já líderes que microgerenciam devido à sua personalidade são mais raros e dificilmente vão mudar.

Pessoas que estão em um time que está sendo microgerenciado tendem a rapidamente se desengajar. Uma vez que estão fazendo as coisas do jeito do gestor, não se sentem responsáveis pelo resultado obtido, seja o resultado bom ou ruim. Se o resultado for bom, o líder provavelmente vai atribuir o sucesso ao seu jeito de fazer as coisas. Se der errado, a pessoa que fez o trabalho não se sentirá responsável, pois “apenas seguiu ordens”.

Maneiras de fazer

Uma das maiores barreiras para a delegação é a certeza que o líder tem de que seu jeito de fazer as coisas é o correto. Quando ele era um contribuidor individual ele fazia as coisas desse jeito e o resultado vinha. Tanto é que ele foi promovido a gestor por fazer as coisas daquele jeito. Então, o que ele entende que tem que fazer como gestor é garantir que todas as pessoas do seu time façam as coisas do jeito que ele faz. Nesse momento a necessidade de microgestão desse líder aparece.

Um líder deve sempre se focar no resultado esperado. A forma como esse resultado é atingido é menos importante do que obter o resultado. Se uma pessoa de sua equipe faz as coisas de forma diferente do que você costuma fazer, isso não significa que a forma como ela faz está errada (claro, desde que não seja uma forma ilícita e não prejudique as pessoas). É só uma forma diferente de fazer as coisas. Talvez até uma forma mais eficiente. O líder precisa respeitar essa diversidade de maneiras de se fazer as coisas e apenas apresentar a sua forma de fazer quando notar que a pessoa não está conseguindo evoluir sozinha.

Oportunidade de aprendizado

Toda vez que delegamos algo para alguém fazer, caso seja a primeira vez que aquela pessoa está fazendo, será uma oportunidade de aprendizado. Por esse motivo, é muito provável que a pessoa cometa alguns erros e aqui entra um dos trade-offs mais difíceis de um líder. Quanto de erro é aceitável? Isso depende muito de cada situação, cabe ao líder entender se os erros são aceitáveis para permitir o aprendizado, ou se dada a criticidade do trabalho a ser feito, erros devem ser minimizados. Devemos sempre criar um ambiente propício ao aprendizado a partir dos erros, pois esse será o aprendizado mais eficaz. É o que busco fazer com os times que lidero.

Resumindo

  • Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades.
  • Entre não delegar e delegar existem vários níveis de delegação que são usados de acordo com o contexto, ou seja, do problema a ser resolvido e quem estará trabalhando no problema.
  • O conceito de delegação anda de mãos dados com o conceito de microgestão, estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários.
  • Existem diferentes maneiras de se fazer as coisas para se atingir o mesmo resultado. Líderes novos costumam achar que só o seu jeito de fazer é o certo.
  • Erros são oportunidades incríveis de aprendizado. Daí a importância em tolerar erros no trabalho.

Pronto, com este capítulo concluímos a parte sobre meus princípios pessoais de liderança (pessoas: a prioridade nº 1, sempre; liderar é como ser um médico; liderando sob pressão; mentoria é uma via de mão dupla; e como e quando delegar). Nos próximos capítulos, veremos o que é cultura e quais são os valores que acredito serem obrigatórios para criar produtos digitais de sucesso.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Mentoria é uma via de mão dupla

A mentoria é uma das responsabilidades mais importantes de um head de produto: ajudar sua equipe a se desenvolver. Como já disse, entre 10% a 40% do tempo do head de produto deve ser focado em ajudar as pessoas de sua equipe a se desenvolverem. Quem me conhece sabe que gosto de termos claramente definidos, então aqui está a definição de mentoria da Wikipedia:

“A mentoria é um processo de transmissão informal de conhecimento, capital social e apoio psicossocial percebido pelo receptor como relevante para o trabalho, carreira ou desenvolvimento profissional; mentoria envolve comunicação informal, geralmente face a face e durante um período, entre uma pessoa que é percebida como tendo maior conhecimento, sabedoria ou experiência relevante (a mentora) e uma pessoa que é percebida como tendo menos (a mentorada)”.

A partir dessa definição, fica clara a natureza unidirecional da mentoria, ou seja, o conhecimento flui da pessoa “mentora” para a “mentorada”.

Recebi e dei orientação durante toda a minha carreira. Mesmo quando era estudante, dava e recebia orientação. Eu acho que alguém recebe orientação desde que nasce. Desde o início da minha carreira, tive a oportunidade de dar orientação às pessoas que lidero e, mais recentemente, tenho sido convidado a orientar empresários e gestores de produto para ajudá-los nas próximas etapas de seus empreendimentos e de suas carreiras. Fico muito feliz em saber que posso ajudar alguém compartilhando minha experiência.

Uma via de mão dupla

No entanto, minha experiência como mentor me mostrou que a definição da Wikipedia está incompleta. Wikipedia define mentoria como transmissão de conhecimento. Meu entendimento é que a mentoria é mais do que uma transmissão de conhecimento. É uma troca de conhecimento. Mesmo considerando que uma das pessoas envolvidas no processo de mentoria é mais experiente em determinado aspecto, tópico ou área, a outra pessoa pode ter experiência e conhecimento em outro aspecto, tópico ou área que pode trazer novos insights. Ou a outra pessoa pode usar sua novidade no tema em que está recebendo mentoria para trazer uma nova perspectiva que o mentor não percebeu.

Portanto, da próxima vez que você estiver em uma situação de mentoria, especialmente se estiver na posição de mentor, pense nisso como uma troca de conhecimento, capital social e apoio psicossocial relevante, útil e valioso tanto para o mentorado quanto para o mentor. Tenho a impressão de que você vai gostar ainda mais de sua próxima sessão de mentoria.

Resumindo

  • Mentoria é um dos papéis mais importantes de um head de produto. É através da mentoria que um head de produtos ajuda seu time a se desenvolver.
  • Mentoria é uma via de mão dupla. A pessoa no papel de mentora deve estar aberta a novos aprendizados vindos de suas sessões de mentoria com sua mentorada.

No próximo capítulo vamos entender um pouco mais sobre cultura, quais valores são essenciais para uma empresa ter produtos de sucesso e o papel do head de produto na criação e manutenção da cultura da empresa.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Conclusion

After this summary, we reach the end of the book. I have tried to document here what I have learned over the course of my career in the hope of helping others to learn more about leading digital product development.

Throughout my 30-year career, I have been experimenting with different ways to help product development teams achieve their goals, that is, to be able to create and evolve successful products. I have helped not only the teams that I dealt with directly, but also teams from other companies for whom I provide advisoring service. All of these experiences provided me with a very fertile field for experimentation and learning.

There are other ways to lead product teams, and some may even have points of disagreement with what I presented here in the book. However, there is no single way to do things and the fact that they are different or even discordant does not mean that any of them is wrong. It just means that they are different and it is up to each of us to find the way that makes the most sense for the leadership challenge we encounter.

The most important thing is that we share our learnings, even if they disagree, so that we can always evolve this discipline so new that it is the development of digital products. It was not even 100 years ago that this science started, we are a newborn compared to mathematics, engineering, medicine, astronomy and so many other sciences that have existed for millennia.

Shall we continue the conversation?

The fact that we are in the early childhood of developing digital products means that there is still a lot to learn and experience. These learnings and experiments need to be shared to help others learn more, experiment, agree and disagree so that we can make the art and science of leading digital products evolve more and more to produce better and more useful products.

I will continue to share my learnings here in this site. I encourage you to also share your experience and learnings about digital product development leadership! I look forward to learning more!

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

Liderando sob pressão

Não existe um ambiente de trabalho sem pressão. Não conheço nenhum local de trabalho em que as pessoas digam que as metas são fáceis, que não há riscos em entregar a meta ou que o projeto será entregue no prazo com 100% de confiança. Se a empresa está crescendo rapidamente, as pessoas precisam sustentar ou melhorar essa taxa de crescimento. Se a empresa está em crise, precisam tirar a empresa da crise.

E isso é bom! Na verdade, esta é a única maneira de fazer as coisas! As pessoas precisam de pressão para fazer as coisas.

O que os líderes precisam saber sobre pressão? Toda gente, incluindo líderes e as pessoas que elas lideram, recebe pressão de fora (o objetivo, a data prevista, a falta de recursos), bem como de dentro (motivação, determinação, força interior).

Pense em pessoas e equipes como balões

Uma boa analogia que eu gosto de usar, especialmente quando a pressão externa aumenta, é que pessoas e equipes são semelhantes a balões. Precisamos equilibrar a pressão exterior com a pressão interior, com alguma tendência a ter um pouco mais de pressão do lado de fora para garantir o melhor desempenho. Se colocarmos muita pressão do lado de fora, sem fornecer às pessoas as ferramentas necessárias para aumentar a pressão interna, o balão explodirá, ou seja, o desempenho diminuirá, as pessoas ficarão incomodadas, às vezes até ficarão doentes (burnout) e provavelmente deixarão a empresa.

Às vezes, podemos ver algum aumento no desempenho logo após um aumento exagerado de pressão externa, mas não devemos nos enganar com esses resultados iniciais. Eles não serão sustentáveis se a pressão interna não for aumentada. Esse aumento no desempenho durará alguns dias e o desempenho diminuirá para níveis ainda menores do que quando aumentamos a pressão externa.

Como podemos melhorar a pressão interna? Ninguém pode impactar diretamente a pressão interna de ninguém. Isso só pode ser feito indiretamente. Aqui estão algumas ferramentas:

  • Precisamos contratar pessoas com a motivação certa, drive e força interior, e devemos criar o ambiente para que elas possam manter tanto a motivação, como o drive e a força interior corretos. Pense em alinhamento de objetivos, visão, valores, cultura e incentivos financeiros e não financeiros.
  • Devemos apoiar o equilíbrio certo entre momentos com pressão e sem pressão. Podemos fazer isso incentivando as pessoas a se afastarem da pressão no local de trabalho e a fazerem outras coisas que gostam, como exercícios, ioga, meditação, música, leitura, passar tempo com seus entes queridos, cozinhar, festejar etc. Por outro lado, devemos evitar trabalhar longas horas, durante a noite, nos finais de semana e feriados. Note que que trabalhar longas horas é uma tática que pode e deve ser usada, mas somente quando necessário. Se isso se torna a norma, e não a exceção, não estamos apoiando o equilíbrio correto entre momentos com pressão e sem pressão.

A analogia do balão funciona tanto para indivíduos quanto para equipes. Muita pressão sobre uma equipe sem a pressão interna apropriada fará o balão explodir. No caso de uma equipe, ela começará a apresentar um mau funcionamento, os membros da equipe começarão a apontar dedos uns para os outros e o desempenho cairá. Para aumentar a pressão interna de uma equipe e ajudá-los a lidar com o aumento da pressão externa, precisamos criar um ambiente que promova a criação de vínculos mais fortes entre os membros da equipe para que eles sejam mais eficazes em responder à pressão externa, sendo mais resilientes e mais adaptativos ao mesmo tempo. Respostas mais eficazes à pressão externa exigem uma combinação de resiliência e adaptação.

Essa analogia também é boa para explicar por que as melhores pessoas decidem deixar uma companhia. Podemos pensar nessa situação como se houvesse mais pressão interna do que pressão externa. Se uma pessoa ou uma equipe tem mais motivação, drive e força interior do que aquilo que o líder lhe pede ou a estratégia da empresa exige dela, ela inflará o balão até ele explodir. Então elas vão deixar a empresa. Lembre da prioridade nº1: pessoas, sempre.

Resumindo

  • Não existe um ambiente de trabalho sem pressão. Pessoas e equipes precisam da pressão externa (a meta, a data prevista, a falta de recursos) e também de dentro (motivação, drive, força interior) para existir e fazer as coisas, como um balão.
  • A pressão interna e a pressão externa precisam ser balanceadas com alguma tendência a ter um pouco mais de pressão do lado de fora para ter melhoria contínua.
  • Sob pressão, uma pessoa e uma equipe explodem ou ficam mais fortes. É papel do líder ajudar a pessoa ou a equipe a perceber isso e trabalhar em conjunto com eles para apoiar o aumento da pressão interna.

No próximo capítulo falarei sobre mentoria.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Summing up

In this chapter, I have transcribed the Summing up sections of all chapters in order to create a quick reference guide on all topics discussed in this book.

Concepts

I started the book by establishing some definitions, reviewing basic concepts like product and product management, and introducing new concepts like product head roles and responsibilities, team structure, career and Y career for product managers.

What is digital product and product management

  • Digital product is any software that has users.
  • Digital products can exist both in digital companies, where the digital product is the product that the company sells, and in traditional companies, which use the digital product to leverage and leverage the company’s main product .
  • Recently, traditional digital-born companies started to appear, that is, companies that sell a non-digital product, but that have the digital product as a critical part of their strategy since the beginning of the company.
  • Platforms are products that deliver more value the more users use the platform, the famous network effect. There are single-sided platforms and multi-sided platforms, which can be exchange, content or techniques.
  • Product management is the function responsible for connecting the company’s strategic objectives with the customers’ problems and needs.

Roles, responsibility and seniority

  • The head of product is responsible for coordinating the definition of the product vision and strategy, for helping product managers in their development and for managing the expectations of all people who have interest in your product.
  • A very important concept to help a product head with its responsibilities is the concept of seniority, which has 3 dimensions, two well known, time and knowledge and a third not so known, but just as important as others, behavioural seniority.

Product management career

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

Product vision

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

Strategy and objectives

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

Team structure

  • Product development teams are organized into minimal teams, also called squads, composed of engineers, product designers and product managers. It is important to keep these teams as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.
  • There are 4 ways to organize product teams: by product or functionality, by type of user, by journey or by objective. It is also possible to use two different types of organization, creating a hybrid organization.
  • There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering and Professional Services.
  • The implementation of the designed team organization can be done either by creating a new structure or by adjusting an existing team. In both situations it is important to know the product vision and strategy well to design and implement a team structure aligned with it.
  • The most suitable ratio between people in engineering and product managers is 7 +/- 2 engineers for each product manager. And a product designer for each product manager.
  • Two important concepts in the design of their team structure are the Conway’s Law, which says that organizations tend to create systems that are a copy of the companies’ communication structure, and the 4 stages of Tuckman of team formation, forming, confronting, standardizing and performing.
  • It is also possible to organize product teams by business units that have other functions besides those included in a product development team, such as marketing, sales and customer service. The motivations for creating business units instead of product teams may be due to the acquisition, or to give more agility to the new business or even because it is a new product line completely different from the original product.
  • What makes a group of people behave as a team are the common goals.

Developing the team and managing expectations

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

Anti-patterns

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

Principles

Here we saw my personal leadership principles:

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

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. Finally, we saw four values ​​that are the core of the entire digital product development team. They make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results:

  • Release early and often.
  • Focus on the problem.
  • Result delivery.
  • Ecosystem mentality.

People: priority #1, always

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

Leading is like being a doctor

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

Leading under pressure

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

Mentorship is a two-way street

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

How and when to delegate

  • Delegating is the act of entrusting someone with a task and / or responsibility. Leadership is an ongoing act of delegating tasks and responsibilities.
  • Between not delegating and delegating there are several levels of delegation that are used according to the context, that is, the problem to be solved and who will be working on the problem.
  • The concept of delegation goes hand in hand with the concept of micromanagement, a management style in which the manager closely observes or controls the work of his subordinates or employees.
  • There are different ways of doing things to achieve the same result. New leaders often think that only their way of doing things is right.
  • Mistakes are incredible learning opportunities. Hence the importance of tolerating mistakes at work.

Culture and values

  • Culture is the way a group of people respond to everyday situations. It is the role of the head of product to assist in the design and promotion of the company’s culture to ensure an environment conducive to the development of successful products.
  • It has five values ​​that I believe are essential to help create a culture that enables the development of successful products. In this chapter I spoke about 3 of those values: don’t waste time looking for the culprits, focus on learning. Don’t compare work situations with war, nobody wants to kill anyone. Profit and revenue are a consequence, it should not be the main focus.

Transparency, the foundation of a high performance team

  • Every leader, to help her team perform better, needs to explain the context and remove impediments.
  • In order to explain the context, it is essential to be transparent, explain the company numbers, explain the motivations behind each decision, include the team in the decisions.
  • Transparency in the management of companies seems modern, but it has existed for some decades. Two interesting examples come from the 1980s. One at an American company called Springfield ReManufacturing Corp (SRC), which created the concept of open book management. The other in a Brazilian company called Semco, by Ricardo Semler, where Clóvis Bojikian, its HR director, implemented participatory management. Both are from the 1980s and are industries, that is, the vanguard of participatory management.
  • With transparency, it is possible to give people the necessary information so that they understand the context and motivation of the work they are doing and are able to make better decisions about that work.

Diversity, the basis of the best products

  • There are two main reasons that motivate the construction of different digital product development teams. The first is that diversity brings new points of view. The second reason is that just as the group of customers using your product is diverse, so should your product development team.
  • People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective.
  • It is in our hands to make the digital product development environment more inclusive. The way for this to happen is to bring up the topic and make it part of the conversations.

Release early and often

  • There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
  • The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
  • If you are not ashamed of your first version, it took too long to launch.
  • Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

Focus on the problem

  • A very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.
  • If you have a list of projects to do, create two more columns in that list, one for problems to be solved in each project and another for whom the problems will be solved. This will help you to focus on the problems to be solved, not the projects, which are the solution.
  • Solution implementation teams are teams working on implementing a solution designed by someone else. Problem solving teams are teams that work to deeply understand the causes of the problem, the context and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.
  • The top-down trap is the perception of the decision-making process being made by the leaders of the company, with no opportunity for the rest of the employees to participate. This perception is exacerbated when a company faces increasing pressure, such as the COVID-19 crisis.
  • People are solution-oriented, and the greater the pressure, the faster people want solutions to be implemented.
  • To help deal with this situation, use empathy to understand the requestor’s view of implementing the solution and ask him why it is necessary to implement the requested solution.
  • Heads of product have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

Result delivery

  • Another fundamental value for any product development team is the focus on delivering results.
  • Care must be taken when defining the result. Delivering functionality is not a result. All functionality is a means that serves an end, the achievement of a business objective.
  • Even 100% digital companies, whose digital product and technology are the company’s core, focus on business objectives.

Ecosystem mindset

  • Ecosystem mindset means making decisions that create value for all actors on a platform.
  • At Gympass, during the COVID-19 crisis, after placing Gympass Wellness for all its customers and their employees, an important part of the ecosystem was still suffering, the gyms. It was the ecosystem mentality that guided Gympass to create the Live Classes product, which allowed gyms to continue operating even though they were behind closed doors.

Tools

Here we saw the tools that I have used in my almost 30 years of leadership in product development leadership and that I have shared with other leaders so that they can use with their teams. The tools I will talk about include vision, strategy, goals, team structure, metrics, relationships and ceremonies.

Vision, strategy, objectives and team structure

  • Vision, strategy, objectives and team structure are, in addition to very important concepts, essential tools for any product head.
  • For vision and strategy, a presentation with a few slides is sufficient. For OKR and team structure, spreadsheets do the trick.
  • More important than the software you use to document Vision, strategy, goals and team structure is what you do with these tools. OKR worksheet I use at least every week. Vision and strategy, whenever I have the opportunity, I talk about these topics. Team structure, whenever we talk about hiring or changes in the team, I use the team structure worksheet.

Measuring and managing productivity

  • There is no silver bullet to increase the productivity of a product development team. However, there are two essential tools to help achieve this goal.
  • The first tool is measurement. There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and consequent measurement.
  • The second tool is to bring the topic of productivity to the center of the discussion. Everyone on the product development team is responsible for the team’s productivity. Therefore, by bringing the topic to the center of the discussion, everyone will be able to collaborate to improve productivity.

Measuring and managing quality

  • Questioning whether or not product development should have a dedicated QA team is not the right question.
  • The problem you are trying to solve is how to improve the quality of your product.
  • A good quality proxy metric is the bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team must have all its members following these metrics and taking action to improve them.
  • Managing bugs is not enough to manage the quality of the digital product. Performance, scalability, operability, monitorability are some examples of non-functional requirements that directly impact the quality of the digital product.
  • Quality is at the forefront to provide a good user experience. In addition, it is essential to increase the speed of your product development team. The less bugs a team has to fix, the more time it has to focus on new things.
  • High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

Metrics

  • The metrics of a product development team can be classified into 3 major categories: internal, user and business.
  • Internal metrics show how the team is in health. User metrics show the relationship of its user with the product. Business metrics are those that show whether the product is, in fact, delivering value to the business.
  • Metrics should be monitored as often as possible, at least weekly. Even if it is a monthly metric, try to follow the weekly, or even daily, partials of this metric, to give greater opportunity to act earlier when there is a course variation.

Relationships

  • Expectation management is anywhere from 50 to 80% of a product head’s time.
  • RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
  • The power-interest matrix, together with RASCI, is a great tool to help you better understand and interact with your stakeholders.
  • But don’t forget, the main tool that a product head needs to understand better and, consequently, have improved and fruitful interactions with its stakeholders is empathy.

Hire the right people

  • The work of hiring people must be done in conjunction with HR. It’s team work.
  • The hiring phases are defining the profile, attracting candidates, interviewing, choosing and making the proposal, onboarding.
  • The life cycle of a person on your team does not end with onboarding. It is important to constantly give and receive feedback from her, to ensure that the relationship works well for both the team and the new person on the team.
  • Finally, the last phase of the person’s life cycle on the team is when the person leaves the team. It is necessary to understand the reasons that led to this decision to understand how these themes can be worked on in the future.

Feedback and performance evaluation

  • Six essential aspects for good feedback are: checking if feedback is necessary, giving it when it happens, being objective, being transparent, empathizing and giving feedback in private.
  • The seven main characteristics of a good product manager are empathy, communication, time management skills, knowledge of new technologies, business skills, keen curiosity and knowledge about the product theme.
  • If the product is not a technical product, it is not necessary to know how to program. However, having some sense of programming can be useful in understanding how your product works. Knowing SQL is also useful, as it will help the product manager to better understand the metrics of their product.
  • Formal performance appraisal processes have been increasingly seen by companies as something that does not bring as many benefits as expected. Several companies are replacing this process with more frequent conversations between leaders and followers about career, performance, potential and values.
  • Semi-annual retrospective is a good way to have a structured conversation with the team member about the results achieved and how they were achieved, and about the challenges to come. This retrospective must be built together with the team member. If there is a formal performance appraisal process in the company where you are working, use the retrospective process to create the performance appraisal.
  • Regarding promotions and salary increases, there are two aspects to consider, when and how. I recommend separating salary increase and promotion conversations from the feedback conversations to maintain full focus on the topic of each of these conversations. I also recommend promoting the person when he has the potential to develop the skills necessary to occupy the next career level, and not expect him to already demonstrate the skills necessary for that next career level, as this will motivate the person more.

Ceremonies

  • These ceremonies with different stakeholders are aimed at planning, alignment and expectation management. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your followers, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day to day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. At least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

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

Liderar é como ser um médico

Em fevereiro de 2011 fui submetido a uma cirurgia de substituição de disco da coluna cervical. O médico fez a cirurgia no dia 25 de fevereiro. No entanto, o processo de cicatrização levou meses. Segundo o médico, poderia demorar um ano até que todos os sintomas que motivaram a cirurgia desaparecessem.

O que me chamou a atenção é que o cirurgião só faz uma intervenção, mas todo o processo de cicatrização é feito pelo corpo. O mesmo acontece quando um médico prescreve um remédio, que também é uma intervenção, mas, novamente, cabe ao corpo todo o processo de cura.

Liderar uma equipe é bastante semelhante. O líder deve fazer algumas intervenções quando necessário, mas cabe à equipe fazer o trabalho para atingir os objetivos.

Liderança ágil

Em uma das minhas leituras sobre liderança, encontrei uma comparação interessante entre liderança e jardinagem feita por Jurgen Appelo, autor do livro Management 3.0: Leading Agile Developers, Developing Agile Leaders:

Costumo comparar gestores a jardineiros. Um jardim não cuidado é normalmente cheio de ervas daninhas, não de beleza. De uma perspectiva biológica, não há diferença. De qualquer forma, o ecossistema no jardim é auto-organizado. É preciso um jardineiro (autorizado pelos proprietários do jardim) para transformar um jardim anarquista em algo que os proprietários vão desfrutar. Da mesma forma, é necessário um gestor (autorizado pelos acionistas) para conduzir as equipes auto-organizadas em uma direção que agregue valor aos acionistas.

Mesmo que eu goste dessa comparação, ela considera que o jardineiro/gestor deve interferir constantemente, o que não acredito ser um comportamento adequado para um gestor. Na minha opinião, a interferência de um gestor deve ser feita apenas quando necessária e, após a interferência, a equipe deve trabalhar por si mesma para resolver as coisas com pouca ou nenhuma intervenção desse gestor. Daí a minha comparação com uma médica que interfere apenas quando necessário, prescrevendo mudança de hábitos, remédios, fisioterapia e/ou cirurgia e que deixa o corpo fazer o trabalho e se responsabilizar pelo processo de cura.

Resumindo

  • Da próxima vez que você estiver em uma equipe, seja como parte dela ou desempenhando o papel de liderar a equipe, pense no papel de liderança semelhante ao do médico e no trabalho em equipe semelhante ao processo de cura realizado pelo corpo. Ajuda a entender as funções e responsabilidades do líder e das pessoas do time.

No próximo capítulo vamos entender como liderar sob pressão.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Ceremonies

In this chapter, I’m going to talk about the ceremonies I usually use with the teams I lead. These ceremonies with different stakeholders aim at planning, aligning and managing expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others, and some of the ceremonies listed here may not be necessary. I will talk about 1:1 meetings (one on one or one to one), leadership meetings, All-Hands meetings, Product Council, Product Update and team structure meetings.

1:1 meetings

1:1 meetings are those that the head of product has with his direct reports, his leader, other members of his team and with people from other areas.

1:1 with direct reports

The 1:1 meetings with the team members are, certainly, one of the most important meetings of the head of product. Ideally they should be every week and one hour long. If the head of product is unable to do these meetings in one week and decides to do it every other week or to shorten its duration, it is a sign that she has too many direct reports. Despite having an hour, this meeting need not necessarily take an hour. In some weeks, they may take less than an hour, in others, more time may be needed.

The theme of this meeting is free. Personal issues, day-to-day issues, concerns, feedbacks, retrospectives. It should not focus solely on the person’s accountability and progress report. During these conversations there will certainly be themes that should be discussed together with other people on your team, so suggest moving the theme to the leadership meeting. Once a month, at the beginning of a new month, it is important to stop by the OKRs to see if there are any impediments you can help with.

This meeting can be held in a room, or in a cafe or restaurant for lunch. Or even by video, in case people are not in the same place. I’ve seen people doing 1:1 walking. It is up to you and the person you are doing the 1:1 with.

I usually write down the themes as I remember a topic to be discussed in a document shared with the team member. I divide this document into new themes and, as we talk, we write down some points about the themes for future reference. After the 1:1, I mark the date when the meeting took place and open another section for new topics.

1:1 with your leader

You report to someone in the organization, so it’s also important to maintain a cadence of at least weekly conversations with that person. This meeting should serve as an alignment between the two of you, to ensure that that person always gives you the context of the company and the product that you lead in that company, and that it helps you to remove the impediments.

As a head of product, it may happen that you report to someone who doesn’t have as much experience with product development management as you do. On the other hand, that person will have experience and knowledge in other areas. It is important that this difference in knowledge and experience is clear to both, so that you can make these conversations as beneficial as possible for both of you.

Regarding where to do it, and how to write it down, the comments I made above about 1:1 with your direct reports are valid here.

1:1 with other people

In addition to the 1:1s with your team members and your leader which, as I said above, should be weekly and one hour long, you may need to do 1:1s with other people on your team and with people from other areas. This is because the rush of everyday life can be so that there is no time for these conversations to happen if they are not scheduled. Assess with each of these people whether there is a weekly, periodic or just occasional need for these conversations. The duration can also be less than an hour.

I usually have the need for 1:1 weekly with HR leaders, to talk about the needs of hiring and managing people from the product development team. I also usually have 1:1 weekly with the leader of the marketing area to talk about generating demand for product and about product marketing, that is, about how to tell the world about the problem that the product solves and how our product solves it. Less frequently than weekly, it may make sense 1:1 with the sales leader, to talk about the product sales process, with the operations leader, to understand the operational impacts of the product, and with the financial leader, to understand the revenues and costs generated by the product and the team.

Leadership team meetings

Leadership team meetings are the meetings that the head of product has with its direct reports. In addition to the direct reports, it is important to have the HR person who is dedicated to helping your team. If you don’t have someone dedicated to HR, bring the most senior HR person who has been closest to the product development team.

This is a team meeting, not the head of product meeting. In other words, topics brought by anyone on the team should be discussed, and not just topics from the head of product. Even when the head of product is not present, it should happen normally. If the topic being discussed requires the presence of someone who is not at the meeting, you must wait to discuss it when that person is at the meeting.

The topics to be discussed can be placed in a Google Docs document, shared with everyone who attends the meeting. Anyone can post topics to be discussed. They can be the most varied, as long as it makes sense to be discussed with the people present. When themes arise proposing to create a new routine or a new project that makes sense to be executed, this is an excellent opportunity for the head of product to delegate to someone on her team, who can create a subgroup to deal with the theme. Examples of such themes are Design System, Hack Day, Career Plan, among others. Some topics that should appear periodically at this meeting to be discussed with all leaders of the product development team:

  • OKRs: definition and monitoring of OKRs. Definition, once a quarter and follow-up at least once a month, ideally every week, to see if there are any impediments that need to be removed.
  • Product Council: I will talk a little later in this chapter about the Product Council, which is a quarterly planning presentation meeting of the product development team for the company’s senior leadership. It is important to plan together with your team what will be discussed at the Product Council.
  • All-Hands and Product Update: for these two meetings, which are monthly, which I will also talk about a little later, it is important to define together with the team on the topics.
  • P&L: profit and loss or revenue and cost. It is important to discuss with the team, at least monthly, how much revenue is being generated with the product and how much the product team costs, including not only people but all other costs (infrastructure, training, consulting, etc.).

Before joining Gympass, I used to have this meeting in person once a week. These meetings were one hour long and, when there were many topics, we increased to 1.5 or 2 hours to be able to talk about all the topics. At Gympass, as part of the team was in other countries, we started to do the meeting remotely, but still once a week. Still at Gympass, when the pandemic started, we decided to change the rate to daily, given the volume of issues that had to be discussed due to the crisis. After some time, we took off the Friday meeting to create a meeting-free day, that is, a day of the week without meetings. When I joined Lopes, as we are remote and have so much to talk about, we chose to hold our meetings daily. When we realize that there is not enough subject for an hour, we will decrease the frequency.

YOUR LEADER’s Leadership meeting

In addition to coordinating your leadership meeting with your team members, you will most likely participate in your leader’s team meeting, which will define the model and pace of those meetings. Take advantage of these meetings to align with your peers and your leader. Bring product development themes that may be relevant to them. If there is space, this is a good meeting to sporadically bring in some of your team members to discuss a topic. With this, you will give visibility to the people of your team, besides allowing them the opportunity to interact with other senior leaders of the company.

All-Hands Meeting

All-Hands meetings are meetings with everyone on the product development team, not just your direct reports. In addition to the people on the product development team, HR people working together with the product development team and other guests such as the CEO / founder, leaders from other areas and whoever makes sense to participate should also participate.

The objective is to celebrate the results, talk about lessons learned, discuss the progress of OKRs, introduce new team members and any other topic that makes sense to talk to the whole team.

The most recommended frequency is monthly and it’s nice to have a happy hour with the whole team after the meeting for relaxation. If the meeting is remote, happy hour will also be remote.

Product Council

The Product Council is a meeting with the leadership of your team and the senior leadership of the company in which your team presents the planning for the next quarter and, at the turn of the year, the planning for next year. The product council’s goal is to have everyone aligned in relation to the objectives to be achieved in the next quarter and in the metrics that will count that these objectives are being achieved.

It should happen quarterly, about a week before the new quarter begins. At this meeting, each leader of the product development team presents their next quarter planning to the company’s senior leadership. Often, the 3-month plan does not include some topics that may be important for the participants of this meeting. For this reason, I have recommended the use of the 12-month rolling roadmap, which allows us to show not only what lies ahead in the next quarter but also in the next 12 months. The objective is not to discuss whether what is in the fourth quarter should come before what is in the third quarter, but whether what is in the fourth quarter should be worked on in the next quarter and, if so, what should be postponed.

Example of a 12-month rolling roadmap

Note that, although we are talking about the roadmap, the first part talks about goals and results. It is essential to maintain the order of priority of the themes. More important than what is going to be done are the goals we want to achieve and which metrics indicate that we are achieving those goals. It is the role of the head of product to remember this priority of discussion of the themes.

One way to change the focus to stay 100% in objectives and results is to not use a roadmap and discuss only OKRs. Both at Gympass and Lopes, I have had the opportunity to participate in very productive Product Councils, focused exclusively on discussing OKRs.

The duration of these meetings depends on the number of topics to be discussed. I have already participated in Product Council meetings that had to be held in two days, given the number of topics and the need for necessary alignment. On the other hand, the shortest Product Council meetings I lead lasted between 1.5 to 2 hours.

The meeting’s agenda starts with the head of product making an introduction with information about the planning context for the next quarter and then each of the leaders of the product development team presents their planning.

An important point is to make a preview of the Product Council without the company’s senior leadership, to give your team members the opportunity to align themselves on their plans if they have not already done so. I once did a Product Council without this prior alignment and, in the middle of presenting a person’s planning, the other commented that he “could not have planned to do that because X and Y are not ready and will only be delivered at the end of the quarter” , which showed the lack of coordination between them.

Another important preparatory work for the Product Council meeting is 1:1 meetings that can be done between a leader of the product development team and someone from the senior leadership, to seek feedback on planning in a more reserved environment and to already take the planning for Product Council considering that feedback. The recommendation is to do as many 1:1s as necessary to obtain a good pre-Product Council alignment.

Product Council with customers

A variation of the Product Council that can be interesting to conduct is the Product Council with customers, that is, you invite some customers to work with them on a prioritization proposal for the next quarter. We did this a few times at Conta Azul, when we called some of our partner accountants to spend the day with us, to give them the opportunity to get to know our operation up close and, in a certain part of the day, we did a prioritization exercise with them, where we listed a series of features, each with a certain development cost, and let them choose within a development cost limit that they could apply.

It is very nice to see customers experiencing the same difficulty that we, product managers, have when making prioritization decisions. This prioritization made by the accountants served as another input for our prioritization work to be prepared for the next quarter and to be presented at the Product Council with the company’s senior leadership.

Product Update

This is also a monthly meeting where the product team presents to the entire company what has been done in the last month and what is planned for the next month, always connecting with the team’s OKRs. This is a very important meeting for managing expectations. At Conta Azul, since we had a company-wide All-Hands meeting every week, we took one of these meetings to be the product update. At Gympass, the All-Hands meetings took place once a month, so we created a separate meeting, called “Global Product Update Call”, which had to be a remote meeting since Gympass had teams in 14 countries at the time.

One way to organize the content is for each leader of the product development team to present their part or, each month, one of the leaders is responsible for preparing and presenting the content for the month. In addition to this content, the product head must make an introduction and there must be demos of the new features delivered. Ideally, these demos should be live. The more demos and fewer slides, the better. In the last product update that I participated at Conta Azul I was super happy because it was 100% demos and no slides. \o/

At the end of the product update it is important to open for questions, and the answers must be given by the leaders of the product development team.

This meeting is very important to report to the company about what the product area is doing. I constantly hear that the tech team is a black box, “nobody knows what they are doing and we don’t understand what they say”. To take this perception out of the black box, the best way is communication and the product update is a very effective communication ceremony.

Team structure meeting

This meeting can take place independently, or be a part of the team’s leadership meeting. The objective is very simple: decide together with the team how the product development team will be organized, how the budget for hiring people will be invested and what the hiring priority will be. Which tribes and squads should we set up? Should we only hire people for engineering, or should we also bring in designers and product managers? We must look at what we have to do, what we can do, and what we need help with. It is a collaborative meeting, which the product head should facilitate.

It is important for HR personnel to attend this meeting. Once at Conta Azul, an HR person who accompanied the operations and sales area asked to participate in this meeting to understand the dynamics and she was impressed with the meeting participants’ ability to converge on the best way to use the budget. It was when she commented to me that “your team is too mature to be able to have this type of discussion. In the leadership of operations and sales, we do not have the maturity to implement this dynamic”, to which I replied that at the beginning we did not have this maturity, but it was achieved with the constant exercise of this dynamic, that is, the team gained maturity as it learned to collaborate more, to understand the needs of other leaders and to perceive itself as a team with a common goal.

Summing up

  • These ceremonies with different stakeholders are aimed at planning, alignment and management of expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your direct reports, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day-to-day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. This meeting should happen at least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

With this chapter, we finish part III on tools. In the next chapter, I will make a large summary of the book to serve as a quick reference, with all the “Summing up” of all chapters.

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

Pessoas: prioridade nº 1, sempre

Toda empresa possui sua própria cultura e, dentro de cada empresa, todo departamento também possui sua própria cultura. Além disso, cada pessoa tem seus princípios e valores que norteiam seus passos pela vida. Neste e nos próximos capítulos vou falar sobre a cultura, os valores e os princípios que acredito serem obrigatórios para criar produtos digitais de sucesso. E também, quais são os 4 principais valores que toda equipe de desenvolvimento de produtos e, consequentemente, toda empresa que tenha times de desenvolvimento de produtos digitais deve ter.

Vou começar esta parte do livro compartilhando meus princípios pessoais de liderança. Serão cinco:

  • Pessoas: a prioridade nº 1, sempre
  • Liderar é como ser um médico
  • Liderando sob pressão
  • Mentoria é uma via de mão dupla
  • Como e quando delegar

Falarei desses princípios ao longo deste e dos próximos capítulos, a começar pelo princípio de que pessoas são a prioridade nº 1, sempre.

Muitas vezes vejo empresas afirmando que a valorização da empresa, a receita, o crescimento, o lucro, o número de clientes, ou a satisfação do cliente é sua prioridade número 1. Todas são boas prioridades e cada uma é apropriada para contextos específicos em que uma empresa pode estar. No entanto, eu argumento que elas devem ser prioridade número 2, 3, 4 e assim por diante, porque nossa prioridade número 1 deve sempre ser as pessoas que fazem parte nossa equipe. Sem as pessoas que trabalham conosco, será muito difícil, se não impossível, atingir qualquer outro objetivo que tenhamos.

Gastamos dinheiro e energia atraindo as melhores pessoas e convencendo-as a se unirem à nossa empresa para construir o que pretendemos construir para atingir a meta que estabelecemos. Pagamos a elas para estarem conosco durante todo o processo de construção e normalmente ficamos chateados quando perdemos pessoas da nossa equipe, especialmente se elas estiverem realmente engajadas e alinhadas com nossos objetivos. Portanto, as pessoas da nossa equipe são como clientes, gastamos dinheiro e energia para adquiri-las e retê-las. Mas elas são ainda mais importantes do que nossos clientes, porque sem a nossa equipe, não há como sermos capazes de lidar com nossos clientes e alcançar nossos objetivos.

Isso não significa que precisamos ser “bonzinhos” com nossa equipe, ou que devemos dar tudo o que eles pedem. O que precisamos fazer é equilibrar as pressões externas e internas para que as pessoas possam melhorar continuamente. Se a pressão externa estiver aumentando, precisamos criar o ambiente e fornecer as ferramentas para que as pessoas fiquem mais motivadas, tenham mais drive e aumentem sua força interior. E se temos pessoas ou equipes com excesso de motivação e de energia, precisamos dar a elas mais responsabilidades e objetivos mais elevados. No capítulo Liderando sob pressão vou falar mais sobre esse equilíbrio.

Maçãs podres

O termo maçã podre, apesar de bastante forte, serve para descrever uma situação bastante delicada na formação e gerenciamento de times. Chamamos de maçã podre a pessoa que destoa negativamente do resto do time e que, com seu comportamento, poderá estragar a equipe.

A InfoQ (https://www.infoq.com/news/2009/01/handling-your-underperformer/) falou bastante sobre esse tema da maçã podre do ponto de vista técnico, o under-performer, aquele que é ou está tecnicamente abaixo do resto da equipe e mostrou como o time pode ajudar essa pessoa a melhorar.

Agora, o que fazer quando nos deparamos com uma maçã podre do ponto de vista comportamental? Alguém que é tecnicamente bom, mas que tem problemas de comportamento? Tecnicamente essa pessoa pode ter bastante para contribuir para o time mas seu comportamento faz com que o time não consiga ter um bom relacionamento com essa pessoa.

Nesses casos há dois caminhos a seguir:

  • O mais simples é tirar essa pessoa do time. Essa é uma solução fácil tanto para o time quanto para o seu líder. A tendência numa situação dessas é o time isolar a pessoa difícil até que ela, por vontade própria ou por decisão do chefe, saia do time.
  • O caminho mais difícil, mas que certamente trará mais benefícios para a equipe, é ajudar essa pessoa difícil a se integrar ao time ao ponto de ela deixar de ser uma maçã podre.

É fácil receber no time pessoas fáceis de lidar. O desafio é receber uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do time devem ser mais fortes que os valores da pessoa difícil ao ponto de os valores do time serem absorvidos e assumidos pela pessoa difícil.

Conversas francas com todo o time e com a pessoa difícil são um bom caminho. A transparência é essencial. Se houver boa vontade e disposição tanto do time quanto da “maçã podre”, há boas chances de a situação ser revertida.

Vale lembrar que, na maioria das vezes, uma maçã podre não quer ser maçã podre. Ele pode não se dar conta de que seu comportamento é prejudicial para o time. Ele pode ter tido experiências anteriores onde seu comportamento seria considerado normal. Por isso vale investir em ajudar o time e a pessoa difícil a se entenderem. Contudo, não dá para tentar indefinidamente fazer com que as coisas se ajeitem. É importante definir um prazo para reavaliar a situação e, caso ela não tenha se resolvido, talvez não haja outra opção a não ser tomar uma decisão mais difícil: dispensar uma ou mais pessoas do time.

Resumindo

  • As pessoas são, e devem ser sempre, a prioridade número 1 de qualquer empresa. Gastamos dinheiro e energia para adquirir e reter as melhores pessoas. Ter as pessoas como a prioridade número 1 é a chave para atingir qualquer outro objetivo. Isso não significa ser “bonzinho”, dando tudo o que elas querem, e sim que devemos ser capazes de equilibrar os desafios que damos às pessoas para que possam melhorar continuamente.
  • A pessoas maçãs podres podem drenar e prejudicar seu time. Você deve ajudar essas pessoas a se encaixarem em seu time e, se isso não for possível, você deverá tomar a decisão mais difícil: tirá-la do time.

No próximo capítulo vamos entender como deve ser o trabalho de um líder por meio da analogia de que liderar é como ser um médico.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Feedback and performance evaluation

One of the main tools for the development of the people on your team is feedback. This word is an English term that originally means a process in which the actions of a given system are inserted back into the system for the improvement of the system itself. In people management, feedback is when a person tells another person how their behavior and actions were perceived by that person. Feedback can be given by peers, subordinates or leaders.

Feedback

As a leader, it is very important that you give feedback whenever necessary to the people you work with. Six aspects are essential for feedback to be as useful and relevant as possible:

  • Be necessary:​​ before giving feedback, it is important to understand if it is necessary. Does what the person did affect the result negatively? Or is it just a different way of doing what needs to be done? Sometimes we give feedback on something because it was done in a different way than we expected, but it didn’t necessarily generate bad results. If the result was achieved with the same time, in an acceptable way, we need to accept these different ways of doing things and obtaining the results.
  • At the time: it is important to give feedback as close as possible to the moment when the situation you want to give feedback about happened. In this way, the details about what happened and the motivations that led people to act the way they did will be fresh in everyone’s memory.
  • Objectivity: when talking about what happened, be objective, that is, go straight to the point and base your feedback on facts. Your feedback should be useful to the person receiving it, it should give clear indications about the expected behavior for that situation.
  • Transparency: feedback has to be transparent, there can be no hidden or unspoken aspects, as long as they are relevant to that feedback.
  • Empathy: being transparent and objective does not mean being rude. Rather, feedback is intended to help people understand how their actions and behavior impact others. Put yourself in the shoes of that person who will receive this feedback and think about how you would like to receive it so that it is as useful as possible.
  • Private: give feedback in a private environment, to give space and freedom for a transparent and productive conversation.

Characteristics of a good product manager

I usually evaluate product managers based on 7 main characteristics:

Empathy: is the ability that a person has to put himself in the place of another to understand his desires, motivations, needs and problems. This characteristic is important to understand the customers and users of the product, to know how they relate to it and what problem they expect to solve or what need they want to be met. This will help the product manager to better understand its user so that, together with UX and engineering, they can design the best product. However, empathy should not be used only with the customer or user. The product manager must also use it in his relationship with all areas of the company, and must understand the impact that his product has on their work.

Communication: to be able to empathize, it is necessary for the product manager to communicate with people in the most different scenarios: in one-on-one conversations and in small groups, or making presentations to small and large groups of people, presentations which can be internal (within the company) or external (in conferences, user groups, etc.). However, it is not just about speaking. Communication is a two-way street, that is, the product manager has to be very good at knowing how to listen and understand what others are saying, and understand their desires and needs; which has to do with the first characteristic, empathy.

Time management: the daily life of a product manager can quickly fill up with tasks and she needs to be able to perceive and differentiate what is urgent from what is important, to ensure that she will always have time to learn more about the customer and the user of your product.

New technologies: the product manager must be aware of new technologies to find out how it can impact his product. Smartphone access, how does this impact the product? Does the user want to access via smartphone? To do what? Social networks, how can the product take advantage of them? Non-relational databases, what are the benefits and shortcomings? Go, Google’s programming language, what is it better than the language used in the product? And what is it worst at? Smartwatches, smart glasses, how does this impact the product? How does the user expect to interact with the product on these new interfaces?

Business skills: the product manager must be concerned with whether his product is meeting business objectives. If the goal is margin, are revenue and costs under control? If the goal is only revenue, how is it growing? If the goal is number of users, how is this metric evolving? In addition, the product manager must understand how each area of ​​the company works and how the product affects those areas. How does legal work? How does the product impact the legal department? And how does the legal department impact the product? These questions can be repeated for all areas of the company: support, operations, finance, HR, marketing, sales, engineering and UX.

Keen curiosity: the product manager needs to have the ability to learn fast in order to gain insights and make judgments about the product. You must be able to learn both the soft side of the product (what is the business motivation, what customer problem the product solves, etc.) and the more technical side (what technology do we use, what is the impact of this technology, what metrics can we get, etc).

Product theme: Last but not least, the product manager needs to know about the product theme. If it is a medical product, the product manager should understand a little about medicine. If it is a financial product, you should know a little about finance. For example, at Locaweb, we have more technical products (like the Cloud Server) and less technical products (like the Virtual Store). The need for technical knowledge is quite different in these two products. The Cloud Server product manager should know technical issues in depth, while the Virtual Store product manager does not need to have as much technical knowledge, but should know a lot about online sales issues.

Product managers need to know how to program?

This is a reasonably controversial question. As stated, depending on the product theme, it is important to know how to program, especially if what the product manager takes care of is a more technical product. Some examples of Locaweb are Website Hosting, Cloud Server and SMTP. However, even companies that do not “sell” a technical product 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 Finance Secretariats for issuing invoices, and at Gympass we had the integration with gym management systems and HR systems. For these 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 anyone to use. Would it be good for these products for the product manager to have technical knowledge, that is, to know how to program? In my view, it is not essential that the product manager has technical knowledge, but it will certainly help. Technical knowledge helps you understand how the product is made, and it will help you to be a better product manager. It helps to understand the work done by the engineering team and can be useful in decisions about prioritization and scope. Two analogies that can help to better understand the benefit that knowing how to program 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 certainly this additional knowledge can help her be a better guitarist.

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

SQL

If the product manager doesn’t already know, he 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.

Performance evaluation

Many companies use performance evaluation as the company’s official tool to collect and record feedback from their employees. Leaders assessing the people on their team. People evaluating their peers and their leaders. People doing self-assessments.

Some companies use the 9-box matrix which has two dimensions:

  • Performance: analysis of the past, the results delivered by that person. Here, more than the result itself, it is important to take into account the person’s role in achieving this result, especially if we consider results of a product development team, which are a result of a team.
  • Potential: analysis of the future, that is, how much the person is prepared to deal with new challenges. Literally, potential means “having or showing the ability to become or develop into something in the future”. As you can see, this dimension of a person’s assessment can be quite subjective. For this reason, some companies have replaced potential with culture, that is, an analysis of how the results were achieved by that person, and whether this “how” is aligned with the company’s values. It tends to be a little subjective too, but a little less than potential.

Leaders assess their subordinates based on these two dimensions. In some companies, these assessments include, with less weight, self-assessment, peer assessments, internal clients and, if the person leads a team, their team members. It is the 360º evaluation. In other companies, self-assessment and peer, client and team member assessments serve as additional data for the leader to make the assessment, but do not enter into the assessment calculation.

After the assessment is made, a calibration process is usually carried out, where leaders compare the assessment of their subordinates to understand whether the assessment criteria used by each leader are equalized. This entire evaluation process is led and coordinated by the company’s HR team, and this calibration is facilitated by someone from HR. The people evaluated are plotted in the 9-box matrix and with that we have a map of the company’s people.

9-box matrix and its quadrants

With this calibrated assessment in hand, the manager returns to the team and then the consequence management work begins, which is the work that needs to be done after the team receives their assessment:

  • Well evaluated: people who are in one of the 4 upper quadrants are those who were well evaluated. Usually it is people who are considered for increases and promotions. They are usually happy with the feedback and are motivated to continue doing the job in the best possible way. However, if the person’s self-assessment is higher than the assessment received, even though they are well assessed, there is a risk that they will experience some frustration. This only does not happen if she is evaluated in the upper right quadrant of the 9-box matrix.
  • Poorly evaluated: people who are in any of the 3 left quadrants or any of the 3 lower quadrants are below expectations in terms of performance and / or potential (or values, if there was a decision in the company to change this axis of the matrix 9-box). These people will need to do something to receive a better evaluation in the next cycle. This situation can cause some discomfort in the person evaluated because he feels that his job may be at risk. For some people, this situation can serve as an incentive for them to seek to improve and, in fact, be better evaluated in the next cycle. On the other hand, some people may feel unmotivated by this assessment and decide to look for an opportunity in another company. This situation is aggravated if the person self-evaluated better than the evaluation he received.

Criticism to the performance evaluation process

The performance evaluation process seeks to classify the employees of a company in order to facilitate the understanding of who are the best people and who are the people who need to improve. However, as I explained above, there are many opportunities for frustration in this assessment process, especially when there is a disagreement between self-assessment and the assessment received. This frustration is usually compounded by the fact that the evaluation process is liable to:

  • subjectivity: how to measure a person’s potential? How to measure your adherence to the company’s values? How to measure your participation in achieving results?
  • bias: distortion due to different aspects of the appraiser’s judgment in relation to the appraised person. Usually, the appraiser remembers an appraisee’s most recent actions. It is also common for actions with negative consequences to be perceived more intensely than actions with positive consequences.

In addition, we are increasingly understanding and respecting human diversity, not only in physical matters and preferences, but also in the diversity of perspective, history and context. With this greater clarity on human diversity, it becomes increasingly difficult to fit all people in a company into just 9 boxes based on two dimensions (potential vs results). To better understand the complexity of the people who make up a company, we will probably need to think in a multidimensional way.

For these reasons, there is a worldwide tendency to abandon the periodic performance evaluation process and replace it with more frequent conversations between leaders and followers about career, performance, potential and values. According to some estimates (https://hbr.org/2016/10/the-performance-management-revolution), more than a third of American companies have already abandoned the periodic performance evaluation process and have adopted these more frequent conversations as an alternative.

Retrospective, an alternative to the performance evaluation process

In addition to the most frequent conversations between leader and team member about career, performance, potential and values, I think it is important every 6 months to do a retrospective with the team about what happened in that period. In the same way that in product development we have retrospective ceremonies, it is a time to revisit what happened and evaluate what went well, what can improve and the challenges ahead.

I do a first version, based on the history I have with the person. If there is a formal performance evaluation process in the company where I am working, I use this opportunity to do the retrospective and consider all information generated through this process, self-assessment, peer review, internal clients and team members, if any.

This first version has 3 sections, strengths, improvements opportunities and challenges for the next semester, which includes not only the main objectives for the next semester but also focus on the points for improvement. If there is a formal performance evaluation process in the company where I am working, place my initial suggestion for classification in the items measured in this formal process (results, potential or adherence to values).

The next step is to use one of the 1:1 meetings to talk to each team member about this retrospective, listen to how she sees it, and eventually adjust the retrospective in agreement with her. It is an excellent time to have a broader conversation and a joint reflection on the semester that has passed and what lies ahead.

If there is a formal performance evaluation process in the company where I am working, I make this conversation before inserting the data into the company’s evaluation system, as I think it is important for the evaluation to contain this retrospective built together with the person. If there are calibration sessions, I advise the team member that the assessment may still undergo adjustments due to the calibration and, after the calibration, I tell in a transparent way what happened in the calibration, to help the person understand how other people perceive her.

EXAMPLE of a GPM retrospective

Strengths

The first semester was particularly difficult for Philippa, with many uncertainties and huge pressure to deliver the Avengers Project. Given all this, Philippa managed to navigate the situation very well and find good solutions, including recommending a company acquisition, as well as keeping her tribe engaged in the process.

Opportunities for improvement

Your PM team is still junior, with little experience in product management, despite having good technical knowledge of the product theme. It is important to look for ways to accelerate this seniority of the team.

Challenges for the next semester

You must work to increase your PMs’ seniority as they still demand a lot of your time, preventing you from having a more strategic role.

Promotions and salary increases

In the chapter “Hiring the right people” I commented that, when making the offer for a person to join your team, it is important to balance short-term (salary and benefits), medium-term (bonus) and long-term (stock options) incentives. From time to time, while that person is on your team, it is important to assess whether these incentives need to be revised, that is, whether he deserves a raise or a promotion. There are two important aspects to consider, when and how to give salary increases and promotions.

When

It is common for companies to define a period of the year for promotions and salary increases, usually just after the period of performance evaluation or periodic retrospective. I recommend not doing this, because in the hierarchy of needs of most people, the need for recognition and financial reward comes before the need for personal development. Therefore, if in the same conversation we put the topic on promotions and salary increases along with the feedback topic and what points he needs to improve, the person’s attention will be much more focused on the topic of promotions and increase. For that reason, I recommend separating these two conversations. When talking about promotion and salary increase, focus only on that topic. And when talking about hindsight, again just focus on that topic.

How

There are two ways to promote a person. The first way is to expect her to be demonstrating skills from at least 70% of the next career level to promote her. This is what I call a “pushed promotion”, that is, she must push to get her promotion. The other way is to assess the person’s potential, that is, whether he has the capacity to develop the skills necessary to operate at the next career level and, if he has, to promote it. I call this form “pull promotion” because the person is pulled to operate at the skill level of the next career level.

I prefer the pulled promotion model, as it generates a very motivating challenge for the person, who will feel that he owes the necessary skills and will rush to develop them as soon as possible. There is, of course, a risk that she may not be able to develop these skills, but in most cases, I see that people with potential usually develop them very quickly. In the pushed promotion, the main advantage is that there is no risk, the person who is promoted already demonstrates the necessary skills. However, precisely because he already has the necessary skills, this person may feel that the promotion is not coming, or that it is taking too long and may want to look at the market, increasing the risk of you losing him from your team, because it takes too long to give him recognition.

Summing up

  • Six essential aspects for good feedback are: checking if feedback is necessary, giving it when it happens, being objective, being transparent, empathizing and giving feedback in private.
  • The seven main characteristics of a good product manager are empathy, communication, time management skills, knowledge of new technologies, business skills, keen curiosity and knowledge about the product theme.
  • If the product is not a technical product, it is not necessary to know how to program. However, having some sense of programming can be useful in understanding how your product works. Knowing SQL is also useful, as it will help the product manager to better understand the metrics of their product.
  • Formal performance appraisal processes have been increasingly seen by companies as something that does not bring as many benefits as expected. Several companies are replacing this process with more frequent conversations between leaders and followers about career, performance, potential and values.
  • Semi-annual retrospective is a good way to have a structured conversation with the team member about the results achieved and how they were achieved, and about the challenges to come. This retrospective must be built together with the team member. If there is a formal performance appraisal process in the company where you are working, use the retrospective process to create the performance appraisal.
  • Regarding promotions and increases, there are two aspects to consider, when and how. I recommend separating the salary increase and promotion conversations from the feedback conversations to maintain full focus on the topic of each of these conversations. I also recommend promoting the person when he has the potential to develop the skills necessary to occupy the next career level, and not expect him to already demonstrate the skills necessary for that next career level, as this will motivate the person more.

In the next chapter, we’ll look at the ceremonies I usually use with the teams I lead.

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

Antipadrões

Um antipadrão é uma resposta comum mas ineficaz e contraproducente a um problema. Esse termo foi criado por Andrew Koenig em 1995, inspirado no livro de 1994, Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de design: Elementos reutilizáveis de software orientado a objetos) escrito por Gamma Erich, Helm Richard, Johnson Ralph e Vlissides John, que lista uma série de padrões de design de desenvolvimento de software que seus autores consideraram simples, sucintos e eficazes para os problemas mais comuns.

Mas o termo foi popularizado pelo livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Antipadrões: Refatorando software, arquiteturas e projetos em crise), de 1998, escrito por Raphael Malveau, William Brown, Hays McCormick e Thomas Mowbray, que estendeu seu uso além do campo do design de software para se referir informalmente a qualquer solução ruim para um problema.

Na Wikipedia em inglês, o termo lista mais de 70 antipadrões. Vou listar a seguir os antipadrões que encontrei com mais frequência na minha carreira. Esses antipadrões que cito acontecem quando a liderança da empresa não tem experiência suficiente em desenvolvimento de produtos e é assessorada por pessoas que foram bem-sucedidas em gestão de desenvolvimento de software no passado, mas que não se atualizaram.

Como expliquei na introdução, desenvolvimento de software é uma ciência muito nova, especialmente se comparamos com outras ciências como astronomia, medicina, matemática, química etc. A primeira vez que um computador armazenou um software em memória e o executou com sucesso foi às 11 horas do dia 21 de junho de 1948, na Universidade de Manchester, no computador Manchester Baby. Isso significa que desenvolvimento de produtos de software está engatinhando. Se um profissional não se mantiver atualizado, o conhecimento e experiência que o fez bem-sucedido no passado pode não ser o mais adequado para fazê-lo bem-sucedido no futuro.

Documentação

Uso excessivo de documentação vai sem dúvida desacelerar o time de desenvolvimento de produtos. Não é à toa que no Manifesto Ágil, escrito em 2001, dizemos que valorizamos “Software em funcionamento mais que documentação abrangente”. Para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.

A última vez que escrevi um PRD (Product Requirement Document ou Documento de Requisitos de Produto) foi em 2005, logo quando eu entrei na Locaweb. Foi um trabalho bastante demorado, onde documentei em detalhes tudo o que precisávamos implementar no software. Passada para a engenharia, a implementação foi feita com vários erros porque os engenheiros acabaram não entendendo o que estava escrito em algumas partes e decidiram implementar como acharam melhor. A partir disso passamos a diminuir o uso de documentação extensa e aumentamos a interação entre gestores de produto, designers de produto e engenheiros.

Marty Cagan tem um artigo muito bacana chamado How to write a good PRD (Como escrever um bom PRD – https://svpg.com/assets/Files/goodprd.pdf) onde ele comenta logo no começo:

“Forneço este documento aqui principalmente para fins históricos. Foi escrito em 2005 para refletir melhores práticas das décadas anteriores.

Não tenho defendido o uso de PRDs por muitos anos, começando aproximadamente em 2007. Não é que os PRDs sejam tão ruins. Contudo, se o gerente de produto está gastando seu tempo escrevendo o PRD, então é improvável que ele ou ela esteja fazendo o trabalho real de discovery de produto.”

Padrão recomendado: é só seguir o manifesto ágil, produto na mão de clientes traz mais valor para os clientes e para a empresa do que documentação abrangente e detalhada.

Foco em dados

Acontece quando o head de produtos e outros líderes só tomam decisões se houver abundância de dados, relatórios, gráficos. Há dois perigos com esse antipadrão:

  • Tempo: às vezes para juntar todos os dados necessários leva-se muito tempo. É a situação conhecida como analysis paralysis ou paralisia da análise. Nada acontece enquanto os dados não são meticulosamente obtidos e analisados. Muitas vezes, após uma primeira análise, mais dados são pedidos e mais tempo é investido na busca desses novos dados, e esse ciclo pode se repetir por inúmeras vezes. E, enquanto esse ciclo se repete, nenhuma decisão é feita. Daí a paralisia da análise.
O custo da análise (fonte: https://xkcd.com/1445)
  • Erros: quando confiamos somente e exclusivamente nos dados, há grandes chances de incorrermos em erros. Como podemos ter certeza de que temos todos os dados necessários para concluir algo? Como podemos ter certeza de que os dados estão corretos? É comum ouvir que as decisões devem ser data-driven, ou seja, baseadas em dados. Contudo, os dados podem estar incorretos e/ou ser insuficientes para descrever uma determinada situação. Pensando nisso, mais recentemente surgiu o conceito de decisões data-informed, ou seja, que são baseadas em dados, mas não somente em dados. Levam em conta, além dos dados, informações qualitativas, experiência prévia e intuição.

Padrão recomendado: procure tomar decisões com dados, mas sempre entendendo que os dados são incompletos, e leve sempre em consideração informações qualitativas, experiência prévia e intuição.

Grande reescrita

Toda empresa tem um sistema legado. Mesmo a startup que acabou de ser criada, em poucos meses, poderá olhar para sua base código como legado e algo que precisa ser melhorado. Nesse momento aparecem 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.

E nesse momento nasce a grande solução da reescrita. E essa grande reescrita vai, em algum momento causar aquele congelamento de evolução do produto. Por que escrever algo para o legado, se o novo sistema vai substituí-lo? E tem também a migração ou transição. Como vamos do sistema legado para o novo?

Normalmente nas estimativas iniciais a reescrita vai levar uns 2 ou 3 meses e quando avançamos percebemos que vai ser um pouco mais longo, podendo levar anos. Na Locaweb tomamos a decisão de reescrever o sistema central que tinha o cadastro de clientes e fazia a cobrança. O projeto original era de 9 meses e acabou levando mais de dois anos. Além disso, quando o novo sistema entrou, nossa cobrança de clientes não funcionou durante uns 2 meses e ficou mais uns 6 meses rodando de forma incorreta até terminarmos todos os ajustes necessários. Ou seja, a reescrita que originalmente levaria 9 meses acabou levando 3 anos.

Padrão recomendado: evite grandes reescritas a todo o custo. Na grande maioria das vezes haverá formas de substituir o sistema legado de forma gradual e progressiva, sem causar disrupções para a empresa e para os clientes.

Lista de desejos

Quando uma nova head de produto se junta a uma nova empresa, é comum durante o processo de onboarding, durantes as inúmeras conversas com pessoas de várias áreas da empresa, ouvir uma série de pedidos e de reclamações em relação ao produto de que essa nova head vai cuidar. Para “marcar pontos” com essas pessoas, que eventualmente vão dar feedback sobre seu trabalho, pode ser tentador construir sua lista do que fazer baseado nesses pedidos e problemas reportados. É a “lista de desejos” da empresa. Em seguida, essa head de produto vai priorizar essa lista ou até mesmo terceirizar essa priorização para algum líder da área de vendas ou de negócios da empresa. Já vi situações em que o head de produto coletava a “lista de desejos” e apresentava em uma reunião com líderes de várias áreas da empresa, dizendo “agora preciso que vocês priorizem o que querem que o time de desenvolvimento de produto faça primeiro”.

Apesar de ser algo tentador, pois a “lista de desejos” vai de fato ajudar o head de produto a marcar pontos com líderes das outras áreas, esse comportamento fará com que o time de desenvolvimento de produto se torne um mero cumpridor de ordens, inibindo o potencial de inovação que ele pode trazer para o negócio. Quando o head de produto foca o time em atender a “lista de desejos”, acaba focando o time em ser um implementador de soluções que são dadas por outras pessoas, tirando o foco dos problemas a serem resolvidos. É a diferença entre o time implementador de soluções que já vêm prontas das outras áreas da empresa versus um time focado em encontrar as melhores soluções para resolver problemas da empresa. Vou falar mais desse assunto na próxima parte do livro, sobre princípios.

Padrão recomendado: time de desenvolvimento de produto trabalham em entender problemas para depois avaliar soluções possíveis. Procure então descobrir a lista de problemas a trabalhar, e não a lista de coisas que as outras áreas querem que o time de desenvolvimento de produto faça.

Resumindo

  • Antipadrões são respostas comuns mas ineficazes de se resolver problemas. Existem muitos antipadrões bem documentados no mundo do desenvolvimento de produtos digitais. Os 4 antipadrões mais comuns em liderança de desenvolvimento de produto são documentação, foco em dados, grande reescrita e lista de desejos.
  • Documentação, que deveria ser mantida em um mínimo, para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.
  • Foco em dados é quando toda e qualquer decisão tem que ser tomada com dados, sem levar em conta informações qualitativas, experiência prévia e intuição.
  • Grande reescrita acontece quando uma nova head de produto encontra um sistema escrito há algum tempo e identifica que será melhor reescrever do zero um novo sistema do que aprimorar o atual.
  • Lista de desejos vem da necessidade de o novo head de produtos de agradar a todos os stakeholders, focando o time de desenvolvimento de produtos a apenas implementar o que é pedido, delegando a priorização para as outras áreas da empresa.

Com este capítulo terminamos a parte 1 sobre os conceitos necessários para entender os papéis e responsabilidades de um head de produtos. Na próxima parte vamos ver quais princípios devem nortear o trabalho de uma head de produto e de seu time.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros: