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:

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:

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:

Ecosystem mindset

This value I learned at Gympass. It was one of the company’s corporate values ​​and, in my opinion, every platform must incorporate this value in its culture. I often came across CEOs and heads of platform products who claimed that they do everything for the customer, that the entire company is customer-centric. However, when I dive deeper in this topic, I end up discovering that the client they were referring to was just one of the actors of their platform and the others were treated only as “necessary evil”.

In the description of the value on the Gympass website it is written:

Ecosystem mindset

We make decisions that create value for our Gympass ecosystem and help us achieve our mission.

The ecosystem mindset example I will describe below is the implementation of the live classes product that Gympass created during the COVID-19 crisis.

Diversifying – and digitizing – a product portfolio

During the COVID-19 pandemic, we diversified – and digitized – our product portfolio in record time. We went from an offline product, access to gyms and studios, to 4 products, 3 of them totally digital, in less than a month:

  • Access to gyms and studios: Access to more than 50,000 gyms and studios in 14 countries;
  • Live classes: for those who like to train in groups or want to relive the feeling of the class with colleagues at the gym;
  • Personal trainers: for those who prefer a more personalized approach and like to exercise in their own time;
  • Gympass Wellness: app package with over 60 apps for those looking for options to improve physical and mental well-being (from nutrition to therapy session).

Below I explain how we did it.

Product Vision

When I joined Gympass in mid-2018, one of the first things I did was to build a product vision. We had a very strong purpose: to defeat inactivity. However, to build a digital product, we need more than a purpose.

Gympass product vision

This vision guided the definition of the Gympass product development organization. As I commented in the chapter Team structure, we set up teams around each of the marketplace participants, in addition to a central team that worked in the payment flow collecting the payment from the companies and their employees, doing all the calculations, and determining the amount to be paid to each gym partner.

When I was building this product vision and discussing it with different people in the organization, it was easy to see many opportunities to expand that marketplace. There are a lot of new service categories that we could add to our marketplace:

Gympass expansion opportunitties

There are 3 types of elements in a market:

  • Supply: goods or services available for consumption.
  • Demand: people or companies that may need goods or services offered by the supplier.
  • Market: where demand meets supply and a transaction occurs.

These three elements are related as follows:

  • Value delivery: the market adds value to demand and supply. The value delivered to the supply is people or companies interested in their goods or services. The value delivered to demand is a varied number of suppliers of goods and services.
  • Payment: To have access to goods and services offered by suppliers, demand pays the market and the market pays for the supply. The market typically retains a fee per transaction. This fee can be fixed or a percentage of the payment.
Dynamics of a marketplace

Given the dynamics above, we can expand a market as follows:

  • Diversification of demand: you can offer goods and services from your marketplace to new segments and geographic regions.
  • Supply diversification: you can offer new goods and services to your demand.
  • Delivery of new value: you can offer new value to your supply and demand.
  • Financial payment management: as the demand payment to the supply passes through the marketplace, you can offer financial services for both demand and supply, such as advance payment and credit, and you can manage the spread.
Marketplace expansion opportunities

However, we had a lot to do with our main product at that time, so we didn’t have enough energy to focus on expanding our marketplace and left the plans in the drawer.

New endeavor

In October 2019, we reached a point where our product development team was well structured and working properly to address our challenges in our core product, so we decided to focus on expanding our marketplace.

We decided to work on an idea called “Gympass end-user partnership hub”. The plan was to partner with wellness apps and provide them to our users.

This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app and ZenApp a meditation app.

Okay, our first hypothesis was validated and we needed to validate the second hypothesis, the willingness to pay. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for name, email and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged in area, just a form to test interest and an email with links to the applications.

Initially, we call it Gympass W, the W meaning wellness. We added a beta so that everyone could understand that it was not a finished product. Later, we renamed it to Gympass Wellness to make its value proposition clearer.

Our plan was to test this proof of concept with 5 corporate clients in the USA and 5 in Brazil, which would provide us with a potential user base of 15,000 employees. Our expectation was to have around 200 subscribers. We launched internally – eat your own dog food – on March 9, 2020 and had 66 subscribers from our 1,200 employees. Then came COVID-19.

