Feedback e avaliação de desempenho

Uma das principais ferramentas para desenvolvimento das pessoas do seu time é o feedback. Essa palavra é um termo inglês que originalmente significa “retroalimentação”, ou seja, um processo em que as ações de um determinado sistema são inseridas de volta no sistema para o aprimoramento do próprio sistema. Na gestão de pessoas, o feedback é quando uma pessoa conta para outra como seu comportamento e suas ações foram percebidos por essa pessoa. Feedback pode ser dado por pares, por subordinados ou por líderes.

Feedback

Como líder, é muito importante você dar feedback sempre que necessário para as pessoas que trabalham com você. Seis aspectos são essenciais para que o feedback possa ser o mais útil e relevante possível:

  • Ser necessário: antes de dar um feedback, é importante entender se ele é necessário. O que a pessoa fez afeta o resultado negativamente? Ou é somente uma forma diferente de fazer o que precisa ser feito? Às vezes, damos feedback sobre algo porque foi feito de uma forma diferente do que esperávamos, mas não necessariamente gerou resultados ruins. Se o resultado foi atingido no mesmo tempo, de uma forma aceitável, precisamos aceitar essas diferentes formas de se fazer as coisas e de se obter os resultados.
  • Na hora: é importante dar o feedback o mais próximo possível do momento em que a situação sobre a qual você quer dar feedback aconteceu. Dessa forma, os detalhes sobre o ocorrido e as motivações que levaram as pessoas a agirem da forma como agiram estarão frescos na memória de todos.
  • Objetividade: ao conversar sobre o que aconteceu, seja objetivo, ou seja, vá direto ao ponto e baseie seu feedback em fatos. O seu feedback deve ser útil para a pessoa que está recebendo, ele deve dar claras indicações sobre o comportamento esperado para aquela situação.
  • Transparência: o feedback tem que ser transparente, não pode haver aspectos escondidos ou não ditos, contanto que sejam aspectos relevantes para aquele feedback.
  • Empatia: ser transparente e objetivo não significa ser rude. Ao contrário, o feedback tem por objetivo ajudar a pessoa a entender como suas ações e seu comportamento impactam as outras. Coloque-se no lugar dessa pessoa que vai receber esse feedback e pense em como você gostaria de recebê-lo para que ele seja o mais útil possível.
  • Privado: procure dar o feedback em um ambiente privado, para dar espaço e liberdade para uma conversa transparente e produtiva.

Características de uma boa gestora de produtos

Eu costumo avaliar gestores de produtos em relação a 7 principais características:

Empatia: é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará a gestora de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto. Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. A gestora de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas.

Comunicação: para poder ter empatia, é necessário que a gestora de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, apresentações que podem ser internas (dentro da empresa) ou externas (em conferências, grupos de usuários etc.). Porém, não é só de falar que vive o gestor de produtos. Comunicação é uma via de mão dupla, ou seja, a gestora de produtos tem de ser muito boa em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

Gestão do tempo: o dia a dia de uma gestora de produtos pode se encher rapidamente de tarefas e ela precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto.

Novas tecnologias: o gestor de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?

Habilidades empresariais: o gestor de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, a receita e os custos estão sob controle? Se o objetivo for só receita, como está o crescimento dela? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, o gestor de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta no departamento jurídico? E como o departamento jurídico impacta no produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.

Curiosidade aguçada: a gestora de produtos precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).

Tema do produto: por fim, mas não menos importante, a gestora de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, o gestor de produtos deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. A gestora de produtos do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto o gestor de produtos da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Gestor de produtos precisa saber programar?

Essa é uma pergunta razoavelmente polêmica. Como dito, a depender do tema do produto, é importante saber programar, principalmente se aquilo de que o gestor de produtos cuida é um produto mais técnico. Alguns exemplos da Locaweb são Hospedagem de Sites, Cloud Server e SMTP. Contudo, mesmo empresas que não “vendem” um produto técnico podem ter uma parte de seu produto com um viés mais técnico. Na Conta Azul tínhamos as APIs, as integrações com fintechs (Iugu e Stoce) e a integração com as Secretarias da Fazenda para emissão de nota fiscal, e no Gympass toda a parte de integração com sistemas de gestão de academias e com sistemas de RH. Para esses produtos, é importante ter um gestor de produtos com conhecimento de técnico, uma vez que o principal usuário do produto será técnico e o objetivo do produto é um objetivo técnico.

Por outro lado, um produto como Lova Virtual, o app do Gympass ou o portal de busca de imóveis da Lopes são produtos feitos para qualquer pessoa utilizar. Será que para esses produtos seria bom o gestor de produto ter conhecimento técnico, ou seja, saber programar? Na minha visão, não é essencial que o gestor de produtos tenha conhecimento técnico, mas certamente vai ajudar. O conhecimento técnico ajuda a entender como o produto é feito, e isso o ajudará a ser um gestor de produtos melhor. Ajuda a entender o trabalho feito pelo time de engenharia e pode ser útil nas decisões sobre priorização e escopo. Duas analogias que podem ajudar a entender melhor o benefício que saber programar traz para um gestor de produtos:

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

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

SQL

Se o gestor de produtos ainda não sabe, deve aprender SQL. Acesso aos dados está cada vez mais democrático nas empresas e saber SQL é fundamental para que o gestor de produtos possa usufruir dos dados de maneira independente, sem precisar ficar pedindo para outras pessoas criarem seus gráficos e dashboards. Quando colocamos o Metabase como solução de democratização dos dados na Conta Azul eu fiquei tão animado que passei uma semana inteira indo dormir às 2:00 da manhã, pois ficava criando gráficos e dashboards para entender melhor como os produtos do Conta Azul eram utilizados.

Avaliação de desempenho

Muitas empresas utilizam a avaliação de desempenho como a ferramenta oficial da empresa para coletar e registrar o feedback dos seus funcionários. Líderes avaliando as pessoas do seu time. Pessoas avaliando os seus pares e seus líderes. Pessoas fazendo autoavaliações.

Algumas empresas utilizam a matriz 9-box que tem duas dimensões:

  • Desempenho: análise do passado, dos resultados entregues por aquela pessoa. Aqui, mais do que o resultado em si, é importante levar em conta o papel da pessoa no atingimento desse resultado, principalmente se considerarmos resultados de um time de desenvolvimento de produtos, que são um resultado de equipe.
  • Potencial: análise do futuro, ou seja, o quanto a pessoa está preparada para lidar com novos desafios. Literalmente, potencial significa “ter ou mostrar a capacidade de se tornar ou se desenvolver em algo no futuro”. Como dá para perceber, essa dimensão de avaliação de uma pessoa pode ser bastante subjetiva. Por esse motivo, algumas empresas têm substituído o potencial por cultura, ou seja, uma análise de como os resultados foram atingidos por aquela pessoa, e se estão alinhados com os valores da empresa. Tende a ser um pouco subjetivo também, mas um pouco menos do que potencial.

Líderes fazem a avaliação de seus liderados com base nessas duas dimensões. Em algumas empresas, essas avaliações incluem, com um peso menor, a autoavaliação, as avaliações de pares, clientes internos e, caso a pessoa lidere um time, de seus liderados. É a avaliação 360º. Em outras empresas, a autoavaliação e as avaliações de pares, clientes e liderados servem como dados adicionais para o líder fazer a avaliação, mas não entram no cálculo da avaliação.

Depois de feita a avaliação, normalmente se faz um processo de calibração, onde os líderes comparam a avaliação de seus liderados para entender se os critérios de avaliação usado por cada líder está equalizado. Esse processo todo de avaliação é liderado e coordenado pelo time de RH da empresa, e essa calibração é facilitada por alguém do RH. As pessoas avaliadas são plotadas na matriz 9-box e com isso tem-se um mapa das pessoas da empresa.

Matriz 9-box e seus quadrantes

Com essa avaliação calibrada em mãos, o gestor retorna para o liderado e então se inicia o trabalho de gestão de consequências, que é trabalho que precisa ser feito após o liderado receber sua avaliação:

  • Bem avaliados: pessoas que ficam em um dos 4 quadrantes superiores são as que foram bem avaliadas. Normalmente são as pessoas que são consideradas para aumentos e promoções. Normalmente elas ficam felizes com o feedback e se sentem motivadas a continuarem fazendo o trabalho da melhor forma possível. Contudo, se a autoavaliação da pessoa for superior à avaliação recebida, mesmo ela estando bem avaliada, há o risco de ela sentir alguma frustração. Isso só não acontece se ela for avaliada no quadrante superior direito da matriz 9-box.
  • Mal avaliados: pessoas que ficam em algum dos 3 quadrantes da esquerda ou algum dos 3 quadrantes superiores estão abaixo do esperado em desempenho e/ou em potencial (ou valores, se na empresa houve a decisão por trocar esse eixo da matrix 9-box). Essas pessoas precisarão fazer algo para serem bem avaliadas no próximo ciclo. Essa situação pode causar certo desconforto na pessoa avaliada por ela sentir que seu emprego pode estar em risco. Para algumas pessoas, essa situação pode servir de incentivo para ela buscar melhorar e, de fato, ser melhor avaliada no próximo ciclo. Por outro lado, algumas pessoas podem se sentir desmotivadas com essa avaliação e decidem procurar alguma oportunidade em outra empresa. Esta situação se agrava se a pessoa se autoavaliou melhor do que a avaliação que recebeu.

Crítica ao processo de avaliação de desempenho

O processo de avaliação de desempenho procura classificar os funcionários de uma empresa com o intuito de facilitar o entendimento de quem são as melhores pessoas e quem são as pessoas que precisam melhorar. Contudo, como expliquei acima, há muitas oportunidades para frustração nesse processo de avaliação, especialmente quando há discordância entre a autoavaliação e a avaliação recebida. Essa frustração normalmente é potencializada pelo fato de o processo de avaliação ser passível de:

  • subjetividade: como medir o potencial de uma pessoa? Como medir sua aderência aos valores da empresa? Como medir sua participação no atingimento dos resultados?
  • bias: distorção em função de diversos aspectos do julgamento do avaliador em relação ao avaliado. Normalmente, o avaliador lembra das ações mais recentes de um avaliado. É comum ações com consequência negativa serem percebidos de forma mais intensa do que ações com consequência positiva.

Além disso, estamos entendendo e respeitando cada vez mais a diversidade humana, não só em questões físicas e de preferências, como também a diversidade de perspectiva, de história e de contexto. Tendo essa maior clareza sobre a diversidade humana, torna-se cada vez mais complicado encaixar todos as pessoas de uma empresa em somente 9 caixas baseadas em duas dimensões (potencial vs. resultados). Para entender melhor a complexidade das pessoas que compõem uma empresa, provavelmente precisaremos pensar de forma multidimensional.