COVID-19

When a company is hit by a crisis, it needs to look at these two perspectives:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

Although product managers and product development teams play an important role in the former, their primary role is in the latter.

At Gympass we have 3 different clients and all of them deeply impacted by COVID-19:

  • gyms in many cities have been closed to support with physical distance measures applied to prevent the spread of COVID-19 and, consequently, are losing recurring revenue from users who were not going to the gyms;
  • users, employees of our customers, can no longer go to the gyms and have to stay at home, but they also have to remain active in some way, but their first reaction was to cancel or pause their Gympass subscription, because they didn’t have access to the gyms for a while;
  • corporate customers, whose employees are at home and no longer go to gyms, while HRs are concerned with how to keep these employees engaged and productive.

Gympass Wellness, the first digital product

We were able to adapt our Gympass Wellness pilot in record time to be offered to our entire user base, so that they can remain active, and also take care of their nutrition and their minds during these challenging times. With Gympass Wellness, we were able to address the problems and needs of users and our corporate customers during the crisis.

And here comes the ecosystem mentality. We must always look at all participants in our marketplace and ensure that everyone benefits from using it.

Live Classes, the second digital product

With Gympass Wellness, we were able to meet the needs of our corporate customers and their employees. But what about the gyms? When closed, they were losing revenue. Their customers no longer visited them, so regular gym users were likely to cancel their subscription, while those who used to go to gyms using Gympass did not go to the gym during the crisis, which would cause a loss of revenue for gyms as well. To help partner gyms cope with this very difficult situation, we decided and implemented 2 solutions in record time:

  • We provided the academies with a white-label application so that they can offer it to all their customers, regardless if they were or weren’t employees of Gympass customers, so that the gyms could deliver value to their customers, helping them to stay active at their homes;
  • We provided a platform for gyms to schedule and broadcast live classes to all Gympass users, so they can keep their instructors employed, while providing Gympass users with exclusive content. This platform is called Live Classes.

Personal Trainers, the third digital product

Live Classes provided a 1:N platform, which means that an instructor could provide physical activity guidance to N users. We soon realized that we could create another product in addition to Live Classes. Workout guidance 1:1, which could be made available in Gympass’ higher tier plans. Then we created our third digital product, Personal Trainers.

Summing up

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

There, with this chapter we conclude the second part of the book, on 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 shared by a group of people working together on how to solve problems and react to situations. We also saw the 5 values ​​needed to create successful digital products:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, should not be the main focus.
  • Transparency, the foundation of a high performance team.
  • Diversity, the basis of the best products.

Finally, we saw a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is 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 mindset

In the next chapter we’ll start the third and final section of the book, about tools! \o/

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

Result delivery

Result delivery

In the previous chapter, we saw the difference between a team that solves problems and a team that implements solutions. While a problem-solving team needs to have a deep understanding of each problem it will solve, the people who are affected by it, the context in which it occurs, and the motivation people have to have this problem solved, the solution implementing team focus on implementing what is asked, no matter if what is implemented will bring any results.

The measurement of result delivery for these two types of teams is often quite different. Through the way a team reports its results, we clearly know what kind of team it is. Something like:

Tell me about the results you deliver and I’ll tell you what kind of team you are on!

While the solution implementing team usually measures its delivery of results based on the number of features delivered, the problem-solving team measures its delivery of results based on how well the problems have been solved.

Feature Factory

Solution implementing teams are those “feature factories” that we already mentioned in the previous chapter, that is, whose main metric is the quantity and speed of feature delivery. As this is its main metric, this team is now measured by its deliveries. The team said it was going to deliver that functionality that day, so that’s what the organization expects and that’s what the organization will ask the team.

This situation is not as unusual as you might think. At Locaweb, before implementing OKRs, the product development team was primarily measured by its planning assertiveness. If the team said it was going to deliver X on day Y, that was what was expected of the team, with no concern whether X was the right thing to do and whether it was actually going to bring results for the company or customers. By implementing OKRs, we managed to make the team increasingly focused on understanding and solving problems.

When I joined Lopes, I found something very similar. A portal team, a CRM team, and an app team, all of them with predefined deliveries planned up to 6 months ahead, because that was what was agreed with the company’s management. Lopes had even hired two consulting companies that, when presenting their results report, showed the number of features delivered as their main result, because that was what was demanded of them, delivery of features.

It is important to note that a situation like this does not happen solely because of the product development team. It is also the responsibility of the people who are making the demands. While the product development team must always ask what problem they are trying to solve with that demand, the people who make the demands must always contextualize these demands bringing the problem that motivated the demand.

Focus on the result

After my first 30 days at Lopes, I started working with the team to define the OKRs for the next quarter, which even motivated HR to also make its planning based on OKRs. These OKRs were then presented to the entire leadership of the company. It was the way I found to bring about a change in culture and mentality both in the product development team and in the entire company.

Most of the OKRs we defined were focused on business results. Increase in sales, increase in the conversion rate, and so on. That’s what matters to the business. Features are a means to get to an end, they are not an end in themselves, even in 100% digital companies, such as Conta Azul and Locaweb, digital products are a means to the end. Locaweb even makes this very explicit in its mission to “make businesses born and prosper through technology”, while Conta Azul wants to “boost the success of small entrepreneurs by giving small businesses more organization, control and time through technology.” Note that in both companies the technology and, consequently, the digital product is a means to an end. Both achieve their mission “through technology”.

Summing up

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

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

In the next chapter, we’ll look at the value of ecosystem mentality.

New book: Digital products leadership

I used the year-end low workload to finish translating my book “Digital products leadership: The science and art of managing product teams” into English. Enjoy! \o/

Here’s a special launch discount coupon:

https://leanpub.com/leadingproductdevelopment/c/launch

And happy 2021, full of amazing results brought to you by the products you manage!

Focus on the problem

It is human nature to solve problems. Whenever we hear about problems, we go into solution mode almost immediately: we start looking for solutions to the problem. However, if we are able to get a better understanding of the context in which the problem occurs and the motivation to solve it before jumping into solution mode, there are more chances of finding solutions that are simpler and easier to implement.

It is common to see other areas in the organization asking the product development team to implement feature A or B because we need it to close a deal or to not lose that big customer. A common example I have heard for sometime back in 2019 was “we need to implement Apple Pay and Google Pay as a new payment method”. The issue is that, talking about solutions, we lose focus on the problem that originated that solution.

What is the problem?

To help people focus on the problem, always ask “What is the problem?” When a new feature request arrives for the product development team, we must thank the requester and then ask about the problem that generated the request. Each member of the product development team must have this behavior whenever a request for a new feature is received.

By putting this into practice, requests will soon come with not only a solution but also a lot of information about the problem. It is interesting to see this cultural change, but it requires discipline from members of the product development team to always ask about the problem. And when I mention the members of the product development team, I’m referring to everyone, not just product managers, but also designers and product engineers.

Problem vs. solution mindset

The main advantage of focusing on better understanding the problem is that the more time we invest in it, the easier it will be to find a solution and there are good chances that this solution will be simpler and faster to implement than the first solution we thought of.

Here is a great quote from Albert Einstein:

“If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and five minutes thinking about solutions.”

Einstein believes that the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you are trying to solve.

Let me tell you a little story to illustrate this. During the space race, scientists were faced with the problem of writing in space where there was no gravity to make the ink fall into a ballpoint pen. The Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink onto paper, even without gravity. Meanwhile, the Russians decided to use pencils.

Pen that writes in weightless environments

This story shows a good example of how jumping straight to the solution can make us spend unnecessary time and money to come up with incomplete or exaggerated solutions. It is a cultural issue, that is, a behavior that we can and must change. And the first step in changing a behavior is to recognize when it happens. When a member of the product development team receives a request to implement something, he must ask the person who brought the request what is the problem that this “something” should solve and why it needs to be solved.

Here are some examples of the companies I worked for.

At Locaweb, a web hosting provider in Brazil, hosting and e-mail services may stop working due to external factors such as the domain that is associated with hosting and e-mail not being renewed.

First solution: Registro.br, the Brazilian registrar of .br domains launched an API to allow Locaweb to charge the customer’s domain on behalf of Registro.br. At first, the idea seemed good, as Locaweb charging the domain seemed to be the easiest way to ensure that the customer knows that they have to pay for the domain registration to keep hosting and email services working properly. However, when we analyzed further, we saw that this solution could cause some problems. The customer would be charged twice for the same domain registration because Registro.br would continue to charge the domain. What happens if the customer pays both bills? What if he only pays for Registro.br? What if he only pays Locaweb? In addition, implementing a new type of billing in which we would charge for a third party service was something new for the Locaweb team. New processes would have to be carefully designed.

Implemented solution: we started to wonder if there would be simpler ways to solve the problem of helping our client not to forget that he has to pay for the domain registration at Registro.br. As it would be possible to charge for Registro.br services, it was possible to access information about the domain about to expire. We decided to design a simpler solution: implement a communication sequence with the client warning him of the importance of paying Registro.br to ensure that the email and hosting services continue to function normally. This is a much simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send the information from this link to the customer and the chances of solving the problem will increase even more. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSBs (micro and small businesses), we used accountants as one of our distribution channels and we wanted to increase sales through accountants.

First solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A batch purchase management system would take about 3 months to implement, as it should allow accountants to purchase Conta Azul licenses in bulk, but it should only start charging the accountant’s customer when that customer actually activates the license.

Implemented solution: accountants didn’t care about batch purchases. What they wanted was to give a discount to their customers so that they could subscribe to Conta Azul with this exclusive discount provided by their relationship with us. The cost to implement this was zero, as the system already had a discount management feature.

At Gympass, a fitness partner who was joining our network asked us to present his waiver to all users who checked in to their facilities.

First solution: change our app to ask users who go to this fitness partner to read their waiver on our app and click a checkbox stating that they have read and agreed.

Implemented solution: no changes to our app. We use a customizable text field when configuring a gym in our system that is typically presented to users who will check in at that gym to present the following text: “By checking in, you agree to the terms and conditions located at http://fitnesspartner.com/waiver”.

Don’t get me wrong, it’s great that everyone brings solutions whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind this solution, so that we have a chance to find simpler and faster solutions to implement. And it is ultimately the job of the product manager and all the members of the product development team to ask what the problem is and why we need to solve it.

Projects vs. problems

The New Year is a time for retrospective and planning. What is normally done every quarter by most product development teams is done more intensively at the turn of the year, in conjunction with other areas of the company. It is the annual planning process, which usually comes with the budgeting process. What will we do in this new year that is coming? What are the main projects that we will work on throughout the year?

Even though planning is super important to be clear about which projects are priorities for the new year, this list of projects can make you lose sight of a very important aspect of planning, the “why”.

It is not uncommon to see new year planning for a product development team, and even for the entire company, as a list of projects. To help you see your list of projects at a different perspective, I recommend you add 2 columns:

  • one to describe what problems you are trying to solve in each project;
  • and another to describe who you’re trying to solve this problem for.

I have already discussed the issues of having a problem-oriented mindset versus a solution-oriented mindset, but when it comes to New Year planning, that problem is even more evident. The benefits of being clear about the problems you want to solve and for whom you plan to solve them are:

  • Ensuring that problems are aligned with the company’s vision and strategy: When we focus on projects, it is easy to lose sight of the problems we are trying to solve, for whom we plan to solve, and if these are the problems we really need to solve.
  • Define which problems are most important to solve: prioritize projects without knowing which problems these projects solve, and for whom, it can make priorities unaligned with what is really important for the company. However, to be more effective in bringing the desired result, we must prioritize the problems to be solved and ensure that the prioritization is aligned with the company’s vision and strategy.
  • Solve more than one problem with the same project: Sometimes you may find that you are trying to solve more than one problem with a project, and this may not be a problem. But you need to know that. Perhaps you can have simpler solutions if you address each problem separately. Perhaps not all are worth resolving at this point.
  • Check if the projects are the best solutions: when we change the focus of the projects to the problems and we have clear visibility of the priority of the problems, it is easier to check if the projects listed are the best solution for the problem in question. Sometimes, we can find solutions that are easier to implement when we shift our focus to understanding problems.

Then take your list of projects and create these two columns, problems to be solved in each project and for whom the problems will be solved. This will help you to focus on the most important things for this new year.

Problem solving teams vs. solution implementing teams

Marty Cagan, a well-known reference in the digital products community, wrote an interesting article some time ago about product teams x feature teams, where he explains the difference between three types of teams, delivery teams, feature teams, and product teams. It defines each type of team as follows:

  • Delivery teams are not multifunctional (basically just developers plus a product owner who manages the backlog), are not focused on the result (people are all oriented towards delivering features) and have no autonomy (they are there to encode and deliver).
  • Feature teams are usually multifunctional (they have at least one designer and a product manager), but are still concerned with the production and delivery of features.
  • Product teams are multifunctional, focused and evaluated by the result, and have the autonomy to present solutions that work.

He explains that the best results for the organization that owns the product and for the users of that product come from the teams he calls product teams. He has used the word empowered a lot to describe these teams.

Any digital product exists for two main purposes:

  • Help the company that owns the digital product to achieve its goals.
  • Solve problems and meet the needs of its users.

Therefore, any digital product and its functionalities are solutions to problems of the company that owns the product and solutions to solve the user’s problems and meet their needs.

In this digital product context, when I say that spending more time understanding the problem produces the best solutions, I mean that we are able to deliver the best product and features as quickly as possible to solve the problem with good software quality and a good user experience.

solve problems vs. implement solutions

What Marty describes as delivery teams and feature teams are teams of solution implementers. These teams work on implementing a solution conceived by someone else. And that other person is usually someone from the so-called “business area” who can be someone from sales, marketing, customer success, customer support, finance, operations, a director, a vice president, or a founder. In such a team, the product manager mainly manages the backlog and helps the team to deliver the requested solution, the product designer focuses mainly on designing a pleasant interface, and engineers have to code and deploy the requested solution. The solution implementation teams do as they are asked to do, with little or no commitment to the quality of the solution, or even if the solution implemented really solves the problem. They may also be called a “feature factory”. Its performance is measured by the amount of functionality that the team produces.

On the other hand, what Marty describes as empowered product teams are problem-solving teams. These teams 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.

There are three main reasons why problem solving teams are more effective than solution implementing teams:

  • Digital product knowledge: There is no one better than team members to find the best digital product solution to a problem. A solution delivered as quickly as possible, with good software quality and good user experience. This is because a team of problem solvers is a multifunctional team made up of engineers who understand the technology available, product designers, who have a deep understanding of users, their pains and needs, and product managers, who have a good understanding of the business context of the problem to be solved.
  • Two heads are better than one: this old saying means that it is easier for two people to help each other to solve a problem than for one person to solve a problem alone. A team of problem solvers does not rule out any suggestions for solutions from “business areas”. In fact, these solution suggestions are very useful in helping the team to better understand the problem, but they should be considered suggestions. A team of problem solvers first understands the problem and then looks at the solution options.
  • Commitment: An additional side effect of a problem-solving team is that members of that team are deeply committed to the successful implementation of the solution since they are deeply involved in the process of finding the solution.

Creation of problem solving teams

Now that I have explained why problem-solving teams are the best type of digital product team a company can have, I will explain how to build problem-solving teams. There are three aspects that need to be considered:

  • Environment: It is essential that the entire organization understands the power of having problem-solving digital product teams. The speed and quality of the solutions delivered by a digital product team that always starts to solve problems from a deep understanding of the problem are much better than the solutions delivered by teams of solution implementers. Consequently, business results will be better and faster. It is the role and responsibility of the product head to help the organization understand this.
  • What is the problem: A very effective way to focus the entire organization away from the solution mindset and closer to the problem mindset is to constantly ask “What problem are we trying to solve?” and “Why is it important to solve this problem?”. This will help people across the organization to change their perspective and, consequently, realize the importance of a deep understanding of the problem before implementing a solution. This is a behavior change that the entire digital product development team can help your organization make. Whenever someone asks the product team to implement something, ask “What problem are we trying to solve?”
  • Trust: This is a critical aspect of building successful problem-solver teams. Usually people in the “business area” believe they have a better understanding of the business than those of the product team. This behavior is even more visible when the digital product team is new to the organization. How can a new person in the organization understand more about the business than someone who has been with the company for years? She probably cannot, especially if she comes from a different market. However, those who are part of the digital product team usually have a lot of experience in building digital products, probably more experience than anyone else in the organization. Therefore, it is essential that the “business area” educate the digital product team about the business aspects of the organization. This search for education is the role and responsibility of product managers, who must learn from the “business area” and educate product designers and engineers about the business. A practical way to accelerate this learning is to bring people from the “business area” to the discussion sessions on the problem. This is how the product team gains the trust of the other areas of the organization.

I believe that the benefits of having digital product teams versus solution implementers teams are clear. The entire organization needs to understand the difference in order to push for more and more problem-solving teams. The head of product has this as one of her greatest responsibilities, helping to build the environment and the trust needed for the success of problem-solving teams.

The top-down trap

When I talk about the differences between problem solving teams vs solution implementing teams, I usually hear comments like “We want to be a problem solving team, but in my company all solutions are top-down and the only thing we can do is implement them “.

These situations worsen when a crisis arises. The most recent crisis that many companies are experiencing is the COVID-19 crisis. In an eagerness to solve problems as quickly as possible, company leaders ask teams to implement this or that solution quickly, very quickly.

The trap

Let me now approach the elephant in the room, the top-down decision-making environment. This has a huge impact on any team in this type of environment. Without being part of the decision about the solution, the people who implement the solution will end up discouraged and demotivated.

Why am I calling it a top-down trap? Because many of the decision-making environments perceived as top-down are what I just wrote, a perception.

Let’s use the main characteristic that every product manager should have, empathy. The ability of someone to put themselves in someone else’s shoes to understand their aspirations, motivations, needs, and problems. People I had the opportunity to talk to about the essential characteristics of a product manager know how important I consider empathy to be a critical trait for successful PMs.

Here are 2 tips to help product team members empathize with so-called top-down decision-makers and escape the top-down trap:

  • Understanding the situation: Put yourself in the place of the solution implementation requester. People solve problems, it is their nature, and whenever they encounter a problem, they jump into solution mode and try to find and implement solutions as quickly as possible. Under greater pressure, such as the COVID-19 crisis, the desire to find and implement solutions is exacerbated. In most cases, people do not want to be top-down decision-makers, they simply have a need to solve the problem as quickly as possible.
  • Changing the status quo: ask questions about the solution implementation request. What problem are we solving? For whom? Why is it important to solve this problem? Why now? Why do we need to deliver something fast, even while compromising quality? If you are asked the reason for so many questions, explain that you are trying to better understand the problem to see if there are other cheaper and faster to implement solutions.

These tips will help everyone on the product team make the move to a more collaborative decision-making process.

Most of the time, people understand the benefits of a collaborative decision-making process. Even under pressure, collaborative solutions will produce better results. Solutions designed in a collaborative process are usually cheaper and faster to implement because more people have had a chance to discuss solution options and the team that will implement the selected solution will be truly committed to your success.

To build, maintain and improve problem solving teams and avoid turning them into solution implementation teams, especially when under greater pressure, it is essential to avoid the top-down trap.

Heads of product have the role and responsibility to promote these behavioral changes to help build a more collaborative and, consequently, more effective decision-making process.

Summing up

  • 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 by 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.
  • Product heads have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

In the next chapter, we will understand more about the focus on delivering results.

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