Por esses motivos, existe uma tendência mundial de abandonar o processo de avaliação de desempenho periódico e substituí-lo por conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores. Segundo algumas estimativas (https://hbr.org/2016/10/the-performance-management-revolution), mais de um terço das empresas americanas já abandonaram o processo de avaliação de desempenho periódico e adotaram essas conversas mais frequentes como alternativa.

Retrospectiva, alternativa ao processo de avaliação de desempenho

Em adição às conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores, acho importante a cada 6 meses fazer uma retrospectiva junto com o liderado sobre o que aconteceu nesse período. Da mesma forma que em desenvolvimento de produtos temos cerimônias de retrospectiva, é um momento de revisitar o que passou e avaliar o que foi bem, o que pode melhorar e os desafios pela frente.

Eu faço uma primeira versão, baseado no histórico que tenho com a pessoa. Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, uso essa oportunidade para fazer a retrospectiva e considero todas informações geradas através desse processo, autoavaliação, avaliação de pares, clientes internos e de liderados, se houver.

Essa primeira versão tem 3 seções, pontos fortes, pontos a melhorar e desafios do próximo semestre, que contempla não só os principais objetivos para o próximo semestre como também foco nos pontos de melhoria. Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, coloque minha sugestão inicial de classificação nos quesitos mensurados nesse processo formal.

O próximo passo é usar uma das reuniões de 1:1 para conversar com o liderado sobre essa retrospectiva, ouvir como ele a enxerga e, eventualmente, ajustar a retrospectiva de comum acordo com ele. É um excelente momento para ter uma conversa mais ampla e uma reflexão conjunta sobre o semestre que passou e sobre o que vem pela frente.

Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, faço essa conversa antes de inserir os dados no sistema de avaliação da empresa, pois acho importante a avaliação conter essa retrospectiva construída em conjunto com o liderado. Caso haja sessões de calibração, aviso o liderado de que a avaliação ainda pode sofrer ajustes pela calibração e, após a calibração, conto de forma transparente o que aconteceu na calibração, para ajudar a pessoa a entender como outras pessoas a percebem.

EXEMPLO

Pontos fortes

O primeiro semestre foi particularmente difícil para Felipa, com muitas incertezas e uma enorme pressão de entrega do Projeto Avengers. Diante disso tudo, Felipa conseguiu navegar muito bem pela situação e encontrar boas soluções, inclusive recomendando uma aquisição de empresa, como também manteve sua tribo engajada no processo.

Pontos a melhorar

Seu time de PMs ainda é júnior, com pouca experiência de gestão de produtos, apesar de ter bom conhecimento técnico do tema do produto. É importante buscar formas de acelerar essa senioridade do time.

Desafios para o próximo semestre

Deve trabalhar para aumentar senioridade de seus PMs pois eles ainda demandam bastante de seu tempo, impedindo-a de ter um papel mais estratégico.

Promoções e aumentos

No capítulo Contratar as pessoas certas comentei que, ao fazer a proposta para uma pessoa se juntar ao seu time, é importante balancear incentivo de curto prazo (salário e benefícios), médio prazo (bônus) e longo prazo (stock options e similares). De tempos em tempos, enquanto essa pessoa estiver no seu time, é importante avaliar se esses incentivos precisam ser revistos, ou seja, se ela merece um aumento ou uma promoção. Há dois aspectos importantes a considerar, quando e como dar aumentos e promoções.

Quando

É comum empresas que definem um período do ano para promoções e aumentos, normalmente logo após o período de avaliação de desempenho ou da retrospectiva periódica. Recomendo não fazer isso, pois na hierarquia de necessidades da maioria das pessoas, a necessidade por reconhecimento e recompensa financeira vem antes da necessidade por desenvolvimento pessoal. Sendo assim, se em uma mesma conversa colocarmos o tema sobre promoções e aumentos junto com o tema feedback e que pontos ela precisa para melhorar, a atenção da pessoa estará muito mais voltada ao tema promoções e aumento. Por esse motivo, recomendo separar essas duas conversas. Quando conversar sobre promoção e aumento, foque apenas nesse tema. E quando conversar sobre retrospectiva, novamente foque apenas nesse tema.

Como

Existem duas formas de promover uma pessoa. A primeira forma é esperar que ela esteja demonstrando habilidades de, pelo menos, 70% do próximo nível de carreira para promovê-la. É o que chamo de “promoção empurrada”, ou seja, ela deve empurrar para conseguir sua promoção. A outra forma é avaliar o potencial da pessoa, ou seja, se ela tem a capacidade de desenvolver as habilidades necessárias para operar no próximo nível de carreira e, se ela tiver, promovê-la. Chamo essa forma de “promoção puxada” pois a pessoa é puxada para operar no nível de habilidade do próximo nível de carreira.

Tenho preferência pelo modelo de promoção puxada, pois gera um desafio bastante motivador para a pessoa, que sentirá que está devendo as habilidades necessárias e vai correr para desenvolvê-las o mais rápido possível. Há, obviamente, o risco de ela não conseguir desenvolver essas habilidades mas, na maioria dos casos, vejo que pessoas com potencial normalmente conseguem desenvolvê-las bem rápido. Já na promoção empurrada, a principal vantagem é que não há risco, a pessoa que é promovida já demostra as habilidades necessárias. Contudo, exatamente por já apresentar as habilidades necessárias, essa pessoa pode achar que a promoção não vem, ou está demorando muito e pode querer olhar o mercado aumentando o risco de você perdê-la do seu time, por demorar a dar o seu reconhecimento.

Resumindo

  • Seis aspectos essenciais para um bom feedback são: checar se o feedback é necessário, dá-lo na hora em que acontece, ser objetivo, ser transparente, ter empatia e dar o feedback em privado.
  • As sete principais características de um bom gestor de produto são empatia, comunicação, capacidade de gestão do tempo, conhecimento de novas tecnologias, habilidades empresariais, curiosidade aguçada e conhecimento sobre o tema do produto.
  • Se o produto não for um produto técnico, não é necessário saber programar. Contudo, ter alguma noção de programação pode ser útil para entender como seu produto funciona. Saber SQL também é útil, pois ajudará a gestora de produtos a entender melhor as métricas de seu produto.
  • Processos formais de avaliação de desempenho têm sido vistos cada vez mais pelas empresas como algo que não traz tantos benefícios como esperado. Várias empresas estão substituindo esse processo por conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores.
  • Retrospectiva semestral é uma boa forma de ter uma conversa estruturada com o liderado sobre os resultados atingidos e como eles foram atingidos, e sobre os desafios que estão por vir. Essa retrospectiva deve ser construída em conjunto com o liderado. Caso haja um processo formal de avaliação de desempenho na empresa onde você estiver trabalhando, use o processo de retrospectiva para criar a avaliação de desempenho.
  • Sobre promoções e aumentos, há dois aspectos a considerar, quando e como. Recomendo separar as conversas de aumento e promoção das conversas sobre feedback para manter o foco total no tema de cada uma dessas conversas. Recomendo também promover a pessoa quando ela apresenta o potencial de desenvolver as habilidades necessárias para ocupar o próximo nível de carreira, e não esperar que ela já demonstre as habilidades necessárias para esse próximo nível de carreira, pois isso vai motivar mais a pessoa.

No próximo capítulo vamos conhecer as cerimônias que costumo usar com os times que eu lidero.

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:

Contratar as pessoas certas

Como comentei no capítulo Pessoas: prioridade nº 1, sempre nós 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. E o primeiro passo para ter as melhores pessoas no seu time é a contratação.

O trabalho de contratação de pessoas deve ser feito em conjunto com o RH. É um trabalho em equipe. Já vi situações em que esse processo é totalmente delegado para o time de RH, e a pessoa que está contratando fica apenas perguntando “cadê os candidatos?” e “por que o RH está demorando tanto para preencher essa vaga?”. Definir perfil, encontrar candidatos, entrevistar, selecionar, fazer onboarding é tanto responsabilidade do RH quanto do head de produto e de seu time.

Definir o perfil

O primeiro passo para contratar as pessoas certas para o seu time é definir o perfil de quem você está procurando para se juntar ao time. Quando falo de perfil, estou pensando não só em conhecimento técnico como também em senioridade comportamental e fit cultural, ou seja, que valores a pessoa precisa ter para trabalhar nesse time. É importante construir esse perfil em colaboração com mais pessoas do time. Desse perfil, sairá a descrição da vaga, ou job description em inglês.

Atrair candidatos

Tendo o perfil definido, é preciso anunciar a vaga a trazer candidatos. É o trabalho de atração de pessoas. Aqui o marketing pode ajudar. Da mesma forma que precisamos contar ao mundo sobre o problema que resolvemos com nossos produtos e como o produto o resolve para encontrar as pessoas certas que terão interesse em virar nossos clientes, precisamos contar ao mundo sobre o tipo de pessoa que precisamos em nosso time.

Para isso, é importante fazer um trabalho de employer branding, que é contar por que a sua empresa é uma empresa interessante na qual trabalhar. Contar nas redes sociais e em eventos sobre os trabalhos feitos pelo time, os desafios e as conquistas, como é o ambiente e a cultura do time. Isso tudo faz parte do employer branding e ajuda a atrair pessoas interessadas em trabalhar no seu time de desenvolvimento de produto. Esse é um trabalho feito em parceria entre RH, marketing e o time de desenvolvimento de produto.

Outra excelente fonte de novas candidaturas são as indicações internas. Peça para as pessoas do time indicarem pessoas com quem trabalharam em outros lugares e com quem eles gostariam de trabalhar de novo. É possível inclusive incentivar essas indicações dando prêmios para quem indicou caso a pessoa indicada seja contratada.

Entrevistar

É importante ter a sequência de entrevistas bem definida. Quem são as pessoas que vão entrevistar? Em que ordem? Serão entrevistas individuais ou em grupo? Haverá resolução de caso? Normalmente, nas empresas em que trabalhei, a primeira entrevista é feita pelo RH, para apresentar a vaga e a empresa e para entender um pouco mais do perfil comportamental da candidata. O RH pode usar algum teste comportamental para isso.

Em seguida, vêm as entrevistas com as pessoas do time de desenvolvimento de produto. Se for uma contratação para uma posição que vai interagir bastante com outras áreas da empresa, é importante que a candidata também seja entrevistada por pessoas dessa outra área. Normalmente sugiro que o líder direto seja o primeiro a entrevistar, em seguida que a pessoa seja entrevistada por pares do time de desenvolvimento de produto e de outras áreas, se for o caso.

Se a pessoa for liderar um time, sugiro a oportunidade de algumas pessoas do time também entrevistarem. Apesar de deixar o processo mais longo, acho interessante mais pessoas entrevistarem por dois motivos: primeiro, dá a oportunidade de mais gente conhecer os candidatos e, quando a decisão for tomada, mais pessoas estarem comprometidas com o sucesso desse novo membro do time; segundo, dá a oportunidade de a candidata conhecer melhor a empresa e as pessoas que compõem o time.

Uma dica importante para quem entrevista é procurar fazer as mesmas perguntas para todos os candidatos, assim você poderá comparar as respostas para escolher aquela que mais se encaixa no perfil que você está buscando. Em relação a que tipo de perguntas fazer, costumo ouvir a história da pessoa e perguntar sobre acertos, erros, relação com outros membros do time e com pessoas de outras áreas.

Durante o processo de entrevistas, pode ser interessante pedir para a candidata resolver um problema em casa para depois ela apresentar a solução. Esse processo é bastante comum tanto em vagas de gestão de produto, como de UX e de engenharia. O objetivo desse teste é conhecer melhor a capacidade de resolução de problemas, bem como de apresentação de soluções. E essa apresentação da solução é uma boa oportunidade para entender como a pessoa se expressa e como ela lida com questionamentos.

Acho interessante o caso a ser resolvido ser um caso prático da empresa, em que o time está trabalhando ou pretende trabalhar em algum momento. Já ouvi críticas de que isso é consultoria gratuita e que depois a empresa vai usar a melhor solução. É importante deixar claro que a resolução de case tem dois objetivos, dar a oportunidade de as pessoas que estão contratando conhecerem melhor o candidato, como ele resolve problemas e apresenta suas soluções, assim como dar ao candidato a oportunidade de conhecer que tipo de problemas ele vai encontrar no dia a dia.

Vale ressaltar que ao pedir uma resolução de caso, há o perigo de perder candidatos. Por isso, é importante deixar claro que o processo terá essa fase, e é importante encantar o candidato antes de apresentar o caso a ser solucionado para deixá-lo com vontade de resolver o caso.

Como comentei, esse é um processo longo, com várias entrevistas e testes, o que pode fazer você perder boas candidaturas. Por isso, é importante manter esse processo atraente, contar à candidata como ela está indo, em que fase ela está e o que falta para chegar ao final do processo. Já ouvi relatos de empresas que conseguem fazer esse processo todo em um dia, chegando ao final do dia com candidatos recebendo uma proposta, mas nunca tive a oportunidade de presenciar um processo assim.

Escolher e fazer a proposta

Após as entrevistas e os testes, chegou o momento de escolher a melhor candidata. A melhor forma de fazer isso é juntando as pessoas que entrevistaram os candidatos para contarem suas impressões sobre cada um, assim a líder da vaga pode tomar a decisão sobre quem escolher. A decisão de quem contratar é da líder que tem a vaga aberta, mas esse momento para trocar percepções é importante. Costumo chamar essa reunião de comitê de contratação, que dá a oportunidade não só de escolher o melhor candidato, como de entender melhor como as pessoas estão fazendo o processo de entrevista e, eventualmente, alinhar alguns pontos em relação a esse processo. Isso deixa os membros do time mais engajados com o sucesso da pessoa que será contratada.

Uma vez definida quem é a pessoa, é preciso desenhar a proposta que será feita para ela. É importante que a proposta seja financeiramente relevante. Não é comum a pessoa aceitar receber menos do que ela está recebendo atualmente. E é importante balancear incentivo de curto prazo (salário e benefícios), médio prazo (bônus) e longo prazo (stock options e similares). Cuidado para não fazer uma oferta que seja muito discrepante com o que as pessoas atuais do time já têm, para não criar diferenças que podem minar o trabalho em equipe.

Onboarding

Supondo que a candidata aceitou a proposta, chegamos a uma nova fase do processo, o de onboarding, ou seja, o de trazer a pessoa para o time e fazê-la parte desse time. O RH vai cuidar da parte mais burocrática desse processo, mas é preciso também desenhar com o RH todo o onboarding para garantir que a contratada se sinta acolhida e entenda mais sobre a empresa, o time e os desafios que ela terá pela frente.

Na Conta Azul tínhamos um processo muito bacana de onboarding, coordenado pelo RH, onde todos os novos funcionários passavam por uma semana de imersão para conhecer todas as áreas da empresa e os principais membros dessas áreas. Em seguida, as pessoas tinham um onboarding local, no time do qual elas fariam parte. No Gympass, além do onboarding, todas as pessoas eram convidadas a participar de algumas ativações, que era o momento em que íamos a um cliente para apresentar o benefício do Gympass para seus funcionários. É importante dar à nova pessoa que está entrando no time a oportunidade de conhecer mais sobre as outras áreas da empresa e sobre o cliente, antes de ela começar a trabalhar.

Conversas do RH com a pessoa após 45 e 90 dias que a pessoa foi contratada podem ajudar a perceber pontos de melhoria nesse processo de onboarding. Esses primeiros dias da pessoa no seu novo time são fundamentais para o sucesso da relação futura, por isso é importante monitorar de perto.

Feedback

O título deste capítulo é Contratar as pessoas certas, mas não basta só contratar, é preciso também cuidar das pessoas durante todo o tempo que ela estiver no time.

Escrevi um capítulo inteiro sobre Feedback e avaliação de desempenho, mas quero pontuar aqui, pois feedback é algo muito importante para as pessoas que fazem parte do seu time. Como elas poderão saber que estão no caminho certo? No que elas podem melhorar? O que eles estão fazendo e que devem continuar fazendo? O que elas não estão fazendo e que deveriam fazer? O que elas estão fazendo e que elas deveriam parar de fazer?

É muito importante deixar claro para cada pessoa do seu time sobre esses pontos. E é muito importante lembrar que feedback é uma via de mão dupla, ou seja, você também deve procurar saber o que você pode fazer para ajudar a pessoa.

Encerrando um ciclo

Eventualmente você pode tomar a decisão de desligar alguém, o que é conhecido como turnover involuntário, ou alguém do seu time pode tomar a decisão de sair do seu time, o turnover voluntário. Esse sempre é um momento difícil, de ruptura, mas importante entender os motivos que acabaram fazendo chegar nessa decisão. Poderia ser evitado? Se inevitável, poderia ter acontecido de uma maneira mais planejada, evitando disrupção para o time?

Resumindo

  • O trabalho de contratação de pessoas deve ser feito em conjunto com o RH. É um trabalho em equipe.
  • As fases da contratação são definir o perfil, atrair candidatos, entrevistar, escolher e fazer a proposta, onboarding.
  • O ciclo de vida de uma pessoa no seu time não termina no onboarding. É importante constantemente dar e receber feedback dela, para garantir que o relacionamento funcione bem tanto para o time quanto para a pessoa nova no time.
  • Por fim, a última fase do ciclo de vida da pessoa no time é quando a pessoa sai do time. É preciso entender os motivos que levou a essa decisão para entender como esses temas podem ser trabalhados no futuro.

No próximo capítulo, vamos entender como fazer feedback e gestão de desempenho.

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:

Relacionamentos

Como comentei no capítulo Papéis, responsabilidades e senioridade, o gerenciamento de expectativas é algo que ocupa entre 50 a 80% do tempo de uma head de produto. Seu dia a dia gira em torno de seus relacionamentos e interações com muitas pessoas dentro e fora de sua organização que têm interesse no produto que você lidera. No jargão corporativo, essas pessoas são chamadas de stakeholders:

Nas últimas décadas do século 20, a palavra stakeholder tem sido cada vez mais usada para significar uma pessoa ou organização que tem um interesse legítimo em um projeto ou entidade. Ao discutir o processo de tomada de decisão para instituições – incluindo grandes empresas, agências governamentais e organizações sem fins lucrativos – o conceito foi ampliado para incluir todos com interesse (ou “stake“, palavra em inglês que significa participação) no que a entidade faz.

Fonte: https://en.wikipedia.org/wiki/Stakeholder_(corporate)

Evolução do uso da palavra “stakeholder” na literatura (fonte: Google Books)

Uma gestora de produtos com alguma experiência sabe da importância de manter bons relacionamentos com os stakeholders do produto. Vou compartilhar aqui duas ferramentas que ajudam a mapear melhor esses stakeholders e como deve ser seu relacionamento com cada um deles.

RASCI

RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função. É a abreviação das primeiras letras dos possíveis papéis que uma pessoa, área ou função pode ter em uma tarefa:

  • Responsible (encarregado): é a pessoa responsável pela execução da tarefa, ou seja, quem tem de liderar o esforço de planejar, fazer e concluir a tarefa. Não pode existir mais de um responsável por tarefa. É aquela máxima de que cachorro com dois donos morre de fome.
  • Accountable (responsável): é a pessoa que responde pela tarefa e que tem o poder de delegar para o responsible a tarefa a ser feita. Responsible e accountable podem ser a mesma pessoa. Também vale a regra de que não pode existir mais de um accountable por tarefa. Se responsible e accountable são duas pessoas diferentes, o accountable pode ser visto como o patrocinador.
  • Support (suporte): são as pessoas ou equipes que trabalham junto e sob a coordenação do responsible para a execução da tarefa.
  • Consulted (consultado): são as pessoas ou equipes que não participam da execução da tarefa, mas que precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, pois elas podem dar inputs relevantes para sua execução.
  • Informed (informado): são as pessoas ou equipes que não participam da execução da tarefa, nem precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, mas que precisam ser informadas quando a tarefa for concluída.

A seguir, está um exemplo de uma matriz de responsabilidade RASCI entre engenharia, UX, marketing de produtos e gestão de produtos que usamos na Locaweb:

Matriz de responsabilidade RASCI da Locaweb

Como usar

O primeiro passo é fazer a matriz de responsabilidades. Minha recomendação é preencher essa tabela juntando todas as pessoas envolvidas em uma sala, assim pode-se discutir se a divisão de responsabilidade está boa para todos e se tem alguma tarefa faltando. Muito provavelmente, vão surgir algumas “bolas divididas”, mas esse é um ótimo momento para discuti-las e definir quem é o responsável.

Em seguida, deve-se experimentar fazer as tarefas seguindo a matriz responsabilidade por algum tempo, tipo um ou dois meses. Depois, é importante fazer uma retrospectiva para ver se está tudo certo, ou se é necessário algum ajuste.

Daí para a frente, o uso passa a ser automático e as pessoas não precisarão mais se referir à matriz de responsabilidades. A cada 1 ano ou quando surgir alguma dúvida, ou mesmo quando surgir alguma tarefa nova, é bom revisitá-la.

Matriz de poder-interesse

A matriz de poder-interesse (do inglês Power-Interest Grid) é um conceito desenvolvido pela primeira vez na década de 90 por Aubrey L. Mendelow, e posteriormente explicado no livro, Making Strategy: Mapping Out Strategic Success, de Fran Ackermann e Colin Eden. Com base no poder e no interesse que uma pessoa ou equipe tem em seu produto, você pode classificá-los em 4 categorias principais.

Matriz de poder-interesse
  • Os atores principais são os que têm grande poder e interesse no seu produto. Você precisa colaborar frequentemente com eles. Os usuários e clientes do seu produto são atores principais, você precisa colaborar com eles para construir o melhor produto que resolva seus problemas e atenda às suas necessidades. Em algumas empresas, provavelmente o fundador mais próximo do produto também é um ator principal. Você deve convidar essas pessoas para qualquer reunião e dinâmica em que decisões estratégicas sejam tomadas. Agende individualmente para apresentar as decisões e pedir seus comentários e contribuições.
  • As pessoas são aquelas com pouco poder, mas alto interesse em seu produto. Eles não têm o poder de vetar ou alterar decisões, mas têm um profundo interesse em seu produto. Em algumas empresas, podemos pensar no suporte ao cliente, vendas e marketing como exemplos de áreas que desempenham o papel de pessoas. Elas têm grande interesse, mas não têm o poder de mudar seu produto. Você pode se comunicar com eles por e-mail semanal de status e demonstrações de produtos. É importante coletar suas opiniões, mas lembre-se de que eles não têm o poder de mudar suas decisões.
  • Os definidores de contexto são aqueles com poder de mudar seu produto, mas pouco interesse em seu produto. Exemplos de áreas que podem desempenhar uma função de definidor de contexto são RH e Jurídico. Se o RH não ajudar você a formar a equipe, você não terá uma equipe para construir seu produto. Se o Departamento Jurídico não estiver ciente e alinhado com os aspectos legais de seu produto, ele tem o poder de bloquear ou atrasar seu lançamento. Um CFO e um controlador também são duas funções que têm o poder de mudar decisões que afetam seu produto. É importante manter os definidores de contexto bem informados sobre as decisões do produto. Consulte-os antes de tomar decisões importantes. Mantenha-os informados semanalmente.
  • A multidão é quem tem baixo poder e pouco interesse. Mesmo que eles tenham pouco poder e interesse, é importante mantê-los informados. Normalmente, uma atualização mensal sobre o andamento do produto é suficiente. Pode ser por e-mail ou em uma reunião geral mensal com demonstrações de produtos como vou comentar mais adiante. Normalmente são as pessoas das áreas de RH, Jurídico, Administrativo e Financeiro que não estão no grupo de definidores de contexto.

É importante observar que cada empresa tem sua própria dinâmica, portanto, uma área ou pessoa que desempenha uma função específica na matriz de poder-interesse de uma determinada empresa pode ter outra função em uma empresa diferente.

Empatia

Essas duas ferramentas são muito úteis para o head de produto poder entender melhor como se relacionar com seus stakeholders e como gerenciar suas expectativas, o que, como eu já disse, vai tomar de 50% a 80% de seu tempo.

A empatia é uma ferramenta fundamental para o head de produto poder gerenciar seus stakeholders. Como comentei no capítulo Desenvolvendo o time e gerenciando expectativas, empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os suas expectativas. Seus anseios, motivações, necessidades e problemas.

Essa característica é importante para que o head de produto entenda os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Também ajuda a entender o impacto de seu produto no seu time e nas pessoas de outras áreas. Por fim, mas não menos importante, o head de produto também precisa se colocar no lugar dos donos do produto, para entender suas expectativas e os resultados que ele trará para a empresa.

Resumindo

  • O gerenciamento de expectativas é algo entre 50 a 80% do tempo de um head de produto.
  • RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função.
  • A matriz de poder-interesse, juntamente com RASCI, é uma ótima ferramenta para ajudá-lo a entender melhor e interagir com seus stakeholders.
  • Mas não se esqueça, a principal ferramenta que um head de produto precisa para entender melhor e, consequentemente, ter interações aprimoradas e frutíferas com seus stakeholders é a empatia.

No próximo capítulo vamos entender mais sobre como contratar pessoas para o time.

Liderança de produtos digitais

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

Métricas

A essa altura você já deve ter percebido o quanto eu gosto de métricas. No meu primeiro livro, Guia da startup: como startups e empresas estabelecidas podem criar produtos de software rentáveis, eu dediquei 6 capítulos inteiros além de falar sobre métricas nos outros capítulos. No meu segundo livro, Gestão de produtos: como aumentar as chances de sucesso do seu software, são mais 5 capítulos dedicados ao tema de métrica, além de novamente esse tema aparecer em outras partes do livro. Aqui não é diferente, os dois últimos capítulos falaram bastante sobre métricas e tenho falado também em alguns outros capítulos sobre OKRs, objetivos, dados e resultados.

Métricas são ferramentas fundamentais para qualquer head de um time de desenvolvimento de produto. Sem métricas é impossível saber se o time está progredindo, evoluindo e cumprindo com sua missão. Contudo, é muito fácil se perder em quantidades enormes de métricas.

Neste capítulo quero compartilhar um pouco sobre como costumo trabalhar com métricas.

Tipos de métrica

Classifico métricas em 3 grandes grupos:

Internas

São as métricas que mostram como o time de desenvolvimento de produto está nesse momento e tem evoluído. Os dois capítulos anteriores mostraram as métricas de produtividade e de qualidade. São métricas que ajudam a head de produto e o time a entenderem como está o processo de trabalho e onde devem focar a energia para melhorar nessas métricas. Como podemos aumentar a produtividade? Como diminuímos a quantidade de bugs? Como garantimos a melhor performance do produto para nossos usuários?

Ainda dentro do tema métricas internas, existem outras mais “soft” mas também muito importantes para você entender a saúde do seu time de desenvolvimento de produto. São métricas que ajudam a entender se as pessoas estão felizes trabalhando nesse time, se estão alinhadas com a cultura e com o propósito do time e da empresa.

Uma métrica bastante simples de acompanhar é entrada, saída e tempo médio das pessoas do time a cada mês. Se saem mais pessoas do que entram, pode haver algum problema no time. Se as pessoas ficam poucos meses e depois vão embora, é mais um ponto de atenção. Você também pode rodar uma pesquisa de NPS (Net Promoter Score ou Índice Líquido de Promotores) com as pessoas do time periodicamente para entender se eles recomendariam trabalhar no seu time para outras pessoas e o porquê da resposta.

A seguir, há dois exemplos do Gympass. No primeiro está a evolução da quantidade total de pessoas do time mês a mês, com total de novos e total de pessoas que saíram, mostrando também quantas dessas saíram voluntariamente, ou seja, pediram para sair. No segundo está o eNPS (employee NPS ou NPS dos funcionários), que mostra se as pessoas estavam dispostas a indicar o time de desenvolvimento de produto do Gympass para os amigos virem trabalhar.

Evolução do time de desenvolvimento de produto do Gympass
NPS do time de desenvolvimento de produto do Gympass

De usuário

São as métricas que mostram que seu produto está sendo utilizado pelos usuários, ou seja, que ele está cumprindo seu objetivo. São as métricas de engajamento e de satisfação de seu usuário com o produto. Qual seria o engajamento ideal de seu usuário com o produto?

Na Conta Azul queríamos que o produto fosse a primeira janela que ele abrisse em seu browser de manhã e a última que ele fechasse à noite. Acompanhávamos quantidade de notas fiscais emitidas por usuário por semana e, por mês, qual o valor delas. No Gympass, acompanhávamos quantos usuários iam à academia por mês, qual a frequência de visita às academias e assim por diante. Na Lopes estamos acompanhando o uso pelos corretores do novo CRM que tem versão web e mobile. Queremos que eles usem pelo menos 4 vezes por semana e é esse número que acompanhamos.

Outra métrica de usuário que pode ser útil são as métricas de satisfação. Essa métrica tende a ser um pouco mais subjetiva, além de ser trabalhosa para medir. Você deve mandar todos os dias uma minipesquisa para uma parte de seus clientes. Por isso, antes de medi-la e acompanhá-la, recomendo acompanhar de perto o engajamento com o produto. Se o usuário está engajado, utilizando o produto na frequência esperada, há boas chances de ele estar minimamente satisfeito.

De negócio

São as métricas que mostram o time de desenvolvimento de produto está de fato entregando valor para o dono do negócio. Qual era o objetivo que a dona de negócio tinha para o produto? Aumento de vendas, diminuição de custos? Esses objetivos variam com o tipo de empresa onde está o produto digital. É uma empresa digital, uma empresa tradicional ou uma empresa tradicional nascida digital?

Na Conta Azul, como o produto vendido era o produto digital, as métricas de usuário e as métricas de negócio se misturam bastante. A quantidade de usuários que utilizam várias vezes por semana são aqueles que certamente vão continuar pagando a assinatura mensal e, consequentemente, continuarão gerando receita.

Já no Gympass, uma empresa tradicional nascida digital, e na Lopes, uma empresa tradicional, a receita existe sem a necessidade do produto digital. Então, o que o produto digital pode fazer para aumentar a receita ou para diminuir os custos? No Gympass, ao mesmo tempo que queríamos diminuir os custos de operação, automatizando a maioria das tarefas manuais, também utilizávamos o produto como potencializador de receita, ajudando o RH dos clientes e seus funcionários a entenderem e, consequentemente, se tornarem assinantes do serviço. Na Lopes, o foco principal é em aumentar as vendas, mas temos também um foco em como diminuir os custos de operação.

Um ponto importantíssimo acompanhar todos os meses é a comparação entre o valor entregue pelo produto digital – aumento de receita e diminuição de custo – e o custo de desenvolvimento de produto. O que se espera é que o valor entregue seja maior do que o custo de desenvolvimento. E gerenciar isso é papel do head de produto.

Acompanhando as métricas

Métricas podem ser diárias, semanais, mensais, trimestrais e anuais. Claro que, quanto maior o período de atualização, mais difícil é de entender o comportamento da métrica e tomar decisões sobre como impactá-la. Tenho preferência por métricas que podemos acompanhar diária e semanalmente. Com métricas semanais, em um trimestre temos 13 oportunidades de avaliar uma métrica, entender como podemos mexer nela e remover algum impedimento que esteja nos atrapalhando no atingimento de algum objetivo atrelado a ela. E as métricas diárias dão o pulso do negócio. Quanto novos usuários por dia? Quanto usuários cancelaram?

Na Locaweb sempre acompanhávamos esses números diariamente e, se algo estava fora do esperado, positiva ou negativamente, já buscávamos entender o que havia acontecido que havia impactado o número. Quando fazíamos algo com a intenção de mexer nesses números, tal como uma nova campanha de marketing ou de retenção, podíamos acompanhar esses resultados diariamente. É possível ainda medir com frequência ainda maior em caso de produtos com grande escala como, por exemplo, o Search do Google.

Por outro lado, há métricas que têm frequência maior mesmo, como o exemplo acima que dei de novas pessoas que entram ou saem em um time de desenvolvimento de produto. Mesmo com métricas mensais ou mesmo de periodicidade maior, recomendo fazer acompanhamento da parcial dessa métrica pelo menos semanalmente. Se você só acompanhar mensalmente, em um trimestre terá apenas 2 oportunidades de avaliar o andamento e corrigir o curso.

Resumindo

  • As métricas de um time de desenvolvimento de produto podem ser classificadas em 3 grandes categorias: internas, de usuário e de negócio.
  • Métricas internas mostram como o time está de saúde: as métricas de usuário mostram a relação de seu usuário com o produto e as métricas de negócio são aquelas que mostram se o produto está, de fato, entregando valor para o negócio.
  • Métricas devem ser acompanhadas com a maior frequência possível, no mínimo semanalmente. Mesmo se for uma métrica mensal, procure acompanhar as parciais semanais, ou mesmo diárias, dessa métrica, para dar maior oportunidade de agir mais cedo quando houver uma variação de curso.

No próximo capítulo vamos ver como gerenciar os relacionamentos com as diferentes áreas.

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:

Medindo e gerenciando a qualidade

Em 2015, decidimos extinguir a função de Quality Assurance (QA) de nossa equipe de desenvolvimento de produtos da Locaweb. Tínhamos 12 QAs, alguns com perfil de desenvolvedor e outros com perfil SysAdmin. Ao propor a extinção da função de QA, alguns dos QAs se tornaram devs, enquanto outros assumiram a função de administradores de sistemas. Os motivos que nos levaram a extinguir a função de QA da Locaweb são:

  • Quando existe uma função de QA separada da função de desenvolvimento de software, é comum ouvir frases como “a funcionalidade está pronta, agora está em fase de QA”, o que denota uma cultura de desenvolvimento de produto em cascata. Essa cultura pode aumentar consideravelmente o tempo de desenvolvimento e afetar negativamente a qualidade do software.
  • Quando há uma função de QA separada da função de desenvolvimento de software, também é comum ouvir frases como “por que o QA não detectou esse bug?”, o que denota uma cultura de encontrar os culpados. Essa cultura pode ser muito prejudicial ao engajamento e motivação da equipe e, consequentemente, impactar negativamente a qualidade do software.
  • A qualidade não deve ser preocupação de uma pessoa ou equipe, deve ser preocupação de todos os que estão trabalhando na criação do software.
  • A qualidade é um requisito não funcional, ou seja, que especifica um critério para avaliar o funcionamento de um produto digital, enquanto requisito funcional especifica um comportamento do software. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos de software não funcionais que são tão importantes quanto a qualidade. Mesmo assim, não há funções definidas para garantia de desempenho, garantia de escalabilidade, garantia de operabilidade e garantia de monitorabilidade. Por que a qualidade é o único requisito não funcional que tem uma função específica dedicada para garanti-la?
  • O controle de qualidade se concentra em garantir a qualidade do processo de desenvolvimento de software. Se uma função separada é necessária para garantir essa qualidade, por que não há necessidade de uma função separada para garantir a qualidade do processo de gestão de produto, o processo de design, o processo de marketing de produto, o processo de vendas, o processo financeiro de uma empresa?
  • Havia uma preocupação de que, se o próprio engenheiro agora tivesse que testar, as entregas demorariam mais para ficar prontas. Essa preocupação existia porque os engenheiros consideravam que seu trabalho estava concluído – e a entrega estava pronta – quando passavam a história para o QA testar. No entanto, o conceito de pronto do engenheiro está incorreto, pois ele acabou de passar a história para a próxima fase, o teste. Do ponto de vista do usuário, a história só está pronta quando o usuário pode usar o novo recurso. Portanto, o tempo que a entrega permanece no controle de qualidade ainda é o tempo de desenvolvimento, mesmo não estando mais nas mãos do engenheiro. E esse tempo fica ainda maior quando a história passa pelo controle de qualidade, mas é rejeitada e precisa voltar para a engenharia.

Quando entrei na Conta Azul, eles também haviam acabado de extinguir a função de QA, e os ex-QAs passaram a ser analistas de negócios, principalmente ajudando gerentes de produto.

Eu vi outras empresas também discutindo a necessidade de QAs e, em alguns casos, um debate acalorado emerge em torno deste tópico. No entanto, ter ou não ter QAs não deve ser o centro da discussão. Ter ou não ter essa função é a solução de um problema, normalmente referido como “como podemos melhorar a qualidade do nosso produto?”, e esse problema deve ser o centro da discussão.

Como podemos melhorar a qualidade do nosso produto?

Uma simples pesquisa no Google sobre qualidade de software produzirá toneladas de definições normalmente relacionadas ao atendimento de requisitos funcionais e não funcionais. Quando o software não atende a um requisito funcional ou não funcional, ele apresenta um defeito, um bug. Portanto, para melhorar a qualidade de um produto de software, precisamos trabalhar em duas coisas:

  • reduzindo seus bugs existentes;
  • não gerando novos bugs.

Uma boa maneira de controlar isso é ter uma medição semanal de seu inventário de bugs e novos bugs por semana e discutir isso todas as semanas com a equipe. Fizemos isso no Gympass. Definimos no início de cada trimestre qual é a meta para o inventário de bugs e a média de novos bugs por semana.

Quantidade total de bugs no Gympass

A imagem mostra a evolução do nosso estoque de bugs para o 2º trimestre de 2019. Iniciamos o trimestre com 215 bugs em nosso estoque e almejamos uma meta de menos de 166 ao final do trimestre, uma redução de quase 23%. Fechamos o trimestre com um estoque de 136 bugs, uma redução de 36%. Fizemos isso nos concentrando não apenas na resolução de bugs em nosso inventário, mas também no controle do número de novos bugs por semana.

Quantidade de novos bugs detectados por semana no Gympass

No primeiro trimestre de 2019, tivemos uma média de 26,2 bugs criados por semana. Durante o segundo trimestre, reduzimos essa média para 17,4 novos bugs por semana, para um total de 226 novos bugs durante o trimestre. Isso é uma redução de 33% no número de novos bugs por semana.

Isso parece uma melhoria muito boa, certo? Mas há muito espaço para melhorias aí. Deixe-me explicar a matemática do gerenciamento de bugs:

Se fomos capazes de reduzir nosso estoque de bugs de 215 para 136, isso significa que resolvemos pelo menos 79 bugs. No entanto, criamos 226 novos bugs (17,4 novos bugs por semana x 13 semanas) durante o trimestre. Resolvemos 79 + 226 = 305 bugs durante o trimestre, é muito trabalho de correção de bugs. Se tivéssemos gerado 90 novos bugs durante o trimestre, uma média de 6,9 novos bugs por semana, em vez dos 226 novos bugs, poderíamos ter zerado o inventário de bugs.

Um aspecto adicional da resolução do bug a ser medido é o SLA (Service Level Agreement) de resolução, ou seja, quantos dias a equipe levou para resolver um bug a partir do dia em que o bug foi identificado pela primeira vez. Para isso, classificamos os bugs pela sua gravidade, que é o impacto que causa aos usuários e ao negócio. Os bugs de maior gravidade são aqueles que precisamos resolver no mesmo dia; erros de alta gravidade, em 7 dias e média de gravidade, em 14 dias. O gráfico a seguir mostra como estávamos no Gympass no quarto trimestre de 2019.

SLA de resolução de bugs no Gympass

Essa não é a visualização ideal porque mostra apenas uma imagem do momento, e não uma evolução. Para entender a evolução de qualquer métrica, você precisa ver como ela se saiu em diferentes pontos no tempo.

Assim que me juntei à Lopes, comecei a trazer esse tema para a discussão com os times. Uma das coisas que notamos é que 50% dos itens “deploiados” era correção de bugs. Fui informado de que “esses bugs eram pegos antes de ir para produção, o que é algo bom”. De fato, ainda bem que esses bugs não chegaram ao ambiente de produção e apareceram para nossos usuários. Contudo, eles chegaram à pré-produção e precisavam ser corrigidos. Não seria melhor se esses erros nem sequer existissem, nem mesmo em pré-produção?

Os OKRs que definimos para nos ajudar com o tema qualidade foram 3 KRs adicionais no objetivo de Aumentar a cadência de deploys em produção que comentei no capítulo anterior:

  • KR: Reduzir o número de novos bugs para 5% em pré-produção.
  • KR: Reduzir o número de bugs totais para 10% em pré-produção.
  • KR: Manter o número de bugs totais abaixo de 5% em produção.

E adicionamos o seguinte OKR:

  • Objetivo: Melhorar a qualidade das entregas das squads.
  • KR: Revisar 100% das novas histórias para encontrar requisitos mal definidos e/ou ambíguos.
  • KR: Efetuar revisão de 25% dos Pull Requests dos squads.
  • KR: Mensurar volume de Pull Requests dos squads.

Outro exemplo de controle de bugs

Na Conta Azul dobramos o time de desenvolvimento de produtos em um período de 8 meses entre novembro de 2017 e julho de 2018. Esse crescimento tinha por objetivo aumentar a capacidade produtiva do time.

Quantidade de entregas e de pessoas por semana da Conta Azul

Além disso dividimos a quantidade de entregas pelo total de pessoas no time para avaliar se estávamos conseguindo aumentar nossa produtividade individualmente.

Quantidade de entregas por pessoa na Conta Azul

Contudo, com o aumento de pessoas no time, acabou aumentando a quantidade de bugs. Tanto que o time que já vinha tendo 40% de suas entregas como correção de bugs acabou tendo que aumentar essa proporção para 60%. Ou seja, apesar de ter aumentado a produtividade individual e total, esse aumento de produtividade não estava sendo sentido pelo usuário, pois acabava sendo usado para refação.

Percentual de correção bug na Conta Azul

Para controlarmos esse problema, aumentamos nosso foco em corrigir esses bugs dentro dos SLAs, que eram:

  • 85% dos chamados resolvidos em até 7 dias
  • 98% dos chamados resolvidos em até 30 dias
SLA de resolução de bugs em 7 dias da Conta Azul
SLA de resolução de bugs em 30 dias da Conta Azul

Veja que a qualidade piorou e o cliente sofreu com isso. Mas, depois de algum tempo, conseguimos retornar aos níveis de SLA definidos. Olhávamos essa métrica semanalmente e, sempre quando discutíamos sobre essa métrica, concordávamos que a melhor maneira de cumprir o SLA era não criar bugs!

Qualidade não é só controle de bugs

Além do controle de bugs, há vários outros aspectos que impactam na qualidade do produto digital que entregamos para os usuários. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais.

Quando me juntei ao Gympass, na minha segunda segunda-feira o sistema ficou fora para os usuários por volta das 19:00. Comecei a perguntar para as pessoas do time o que estava acontecendo e a resposta foi que as segundas-feiras são dias de pico de visita às academias e que às vazes o sistema não dava conta do volume. Como não havia monitoração, não éramos alertados de que o volume estava maior que o usual e não conseguíamos nos preparar adequadamente. Dois meses depois, quando o Rodrigo Rodrigues se juntou ao Gympass como CTO, ele apelidou o evento de “Back Mondays”. Para endereçar o problema passamos a monitorar e implementar uma infraestrutura que desse conta dos picos das segundas-feiras. E definimos OKRs para uptime, requests de HTTP bem-sucedidos e tempo de reposta do backend.

Uptime – Gympass
Requests de HTTP bem sucedidos – Gympass
Tempos de resposta do backend – Gympass

Por que a qualidade é tão importante?

Qualquer usuário prefere utilizar um produto de boa qualidade que se comporte conforme o esperado. Isso é condição sine qua non para fornecer uma boa experiência do usuário.

Além da experiência do usuário, há outro aspecto importante a considerar quando falamos sobre qualidade e bugs. Sempre que alguém precisa trabalhar na resolução de um bug que foi encontrado em um produto digital, essa pessoa precisa parar de trabalhar no que quer que esteja trabalhando no momento para poder resolver o bug. Esta é uma interrupção no fluxo de trabalho. Se essa pessoa fosse capaz de entregar o software sem aquele bug, ela poderia continuar a trabalhar em coisas novas sem interrupções, o que a tornaria mais produtiva.

A relação entre produtividade e qualidade

Tive a oportunidade de participar de um curso do MIT sobre como criar organizações de alta velocidade. O curso foi ministrado pelo Professor Steven J. Spear, autor do livro The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. Esse é um daqueles cursos muito densos, cheios de conteúdo, mas que pode ser resumido em um parágrafo:

Organizações de alta velocidade são capazes de aprender muito rápido, especialmente com suas falhas, e de absorver esse aprendizado como parte integrante do conhecimento da organização.

Uma organização de alta velocidade trabalha seguindo os 4 passos adiante:

  • Estar preparado para capturar conhecimento e encontrar problemas em sua operação.
  • Entender e resolver esses problemas para construir novos conhecimentos.
  • Compartilhar o novo conhecimento com toda a organização.
  • Liderar para desenvolver habilidades 1, 2 e 3.

O exemplo clássico é a Toyota, com a manufatura enxuta e o conceito de parar a produção sempre que houver falhas, corrigindo-as e usando-as como oportunidade de aprendizado para que não aconteçam mais. Essa capacidade de aprender com as falhas é o que dá à Toyota a capacidade de permanecer à frente de seus concorrentes por tanto tempo.

Outro bom exemplo é a Alcoa, que tinha uma taxa de incidentes de trabalho de 2% ao ano, considerada normal. A Alcoa tem mais de 40.000 funcionários, portanto, 2% dos incidentes de trabalho por ano significa que 800 funcionários por ano têm algum tipo de incidente de trabalho. Esse é um número bastante impressionante e preocupante.

Para combater esse problema, eles implementaram uma política de tolerância zero a erros. Antes de implementar esta política, os erros eram vistos como parte do trabalho. Agora, os funcionários são incentivados a relatar erros de operação em 24 horas, propor soluções em 48 horas e contar a solução encontrada para seus colegas para garantir que o conhecimento se espalhe por toda a organização.

Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao ano! Essa redução na taxa de incidentes significava que menos de 30 funcionários por ano tinham algum problema de incidente de trabalho depois que a política de tolerância a erro zero foi implementada e a Alcoa obteve um aumento de produtividade e qualidade semelhante ao da Toyota.

Falhar rápido vs. aprender rápido

Um fator importante nos exemplos da Toyota e da Alcoa é que reconhecer e aprender com as falhas deve fazer parte da cultura da empresa. Isso é algo um pouco mais comum na cultura das empresas de tecnologia, mas não tão comum em empresas tradicionais. Durante o curso do MIT dividi mesa com um executivo brasileiro, do Grupo Globo, um executivo espanhol, da AMC Networks International (Walking Dead, Breaking Bad e Mad Men), um gerente de projetos alemão residente no Azerbaijão que trabalha para a Swire Pacific Offshore (indústria de petróleo e gás) e uma estudante de pós-doutorado do MIT em energia solar vinda da Arábia Saudita.

Todos os meus companheiros de mesa eram de indústrias mais tradicionais. Eu era o único de uma empresa de internet. Os executivos da Globo e da AMC estavam lá porque viram a Netflix com seu streaming de vídeo sob demanda e o YouTube com seu enorme catálogo de vídeos gerados por usuários como grandes ameaças, roubando seu público muito rapidamente e eles queriam entender como poderiam se defender.

Embora o tema seja um tanto óbvio para as empresas de internet, especialmente com a cultura de startups de tecnologia que valorizam o fail fast (falhar rápido). É isso que torna a Netflix e o YouTube uma ameaça às empresas de mídia tradicionais, como o Grupo Globo e AMC Networks. No entanto, mesmo isso sendo parte da cultura das empresas de internet, sentar e discutir isso com pessoas de empresas mais tradicionais foi uma grande oportunidade de reflexão sobre a relação entre a falha, o reconhecimento da falha, o aprendizado e a alta velocidade:

  • Reconhecer as falhas e usar as falhas como uma oportunidade de aprendizagem deve estar bem enraizado na cultura da organização. Se as pessoas não tomarem cuidado, à medida que uma empresa cresce, ela pode perder a capacidade de aceitar as falhas como oportunidades de aprendizado. É muito comum que as empresas, à medida que cresçam, sejam cada vez mais avessas a falhas e criem uma cultura que, em última análise, incentive as pessoas a esconderem erros e falhas.
  • Outro aspecto importante do aprendizado com as falhas é tornar esse processo um padrão da empresa. Não adianta falhar, reconhecer o erro, afirmar que você não vai mais cometer aquela falha e, algum tempo depois, cometê-la novamente. Esse processo de aprendizado com as falhas deve fazer parte da cultura da empresa. Sempre que uma falha é identificada, o aprendizado deve acontecer o mais rápido possível para evitar que ela aconteça novamente. Se a mesma falha acontecer novamente, algo está quebrado no processo de aprendizagem com a falha.
  • Mesmo em empresas de internet, percebo que aprender com as falhas é mais comum na equipe de desenvolvimento de produtos, uma vez que retrospectivas e aprendizado contínuo fazem parte da cultura de desenvolvimento ágil de software. Em outras áreas da empresa, aprender com as falhas é menos comum. Essa capacidade de sistematizar o aprendizado com o fracasso deve permear toda a empresa.

Mesmo que ouçamos muito sobre a cultura das empresas de internet de falhar rápido, falar sobre falhar rápido diverge nosso foco do que é realmente importante, aprender rápido. Devemos colocar nossa energia no aprendizado, não no fracasso. É o processo de aprendizagem que faz evoluir pessoas e empresas. E é a capacidade de uma organização aprender rápido, principalmente com seus fracassos, que vai permitir que ela se mova em velocidades realmente altas.

Resumindo

  • Questionar se o desenvolvimento de produto deve ou não ter uma equipe de QA dedicada não é a pergunta certa.
  • O problema que você está tentando resolver é como melhorar a qualidade do seu produto.
  • Uma boa métrica proxy de qualidade são os bugs. Inventário de bugs, novos bugs por semana e SLA de resolução de bugs.
  • Uma equipe de desenvolvimento de produto deve ter todos os seus membros seguindo essas métricas e agindo para melhorá-las.
  • Gerir bugs não é suficiente para gerir a qualidade do produto digital. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais que impactam diretamente na qualidade do produto digital.
  • A qualidade está em primeiro plano para fornecer uma boa experiência do usuário. Além disso, é fundamental para aumentar a velocidade de sua equipe de desenvolvimento de produto. Quanto menos bugs uma equipe tiver para corrigir, mais tempo ela terá para se concentrar em coisas novas.
  • Organizações de alta velocidade são capazes de aprender muito rápido, especialmente com suas falhas, e de absorver esse aprendizado como parte integrante do conhecimento da organização.

No próximo capítulo vamos ver um pouco mais sobre métricas.

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:

Visão, estratégia, objetivos e estrutura de time

Aqui vou falar sobre as ferramentas que tenho usado nos meus quase 30 anos de carreira em liderança de desenvolvimento de produtos e que tenho compartilhado com outros e outras líderes para possam utilizar com suas equipes. Elas incluem visão, estratégia, objetivos, métricas, relacionamentos, contratação, feedback e cerimônias.

Você vai perceber que as ferramentas que vou comentar aqui não são softwares como planilhas, apresentações, documentos, Slack, JIRA, Confluence etc. Esses softwares costumam ser bem úteis, mas eles são só um veículo de documentação, comunicação e metrificação das ferramentas que vamos ver.

Visão, estratégia, objetivos e estrutura de time

Todos esses itens são, além de conceitos muito importantes, ferramentas essenciais para qualquer head de produto. Em todas as oportunidades que iniciei como head de produto, esses foram os primeiros temas de que eu tratei, começando sempre com visão de produto e, em seguida, partindo para os temas de estratégia, objetivos e estrutura de time. Esse também é meu primeiro foco quando começo algum trabalho de advisoring. Procuro entender quais são a visão, estratégia, objetivos e estrutura de time. Caso não haja algum desses elementos, eu ajudo as pessoas da empresa a os criarem.

Já expliquei o que são e como criar cada um desses itens nos seus respectivos capítulos da parte I, por isso farei apenas uma rápida revisão dessas ferramentas.

Visão

Como expliquei no capítulo Visão de produto, para fazer a visão de produto é preciso ter clareza sobre os objetivos da empresa com o produto, bem como entender profundamente os problemas e as necessidades que os clientes têm e que serão resolvidos pelo produto. Os 6 passos para construir uma visão de produto são obter objetivos estratégicos da empresa, obter entendimento dos problemas e necessidades dos clientes, desenhar primeira versão da visão, iterar e refinar, comunicar e revisar.

Costumo documentar e comunicar a visão de produto em uma apresentação. Se necessário, coloco alguma introdução teórica explicando os conceitos de plataforma e de marketplace. Em toda apresentação que faço, reapresento a visão de produto para deixá-la clara para todos.

Estratégia e objetivos

A estratégia de produto nada mais é do que o caminho que você vai seguir para chegar à sua visão de produto. Para criar sua estratégia de produto você precisa ter bastante entendimento sobre seu mercado, ou seja, os concorrentes, o mercado potencial e acessível, o crescimento desse mercado, se existem disruptores e como ele é regulado. Você também precisa entender seus pontos fortes e fracos, as oportunidades e ameaças. Uma análise SWOT pode ajudar. Com essas informações em mãos, você define o que você e seu time vão fazer para atingir a visão de produto, quais os objetivos que vocês precisam alcançar e quais métricas lhes dirão que vocês estão atingindo esses objetivos. OKRs são uma ótima ferramenta para trabalhar seus objetivos e métricas.

Existem alguns livros e cursos falando sobre como definir e usar OKRs. Por isso não vou entrar em muitos detalhes aqui. De forma bem sucinta, você define junto com o time alguns objetivos para um período – normalmente um trimestre ou um ano – e define em quais métricas vocês vão mexer para mostrar que o objetivo está sendo atingido.

Costumo documentar os OKRs em planilhas, que uso para acompanhar a evolução toda a semana com líderes do meu time de desenvolvimento de produtos, e também apresentar e discutir os OKRs com outras lideranças e áreas da empresa. A seguir, um exemplo:

Exemplo de planilha de OKRs

Note que toda semana os KRs são atualizados. Cada líder do time atualiza seus KRs com seus times toda segunda-feira e, depois, líderes e head de produto passam pelos KRs para ver como está o andamento de cada um e se há algum impedimento em que pode ser colocada energia para remover. Gosto de fazer na segunda-feira pois ajuda o time a organizar o trabalho da semana. A cadência semanal é fundamental para ajudar o time a revisar a performance no mínimo semanalmente e fazer ajustes se necessário. Se a cadência for maior (quinzenal ou mensal), perdem-se valiosas oportunidades de corrigir problemas e remover impedimentos.

A coluna T0 indica o valor inicial da métrica. A coluna responsável tem o nome da pessoa que é responsável por aquele KR e que vai liderar os esforços para fazê-lo acontecer. E a coluna suporte lista as pessoas ou áreas que vão ajudar o responsável.

Vale relembrar que, quanto mais próximo dos objetivos e das métricas de negócio forem os OKRs, melhor será para o time, pois ele 7estará trabalhando para ajudar a empresa em seus objetivos e resultados.

Estrutura de time

No capítulo Estrutura de Time eu disse que times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiras, product designers e product managers. É importante deixá-los o mais enxuto possível para ajudar em sua produtividade. Esses times mínimos são agrupados em times de produto chamados de tribos de produto.

4 formas de se organizar os times de produto: por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização criando uma organização híbrida. Existem também as tribos estruturais, que criam a estrutura necessária para as tribos de produto performarem. Times que compõem as tribos estruturais são SRE/DevOps, Dados, Arquitetura/Ferramentas/Fundação, Design Ops, Segurança da Informação, Sistemas Internos, Engenharia de Vendas e Serviços Profissionais.

Para ajudar a organizar o time, costumo usar um modelo de planilha bem simples como a seguinte:

Exemplo de planilha de estrutura de time

Essa planilha contém a estrutura do time e as pessoas que fazem parte dele. Note que não estamos documentando liderança funcional, e sim a liderança de cada time. No exemplo, temos João como GPM líder da PM Letícia e da PD Carol, Maria como GPM líder do PD Rafa e Sandra como líder dos times estruturais de SRE/TI, de Dados e do Pedro, que lidera a engenharia de 2 squads da tribo A e do squad da tribo B.

Um ponto importante é que não basta só criar esses elementos e depois não os utilizar. Essas ferramentas são proveitosas quanto mais você as utiliza. Planilha de OKRs eu uso no mínimo toda semana. Visão e estratégia, sempre que tenho oportunidade, eu falo sobre esses temas. Estrutura de time, sempre que vamos falar de contratações ou mudanças no time, utilizo a planilha que mostrei acima.

Resumindo

  • Visão, estratégia, objetivos e estrutura de time são, além de conceitos muito importantes, ferramentas essenciais para qualquer head de produto.
  • Para visão e estratégia, uma apresentação com alguns slides é suficiente. Para OKR e estrutura de time, planilhas dão conta do recado.
  • Mais importante do que os softwares que você utiliza para documentar Visão, estratégia, objetivos e estrutura de time é o que você faz com essas ferramentas. Planilha de OKRs eu uso no mínimo toda semana. Visão e estratégia, sempre que tenho oportunidade, eu falo sobre esses temas. Estrutura de time, sempre que vamos falar de contratações ou mudanças no time, utilizo a planilha de estrutura de time.

No próximo capítulo vamos ver como medir e aumentar a produtividade de um time de desenvolvimento de produto.

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:

Mentalidade de ecossistema

Esse valor eu aprendi no Gympass. Era um dos valores corporativos da empresa e, na minha opinião, toda plataforma tem que ter esse valor. Muitas vezes me deparei com CEOs e heads de produto de plataforma que afirmavam que faziam tudo pelo cliente, que a empresa inteira era voltada ao cliente. Contudo, quando eu perguntava mais sobre esse tema, eu acabava descobrindo que o cliente ao que eles se referiam era apenas um dos atores da plataforma e os outros eram tratados apenas como “mal necessário”.

Na descrição do valor no site do Gympass está escrito:

Mentalidade de ecossistema

Tomamos decisões que criam valor para o nosso ecossistema Gympass e nos ajudam a alcançar nossa missão.

O exemplo que darei sobre mentalidade de ecossistema foi a implementação do produto de aulas ao vivo que o Gympass criou durante a crise do COVID-19.

Diversificando – e digitalizando – um portfólio de produtos

Durante a pandemia do COVID-19, diversificamos – e digitalizamos – nosso portfólio de produtos em tempo recorde. Passamos de um produto offline, acesso a academias e estúdios, para 4 produtos, 3 deles totalmente digitais, em menos de um mês:

  • Acesso a academias e estúdios: acesso a mais de 50.000 academias e estúdios em 14 países;
  • Aulas ao vivo: para quem gosta de treinar em grupo ou quer reviver a sensação da aula com os colegas da academia;
  • Personal trainers: para quem prefere uma abordagem mais personalizada e gosta de se exercitar no seu tempo;
  • Gympass Wellness: pacote de aplicativos com mais de 60 aplicativos para quem busca opções para melhorar o bem-estar físico e mental (da nutrição à sessão de terapia).

A seguir explico como fizemos isso.

Visão do Produto

Quando entrei para o Gympass, em meados de 2018, uma das primeiras coisas que fiz foi construir uma visão de produto. Tínhamos um propósito muito forte: vencer a inatividade. No entanto, para construir um produto digital, precisamos mais do que um propósito.

Visão de produto do Gympass

Essa visão orientou a definição da organização de desenvolvimento de produtos Gympass. Como comentei no capítulo Estrutura de time, montamos equipes em torno de cada um dos participantes do marketplace, além de uma equipe central que atuava no fluxo de pagamentos recolhendo o pagamento das empresas e de seus funcionários, fazendo todos os cálculos e determinando o pagamento de cada academia parceira.

Quando eu estava construindo essa visão de produto e discutindo-a com diferentes pessoas na organização, foi fácil ver muitas oportunidades de expandir esse mercado. Há uma grande quantidade de novas categorias de oferta que poderíamos adicionar ao nosso marketplace:

Oportunidades de expansão do Gympass

Existem 3 tipos de elementos em um mercado:

  • Oferta: bens ou serviços disponíveis para consumo.
  • Demanda: pessoas ou empresas que podem precisar de bens ou serviços oferecidos pelo fornecedor.
  • Mercado: onde a demanda encontra oferta e ocorre uma transação.

Esses três elementos se relacionam da seguinte maneira:

  • Entrega de valor: o mercado agrega valor à demanda e à oferta. O valor entregue à oferta são pessoas ou empresas interessadas em seus bens ou serviços. O valor entregue à demanda é um número variado de fornecedores de bens e serviços.
  • Pagamento: para ter acesso aos bens e serviços oferecidos pelos fornecedores, a demanda paga o mercado e o mercado paga a oferta. Normalmente, o mercado retém uma taxa por transação. Essa taxa pode ser fixa ou uma porcentagem do pagamento.
Dinâmica de um marketplace

Dada a dinâmica acima, podemos expandir um mercado da seguinte maneira:

  • Diversificação da demanda: você pode oferecer os bens e serviços do seu mercado para novos segmentos e regiões geográficas.
  • Diversificação de suprimentos: você pode oferecer novos bens e serviços à sua demanda.
  • Entrega de novo valor: você pode oferecer um novo valor para sua oferta e demanda.
  • Gestão financeira de pagamentos: como o pagamento da demanda para a oferta passa pelo mercado, você pode oferecer serviços financeiros tanto para a demanda quanto para a oferta, como pagamento antecipado e crédito, e pode gerenciar o spread.
Possibilidade de expansão de um marketplace

No entanto, tínhamos muito a fazer em nosso produto principal naquela época, então não tínhamos energia suficiente para nos concentrar na expansão de nosso marketplace e deixamos os planos na gaveta.

Novo empreendimento

Em outubro de 2019, chegamos a um ponto em que nossa equipe de desenvolvimento de produto estava bem estruturada e trabalhando adequadamente para enfrentar nossos desafios em nosso produto principal, então decidimos nos concentrar na expansão de nosso marketplace.

Decidimos trabalhar em uma ideia chamada “hub de parcerias do usuário final Gympass”. O plano era fazer parceria com aplicativos de bem-estar e fornecê-los aos nossos usuários.

Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

  • Disposição para parceria de fornecedores de aplicativos. Os provedores de aplicativos, assim como as academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
  • Disposição de pagar de nossa base de usuários. Nossa base de usuários está interessada em pagar uma mensalidade para ter acesso aos aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejávamos entregar aos parceiros e conversamos com alguns parceiros em potencial. Apresentamos a oportunidade de parceria a 8 potenciais parceiros, dos quais 6 mostraram interesse e 4 decidiram juntar-se à nossa prova de conceito. NEOU, um app de treino de atividade física, 8fit, um app de treino de atividade física e de nutrição, Tecnonutri, um app de nutrição e ZenApp um app de meditação.

Ok, nossa primeira hipótese foi validada e precisávamos validar a segunda hipótese, a disposição a pagar. Nosso usuário está disposto a pagar para ter acesso a esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevemos o produto e perguntamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele seria direcionado para uma página de assinatura do Paypal, onde ele precisa fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação de cada aplicativo. Não havia um produto real, apenas um formulário para testar o interesse e um e-mail com os links para os aplicativos.

Inicialmente, o chamamos de Gympass W, o W significando wellness (bem-estar). Adicionamos um beta para que todos pudessem entender que não era um produto acabado. Mais tarde, renomeamos para Gympass Wellness para deixar sua proposta de valor mais clara.

Nosso plano era testar essa prova de conceito com 5 clientes corporativos nos EUA e 5 no Brasil, o que nos forneceria uma base de potenciais usuários de 15.000 funcionários. Nossa expectativa era ter cerca de 200 assinantes. Lançamos internamente – eat your own dog food (coma sua própria ração para cachorro) – em 9 de março de 2020 e conquistamos 66 inscritos. Em seguida, veio o COVID-19.

COVID-19

Quando uma empresa é atingida por uma crise, ela precisa olhar para estas duas perspectivas:

  • preservar o dinheiro;
  • identificar e se adaptar às mudanças nos problemas e necessidades do cliente.

Embora gestores de produto e as equipes de desenvolvimento de produto tenham um papel importante no primeiro, seu papel principal é no segundo.

No Gympass temos 3 clientes diferentes e todos eles profundamente impactados pelo COVID-19:

  • academias em muitas cidades foram fechadas para auxiliar nas medidas de distanciamento físico aplicadas em muitas cidades para evitar a disseminação do COVID-19 e, consequentemente, estão perdendo receitas recorrentes de usuários que não frequentam a academia;
  • os usuários, funcionários de nossos clientes, não podem mais ir às academias e têm que ficar em casa, mas também têm que se manter ativos de alguma forma, mas sua primeira reação é cancelar ou pausar sua inscrição no Gympass, pois não terão acesso às academias por um tempo;
  • clientes corporativos, cujos funcionários estão em casa e não vão mais a academias, enquanto os RHs se preocupam em como manter esses funcionários engajados e produtivos.

Gympass Wellness, o primeiro produto digital

Fomos capazes de adaptar nosso piloto do Gympass Wellness em tempo recorde para ser oferecido a toda a nossa base de usuários, de forma que eles possam não apenas permanecer ativos, mas também cuidar de sua alimentação e de suas mentes durante esses tempos tão desafiadores. Com o Gympass Wellness, fomos capazes de atender aos problemas e necessidades dos usuários e de nossos clientes corporativos durante a crise.

E aqui entra a mentalidade de ecossistema. Devemos sempre olhar para todos os participantes em nosso mercado e garantir que todos se beneficiem de usá-lo.

Live Classes, o segundo produto digital

Com o Gympass Wellness, fomos capazes de atender às necessidades de nossos clientes corporativos e de seus funcionários. E as academias? Ao serem fechadas, estavam perdendo receita. Seus clientes não os visitavam mais, então os usuários regulares das academias estavam propensos a cancelar sua assinatura, enquanto aqueles que costumavam ir às academias usando o Gympass não iam à academia durante a crise, o que causaria uma perda de receita para as academias também. Para ajudar as academias parceiras, decidimos e implementamos em tempo recorde 2 soluções:

  • Fornecemos às academias um aplicativo white-label para que elas pudessem oferecer a todos os seus clientes, independente de serem ou não funcionários de clientes do Gympass, para que as academias pudessem entregar valor aos seus clientes, ajudando-os a se manter ativos em casa;
  • Fornecemos uma plataforma para as academias agendarem e transmitirem aulas ao vivo para todos os usuários do Gympass, para que eles possam manter seus instrutores empregados, enquanto fornecem aos usuários do Gympass conteúdo exclusivo. Essa plataforma é chamada de Live Classes.

Personal Trainers, o terceiro produto digital

As Live Classes forneciam uma plataforma 1:N, o que significa que um instrutor poderia fornecer orientação de atividade física para N usuários. Logo percebemos que poderíamos criar outro produto além do Live Classes, orientação de atividade física 1:1, que poderia ser disponibilizada nos planos de nível superior do Gympass. Em seguida, criamos nosso terceiro produto digital, Personal Trainers.

Resumindo

  • Mentalidade de ecossistema significa tomar decisões que criam valor para todos os atores de uma plataforma.
  • No Gympass, durante a crise do COVID-19, depois de colocarmos o Gympass Wellness para todos os seus clientes e os funcionários desses clientes, uma parte importante do ecossistema ainda estava sofrendo, as academias. Foi a mentalidade de ecossistema que guiou o Gympass para criar o produto de Live Classes, que permitiu que as academias continuassem operando mesmo estando de portas fechadas.

Pronto, com este capítulo concluímos a segunda parte do livro, sobre Princípios. Aqui vimos 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.
  • Como e quando delegar.

Vimos também o que é cultura empresarial, um conjunto de maneiras de resolver problemas e reagir a situação compartilhadas por um grupo de pessoas trabalha junto. Vimos também os 5 valores necessários para criar produtos digitais de sucesso:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não deve ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Por fim, vimos um conjunto de quatro valores que são de fato o núcleo de todo time de desenvolvimento de produtos digitais. São os valores que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados:

  • Lançamento antecipado e frequente
  • Foco no problema
  • Entrega de resultado
  • Mentalidade de ecossistema

Vamos agora ver as ferramentas? \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:

Entrega de resultado

No capítulo anterior vimos a diferença entre um time que soluciona problemas e um time que implementa soluções. Enquanto um time que resolve problemas precisa ter um profundo entendimento de cada problema que vai resolver, das pessoas que são afetadas por ele, do contexto onde acontece e da motivação das pessoas para terem esse problema resolvido, o time implementador de soluções se foca em implementar aquilo que lhe é pedido, não se importando se o que está sendo implementado serve para algo.

A medição de entrega de resultado desses dois tipos de times costuma ser bem diferente. Por meio da forma como um time reporta seus resultados conseguimos claramente saber que tipo de time é. Algo como “conte-me sobre seus resultados que lhe direi que tipo de time é!”. Enquanto o time implementador de soluções costuma medir sua entrega de resultado baseado na quantidade de funcionalidades entregues, o time solucionador de problemas mede sua entrega de resultado baseado em quão bem os problemas foram resolvidos.

Fábrica de funcionalidades

Os times implementadores de soluções são aquelas “fábricas de funcionalidades” que já mencionamos no capítulo anterior, ou seja, cuja principal métrica é a quantidade e a velocidade de entrega de funcionalidades. Como essa é sua principal métrica, esse time passa a ser medido pelas suas entregas. O time disse que ia entregar tal funcionalidade nesse dia, então é isso que a organização espera e será isso que a organização vai cobrar do time.

Essa situação não é tão incomum quanto se imagina. Na Locaweb, antes de implementarmos OKRs, o time de desenvolvimento de produto era primariamente cobrado por assertividade do planejamento. Se o time disse que ia entregar X no dia Y, era isso que era esperado do time, com nenhuma preocupação se X era a coisa certa a fazer e se ia de fato trazer resultado para a empresa ou para os clientes. Ao implementarmos OKRs, conseguimos fazer o time cada vez mais focado em entender e resolver problemas.

Ao me juntar à Lopes, encontrei algo bastante similar. Um time de portal, outro de CRM e outro de app, todos eles com entregas predefinidas até 6 meses para frente, porque foi isso o que foi acordado com a direção da empresa. Inclusive a Lopes tinha contratado duas empresas de consultoria que, ao apresentarem seu relatório de resultados, mostravam a quantidade de funcionalidades entregues como seu principal resultado, porque foi isso que foi demandado delas, entrega de funcionalidades.

É importante notar que uma situação como essa não acontece exclusivamente por responsabilidade do time de desenvolvimento de produto. É também responsabilidade das pessoas que estão fazendo as demandas. Enquanto o time de desenvolvimento de produto deve sempre perguntar qual o problema que está tentando resolver com aquela demanda, as pessoas que fazem as demandas devem sempre contextualizar essas demandas trazendo o problema que motivou a demanda.

Foco no resultado

Após meus primeiros 30 dias na Lopes já comecei a trabalhar com o time na definição dos OKRs para o próximo trimestre, o que motivou inclusive o RH a também fazer seu planejamento baseado em OKRs. Depois, esses OKRs foram apresentados para toda a liderança da empresa. Foi a forma que encontrei de provocar a mudança de cultura e de mentalidade tanto no time de desenvolvimento de produto quanto em toda a empresa.

A maioria dos OKRs que definimos são focados em resultados de negócio. Aumento de vendas, aumento da taxa de atendimento e assim por diante. É isso o que importa para o negócio. As funcionalidades são um meio, não um fim em si mesmo, mesmo em empresas 100% digitais, como a Conta Azul e a Locaweb, os produtos digitais são um meio para o fim. A Locaweb inclusive deixa isso bem explícito em sua missão de “fazer negócios nascerem e prosperarem por meio da tecnologia”, enquanto a Conta Azul quer “impulsionar o sucesso dos pequenos empreendedores levando às pequenas empresas mais organização, controle e tempo por meio da tecnologia.” Repare que em ambas a tecnologia, o produto digital é um meio para se atingir um fim.

Resumindo

  • Outro valor fundamental para qualquer time de desenvolvimento de produto é o foco na entrega de resultado.
  • É preciso tomar cuidado na definição de resultado. Entregar uma funcionalidade não é um resultado. Toda funcionalidade é um meio que serve para um fim, o atingimento de um objetivo de negócio.
  • Mesmo empresas 100% digitais, cujo produto digital e a tecnologia são o core da empresa, têm por foco objetivos de negócio.

No próximo capítulo vamos ver o valor de mentalidade de ecossistema.

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:

Foco no problema

É da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução: começamos a buscar soluções para o problema. No entanto, se antes conseguirmos um melhor entendimento sobre o contexto em que o problema ocorre e a motivação para resolvê-lo, há mais chances de conseguirmos encontrar soluções mais simples e fáceis de implementar.

É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos dele para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução.

Qual é o problema?

Para ajudar as pessoas a se focarem no problema, pergunte sempre “Qual é o problema?”. Quando uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pelo pedido e, em seguida, devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida.

Ao colocar isso em prática, em breve as solicitações virão não apenas com uma solução, mas também com muitas informações sobre o problema. É interessante ver essa mudança cultural, mas requer a disciplina dos membros da equipe de desenvolvimento de produtos para sempre perguntar sobre o problema. E quando menciono os membros da equipe de desenvolvimento de produtos, estou me referindo a todos, não apenas aos gestores de produto, mas também aos designers e às engenheiras e engenheiros de produto.

Mentalidade de problema vs. solução

A principal vantagem de nos focarmos em entender melhor o problema é que, quanto mais tempo investirmos nisso, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, gastaria 55 minutos pensando sobre o problema e cinco minutos pensando nas soluções.”

Einstein acredita que a qualidade da solução que você gera está em proporção direta com sua capacidade de identificar e compreender o problema que espera resolver.

Deixe-me contar uma pequena história para ilustrar isso. Durante a corrida espacial, os cientistas se depararam com o problema de escrever no espaço onde não houvesse gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos começaram seus esforços de P&D e depois de algum tempo e alguns milhões de dólares, eles construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis.

Caneta que escreve em ambientes sem gravidade.

Essa história mostra um bom exemplo de como pular direto para a solução pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções incompletas ou exageradas. É uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. E o primeiro passo para mudar um comportamento é reconhecer quando ele acontece. Quando um membro da equipe de desenvolvimento de produto recebe uma solicitação para implementar algo, ele deve perguntar à pessoa que trouxe a solicitação qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, provedora de hospedagem web no Brasil, os serviços de hospedagem e e-mail podem parar de funcionar devido a fatores externos como o domínio que está associado à hospedagem e ao e-mail não ser renovado.

Primeira solução: Registro.br, o registrador brasileiro de domínios .br lançou uma API para permitir que a Locaweb cobrasse o domínio do cliente em nome do Registro.br. A princípio, a ideia parecia boa, já que a Locaweb cobrar o domínio parecia a forma mais fácil de garantir que o cliente saiba que tem que pagar pelo registro do domínio para manter os serviços de hospedagem e e-mail funcionando corretamente. Porém, quando analisamos mais a fundo, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que acontece se o cliente pagar as duas contas? E se ele pagar apenas o Registro.br? E se ele pagar apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que cobraríamos por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução real: começamos a nos perguntar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos desenhar uma solução mais simples: implementar uma régua de comunicação com este cliente avisando-o da importância de pagar ao Registro.br para garantir que os serviços de e-mail e hospedagem continuem funcionando normalmente. Esta é uma solução muito mais simples do que implementar um processo de faturamento dobrado. Se o Registro.br nos fornecer a URL de cobrança, podemos enviar as informações desse link ao cliente e as chances de solucionar o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de faturamento duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiririam um número fixo de licenças do Conta Azul para revender aos seus clientes. Um sistema de gerenciamento de compras em lote levaria cerca de 3 meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul a granel, mas só deveria começar a cobrar do cliente da contadora quando esse cliente realmente ativasse a licença.

Solução real: os contadores não se importavam com as compras em lote. O que eles queriam era dar um desconto aos seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo proporcionado por seu relacionamento conosco. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

No Gympass, um parceiro de fitness que estava ingressando em nossa rede solicitou que apresentássemos seu waiver (termo de isenção de responsabilidade) a todos os usuários que fizessem o check-in em suas instalações.

Primeira solução: mudar nosso aplicativo para pedir aos usuários que vão a este parceiro de fitness que leiam seu waiver em nosso aplicativo e marquem um checkbox informando que leram e estão de acordo.

Solução real: nenhuma alteração em nosso aplicativo. Usamos um campo de texto personalizável na configuração de uma academia em nosso sistema que normalmente é apresentado aos usuários que farão check-in nessa academia para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com os termos e condições localizados em http://fitnesspartner.com/waiver”.

Não me interprete mal, é muito bom que todos tragam soluções sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produto. Quanto mais ideias de solução tivermos, melhor. No entanto, precisamos nos educar para ter um entendimento mais profundo do problema por trás dessa solução, para que tenhamos a chance de encontrar soluções mais simples e rápidas para implementar. E é, em última análise, o trabalho da gestora de produto e de todos os membros da equipe de desenvolvimento de produto perguntar qual é o problema e por que precisamos resolvê-lo.

Projetos vs. problemas

O ano novo é tempo de retrospectiva e planejamento. O que normalmente é feito a cada trimestre pela maioria das equipes de desenvolvimento de produtos é feito de forma mais intensa na virada do ano, em conjunto com outras áreas da empresa. É o processo de planejamento anual, que normalmente vem junto com o processo de orçamento. O que faremos neste novo ano que está chegando? Quais são os principais projetos que trabalharemos ao longo do ano?

Mesmo que o planejamento seja superimportante para ter clareza sobre quais projetos são prioridades para o novo ano, esta lista de projetos pode fazer você perder de vista um aspecto muito importante do planejamento, o “porquê”.

Não é incomum ver o planejamento de ano novo para uma equipe de desenvolvimento de produto, e até mesmo para toda a empresa, como uma lista de projetos. Para ajudá-lo a ver sua lista de projetos em um ângulo diferente, adicione 2 colunas:

  • uma para descrever quais são os problemas que você está tentando resolver em cada projeto;
  • e outra para descrever para quem você está tentando resolver este problema.

Já discuti as questões de ter uma mentalidade orientada para a solução versus uma mentalidade orientada para o problema, mas quando se trata de planejamento de ano novo, esse problema fica ainda mais evidente. Os benefícios de ter clareza sobre os problemas que deseja resolver e para quem você planeja resolvê-los são:

Garantir que os problemas estejam alinhados com a visão e estratégia da empresa: quando focamos em projetos, é fácil perder de vista os problemas que estamos tentando resolver, para quem planejamos resolver, e se são esses problemas que realmente precisamos resolver.

Definir quais problemas são mais importantes para resolver: priorizar projetos sem saber quais problemas esses projetos resolvem, e para quem, pode tornar as prioridades não alinhadas com o que é realmente importante para a empresa. Porém, para sermos mais eficazes em trazer o resultado desejado, devemos priorizar os problemas a serem resolvidos e garantir que a priorização esteja alinhada com a visão e estratégia da empresa.

Resolver mais de um problema com o mesmo projeto: às vezes, você pode descobrir que está tentando resolver mais de um problema com um projeto, e isso pode não ser um problema. Mas você precisa saber disso. Talvez você possa ter soluções mais simples se tratar cada problema separadamente. Talvez nem todos valham a pena resolver neste momento.

Verificar se os projetos são as melhores soluções: quando mudamos o foco dos projetos para os problemas e temos uma visibilidade clara da prioridade dos problemas, fica mais fácil verificar se os projetos listados são a melhor solução para o problema em questão. Às vezes, podemos encontrar soluções que são mais fáceis de implementar quando mudamos nosso foco para a compreensão dos problemas.

Então pegue sua lista de projetos e crie essas duas colunas, problemas a serem resolvidos em cada projeto e para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nas coisas mais importantes para este novo ano.

Equipes solucionadora de problemas vs. equipes implementadoras de solução

Marty Cagan, uma referência bem conhecida na comunidade de produtos digitais, escreveu há algum tempo um artigo interessante sobre equipes de produtos x equipes de funcionalidades, onde explica a diferença entre três tipos de equipes, as equipes de entrega, as equipes de funcionalidades e as equipes de produto. Ele define de cada tipo de equipe da seguinte forma:

  • As equipes de entrega não são multifuncionais (basicamente apenas desenvolvedores mais um product owner que administra o backlog), não estão focadas no resultado (as pessoas são todas orientadas à entrega de funcionalidades) e não têm autonomia (estão lá para codificar e entregar).
  • As equipes de funcionalidades geralmente são multifuncionais (têm pelo menos uma designer e uma gestora de produto), mas ainda se preocupam com a produção e entrega de funcionalidades.
  • As equipes de produto são multifuncionais, focadas e avaliadas pelo resultado, e têm autonomia para apresentar soluções que funcionem.

Ele explica que os melhores resultados para a organização dona do produto e para os usuários desse produto vêm das equipes que ele chama de equipes de produto. Ele tem usado muito a palavra empoderado (empowered) para descrever esses times.

Qualquer produto digital existe para dois propósitos principais:

  • Ajudar a empresa dona do produto digital a atingir seus objetivos.
  • Resolver os problemas e atender as necessidades de seus usuários.

Portanto, qualquer produto digital e suas funcionalidades são soluções para problemas da empresa dona do produto e soluções para resolver os problemas do usuário e atender às suas necessidades.

Neste contexto de produto digital, quando digo que gastar mais tempo entendendo o problema produz as melhores soluções, quero dizer que somos capazes de entregar o mais rápido possível o melhor produto e funcionalidades para resolver o problema em mãos com software de boa qualidade e boa experiência de usuário.

Solucionar problemas vs. implementar solução

O que Marty descreve como equipes de entrega e equipes de funcionalidades são equipes de implementadores de soluções. Essas equipes trabalham na implementação de uma solução concebida por outra pessoa. E essa outra pessoa normalmente é alguém da chamada “área de negócios”, que pode ser alguém de vendas, marketing, sucesso do cliente, suporte ao cliente, finanças, operações, um diretor, um vice-presidente ou um fundador. Em tal equipe, o gerente de produto gerencia principalmente o backlog e ajuda a equipe a entregar a solução solicitada, o designer de produto se concentra principalmente em desenhar uma interface agradável e os engenheiros têm que codificar e implantar a solução solicitada. As equipes de implementação da solução fazem o que foi solicitado, com pouco ou nenhum compromisso com a qualidade da solução, ou mesmo se a solução implementada realmente resolve o problema. Podem também ser chamadas de “fábrica de funcionalidades”. Sua performance é medida pela quantidade de funcionalidades que o time produz.

Por outro lado, o que Marty descreve como equipes de produto empoderadas são equipes de solução de problemas. Essas equipes trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.

Existem três razões principais pelas quais as equipes de solução de problemas são mais eficazes do que as equipes de implementadores de soluções:

Conhecimento de produto digital: não há ninguém melhor do que os membros da equipe para encontrar a melhor solução de produto digital para um problema. Uma solução entregue o mais rápido possível, com boa qualidade de software e boa experiência do usuário. Isso acontece porque uma equipe de solucionadores de problemas é uma equipe multifuncional composta por engenheiros que entendem a tecnologia disponível, designers de produto, que têm um conhecimento profundo dos usuários, suas dores e necessidades, e gestores de produto, que têm um bom entendimento do contexto empresarial do problema a ser resolvido.

Duas cabeças pensam melhor do que uma: este velho ditado significa que é mais fácil para duas pessoas que se ajudam resolverem um problema do que para uma pessoa resolver um problema sozinha. Uma equipe de solucionadores de problemas não descarta nenhuma sugestão de solução das “áreas de negócios”. Na verdade, essas sugestões de solução são muito úteis para ajudar a equipe a entender melhor o problema, mas elas devem ser consideradas dessa forma, sugestões. Uma equipe de solucionadores de problemas primeiro entende profundamente o problema e, em seguida, analisa as opções de solução.

Compromisso: um efeito colateral adicional de uma equipe de solução de problemas é que os membros dessa equipe estão profundamente comprometidos com o sucesso da implementação da solução, uma vez que estão profundamente envolvidos no processo de busca da solução.

Criação de equipes de solução de problemas

Agora que expliquei por que as equipes de solução de problemas são o melhor tipo de equipe de produto que uma empresa pode ter, explicarei como construir equipes de solução de problemas. Existem três aspectos que precisam ser considerados:

Ambiente: é fundamental que toda a organização entenda o poder de ter equipes de produtos digitais para solução de problemas. A velocidade e a qualidade das soluções entregues por uma equipe de produto digital que sempre começa a resolver os problemas a partir de um entendimento profundo do problema é muito melhor do que as soluções entregues por equipes de implementadores de soluções. Consequentemente, os resultados do negócio serão melhores e mais rápidos. É função e responsabilidade do head de produto ajudar a organização a entender isso.

Qual é o problema: uma maneira muito eficaz de enfocar toda a organização para longe da mentalidade de solução e mais próximo da mentalidade de problema é perguntar constantemente “Qual é o problema que estamos tentando resolver?” e “Por que é importante resolver este problema?”. Isso ajudará as pessoas de toda a organização a mudar sua perspectiva e, consequentemente, perceber a importância de um entendimento profundo do problema antes de implementar uma solução. Essa é uma mudança de comportamento que toda a equipe de desenvolvimento de produto digital pode ajudar sua organização a fazer. Sempre que alguém pede à equipe de produto para implementar algo, pergunte “Qual é o problema que estamos querendo resolver?”.

Confiança: este é um aspecto crítico para construir equipes bem-sucedidas de produtos digitais de solucionadores de problemas. Normalmente as pessoas da “área de negócios” acreditam ter um melhor entendimento do negócio do que as da equipe de produto. Esse comportamento fica ainda mais visível quando a equipe de produto digital é nova na organização. Como uma pessoa nova na organização pode entender mais sobre o negócio do que quem está na empresa há anos? Provavelmente ela não pode, especialmente se ela vier de um mercado diferente. No entanto, quem faz parte da equipe de produto digital normalmente tem muita experiência na construção de produtos digitais, provavelmente mais experiência do que qualquer outra pessoa na organização.

Por isso, é fundamental que a “área de negócios” eduque a equipe de produto digital sobre os aspectos de negócios da organização. Essa busca por educação é papel e responsabilidade dos gerentes de produto, que devem aprender com a “área de negócios” e educar designers e engenheiros de produto sobre o negócio. Uma forma prática de acelerar esse aprendizado é trazer pessoas da “área de negócios” para as sessões de discussão sobre o problema. É assim que a equipe de produto ganha a confiança das demais áreas da organização.

Acredito que estão claros os benefícios de ter equipes de produto digital de solucionadores de problemas versus implementadores de solução. Toda a organização precisa entender a diferença a fim de pressionar por mais e mais equipes de resolução de problemas. A head de produto tem essa como uma de suas maiores responsabilidades, ajudar a construir o ambiente e a confiança necessária para o sucesso das equipes de solução de problemas.

A armadilha do top-down

Quando falo sobre as diferenças entre equipes solucionadoras de problemas vs equipes implementadoras de solução, normalmente ouço comentários como “Queremos ser uma equipe de solucionadores de problemas, mas na minha empresa todas as soluções são top-down e a única coisa que podemos fazer é implementá-las”.

Essas situações agravam-se quando surge pressão. A pressão mais recente que muitas empresas estão sofrendo é a crise do COVID-19. Na ânsia de resolver os problemas o mais rápido possível, os líderes da empresa pedem às equipes que implementem esta ou aquela solução de maneira rápida, muito rápida.

A armadilha

Deixe-me agora abordar o elefante na sala, o ambiente de tomada de decisão top-down. Isso tem um impacto enorme em qualquer equipe neste tipo de ambiente. Sem fazer parte da decisão sobre a solução, as pessoas que implementam a solução acabarão por ficar desmotivadas.

Por que estou chamando de armadilha do top-down? Porque muitos dos ambientes de tomada de decisão percebidos como top-down são isso que acabei de escrever, uma percepção.

Vamos usar a principal característica que toda gestora de produto deve ter, empatia. A habilidade de alguém se colocar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Pessoas com quem tive a oportunidade de falar sobre as características essenciais de um gestor de produto sabem o quão importante considero a empatia como um traço crítico para PMs de sucesso.

Aqui estão 2 dicas para ajudar os membros da equipe de produto a ter empatia com os chamados tomadores de decisão top-down e escapar da armadilha de cima para baixo:

  • Compreendendo a situação: coloque-se no lugar do solicitante da implementação de solução. As pessoas resolvem problemas, é a natureza delas, e sempre que se deparam com um problema, pulam para o modo de solução e tentam encontrar e implementar soluções o mais rápido possível. Sob maior pressão, como a crise COVID-19, o desejo de encontrar e implementar soluções é exacerbado. Na maioria dos casos, as pessoas não querem ser tomadores de decisão top-down, elas simplesmente têm uma necessidade de resolver o problema o mais rápido possível.
  • Alterando o status quo: faça perguntas sobre a solicitação de implementação de solução. Que problema estamos resolvendo? Para quem? Por que é importante resolver esse problema? Por que agora? Por que precisamos entregar algo rápido, mesmo comprometendo a qualidade? Se lhe perguntarem o motivo de tantas perguntas, explique que está tentando entender melhor o problema para ver se existem outras soluções mais baratas e rápidas.

Essas dicas ajudarão todos na equipe de produto a fazer a mudança para um processo de tomada de decisão mais colaborativo.

Na maioria das vezes, as pessoas entendem os benefícios de um processo colaborativo de tomada de decisão. Mesmo sob pressão, as soluções colaborativas produzirão melhores resultados. Soluções concebidas em um processo colaborativo são normalmente mais baratas e rápidas de implementar porque mais pessoas tiveram a chance de discutir as opções de solução e a equipe que implementará a solução selecionada estará verdadeiramente comprometida com seu sucesso.

Para construir, manter e melhorar as equipes de solução de problemas e evitar transformá-las em equipes de implementação de soluções, especialmente quando sob maior pressão, é fundamental evitar a armadilha do top-down.

Os heads de produto têm o papel e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo e, consequentemente, mais eficaz.

Resumindo

  • Um passo muito importante para criar uma boa solução é a compreensão do problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar nas soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.
  • Se você tiver uma lista de projetos para fazer, crie duas colunas a mais nessa lista, uma para problemas a serem resolvidos em cada projeto e outra para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nos problemas a serem resolvidos, e não nos projetos, que são a solução.
  • Equipes de implementação de solução são equipes trabalham na implementação de uma solução concebida por outra pessoa. Equipes de solução de problemas são equipes trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.
  • A armadilha top-down é a percepção do processo de tomada de decisão sendo feito pelos líderes da empresa, sem oportunidade de participação do resto dos funcionários. Essa percepção é exacerbada quando uma empresa enfrenta uma pressão crescente, como a crise do COVID-19.
  • As pessoas são orientadas para a solução e, quanto maior a pressão, mais rápido as pessoas desejam que as soluções sejam implementadas.
  • Para ajudar a lidar com essa situação, use a empatia para entender o ponto de vista do solicitante de implementação da solução e pergunte a ele por que é necessário implementar a solução solicitada.
  • Os heads de produto têm a função e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo.

No próximo capítulo vamos entender mais sobre o foco em entrega de resultados.

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:

Lançamento antecipado e frequente

Nos capítulos anteriores vimos 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.
  • Como e quando delegar.

Vimos também o que é cultura empresarial, um conjunto de maneiras de resolver problemas e reagir à situação compartilhado por um grupo de pessoas trabalha junto. E vimos os 5 valores necessários para criar produtos digitais de sucesso:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequências, não devem ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Cultura de produto

Acontece que esses valores são necessários, mas não suficientes. Existe um conjunto de quatro valores que são de fato o núcleo de todo time de desenvolvimento de produtos digitais. São os valores que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados. Os quatro valores, que serão tema deste e dos próximos capítulos, são:

  • Lançamento antecipado e frequente
  • Foco no problema
  • Entrega de resultado
  • Mentalidade de ecossistema

Vamos começar com o primeiro: Lançamento antecipado e frequente.

Quanto mais cedo apresentarmos o produto a seus usuários, melhor, pois poderemos receber feedback de usuários reais que poderão usar o produto em seu próprio contexto. Existem 3 razões que justificam essa necessidade de lançar seu produto ou funcionalidade o quanto antes e frequentemente.

Momento da verdade

Por mais pesquisas, entrevistas e protótipos que você faça, o momento da verdade, ou seja, o momento em que você saberá se o seu produto é, de fato, a solução de um problema de um conjunto de pessoas, é quando ele estiver nas mãos de seus clientes, no contexto onde eles precisam do produto.

Quanto mais tempo você demorar para colocar seu produto na rua, mais tempo demorará para aprender com pessoas reais se você está no caminho certo. E pior, mais passos você certamente estará dando na direção errada.

Você só vai saber se o produto que você fez realmente resolve o problema de algumas pessoas se elas o usarem. Quanto mais tempo demorar para isso acontecer, mais tempo vai levar para saber se ele é ou não é a solução do problema.

E se não for, o que você faz? Conserta, ajusta, muda! Quanto mais cedo você souber que o que você está desenvolvendo não está no caminho certo, melhor, pois menos tempo, energia e dinheiro você desperdiçará indo no caminho errado.

Excesso de funcionalidades

Existe um limite de funcionalidades que o usuário consegue entender. Quando colocamos funcionalidades demais, em vez de criarmos uma solução para o problema do cliente, acabamos criando um novo problema para ele.

Kathy Sierra, reconhecida instrutora de programação e de experiência do usuário, criou um gráfico de funcionalidades que ilustra de forma clara e divertida como a satisfação do usuário diminui à medida que aumentamos a quantidade de funcionalidades de um produto.

Curva de satisfação do usuário como função da quantidade de funcionalidades

Retorno do investimento

Quanto mais tempo seu produto demorar para ter usuários e, consequentemente, clientes que em algum momento pagarão pelo seu produto, mais você terá de investir do seu próprio bolso. Veja a seguir um gráfico típico de retorno de investimento de um produto (ROI).

Enquanto você não o lançar e não tiver receita, tudo o que você terá é custo. Ou seja, você estará na parte de investimento da curva. Isso só muda quando você começar a ter receita e esta for maior do que os custos mensais. Então você entra na área descrita a seguir como rentabilidade mensal. Só depois de alguns meses nessa área é que você terá o retorno do seu investimento. Veja como o caminho é longo.

Retorno do investimento

Agora veja no gráfico adiante, como um atraso de 3 meses em obter receita pode atrasar em 6 meses a obtenção do retorno do investimento. Será que esses 3 meses de atraso em obter receita valem a pena? O que você vai fazer nesses 3 meses realmente compensam 6 meses de atraso no retorno do investimento?

Retorno do investimento postergado

Por outro lado, veja só o que você ganha se conseguir acelerar o desenvolvimento de seu produto e lançá-lo 3 meses antes do planejado. Você ganha 6 meses de retorno do investimento! E a explicação para isso não é só porque você adiantou a entrada de receita, é porque você gastou menos para poder lançar o produto mais rápido. Veja no gráfico a seguir.

Retorno do investimento antecipado

Se você não tem vergonha da sua primeira versão, demorou demais para lançar

Reid Hoffman, fundador do LinkedIn disse certa vez que:

“Se você não tem vergonha da primeira versão do seu produto, você demorou demais para lançar”.

Para ilustrar essa frase, que de certa forma sumariza o valor de lançamento antecipado e frequente, resolvi pegar prints da tela da primeira versão de alguns serviços bem conhecidos.

Facebook 2005
Facebook 2005
Google 1998
Google 1997
Linkedin 2005
Twitter 2006
Locaweb 2002
Conta Azul 2011
Ágil ERP (Conta Azul) 2008
Gympass 2014
Lopes 1997

MMF – Minimal Marketable Feature

Minimal Marketable Feature ou MMF vem de um livro de 2003 chamado Software by Numbers, de Mark Denne e Dra. Jane Cleland-Huang. Neste livro, eles introduzem o conceito de:

Metodologia de Financiamento Incremental (Incremental Funding Methodology – IFM), uma abordagem baseada no ROI (Return on Investment – Retorno do Investimento) para o desenvolvimento de software em que o software é desenvolvido e entregue em blocos cuidadosamente priorizados de funcionalidades valorizadas pelo cliente. Esses blocos são conhecidos como Funcionalidades Mínimas Comercializáveis ou Minimal Marketable Features – MMFs.

É um conceito anterior ao de MVP, que traz a vantagem dessa mentalidade de implementar o mínimo necessário para cada funcionalidade do produto. A diferença básica entre MVP e MMF é que, enquanto MVP fala de um produto mínimo viável, ou seja, precisa de um produto completo, mesmo que mínimo, para poder ser apresentado a possíveis usuários, o MMF traz esse conceito do mínimo para o nível da funcionalidade.

Para ilustrar o MMF, eles usaram um exemplo muito simples de entender: imagine que você tenha que construir um sistema de internet banking na web. Existem muitos recursos e pode levar muitos meses ou até anos para esse produto ser entregue com todos os recursos “obrigatórios”. Ao pensar em termos de MMF, devemos olhar para aqueles recursos “obrigatórios” e descobrir se podemos lançá-los de forma independente, ou seja, se um determinado recurso, se lançado de forma independente, traria algum valor para o cliente. Em um sistema de internet banking pela Web, poderíamos optar por liberá-lo apenas com extrato da conta e nenhum outro recurso. Esse seria um sistema de internet banking muito simples, mas, se lançado assim que estiver pronto, e não depois que alguns outros recursos também estiverem prontos, ele trará valor para o cliente mais cedo. E sempre que você entrega valor ao cliente, você também entrega valor à sua empresa. Além do cliente satisfeito, neste exemplo você provavelmente reduziu o custo que sua empresa tem em servir esses clientes, pois se os usuários não obtiverem seus extratos de conta pela internet, eles certamente usarão outra forma de obter essas informações e provavelmente esta outra forma não é tão econômica quanto o acesso via internet, como ir a uma agência ou a um caixa eletrônico.

Uma funcionalidade mínima comercializável (MMF) é mínima, porque se fosse menor não seria comercializável. E uma MMF é comercializável pois, quando lançada como parte de um produto, as pessoas usam (ou compram) a funcionalidade.

Da próxima vez que você estiver planejando um novo produto ou conjunto de funcionalidades para um produto existente, tente pensar em termos de MMF. Pode trazer muito valor para você, seus clientes e para sua empresa.

Resumindo

  • Existe um conjunto de quatro valores que são de fato o núcleo de todo time de desenvolvimento de produtos digitais. São os valores que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados.
  • As três razões para você lançar logo seu produto são que (i) esse é o momento da verdade, (ii) assim você evita o excesso de funcionalidades e (iii) acelera o retorno do investimento.
  • Se você não tem vergonha da sua primeira versão, demorou demais para lançar.
  • Minimal Marketable Feature ou MMF é um conceito anterior ao de MVP, que traz a vantagem de trazer essa mentalidade de implementar o mínimo necessário para cada funcionalidade do produto.

No próximo capítulo veremos a importância de nos focarmos em entender bem o problema a ser resolvido antes de pensarmos em soluções.

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: