Estrutura de time

O time de desenvolvimento de produto é quem vai executar a estratégia e atingir os objetivos para alcançar a visão de produto. Por isso, uma parte essencial da definição de estratégia é desenhar e implementar sua estrutura de time. Para isso, é importante entender as diferentes formas de se organizar um time de desenvolvimento de produtos e definir qual a mais apropriada para a sua estratégia.

Times de produto

O time mínimo de desenvolvimento de produto que vimos no capítulo sobre Carreira de gestão de produtos é composto um product manager, um product designer e dois ou mais engenheiros. Esse time mínimo pode também ser chamado de squad e deve ter no máximo umas 7 pessoas. Quanto maior o time, maior a dificuldade de coordenação. Na Amazon existe a famosa regra dos times de duas pizzas, ou seja, o tamanho máximo do time é aquele que consegue ser alimentado por duas pizzas grandes. O racional por trás da vantagem de rodar com times pequenos é baseado no mesmo conceito que apresentei quando falei de plataformas no capítulo O que é produto digital e gestão de produtos?. A quantidade de interações entre os membros do time crescem rapidamente com o tamanho do time, seguindo a fórmula n*(n-1)/2. Assim, enquanto um time de 5 pessoas tem 10 possibilidades de interação entre seus membros, em um de 7 pessoas esse número cresce para 21.

Quando juntamos dois ou mais squads temos um time de produto, que também pode ser chamado de tribo.

Times de produto

Essa tribo de produto pode ter um, dois ou três líderes. Se for uma líder, ela será responsável por liderar product managers, product designers e engenheiros. Se forem dois líderes, normalmente um vai liderar product managers e product designers, e o outro liderará engenheiros. Se forem três, um lidera product managers, outro, product designers e o terceiro, engenheiros. Já tive oportunidade de trabalhar em estruturas com um, dois e três líderes em cada tribo de produto e cada uma dessas estruturas traz seus pontos positivos e negativos, como expliquei no capítulo sobre Carreira de gestão de produtos onde falo sobre liderança única e liderança compartilhada.

Times de produto também podem ter alguns papéis compartilhados entre os squads. Tê-los compartilhados ao invés de dedicados por squad tem três principais objetivos:

  • Tamanho de squad: manter o squad pequeno é importante para conseguir preservar a agilidade desse time. Quanto maior o time, maior a necessidade de coordenação entre os membros do time.
  • Ownership: a partir do momento em que você tem uma pessoa no squad com uma função específica, essa função deixa de ser responsabilidade dos outros membros do time. Por exemplo, se tivermos uma pessoa cuidando da qualidade, esse tema virará responsabilidade dela, e as outras pessoas do squad vão se preocupar menos com o tema. As exceções são as três funções primárias de um squad que são engenharia, design de produto e gestão de produto.
  • Alocação de recursos: além de o squad ficar grande se colocarmos esses papéis dentro dele, necessitando de mais coordenação e tendo o risco de ficar mais lento, cada squad custará mais caro. Com squads menores, temos a possibilidade de alocar os recursos que você tem disponível para desenvolvimento de produto em mais squads que constroem produto.

Exemplos de papéis que podem existir em uma tribo de produto compartilhado entre os diferentes squads:

  • Agile Coach: ajuda os squads em seus processos e cultura ágil. Em vez de um scrum master por squad, tem-se um agile coach por tribo que ajuda os squads nesse tema, mas os processos e a cultura ágil de cada squad é responsabilidade de cada membro do squad.
  • Quality Assistance: assim como processos e cultura ágil são responsabilidade de cada membro do squad, o mesmo acontece com qualidade. Em vez de um quality assurance por squad, podemos ter um quality assistance por tribo de produto, que vai ajudar cada squad com questões de qualidade.
  • Data Analyst: todo squad gera muitos dados e precisa entender o que esses dados querem dizer. De novo, entender o que esses dados significam é uma responsabilidade do squad. Contudo, quando a estrutura de dados é muito complexa, pode fazer sentido ter uma pessoa por tribo de produto ajudando seus squads nas necessidades mais complexas de dados de cada squad.
  • SRE: para produtos com muita integração com sistemas de terceiros pode ser interessante ter um Site Reliability Engineer (SRE) por tribo ajudando os squads a definir e implementar arquiteturas estáveis, com boa performance e resilientes. Na Conta Azul, como tínhamos integração com bancos e com os sistemas das Secretarias da Fazenda de cada estado para emissão de nota fiscal, fez sentido termos uma pessoa com esse conhecimento em cada tribo.
  • User Research: essa é a responsabilidade dos product designers, com apoio dos gestores de produto de cada squad. Em alguns casos, pode fazer sentido ter uma pessoa com foco em research na tribo de produto para ajudar nessas pesquisas de cada squad.
  • Product Marketing: enquanto a missão da gestora de produtos é construir o produto ou funcionalidade que resolve problemas dos usuários, o product marketing tem por missão contar ao mundo sobre o produto ou funcionalidade e o problema que ele resolve. Esse “mundo” refere-se tanto aos usuários do produto quanto aos novos usuários que queremos trazer. É responsável por desenhar e implementar a estratégia de go to market (GTM) do produto. Em muitas empresas essa responsabilidade recai sobre a gestora de produtos. Isso funciona em muitos casos, mas pode tirar seu foco em construir o melhor produto ou funcionalidade.

Há outros papéis que podem ser compartilhados mas lembre-se de que, quanto mais papéis compartilhados tiver, mais difícil ficará a coordenação das pessoas da tribo. Minha recomendação é ter no máximo 3 papéis compartilhados. Eles podem ser liderados pela(s) líder(es) da tribo ou pela líder da tribo estrutural correspondente à sua função.

Organizando times de produto

Existem 4 formas possíveis de se organizar 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. Vou descrever a seguir cada uma:

Por produto ou funcionalidade

É uma das formas mais comuns de organização de times de produto. Para cada produto ou funcionalidade temos uma tribo. Na Locaweb tínhamos time de produto para cada produto, Email Marketing, PABX virtual, cloud, hospedagem de sites e assim por diante. Na Conta Azul também usávamos esse modelo, com um time, o Spartans, focado em funcionalidades relacionadas à gestão financeira e o outro time, o Underground, focado em funcionalidades fiscais e contábeis. Na Lopes, quando entrei, tínhamos um time focado no portal, outro no CRM utilizado pelos corretores e franquias e um terceiro focado no app para corretores.

A principal vantagem desse forma de organização é que a parte do produto que é responsabilidade da tribo é bem clara mas, por outro lado, com o foco no produto perde-se um pouco de perspectiva da(s) pessoa(s) cujos problemas esse produto resolve.

Por tipo de usuário

Esse é um modelo muito útil em marketplaces e plataformas. Cada tribo tem o foco em um ator. Por exemplo, no Gympass, onde tínhamos academias, RH das empresas e funcionários das empresas, tínhamos 3 tribos, cada uma focada nesses três atores do marketplace. Na Conta Azul tínhamos duas tribos focadas no dono do pequeno negócio e duas focadas no contador. Na Lopes desenhamos uma estrutura onde temos uma tribo focada no comprador de imóvel, outra no vendedor e uma terceira focada no corretor, que faz a intermediação.

A vantagem desse modelo de organização é que o foco de cada time é bem definido, visando melhorar a experiência e resolver o problema de cada ator da plataforma. Caso a arquitetura de sistemas seja muito acoplada, pode haver bastante dependência entre os times. Outro ponto de atenção é que algumas jornadas podem ficar divididas entre duas tribos. Por exemplo, no Gympass existe a jornada de fazer check-in em uma academia, que acontece quando o usuário vai até a academia, faz o check-in e a recepção o valida. Em uma organização de time por tipo de usuário, tanto o time de academias quanto o de usuário são responsáveis por essa jornada e devem se coordenar para fazer mudanças nessa parte do produto.

Por jornada

Nesse modelo, os times são organizados de acordo com cada jornada do usuário. Busca, compra, agendamento de aula e assim por diante são jornadas pelas quais seu usuário pode passar ao usar o seu produto. Confesso que nunca vi um time 100% organizado por jornada, mas já vi times organizados por produto ou por tipo de usuário terem uma ou mais tribos focadas em alguma jornada. Por exemplo, na Conta Azul tínhamos um time chamado Hubble que cuidava da jornada do usuário até ele poder usar funcionalidades financeiras, cuidadas pelo Spartans e funcionalidades fiscais e contábeis, cuidadas pelo time Underground. No Gympass, além dos times de usuário, academia e RH da empresa, tínhamos um time, chamado de Cross Features, que cuidava do cadastro de cada um dos participantes do marketplace (usuários, academias e RHs) e de receber o pagamento feito por RHs e usuários, e por fazer o pagamento para as academias. Na Lopes, decidimos criar, além dos times para comprador, vendedor e corretor, um time chamado Leads, que cuida das interações entre comprador e corretor. Na Locaweb criamos o time de sistemas centrais, depois renomeado para enterprise applications, responsável pela central do cliente, onde o cliente da Locaweb pode ver e administrar todos os produtos contratados.

A principal vantagem dessa estrutura é que o foco em uma jornada aumenta a chance de proporcionar uma ótima experiência naquela jornada específica. Por outro lado, normalmente um squad é suficiente para cuidar de uma jornada, então você pode acabar com muitas tribos de um só squad.

Por objetivo

A organização por objetivo significa que a tribo tem foco em um objetivo específico. Conversão, retenção, experiência de uso etc. Não conheço nenhum time 100% estruturado somente por objetivos. No Gympass usávamos esse modo de organização no time de usuário quando o dividimos em duas tribos, uma focada em crescimento, que tinha por objetivo garantir que os funcionários dos clientes baixassem o app, criassem a conta gratuita e se tornassem assinantes e a outra focada em experiência digital para garantir que os usuários utilizassem e tirassem o maior proveito possível do app, garantindo a satisfação e a retenção destes.

Nesse tipo de organização, o principal benefício é o foco no lugar aonde você quer chegar, o objetivo. A desvantagem é que você pode ter dois squads com objetivos diferentes lidando com a mesma área do produto, o que pode causar uma experiência estranha para o usuário. Outra desvantagem é que, se a arquitetura de sistemas estiver muito acoplada, pode haver muita dependência entre as equipes.

Prós e contras dos diferentes tipos de organização de times de desenvolvimento de produto

Híbrida

Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, ou seja, não são exclusivas. Na verdade, nunca vi uma equipe de desenvolvimento de produto usando exclusivamente um tipo de organização. As equipes são estruturadas em organizações híbridas. Veja a seguir alguns exemplos de organização híbrida.

Na Locaweb tínhamos times por produto (Hospedagem, Email Marketing, Cloud etc.) e um time focado na jornada do cliente (Central do Cliente)

Times de produto da Locaweb (2016)

Na Conta Azul usávamos organização por funcionalidade. Um time para gestão financeira do pequeno negócio (Spartans) e outro para gestão fiscal e contábil (Underground). Um para gestão fiscal, contábil e de folha dos clientes do contador (Area 42) e outro para gestão de clientes do contador (Babilônia). Também organizávamos por tipo de usuário (times focados no dono do negócio e no contador) e por jornada (Hubble).

Times de produto da Conta Azul (2018)

No Gympass definimos os times por tipo de usuário (usuário final, academia e RH), mas também usamos a organização por jornada para criar o time de Cross Features, responsável pelo cadastro de cada um dos participantes do marketplace (usuários, academias e RHs), por receber o pagamento feito por RHs e usuários e por fazer o pagamento para as academias. E usamos também a organização por objetivos quando quebramos o time de usuário final em duas tribos, uma de crescimento e outra de experiência digital.

Times de produto do Gympass (2019)

Na Lopes também definimos os times por tipo de usuário (cliente final, incorporador & proprietário, corretor & franquia) e definimos uma tribo focado na jornada entre cliente e corretor, que chamamos de Leads.

Times de produto da Lopes

É importante ressaltar que esses exemplos são da época em que trabalhei nessas empresas. Da mesma forma que a visão e estratégia de produto evoluem, a estrutura de times também deve evoluir.

Organizando squads em um time de produto

Essas formas de organização de times de produto servem tanto para definir a organização entre tribos, bem como a organização dos squads de uma tribo. Alguns exemplos:

  • Hospedagem de sites (Locaweb): dentro do time de hospedagem de sites da Locaweb tínhamos 3 squads, um focado em hospedagem Windows, outro em hospedagem Linux e um terceiro com foco no painel de controle de gestão da hospedagem.
  • Academias (Gympass): no time focado em academias do Gympass tínhamos um squad focado em APIs para integração com sistemas de gestão para integração de processo de check-in dos usuários e de reserva de aulas e outro squad focado na experiência do gestor da academia, para que ele pudesse ter acesso a relatórios e configurar como sua academia apareceria no app do usuário.
  • Financeiro (Conta Azul): no time focado em gestão financeira do Conta Azul, tínhamos um time focado em integração com os bancos para receber dados de extrato bancário dos clientes, um outro focado na interface de gestão financeira, com relatórios e sistema de categorização dos lançamentos do extrato e um terceiro focado em uma funcionalidade que tinha nome próprio, o Receba Fácil, sistema de emissão de boleto bancário.

Times estruturais

Times estruturais são os times que trabalham na estrutura necessária para os times de produto poderem fazer seu trabalho.

Times estruturais

Alguns tipos de times estruturais necessários no desenvolvimento de produtos digitais:

  • SRE ou DevOps: SRE significa Site Reliability Engineering. Essa área, às vezes chamada de DevOps, é responsável pela infraestrutura onde o produto será hospedado e servido aos clientes. Responsável também por monitorar o produto e a infraestrutura de hospedagem para garantir que ele opere com a performance ideal.
  • Dados: aqui temos normalmente 3 disciplinas que precisam ser cuidadas pelo time de dados. Primeiro, é necessário um time de engenharia de dados que cuide da infraestrutura necessária para gestão dos dados da empresa. Em seguida, é necessário um time de análise de dados, responsável por gerar relatórios e dashboards com base nos dados e mostrando a performance do produto. Por fim, é interessante ter também um time de cientistas de dados capaz de tirar insights dos dados e eventualmente criar algoritmos de machine learning que possam evoluir à medida que mais dados são coletados e analisados.
  • Arquitetura/Ferramentas/Fundação: time que ajuda os times de produto a definirem os padrões de arquitetura de software. Esse time também pode trabalhar em temas que são comuns a todos os times como, por exemplo, autenticação e autorização, e infraestrutura de APIs.
  • Design Ops: time central de design que cuida de criar e manter o Design System, biblioteca de componentes e padrões de interação. Essa equipe também pode cuidar da eficiência operacional dos product designers, dando-lhes ferramentas, capacitando os gestores e líderes para avaliar o desempenho desses product designers e auxiliando no onboarding. Nesse time também podem ficar profissionais de user research e de UX writing.
  • Segurança da Informação: responsável por todos os aspectos de segurança da informação, tais como LGPD, certificação PCI, certificação ISO 27001, políticas de BYOD (bring your own device) para permitir que os funcionários utilizem seus próprio devices para o trabalho.
  • Sistemas Internos: responsável por cuidar dos sistemas de terceiros, tais como Google Suite, Office 365, Slack etc., bem como dos equipamentos da empresa.
  • Engenharia de Vendas: essa área faz bastante sentido em empresas que desenvolvem produtos para outras empresas. É um time com conhecimento técnico capaz de discutir detalhes de implementação e integração do seu produto com os sistemas do cliente.
  • Serviços Profissionais: caso as necessidades de implementação e de integração do novo cliente fujam do padrão, ou o cliente não esteja preparado para fazer essa implementação ou integração, pode ser interessante ter um time de serviços profissionais que faça esse trabalho. O recomendado é que esse time seja bem enxuto e utilize terceiros conforme a demanda para fazer o trabalho de implementação e integração.
  • HRBP e contratação: como visto acima, times de produto e suas estruturas são complexos, com muito trabalho colaborativo e com estruturas matriciais. É essencial ter um time de RH por perto para ajudar na gestão do time, com dois focos. HRBP, ou Human Resources Business Partners ajuda no dia a dia dos times e líderes em todas as questões ligadas à RH. Contratação, no inglês talent acquisition é responsável por todo o processo de atração e contratação de pessoas para o time.

Implementação

A implementação da estrutura de produtos que foi desenhada pode acontecer de duas formas. Ou você está criando uma estrutura do zero, ou você está ajustando uma estrutura já existente.

Criando uma nova estrutura

Quando você cria uma estrutura do zero, você tem a oportunidade de crescer de acordo com as necessidades. Você pode começar com um único squad, depois criar o segundo e assim por diante. É importante você ter em mente aonde você deseja chegar com essa estrutura. Você terá times estruturais? Quais? Que times de produto você pretende ter?

Recomendo também começar a montar esses times pelos seus líderes, para que eles possam ter a oportunidade de contratar e formar os times conforme suas necessidades, desde que alinhados com a visão que você desenhou.

Mudando uma estrutura existente

Quando você chega para liderar um time já formado, é importante ter clareza da visão de produto, da estrutura atual e das pessoas que fazem parte desse time. Você precisará fazer várias conversas para entender bem esses três aspectos antes de propor mudanças na estrutura atual. Assim que você desenhar uma primeira versão da sua proposta, apresente-a como trabalho em progresso para algumas pessoas para colher feedback e ir ajustando.

Uma vez acordada a nova estrutura, coordene com as pessoas dos times para fazer a mudança. Pode ser que alguns times que serão mexidos estejam terminando de fazer algumas coisas, então é importante alinhar com essas tarefas pendentes para permitir uma transição mais suave da estrutura atual para a nova.

Qual é a melhor proporção entre Eng, UX e PM?

Podemos encontrar muitos artigos de diferentes equipes de desenvolvimento de produto ao redor do mundo mostrando benchmarks de relações Eng:PM e UX:PM. Há um artigo recente de Ken Norton, parceiro do Google Ventures e ex-líder de gestão de produto do Google e do Yahoo!, onde ele compartilha os resultados de uma pesquisa informal que fez no Twitter:

Uma maioria significativa dos tweets recomendou algo na faixa de 5 a 9 engenheiros para cada PM. Houve motivos pelos quais as pessoas recomendaram ter mais ou menos, mas entre 5 e 9 parece ser o ideal. Pensando em minha própria experiência, minhas equipes de melhor desempenho também se enquadraram nessa faixa.

Quando se trata de designers, prefiro uma proporção de 1:1 com PMs para equipes de produtos focadas no usuário. As equipes de produto funcionam melhor quando a tríade dedicada de PM, designer e líder de tecnologia forma o núcleo.

Portanto, parece que a recomendação geral é de 5 a 9 engenheiros por PM e 1 UX por PM. Aqui, quando contabilizamos as pessoas de engenharia, devemos também considerar as pessoas dos times estruturais.

Alguns números da vida real

No Gympass, trabalhamos para aumentar o número de engenheiros por gestores de produto. Em nossos esforços para aumentar a equipe de 32 para 85 pessoas em 5 meses conseguimos aumentar a relação Eng:PM e também a relação UX:PM. Nosso plano era chegar ao final de 2019 com quase 200 pessoas em nossa equipe de desenvolvimento de produto, com ainda mais engenheiros por gerente de produto e um melhor equilíbrio entre designers de UX e gerentes de produto, como acabou acontecendo.

Gympass

Todos os benchmarks são claros quando explicam que cada gestor de produto deve ser pareado com um UX, especialmente para produtos voltados para o cliente. No caso do Gympass, são 3 tipos diferentes de clientes (usuários finais, academias e clientes corporativos) o que reforça a necessidade de manter a proporção recomendada de 1 product designer por gerente de produto.

Na Conta Azul já tínhamos uma boa relação Eng:PM quando entrei em agosto de 2016. No entanto, a relação UX:PM estava abaixo dos padrões de mercado. Principalmente levando em consideração que um dos 4 valores fundamentais da Conta Azul é entregar o “Uau” aos clientes. Por esse motivo, trabalhamos para aumentar a proporção de designers de experiência do usuário em relação aos gestores de produto para aumentar o “Uau” entregue aos clientes.

Conta Azul

Na Locaweb, muitos produtos que construímos eram para engenheiros de software. Hospedagem de sites, hospedagem de banco de dados, SMTP, Servidores cloud e servidores dedicados. Por isso, o número de engenheiros por gestores de produto é maior que o da Conta Azul e do Gympass. É ainda maior do que o limite superior recomendado de 9 engenheiros por gestor de produto. No entanto, podemos ver um fato interessante na proporção de designer de UX por gestor de produto. Como visto nos números de agosto de 2015, uma proporção maior de Eng:PM força um aumento em UX:PM em comparação à proporção de 1:1 recomendada. Quando olhamos os números de julho de 2016, temos mais engenheiros por gestores de produto, chegando a quase 12 Eng:PM, o que fez aumentar a proporção UX:PM para quase 2:1. Tivemos que colocar 2 designers de UX para cada gerente de produto para que eles pudessem lidar com todo o trabalho de discovery que precisava ser feito para que os engenheiros pudessem construir o produto certo. Considerando os engenheiros como responsáveis pelo delivery e UX e gestores de produto como discovery, isso nos mostra que tínhamos cerca de uma pessoa de discovery para cada 4 de delivery.

Locaweb

Lei de Conway

A Lei de Conway foi criada por Melvin Conway, cientista da computação americano, e publicada pela primeira vez em abril de 1968, em uma revista de Tecnologia da Informação bastante conhecida na época chamada Datamation. A Lei de Conway diz que:

Lei de Conway

Qualquer organização que desenvolve um sistema produzirá um sistema cuja estrutura é uma cópia da estrutura de comunicação da organização.

Já vi situações em que um time de desenvolvimento de produto é organizado em paridade com as áreas de negócio, ou seja, um time é focado nas necessidades do atendimento ao cliente, outro é focado no time de vendas, outro é focado no financeiro, mais um focado no marketing, e assim por diante. Não recomendo esse tipo de estrutura, pois diminui o foco no cliente.

Os estágios de Tuckman de evolução de times

Bruce Tuckman, um pesquisador americano sobre dinâmica de grupos, propôs em 1965 quatro estágios pelos quais passa um grupo de pessoas que começam a trabalhar juntas, e como esses estágios impactam na eficácia desse grupo.

Os 4 estágios de Tuckman para formação de times
  • Formando (forming): nesse estágio, as pessoas do grupo estão se conhecendo, entendendo os objetivos comuns e buscando formas de trabalharem juntas.
  • Confrontando (storming): em seguida, acontecem alguns confrontos, quando o grupo começa a discutir sobre como o trabalho será feito e começa a conhecer as habilidades de cada pessoa no grupo.
  • Normatizando (norming): esse é o momento em que os membros do grupo definem o processo de trabalho e os papéis e responsabilidades de cada membro do time. Nessa fase os membros do time já se conhecem melhor e respeitam as habilidades uns dos outros.
  • Performando (performing): é nesse momento que o time de fato começa a produzir e a entregar resultados. O time já se conhece bem, o processo de trabalho é claro e acordado entre todos os membros do time.

Não há uma melhor forma de se estruturar um time de produto. Há aquela que faz mais sentido para a estratégia e objetivos definidos para atingir a visão de produto. Por isso, a estrutura de time não é escrita em pedra. Se houver necessidade, por mudança de objetivos ou de estratégia, pode fazer sentido mudar a estrutura do time. Contudo, não recomendo fazer isso com muita frequência, devido ao tempo necessário para um time recém-formado passar pelos estágios de Tuckman. Ouvi certas pessoas comentando que trabalham em empresas que mudavam a estrutura de time de desenvolvimento de produtos a cada 3 ou 6 meses. Não é tempo suficiente para passar pelos estágios de Tuckman.

Unidades de negócio

Em algumas situações, em vez de ter times de produto separados, mas dentro da mesma organização, pode ser interessante criar unidades de negócio razoavelmente independentes. Em unidades de negócio, temos não só um time de desenvolvimento produto separado, como todas as áreas necessárias para o negócio acontecer de forma independente tais como marketing, vendas, atendimento ao cliente etc.

Na Locaweb optamos pelo modelo de unidades de negócio independentes quando adquirimos empresas. A Tray era uma empresa de soluções de ecommerce que passaram a fazer parte do portfólio de produtos da Locaweb. Como a Tray já operava como uma empresa independente, optamos por mantê-la dessa forma, somente tendo as áreas de administração, financeiro e RH em comum. Essa é uma maneira bem comum de criar áreas de negócio, por meio de aquisições de empresas.

No Gympass vislumbramos a oportunidade de criar um novo produto chamado Gympass Wellness, que oferece serviços de bem-estar tais como aplicativos de atividade física, de nutrição e de meditação para os funcionários dos clientes do Gympass. Optamos por iniciar esse novo produto como uma unidade de negócios, com time de produto, de marketing e de vendas independente do Gympass, visando dar maior autonomia e agilidade para esse time.

Na Lopes temos a CrediPronto, unidade de negócios que é uma joint-venture entre Lopes e Itaú para oferecer crédito para compradores de imóveis. Pelo fato de a natureza do negócio ser completamente diferente do negócio principal de transação imobiliária e ainda por ter um novo sócio, optou-se pelo modelo de unidade de negócio.

O que faz um grupo de pessoas se comportar como um time?

Não é suficiente organizar as pessoas na estrutura de equipes descrita aqui para que se comportem como uma equipe. Para que se percebam como uma equipe e passem a atuar como tal, precisam de objetivos comuns.

Um problema muito comum que vejo nas equipes de desenvolvimento de produto é que, mesmo sendo muito bem organizados em tribos e esquadrões, com tribos estruturais e tribos de produtos, e as pessoas certas com as funções certas em cada equipe, os objetivos são definidos por função. Os gerentes de produto têm um conjunto de objetivos diferente dos de designers de produto, que são diferentes dos objetivos dos engenheiros. Isso simplesmente não funciona, porque cada pessoa se concentrará nos seus próprios objetivos.

Se definirmos todos os objetivos como sendo comuns a todos os membros da equipe, todos eles trabalharão juntos para atingi-los. Mesmo que o objetivo pareça mais relacionado a um dos aspectos, como mais relacionado ao negócio (gerente de produto) ou à experiência do usuário, ou mais relacionado à engenharia, todos os membros da equipe devem ter os mesmos objetivos.

Então, a resposta curta para a pergunta “O que faz um grupo de pessoas se comportar como uma equipe?” são objetivos comuns.

Resumindo

  • Times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiros, product designers e product managers. É importante deixar esses times 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.
  • A implementação da organização de time desenhada pode ser feita ou criando uma nova estrutura ou ajustando um time já existente. Em ambas as situações é importante conhecer bem a visão e a estratégia de produto para desenhar e implementar uma estrutura de time alinhada com ela.
  • A proporção mais indicada entre pessoas em engenharia e gestores de produto é de 7 +/- 2 engenheiros para cada gestor de produto. E de um product designer para cada gestor de produto.
  • Dois conceitos importantes no desenho de sua estrutura de time são o da Lei de Conway, que diz que as organizações tendem a criar sistemas que são uma cópia da estrutura de comunicação das empresas, e os 4 estágios de Tuckman de formação de times, formando, confrontando, normatizando e performando.
  • É possível também organizar times de produto por unidades de negócio que tenham outras funções além das compreendidas em um time de desenvolvimento de produto, tais como marketing, vendas e atendimento ao cliente. As motivações para criar unidades de negócio em vez de times de produto podem ser devido à aquisição, ou para dar mais agilidade ao novo negócio ou mesmo por se tratar de uma nova linha de produto completamente diferente do produto original.
  • O que faz um grupo de pessoas se comportar como um time são os objetivos comuns.

No próximo capítulo vamos ver um pouco mais sobre desenvolver o time e gerenciar expectativas.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Metrics

By now you should have realized how much I like metrics. In my first book, Startup Guide: how startups and established companies can create profitable digital products, I dedicated 6 entire chapters in addition to talking about metrics in the other chapters. In my second book, Product management: how to increase the chances of success of your digital product, there are 5 chapters dedicated to the theme of metrics, in addition to this theme appearing in other parts of the book again. It is no different here, the last two chapters talked a lot about metrics and I have also spoken in some other chapters about OKRs, objectives, data, and results.

Metrics are fundamental tools for any head of a product development team. Without metrics it is impossible to know if the team is progressing, evolving and fulfilling its mission. However, it is very easy to get lost in huge amounts of metrics.

In this chapter I want to share a little bit about how I usually work with metrics.

Metric types

I classify metrics into 3 major groups:

Internal metrics

These are the metrics that show how the product development team is at the moment and has evolved. The previous two chapters showed the metrics of productivity and quality. These are metrics that help the head of product and the team to understand how the work process is doing and where they should focus the energy to improve on these metrics. How can we increase productivity? How do we decrease the number of bugs? How do we guarantee the best product performance for our users?

Still within the theme of internal metrics, there are others that are more “soft” but also very important for you to understand the health of your product development team. They are metrics that help you understand if people are happy working in this team, if they are aligned with the culture and purpose of the team and the company.

A very simple metric to follow is the entry, exit and average time of the people of the team each month. If more people leave than enter, there may be a problem with the team. If people stay a few months and then leave, it is another point of attention. You can also run an NPS survey (Net Promoter Score) with team members periodically to understand whether they would recommend working on your team for others and why they answered this way.

The following are two examples from Gympass. The first is the evolution of the total number of people on the team month by month, with total new and total people who left, also showing how many of those left voluntarily, that is, asked to leave. The second is the eNPS (employee NPS), which shows whether people were willing to refer the Gympass product development team to their friends to join us.

volution of the Gympass product development team
NPS from Gympass product development team

User metrics

These are the metrics that show that your product is being used by users, that is, that it is fulfilling its objective. These are the metrics of engagement and user satisfaction with the product. What is your user’s ideal engagement with the product?

At Conta Azul we wanted the product to be the first window he opened in his browser in the morning and the last he closed at night. We tracked the number of invoices issued per user per week, per month, and the amount of the invoices. At Gympass, we monitored how many users went to the gym per month, how often they visited gyms, and so on. At Lopes, we are monitoring the use of the new CRM by brokers. We want them to use it at least 4 times a week and that’s the number we’re tracking.

Another user metric that can be useful is satisfaction metrics. This metric tends to be a little more subjective, in addition to being laborious to measure. You should send a mini-survey to a portion of your customers every day. Therefore, before measuring and monitoring it, I recommend closely monitoring the engagement with the product. If the user is engaged, using the product at the expected frequency, there is a good chance that he will be minimally satisfied.

Business metrics

These are the metrics that show the product development team is actually delivering value to the business owner. What was the goal that the business owner had for the product? Increase sales, decrease costs? These goals vary with the type of company where the digital product is located. Is it a digital company, a traditional company, or a traditional born-digital company?

At Conta Azul, as the product sold was the digital product, user metrics and business metrics mix a lot. The number of users that use several times a week are those that will certainly continue to pay the monthly subscription and, consequently, will continue to generate revenue.

At Gympass, a traditional company born-digital, and at Lopes, a traditional company, revenue exists without the need for a digital product. So, what can the digital product do to increase revenue or decrease costs? At Gympass, at the same time that we wanted to reduce operating costs by automating most manual tasks, we also used the product as a revenue enhancer, helping the HR of our customers and their employees to understand and, consequently, become subscribers to the service. At Lopes, the main focus is on increasing sales, but we also have a focus on how to lower operating costs.

A very important point to monitor every month is the comparison between the value delivered by the digital product – revenue increase and cost reduction – and the cost of product development. What is expected is that the value delivered will be greater than the development cost. And managing this is the role of the head of product.

Tracking metrics

Metrics can be tracked daily, weekly, monthly, quarterly and yearly. Of course, the longer the update period, the more difficult it is to understand the metric’s behavior and make decisions about how to impact it. I prefer metrics that we can monitor daily and weekly. With weekly metrics, in a quarter we have 13 opportunities to evaluate a metric, understand how we can work on it and remove any impediments that are hindering us in reaching any objective linked to it. And the daily metrics give the pulse of the business. How many new users per day? How many users canceled?

At Locaweb, we always followed these numbers daily and, if something was out of the expected, positively or negatively, we tried to understand what had happened that had impacted the number. When we did something with the intention of changing these numbers, such as a new marketing or retention campaign, we could monitor these results daily. It is even possible to measure even more frequently in the case of products with large scale, such as Google Search.

On the other hand, there are metrics that are less frequent, such as the example above that I gave of new people joining or leaving a product development team. Even with monthly metrics or less frequent ones, I recommend monitoring the partial of this metric at least weekly. If you only follow up monthly, in a quarter you will have only 2 opportunities to assess progress and correct the course.

Summing up

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

In the next chapter, we’ll look at how to manage relationships with different areas.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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

Estratégia e objetivos

O que precisa ser feito para que seu produto se aproxime da visão de produto? São sua estratégia e seus objetivos. Estamos falando em definir o que fazer, como fazer, em que ordem e que métricas nos dizem que estamos indo na direção certa, uma vez que o motivo por que fazer já foi definido na visão de produto.

A estratégia e os objetivos provêm um caminho a ser seguido e as métricas que mostram se estamos ou não no caminho certo. Sem isso claramente definido é muito difícil definir qual o time mais apropriado e o que precisa ser feito para atingir esses objetivos.

Criando sua estratégia de produto

Como você já tem clareza da sua visão de produto, você precisa entender o que é preciso fazer para executá-la para chegar aonde você quer chegar. A seguir estão algumas ferramentas que ajudarão você a criar sua estratégia de produto:

Análise de mercado

Para criação da sua estratégia, você precisa ter um bom entendimento do seu mercado em relação a cinco aspectos:

Concorrentes: tanto os diretos quanto os indiretos, ou seja, aqueles que competem pelo tempo e atenção do seus usuários. Por exemplo, um concorrente da atividade física são os serviços de streaming, que motivam seus usuários a assistirem cada vez mais vídeos.

Mercado potencial e acessível: quanto mercado, ou seja, quantas pessoas poderiam ser seus clientes? Para poder ser seu cliente, existe algum requisito mínimo? Por exemplo, se você vende um curso online para estudantes de medicina se prepararem para o processo de avaliação para ingressar em um programa de residência médica, seu mercado potencial são todos os estudantes de medicina dos últimos anos de graduação. Esse é seu mercado potencial. E desse total de pessoas, com quantas você de fato consegue falar e mostrar seu produto, e que vão querer usá-lo? Esse é seu mercado acessível.

Crescimento do mercado: o número de pessoas com potencial de usar o seu produto está crescendo, estável ou diminuindo? E o número de pessoas com quem você consegue falar sobre o seu produto? É muito importante você entender se o mercado que você enxerga para o seu produto está crescendo, estável, ou diminuindo, e se esse movimento é de curto ou longo prazo. Entender como o seu mercado está se comportando é fundamental para ajudar a definir sua estratégia.

Disruptores: tão importante quanto conhecer seus concorrentes diretos e indiretos, é preciso conhecer que produtos podem disromper o seu produto, ou seja, substituir o benefício que seu produto entrega de uma maneira melhor e mais atraente para seus usuários. Por exemplo, as pessoas estão usando cada vez menos email em função das opções de comunicação que produtos de mensagem direta como WhatsApp e Slack têm oferecido.

Regulamentação: seu mercado é regulado? Você conhece essa regulação? Houve mudanças nessa regulação? Por exemplo, na conta Azul monitorávamos diariamente a regulação fiscal e contábil para garantir que o produto estivesse alinhado com essas regulações.

Esse trabalho deve ser coordenado pelo head de produto em conjunto com a liderança de marketing. Provavelmente esse tipo de análise tem sido feito de forma pontual. Minha recomendação é transformar a análise de mercado uma disciplina permanente, isto é, uma vez criada a primeira versão com os itens acima, atualizar mensalmente para garantir ter as informações mais atualizadas sobre o seu mercado.

Análise SWOT

De posse da sua análise de mercado, o próximo passo é entender a posição do seu produto nesse mercado. Tanto a posição atual, quanto a posição que você deseja ocupar quando tiver executado sua visão de produto. Uma boa ferramenta para ajudar nesse entendimento é fazer uma análise SWOT, sigla em inglês para Strengths, Weaknesses, Opportunities and Threats, ou pontos fortes, fracos, oportunidades e ameaças do seu produto. Já encontrei versões em português com o nome FOFA – pontos Fortes, Oportunidades, Fraquezas e Ameaças.

Análise SWOT

Os pontos fortes e os pontos fracos são itens internos (do seu time de desenvolvimento de produto, ou da sua empresa) sobre as quais você, seu time ou sua empresa têm algum controle, que ajudam ou atrapalham o seu produto para atingir a sua visão. As oportunidades e ameaças são os elementos externos à organização, isto é, sobre os quais a organização não tem controle, e que podem influenciar positiva ou negativamente no atingimento da visão do produto. Tem a ver com a análise de mercado descrita anteriormente.

Preencher o SWOT deve ser um trabalho de equipe. O head de produtos deve ter uma ou mais sessões junto a pessoas que podem contribuir para essa análise. Líderes do seu time e de outras áreas são a audiência indicada para esse tipo de sessão. Como organizar uma sessão de análise SWOT:

  • Lição de casa: peça para todos preencherem cada um uma análise SWOT. Limite a, no máximo, três itens por quadrante. É comum, principalmente no quadrante das fraquezas, as pessoas criarem uma lista bem grande de itens, não raro com mais de 10 fraquezas. Ao pedir para limitar por 3 itens por quadrante, as pessoas serão forçadas a fazer uma primeira priorização.
  • Consolidação: junte todas as análises SWOT em uma única. Haverá algumas sobreposições e algumas diferenças. Coloque os itens em cada quadrante com a quantidade de pessoas que colocou cada item em sua análise SWOT individual. Essa quantidade pode servir como um primeiro indício de priorização.
  • Versão final: junte as pessoas em uma conversa para avaliar a versão consolidada. O objetivo agora é fazer a versão consolidada também ter no máximo 3 itens por quadrante para forçar a todos a mais uma vez priorizar. Normalmente uma única sessão pode ser suficiente para construir essa versão final.

Uma vez tendo sua versão final da análise SWOT, você tem 12 itens que podem servir de foco da sua estratégia. Digo que “podem” pois você não precisa trabalhar em todos os itens ao mesmo tempo. Aqui, mais uma vez, entra a capacidade de priorização, lembrando que o SWOT foi feito para nos ajudar a mostrar o caminho que precisa ser percorrido para atingirmos nossa visão de produto.

  • Pontos fortes: como mantê-los relevantes? É preciso fazer algo para reforçá-los? Algum dos pontos fortes é mais importante que os outros?
  • Fraquezas: como diminuir o impacto das fraquezas? Qual dessas fraquezas tem impacto maior?
  • Oportunidades: é possível explorar as oportunidades? O que podemos fazer para isso? Qual é mais relevante para a execução da visão de produto?
  • Ameaças: o que devemos fazer para nos proteger das ameaças? Como essas ameaças impactam a execução da visão de produto?

Essas discussões também devem ser feitas em grupo, e podem até mesmo ser feitas na continuação da criação da análise SWOT. Com isso você já terá um alinhamento entre a liderança das diferentes áreas sobre a estratégia de produto.

OKR

OKR vem do inglês Objective and Key Results, objetivos e resultados principais. É uma ferramenta de gestão que serve para alinhar e acompanhar a execução da estratégia. Essa ferramenta é usada no Google desde seu início e foi levada para lá por John Doerr, um funcionário da Intel, empresa onde foi criada. Várias empresas de tecnologia hoje usam OKRs, tais como Locaweb, Conta Azul, Gympass, Linkedin, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify. OKR é um framework derivado de uma técnica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954.

É uma ferramenta bastante simples e poderosa. Você define junto do 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. Cada objetivo poderá endereçar um ou mais itens de sua análise SWOT ou representar algo que vocês querem executar da sua visão.

Por exemplo, digamos que um de seus objetivos seja “Atingir recordes de compras por mês em nosso site”. Para atingir esse objetivo, você pode definir as seguintes métricas:

  • Aumentar de 15.000 para 20.000 visitas por semana.
  • Melhorar a taxa de conversão de 4,5% para 6%.
  • Diminuir o bounce rate de 35% para 20%.
  • Melhorar o tempo de carregamento das páginas para menos de 2 segundos.

O time deve olhar os OKRs todas as semanas para ver se as métricas estão mexendo e entender se há algum impedimento a ser removido ou algo a ser feito para acelerar o atingimento dos objetivos. Entregas e medições mais frequentes ajudam. Se houver entregas e medições apenas mensais, o time só terá duas chances no trimestre para testar sua ideia de como mexer a métrica. Se houver entregas e medições semanais, são 12 oportunidades de avaliar e mudar o rumo se necessário.

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

Pronto, você agora tem a estratégia de seu produto, os objetivos que você quer alcançar e as métricas que dirão se você está atingindo seus objetivos. Seu próximo passo será definir a estrutura de time mais apropriada para executar sua estratégia e atingir seus objetivos, tema do próximo capítulo.

Revisando sua estratégia de produto

Um ponto importante é que seu produto evolui à medida que o time trabalha nele e você se aproxima da sua visão de produto. Muito se aprende sobre os usuários do produto, seus problemas e necessidades e com isso novas alternativas podem aparecer para ajudar seu usuário a resolvê-los. O dono do produto também pode revisitar seus objetivos estratégicos e, consequentemente, revisitar os objetivos definidos para o produto digital.

Além disso, pontos fortes e pontos fracos podem mudar com o tempo, e oportunidades e ameaças podem aparecer ou sumir. Por isso, é importante entender que nem a visão, nem a estratégia, nem os objetivos do produto estão escritos em pedra. Elas podem e devem ser revisitadas periodicamente. Minha sugestão é isso seja feito anualmente, ou quando algum evento relevante acontecer, como quando houver uma mudança nos objetivos estratégicos da empresa, ou quando aparecer uma alternativa que resolve o problema ou necessidade do usuário de uma forma diferente da do seu produto, ou quando acontece uma crise como a pandemia da COVID-19. Já para os OKRs, minha sugestão, como comentado anteriormente, é que eles sejam definidos trimestralmente e revisados semanalmente. Isso dará ao seu time uma boa cadência de execução.

Resumindo

  • 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 esse mercado é regulado.
  • Utilize a análise SWOT para ajudar a definir que pontos você vai trabalhar em sua estratégia de produto.
  • Utilize OKRs para ajudar a definir os objetivos de sua estratégia e as métricas que dirão se você está no caminho correto.
  • Revise pelo menos anualmente, ou quando houver eventos relevantes no mercado, a sua estratégia e sua visão de produto. O mercado muda, seu produto evolui, então sua visão e estratégia de produto também deve evoluir. Os OKRs devem ser revistos trimestralmente.

No próximo capítulo vamos ver diferentes formas de estruturar o time de desenvolvimento para poder executar a estratégia de produto a fim de atingir a visão de produto.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Measuring and managing quality

In 2015, we decided to extinguish the Quality Assurance (QA) function of our Locaweb product development team. We had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the QA role, some of the QAs became devs, while others took on the role of system administrators. The reasons that led us to extinguish Locaweb’s QA function were:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the functionality is ready, now it is in the QA phase”, which denotes a cascading product development culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA detect this bug?”, Which denotes a culture of finding the culprits. This culture can be very detrimental to the engagement and motivation of the team and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of a person or team, it should be the concern of everyone working on creating the software.
  • Quality is a non-functional requirement, that is, it specifies a criterion to evaluate the functioning of a digital product, while a functional requirement specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions to guarantee performance, guarantee scalability, guarantee operability and guarantee monitorability. Why is quality the only non-functional requirement that has a specific dedicated function to guarantee it?
  • Quality control focuses on ensuring the quality of the software development process. If a separate function is needed to guarantee this quality, why is there no need for a separate function to guarantee the quality of the product management process, the design process, the product marketing process, the sales process, the finance processof a company?
  • There was a concern that, if the engineer himself now had to test, deliveries would take longer to be ready. This concern existed because the engineers considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, the engineer’s definition of ready is incorrect, as he has just passed the story on to the next phase, the test. From the user’s point of view, the story is only ready when the user can use the new feature. Therefore, the time that the delivery remains in quality control is still development time, even though it is no longer in the hands of the engineer. And that time gets even longer when the story goes through quality control, but it is rejected and needs to go back to engineering.

When I joined the Conta Azul, they had also just extinguished the role of QA, and the ex-QAs became business analysts, mainly helping product managers.

I saw other companies also discussing the need for QAs, and in some cases, a heated debate emerges around this topic. However, having or not having QAs should not be the focus of the discussion. Having or not having this function is the solution to a problem, usually referred to as “how can we improve the quality of our product?”, And that problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search for software quality will yield tons of definitions typically related to meeting functional and non-functional requirements. When the software does not meet a functional or non-functional requirement, it has a defect, a bug. Therefore, to improve the quality of a software product, we need to work on two things:

  • reducing existing bugs;
  • not generating new bugs.

A good way to track this is to have a weekly measurement of your bug inventory and new bug creation per week and discuss this every week with the team. We did that at Gympass. We define at the beginning of each quarter what the target is for the bug inventory and the average new bugs per week.

Total amount of bugs at Gympass

The image shows the evolution of our bug inventory during the 2nd quarter of 2019. We started the quarter with 215 bugs in our stock and we aimed for a target of less than 166 at the end of the quarter, a reduction of almost 23%. We ended the quarter with an inventory of 136 bugs, a reduction of 36%. We did this by focusing not only on resolving bugs in our inventory, but also on controlling the number of new bugs per week.

Number of new bugs detected per week at Gympass

In the first quarter of 2019, we had an average of 26.2 bugs created per week. During the second quarter, we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. This is a 33% reduction in the number of new bugs per week.

That looks like a pretty good improvement, right? But there is a lot of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug stock from 215 to 136, it means that we have resolved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, a lot of bug fixing work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed out on the bug inventory.

An additional aspect of the bug resolution to be measured is the SLA (Service Level Agreement) resolution, that is, how many days the team took to resolve a bug from the day the bug was first identified. For this, we classify the bugs by their severity, which is the impact it has on users and the business. The most serious bugs are those that we need to resolve on the same day; high severity errors, in 7 days and average severity, in 14 days. The following chart shows how we were at Gympass in the fourth quarter of 2019.

Gympass bug resolution SLA

This is not the ideal way of viewing this info because it shows only an image of the moment, and not an evolution. To understand the evolution of any metric, you need to see how it did at different points in time.

As soon as I joined Lopes, I started bringing this topic up for discussion with the teams. One of the things we noticed is that 50% of deployed items were bug fixes. I was informed that “these bugs were caught before going into production, which is a good thing”. In fact, it is a good thing that these bugs did not reach the production environment and appeared to our users. However, they reached pre-production and needed to be corrected. Wouldn’t it be better if these errors didn’t even exist, not even in pre-production?

The OKRs we defined to help us with the quality theme were 3 additional KRs in order to Increase the cadence of deploys in production that I mentioned in the previous chapter:

  • KR: Reduce the number of new bugs to 5% in pre-production.
  • KR: Reduce the number of total bugs to 10% in pre-production.
  • KR: Keep the number of total bugs below 5% in production.

And we add the following OKR:

  • Objective: To improve the quality of the deliveries to the squads.
  • KR: Review 100% of new stories to find poorly defined and / or ambiguous requirements.
  • KR: Perform a 25% review of the Pull Requests of the squads.
  • KR: Measure the Pull Requests volume of the squads.

Another example of bug tracking

At Conta Azul, we doubled the product development team in a period of 8 months between November 2017 and July 2018. This growth was aimed at increasing the team’s productive capacity.

Number of deliveries and people per week at Conta Azul

In addition, we divided the quantity of deliveries by the total number of people on the team to assess whether we were managing to increase our productivity individually.

Number of deliveries per person at Conta Azul

However, with the increase of people on the team, it ended up increasing the amount of bugs. So much so that the team that had already had 40% of its deliveries as a bug fix ended up having to increase this proportion to 60%. That is, despite having increased individual and total productivity, this increase in productivity was not being felt by the user, as it ended up being used for bug correction.

Percentage of bug fixes at Conta Azul

To control this problem, we increased our focus on fixing these bugs within the SLAs, which were:

  • 85% of tickets resolved within 7 days
  • 98% of tickets resolved within 30 days
7 day bug fix SLA at Conta Azul
30 day bug fix SLA at Conta Azul

See that the quality has worsened and the customer suffered from it. But, after some time, we managed to return to the defined SLA levels. We looked at this metric weekly and, whenever we discussed this metric, we agreed that the best way to comply with the SLA was not to create bugs!

Quality is not just bug control

In addition to bug control, there are several other aspects that impact the quality of the digital product that we deliver to users. Performance, scalability, operability, monitorability are some examples of non-functional requirements.

When I joined Gympass, on my second Monday the system went down for users around 7 pm. I started asking people on the team what was going on and the answer was that Mondays are peak days in terms of gym visits and that the system could not handle the volume at all. As there was no monitoring, we were not alerted that the volume was higher than usual and we were unable to prepare properly. Two months later, when Rodrigo Rodrigues joined Gympass as CTO, he dubbed the event “Black Mondays”. To address the problem, we started to monitor and implement an infrastructure that could handle Monday peaks. And we set OKRs for uptime, successful HTTP requests and backend response time.

Uptime – Gympass
Successful HTTP requests – Gympass
Backend response times – Gympass

Why is quality so important?

Any user prefers to use a good quality product that behaves as expected. This is a sine qua non condition to provide a good user experience.

In addition to the user experience, there is another important aspect to consider when we talk about quality and bugs. Whenever someone needs to work on resolving a bug that was found in a digital product, that person needs to stop working on whatever they are currently working on in order to resolve the bug. This is an interruption in the workflow. If that person were able to deliver the software without that bug, they could continue to work on new things without interruption, which would make them more productive.

The relationship between productivity and quality

I had the opportunity to participate in an MIT course on how to create high-speed organizations. The course was taught by Professor Steven J. Spear, author of the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. This is one of those very dense courses, full of content, but which can be summarized in one paragraph:

High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

A high-speed organization works by following the 4 steps ahead:

  • Be prepared to capture knowledge and encounter problems in your operation.
  • Understand and solve these problems to build new knowledge.
  • Share the new knowledge with the entire organization.
  • Lead to develop skills 1, 2 and 3.

The classic example is Toyota, with lean manufacturing and the concept of stopping production whenever there are failures, correcting them and using them as a learning opportunity so that they no longer happen. This ability to learn from failure is what gives Toyota the ability to stay ahead of its competitors for so long.

Another good example is Alcoa, which had a work incident rate of 2% per year, which was considered normal. Alcoa has more than 40,000 employees, so 2% of work incidents per year means that 800 employees per year have some type of work incident. This is a very impressive and worrying number.

To combat this problem, they implemented a zero error tolerance policy. Before implementing this policy, mistakes were seen as part of the job. Employees are now encouraged to report operational errors within 24 hours, propose solutions within 48 hours and report the solution found to their colleagues to ensure that knowledge spreads throughout the organization.

This caused the risk of incidents to drop from 2% to 0.07% per year! This reduction in the incident rate meant that fewer than 30 employees per year had any work incident problems after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

Fail fast vs. learn fast

An important factor in the Toyota and Alcoa examples is that recognizing and learning from failures must be part of the company’s culture. This is somewhat more common in the culture of technology companies, but not so common in traditional companies. During the MIT course I shared a table with a Brazilian executive from Grupo Globo, the major TV company in Brazil, a Spanish executive from AMC Networks International (Walking Dead, Breaking Bad and Mad Men), a German project manager living in Azerbaijan who works for Swire Pacific Offshore (oil and gas industry) and an MIT postdoctoral student in solar energy from Saudi Arabia.

All of my table mates were from more traditional industries. I was the only one at an internet company. The executives at Globo and AMC were there because they saw Netflix with its streaming video on demand and YouTube with its huge catalog of user-generated videos as major threats, stealing their audience very quickly and they wanted to understand how they could defend themselves.

Although the theme is somewhat obvious for internet companies, especially with the culture of technology startups that value fail fast. That’s what makes Netflix and YouTube a threat to traditional media companies like Grupo Globo and AMC Networks. However, even though this is part of the culture of internet companies, sitting and discussing it with people from more traditional companies was a great opportunity to reflect on the relationship between failure, failure recognition, learning and high speed:

  • Recognizing the flaws and using the flaws as a learning opportunity must be well rooted in the organization’s culture. If people are not careful, as a company grows, it may lose the ability to accept failures as learning opportunities. It is very common for companies, as they grow, to become more and more averse to failure and to create a culture that ultimately encourages people to hide mistakes and failures.
  • Another important aspect of learning from failures is to make this process a company standard. There is no point in failing, acknowledging the error, stating that you will no longer make that mistake and, some time later, making it again. This learning process with failures must be part of the company’s culture. Whenever a fault is identified, learning should happen as quickly as possible to prevent it from happening again. If the same failure happens again, something is broken in the learning process with the failure.
  • Even in Internet companies, I realize that learning from failures is more common in the product development team, as retrospectives and continuous learning are part of the culture of agile software development. In other areas of the company, learning from failures is less common. This ability to systematize learning from failure must permeate the entire company.

Even though we hear a lot about the culture of internet companies to fail fast, talking about failing fast diverts our focus from what is really important, learning fast. We must put our energy into learning, not into failure itself. It is the learning process that makes people and companies evolve. And it is the ability of an organization to learn fast, especially with its failures, that will allow it to move at really high speeds.

Summing up

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

In the next chapter we’ll see a little more about metrics.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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

Visão de produto

Apesar de ser apenas 10% do tempo de um líder de produto, definição de visão de produto é sua responsabilidade mais importante. Sem a clareza de visão de produto, fica muito difícil trabalhar em qualquer outro tema em relação ao produto. Quais são as prioridades? Que estrutura de time de produto é necessária? Esse pedido do time comercial é importante? E esse do time de suporte ao cliente? E esse pedido do CEO/Founder? Devemos focar em ter mais clientes ou em reter os que já temos? Essas perguntas são muito difíceis de responder se não houver clareza sobre a visão de produto.

Quando me junto a uma nova empresa, quer seja em um papel de tempo integral, quer seja em meus trabalhos de advisoring, minha primeira preocupação é entender se existe uma visão de produto e se ela está clara para todos na empresa. Esse é sempre o meu primeiro foco, pois da visão de produto deriva todo o trabalho de desenvolvimento de produto.

O que é visão de produto?

A visão de produto nada mais é do que o entendimento de como será o seu produto no futuro. Por “futuro” quero dizer médio a longo prazo, ou seja, um horizonte de mais de 2 ou 3 anos. Como ele vai atingir os objetivos da empresa que é dona do produto enquanto resolve problemas e necessidades seus usuários?

Construir a visão de produto é um trabalho colaborativo feito em conjunto com várias pessoas de dentro da organização, assim como com input de pessoas de fora como clientes e não clientes, fornecedores, concorrentes, especialistas do mercado etc. Esse é um trabalho liderado pela head de produto, quer seja ela uma VP ou CPO, quer seja ela um GPM. Se for uma VP ou CPO, a visão terá por escopo todos os produtos da empresa ou da área, enquanto que, se for uma GPM, o foco da visão será o produto, ou pedaço de produto, de que essa GPM cuida. Para a GPM conseguir fazer sua visão, ela precisa ter clareza da visão de produto da empresa.

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. Alguns exemplos de visão de produto que ajudei a criar:

Produto E-mail da Locaweb

Durante meu período na Locaweb, montamos a seguinte visão de produto para o produto E-mail da Locaweb:

O produto E-mail da Locaweb será a solução de email mais completa e flexível do mercado brasileiro. (Nota: essa visão é de 2016.)

Visão de produto da Conta Azul

Criamos a visão de produto da Conta Azul como uma imagem, porque com a imagem era mais fácil explicar todos os elementos do que víamos como o futuro do produto da Conta Azul.

Visão de produto da Conta Azul (2017/2018)

Visão de produto do Gympass

Novamente, preferimos uma imagem em vez de palavras. O chavão uma imagem vale mais que mil palavras tem uma razão para existir.

Visão de produto Gympass (2018-2020)

Visão de produto da Lopes

E aqui mais uma vez fizemos uso de uma imagem.

Visão de produto da Lopes

Processo de criação de visão de produto

Aqui vai um passo a passo de como criar a visão de produto:

Obter objetivos estratégicos da empresa: se você ainda não tem essa informação, vá obtê-la. Converse com os líderes da empresa, o CEO, os founders, o conselho. Claro que toda empresa quer crescer e ter mais receita e clientes, mas como? Quais são os objetivos da empresa, e qual é a estratégia para atingi-los?

Obter entendimento dos problemas e necessidades dos clientes: se isso ainda não estiver claro, existem várias ferramentas que ajudam. Mapa de empatia e personas são ferramentas úteis para obter essa informação. Existem várias outras, tais como observação, entrevista, pesquisa, job to be done etc. para você obter essa informação.

Desenhar primeira versão da visão: estando de posse das duas informações você já consegue fazer a primeira versão da visão de produto. Esse é um trabalho de criação e é mais produtivo se feito sozinho. Já experimentei fazer esse trabalho em conjunto com outras pessoas e o processo acabou sendo demorado e o resultado não foi tão bom por ter várias pessoas discutindo algo que ainda não existia. Baseado em minha experiência, é mais produtivo e gera melhores resultados quando o head de produto faz a primeira versão e, a partir dela, faz iterações para colher feedback e refinar a visão.

Iterar e refinar: uma vez feita a primeira versão da visão de produto, é hora de iterar e refinar. As primeiras pessoas com quem se iterar são as pessoas do próprio time de desenvolvimento de produto. PMs, GPMs, designers, engenheiros. Ouça o feedback deles e refine a visão de produto com base nele. Em seguida, apresente para as lideranças das outras áreas, gerentes, diretores, C-level, founders, conselhereiros, mais feedback e refinamento. Tenho preferência por fazer essas sessões de feedback e refinamento individualmente. Apesar de dar mais trabalho, dá a oportunidade de todos falarem.

Comunicar: feitas as iterações e refinamentos da visão de produto em sessões 1:1 com os stakeholders, o próximo passo é comunicar essa visão para toda a empresa e até mesmo para fora da empresa. Isso deve ser feito repetidamente. Em todas as oportunidades relembre a visão de produto. Eu costumo usar a visão de produto em todos os momentos possíveis. Reuniões de all-hands, de produto, de diretoria, de onboarding etc. Uso até mesmo publicamente em palestras e artigos, para explicar como enxergamos o futuro do produto em nossa empresa. Uso também em conversas com candidatos, para ajudá-los a entender o que estamos construindo e se animar a se juntar conosco.

Revisar: periodicamente é importante revisar a visão, ver se todos os seus elementos ainda fazem sentido e se algo novo precisa ser incluído. Minha sugestão é fazer essa revisão uma vez por ano, ou quando algo novo aparece, como um novo concorrente, ou alguma mudança no mercado.

Pronto, esses são os passos para fazer a visão de produto.

Resumindo

  • Apesar de ser apenas 10% do tempo de um líder de produto, definição de visão de produto é sua responsabilidade mais importante. Sem ela todo o trabalho de desenvolvimento de produto fica muito mais difícil.
  • A visão de produto nada mais é do que o entendimento de como será o seu produto no futuro.
  • 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.

No próximo capítulo vamos ver qual o caminho para executar a sua visão de produto.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Measuring and managing productivity

How can we deliver faster? How can we deliver more with the same team? Why do we have the impression that the team is slow? When the team was smaller, it seemed that it could deliver more. These are very common questions and statements that I hear about product development teams. Every company that has a digital product development team would like this team to be faster. In this chapter, I will show you the two essential tools to achieve faster and more productive teams.

Measurement

There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and have it measured.

In my last year at Locaweb, we were focusing a lot on productivity, that is, on how Locaweb’s product and software development teams could produce more, without having to add more people to the teams, and without dropping quality levels.

The following graph shows our numbers. We count quantities of deliveries per week and, as you can see, in a few weeks we were able to more than quadruple the quantity of deliveries per week.

Amount of deliveries per week at Locaweb in 2016

This increase in productivity happened when the team grew only 10% in number of people, so it is not possible to credit this increase in productivity to the increase in number of people in the teams.

When there is such an increase, in addition to the natural question about whether the increase in productivity is due to the increase in the number of people in the teams, another question that exists is whether there was a drop in the quality of deliveries. One of the quality measurements we had was the number of rollbacks. As you can see below, even with the increase in productivity, the number of rollbacks was reduced by 40%!

Number of rollbacks per week at Locaweb in 2016

At Locaweb we made estimated calculations of deliveries per week from September 2015 to February 2016. The calculation was very simple, total deployments made in the period divided by the number of weeks. We then started to communicate the entire company about the week’s deliveries.

After I arrived at Conta Azul, we decided to implement the same type of control of weekly deliveries and ended up also achieving a good increase in productivity.

Amount of deliveries per week at Conta Azul in 2017

Both at Locaweb and Conta Azul, each product manager sent me the deliveries of the week on Friday, I compiled the data and wrote down the quantity for each week, generating these graphs. From the moment we started measuring, it became clearer the level we were at, and the actions we started to take in order to increase productivity began to show results on the graph. In addition, the teams started to use a single measurement tool, JIRA, which gave them a better view of each team’s progress and allowed comparisons with the exchange of experience, that is, something like “look how interesting your graph is, how did you manage to increase this indicator? ”.

At Gympass, as we scaled the team very quickly, we decided to control the number of deliveries per person per week. We considered people who joined 2 months before since people need 1 to 2 months after they joined Gympass to become productive. In one quarter, we managed to increase our productivity per person by 16%. The number of deliveries was extracted directly from JIRA.

Amount of deliveries per week at Gympass in 2019

At Gympass, we also measure the number of deploys, both in our core, aka monolith, and in microservices. We also achieved a considerable increase in one year.

Number of deploys per week at Gympass in 2019

At Lopes, as soon as a deploy was done, an email was sent with a list of deployed items. One of the first things I did when I joined the company was to compile these reports in a spreadsheet to build the chart below. Hence it was easy to notice that the deploys did not happen every day. They happened once per week on average. As soon as we noticed this, we defined OKRs to increase the frequency of deploys, which has been yielding results. The OKRs we defined were:

  • Objective: Increase the cadence of deploys in production;
  • KR: Increase the number of deploys per week to at least 3 (the more the better);
  • KR: Reduce the maximum number of new features per deploy to a maximum of 10.
Number of deploys per week at Lopes

What impacts productivity

The productivity of a product development team is impacted by several factors. I once found a very interesting article written by Michael Dubakov, founder of the company Targetprocess where he shows a mind map with all the elements that can positively or negatively impact the productivity of a product development team. This article is no longer available, but thanks to the Wayback Machine website (http://web.archive.org), you can access it at:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

The mind map is this one:

Number of deploys per week at Lopes

This diagram shows things and activities that affect the speed of development in some way. Green means that the activity increases speed. The more you have, the better. Yellow indicates that there is some maximum. For example, you can accumulate technical debt and increase speed, but if you accumulate too much, it will significantly delay you. Red shows things that slow development, the less you have, the better. The green arrow indicates an increasing effect. For example, focused work increases the speed of development. The red arrow indicates a decreasing effect. For example, better development skills decrease the complexity of the system (good engineers create less complex systems).

What I like about this image is that it shows how complex this theme is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed this topic every quarter at the Product Council, a meeting where we talked about the quarterly planning of the product development team with the leadership. There was a slide where we listed all the topics that could impact the speed to discuss what we were doing about each of these topics.

Themes that impact the speed of the Conta Azul product development team

Place the topic of productivity at the center of the discussion

There is no silver bullet, with each team I’ve worked on there were several actions we took and we were always sure that there are always more actions that could be taken to increase productivity even more.

The only silver bullet that exists is we made productivity into an important topic in our conversations. Everyone started talking about productivity and what we could do to improve it.

This movement made us initiate several changes and experiments that helped us to increase our productivity considerably. If you also want to increase the productivity of your product development team, place this topic at the center of your conversations and experiment a lot. You will see how there is room to greatly improve the productivity of your software development team.

Another important point: be sure to discuss the topic of productivity frequently. My recommendation is that you do it weekly. Creating a weekly cadence will give you the opportunity, each week, to experiment with something new and discuss the results with the team.

Summing up

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

In the next chapter we will see another metric that has a direct impact on productivity, quality.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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

Carreira de gestão de produtos

A progressão de carreira de gestão de produtos pode ser vista iniciando com o Business Analyst (BA), tendo por responsabilidade a especificação do que o time de desenvolvimento de produto vai construir, avançando para Product Owner (PO), que além de especificar deve priorizar o que o time deve fazer, e chegando ao topo da carreira com o Product Manager (PM), que, além de especificar e priorizar, deve definir a visão e estratégia do produto ou pedaço de produto de que ele cuida.

BA, PO e PM

Uma outra forma que muitas empresas têm adotado para enxergar essa evolução de carreira é considerar as fases de BA e PO como Associate Product Manager (APM), com a responsabilidade de especificar e priorizar. É o primeiro passo na carreira de gestão de produtos.

APM e PM

Como gestão de produtos é um papel de grande responsabilidade, recomendo que as pessoas que ingressem na carreira de produtos tenham alguma experiência prévia em outras áreas, tais como engenharia, design e marketing.

Já vi também ótimos gestores de produto vindos de operações, suporte, gestão de projetos, financeiro, e até mesmo jurídico. Ao longo da minha carreira tenho notado que pessoas que acabaram de sair da faculdade não têm a bagagem necessária para conseguir ser bons gestores de produto. É importante ter esse conhecimento em outras áreas até mesmo para ajudar a entender como seu produto impacta essas outras áreas.

E depois?

A pergunta que fica é: o que vem depois? De APM para PM, que pode chegar a PM sênior, mas qual é o próximo passo da carreira de gestão de produtos?

Um time mínimo de desenvolvimento de produtos é composto por alguns engenheiros. Normalmente começa com 2, podendo chegar a até 7 engenheiros, sendo um deles alguém mais sênior, com um papel de tech lead, mais um product designer (PD) e um product manager (PM). Quando há a necessidade de criar um segundo time para cuidar de uma outra parte do produto, há duas formas de fazer essa expansão:

  • Expandir engenheiros, dividir e contratar PM e PD: podemos dividir o time de engenheiros em 2 times, cada um com um foco, e manter temporariamente o product manager e o product designer nesses dois times até conseguirmos contratar um segundo product manager e um segundo product designer. Esse modelo é usado quando se tem muita clareza do escopo de trabalho do segundo time.
  • Contratar PM e PD para fazer discovery, expandir engenheiros e dividir: nesse caso trazemos primeiro um PM e um PD adicional para trabalhar no discovery do que se quer fazer com esse segundo time. Enquanto isso, continua-se contratando mais engenheiros para expandir o primeiro time. Em um determinado ponto do discovery, já tendo alguma clareza do que esse segundo time vai fazer, aí sim fazer a divisão de time. Esse modelo pode ser útil quando ainda não há clareza do que esse segundo time vai trabalhar e é preciso fazer um trabalho de discovery que não cabe no dia a dia do PM e do PD originais.
Duas formas de criar um segundo time

Em ambos os casos, se a PM original for mais sênior, podemos contratar para essa posição de segundo PM alguém mais júnior ou até mesmo um associate product manager e dar à PM mais sênior a oportunidade de ajudar o mais júnior a se desenvolver. Seria uma primeira oportunidade de gestão de pessoas para essa PM sênior, se isso for algo que ela está buscando para a sua carreira. Enquanto ela ainda cuida de um produto ou pedaço de produto com o primeiro time, ela pode começar a experimentar na prática como é liderar um outro PM júnior.

Depois de um a dois trimestres rodando nessa configuração é possível entender se a PM mais sênior gostou desse novo papel, de ajudar um PM mais júnior a se desenvolver. Se esse papel for algo que faça sentido para a PM sênior, é possível pensar em colocar mais PMs para ela ajudar. Nesse ponto vai ficar cada vez mais difícil para essa PM sênior gerenciar um produto ou um pedaço de um produto.

Estou focando na carreira de PM, mas existe um caminho similar tanto em engenharia quanto em product design. O tech lead mais sênior pode vir a liderar o tech lead do outro time, assim como o product designer mais sênior pode liderar o product designer do outro time.

Group Product Manager

Esse é o momento em que o PM sênior se torna um Group Product Manager (GPM). Esse é o primeiro passo em uma carreira de head de produto, quando o product manager não cuida diretamente de um produto ou de um pedaço de um produto e tem a responsabilidade de ajudar outros PMs a se desenvolverem e a gerenciarem seus produtos. Normalmente isso acontece quando a pessoa está liderando 3 ou mais product managers e é responsável por um conjunto de funcionalidades ou mesmo um produto inteiro. Em algumas empresas essa posição é chamada de head de produto, ou diretor de produto ou até mesmo de vice-presidente de produto.

Na Conta Azul, tínhamos GPMs que cuidavam de pedaços do produto. Um GPM ficava mais focado nas funcionalidades financeiras do produto tais como relatório financeiro, emissão de boleto etc. enquanto ou outro tinha foco maior em funcionalidades contábeis e fiscais tais como registro de compra e venda, gestão de estoque, emissão de notas fiscais etc.

No Gympass, tínhamos diretores de produto focados em cada ator de nosso marketplace. Um diretor de produto focado nas academias, outro focado no RH de nossos clientes e um terceiro focado nos funcionários de nossos clientes.

Em uma empresa pequena, o GPM pode ser o nível mais alto de carreira de produtos. Por exemplo, em uma empresa com até uns 6 ou 7 PMs, um único GPM para coordenar esses PM pode ser suficiente. Quando passa desse número, pode ser interessante ter um segundo GPM, ou mesmo um CPO ou VP de produto que lidera o GPM e alguns PMs.

Além de liderar PMs, o GPM também tem o papel de coordenar a definição da visão e da estratégia de um grupo de produtos ou de funcionalidades. Por exemplo, o diretor de produtos para RH no Gympass tem que liderar os PMs que trabalham em pedaços do produto para os RHs, que chamávamos de Portal do RH, bem como em definir a visão de futuro desse Portal RH, ou seja, onde queríamos chegar com o Portal RH e a estratégia, ou seja, o caminho para chegar lá. E com os PMs, é responsável pela execução dessa estratégia.

Liderança interina

Imagino que você já tenha visto alguma situação em que a pessoa é uma excelente colaboradora, recebe uma promoção para liderar pessoas e, por não estar preparada ou até mesmo por descobrir que não gosta de liderar pessoas, acaba tendo um perfomance ruim como gestora. Só que essa pessoa entende que não pode voltar atrás, voltar a uma posição de contribuidor individual pode ser visto como um retrocesso na carreira, como uma falha.

Uma ferramenta interessante para prevenir situações como essa é o conceito de interinidade. Ao invés da pessoa já assumir um cargo permanente de GPM e liderar uma ou mais pessoas, pode-se usar o conceito de GPM interino, ou seja, é a pessoa assume esse papel de forma temporário, como um teste para ela ver se gosta e se sente confortável fazendo a função de líder. Essa ferramenta pode ser usada em qualquer carreira, não somente na carreira de gestão de produtos. De engenheiro para líder de engenheiros, de product designers para líder de UX etc.

Essa ferramenta cria uma salvaguarda, uma rede de proteção para as pessoas que nunca lideraram pessoas e querem experimentar essa opção de carreira. Com essa ferramenta há espaço para voltar atrás caso a pessoa não goste ou não se sinta preparada para exercer essa função. É o famoso conceito de change rollback ou undo que permite desfazer uma mudança e voltar à versão anterior caso a gente perceba que a mudança feita não está funcionando como esperado.

CPO ou VP de Produto

O Chief Product Officer (CPO) ou Vice-Presidente de Produtos é o cargo mais alto de produtos em uma empresa. Lidera GPMs ou diretores de produto e tem por responsabilidade coordenar a definição da visão e da estratégia de todos os produtos da empresa, bem como pela execução dessa estratégia, em conjunto com os GPMs e diretores de produto. Em alguns casos pode fazer sentido a área de UX reportar para o CPO. Idealmente, dada a importância da estratégia digital nas empresas, o cargo de CPO deve reportar para o CEO e ter acesso aos membros do Conselho.

Carreira de produtos

A nomenclatura pode ser um pouco confusa. Algumas empresas chamam essa posição de head de produto, outras de diretor de produto ou vice-presidente de produto ou CPO. Apesar disso, o importante é a estrutura estar clara para todos dentro e fora do time de desenvolvimento de produtos.

Existem dois modelos de estrutura de liderança de times de desenvolvimento de produto, cada um com os seus prós e seus contras, a depender do contexto onde está esse time:

Liderança única

Tanto na Locaweb quanto na Conta Azul eu tive o papel de CPO com a responsabilidade de liderar todo o time de desenvolvimento de produto, ou seja, gestores de produto, product designers e engenharia.

A liderança única funciona quando se tem pessoas sêniores para ajudar na gestão de engenharia assim como na gestão de design e de produtos. Na Conta Azul, o time chegou a ter 130 pessoas e eu tinha um head de engenharia, 4 GPMs e um head de design para me ajudar. Na Locaweb, com um time de 100 pessoas eu tinha dois gerentes seniores de engenharia, 5 PMs seniores e um head de UX.

Gosto dessa configuração pois sempre vi o time de desenvolvimento de produto como um único time, com objetivos comuns de entregar o melhor produto para atender aos objetivos da empresa enquanto resolve problemas e necessidades dos usuários. Essa configuração ajuda no alinhamento e nessa visão de time único.

Esse tipo de configuração funciona muito bem para times pequenos, de até umas 80 a 100 pessoas. Quando chega nesse tamanho, existe o risco de sobrecarregar esse líder único responsável por todo o time de desenvolvimento de produto. É uma infinidade de temas diferentes, daí a importância de ter pessoas seniores ajudando na liderança.

Em algumas empresas, ao invés de CPO, essa liderança única é chamada de Chief Technical Officer (CTO) ou de Vice-Presidente de Desenvolvimento de Produtos.

Pode fazer sentido pensar em dividir a área em duas lideranças quando o time cresce para mais de 100 pessoas, tendo um CPO e um CTO fazendo a liderança compartilhada. Vale lembrar de que a liderança compartilhada, apesar de ser benéfica no sentido de dividir responsabilidades, pode ter efeitos colaterais prejudiciais se não for bem gerenciada pelo CEO.

Liderança compartilhada

No Gympass rodamos durante 18 meses com um CTO e dois CPOs, sendo um de produtos para consumers e eu focado em produtos para empresas e parceiros. Optamos por essa configuração pois prevíamos um crescimento considerável do time. Quando o time estava ainda com 60 pessoas, já vislumbrávamos um crescimento até 400 pessoas. Poder dividir a responsabilidade, principalmente quando o time cresce rápido para números acima de 100 pessoas, ajuda a colocar mais atenção e ir mais fundo nos temas de que cada líder cuida. Isso evita a sobrecarga que comentei acima.

Estrutura de liderança de desenvolvimento de produtos no Gympass de agosto de 2018 a outubro de 2019.

No Gympass, o time de UX reportava para o CPO de consumers enquanto eu tinha, além dos times de produto para empresas e parceiros, um time de Professional Services (PS) que era responsável por fazer as integrações customizadas com sistemas de academias e de sistemas de RH de nossos clientes. Esse trabalho de professional services é mais orientado a projetos, com definição clara de escopo e prazos bem definidos, por isso criamos uma área separada para cuidar dessas integrações.

Na Conta Azul, quando eu saí de lá em meados de 2018, estávamos começando a pensar em dividir os papéis entre CTO e CPO. Tanto que em 2020 a estrutura ficou com a liderança compartilhada do time de desenvolvimento de produtos.

Estrutura de liderança de desenvolvimento de produtos na Conta Azul

Outra possibilidade de liderança compartilhada de times de produto é ter head de engenharia, de produtos e de UX.

A liderança compartilhada tem por efeito colateral o risco inerente de criação de silos, ou seja, de haver times trabalhando de forma isolada e sem a necessária colaboração. No Gympass, tínhamos uma preocupação forte em evitar esse comportamento. Sentávamos nós 3 lado a lado e reservávamos no mínimo três horas por semana para conversarmos sobre temas do time de desenvolvimento de produtos, sendo uma hora entre nós 3, uma hora junto com business partner de RH, e uma hora com o CEO. Além disso, buscávamos setar os objetivos de forma comum para os times e tratávamos o orçamento como um orçamento único da área de desenvolvimento de produtos.

Contudo, apesar de nossos esforços, ainda assim havia situações de falta de colaboração entre os membros de diferentes times. Por este motivo, tenho preferência por configurações com liderança única de time de desenvolvimento de produtos, apesar da eventual sobrecarga que isso possa causar nessa liderança. Uma forma de diminuir essa sobrecarga é contar com líderes seniores.

CPO e CTO

Como comentei anteriormente, a área de desenvolvimento de produtos é uma área só, com objetivo comum de criar o melhor produto para atender aos objetivos estratégicos da empresa enquanto resolve problemas e necessidades dos clientes. Ter duas ou mais lideranças para essa área requer bastante coordenação entre elas para garantir que os times estão colaborando e evoluindo na mesma direção. A forma mais comum de dividir essa liderança é ter duas pessoas, CPO e CTO, para liderar o time de desenvolvimento de produtos. Enquanto o CPO lidera pessoas de produto e de UX, o CTO lidera as pessoas de engenharia.

Divisão de responsabilidades entre CTO e CPO

Essa imagem ilustra bem as responsabilidades de cada liderança. O CTO cuida do desenvolvimento propriamente dito do produto, ou seja, tem que se preocupar com a qualidade do que está sendo desenvolvido, bem com a velocidade de desenvolvimento. Também cuida de questões de infraestrutura e operacionais tais como a estabilidade, performance e disponibilidade do produto. O CPO cuida do produto tanto do ponto de vista do negócio quanto do ponto de vista do cliente. Do ponto de vista do negócio, é responsável por definir a visão de produto alinhada com os objetivos estratégicos do negócio. Do ponto de vista do cliente, precisa garantir que o produto resolve um problema ou necessidade do cliente com qualidade e, para isso, ele precisa entender a satisfação e o engajamento do cliente com o produto.

Em conjunto, CTO e CPO devem definir e evoluir a estrutura do time de desenvolvimento de produto, com times de produto e times estruturais (SRE, Data etc.) como veremos no capítulo Estrutura de times, bem como definir e evoluir os processos que esse time usará no seu dia a dia.

Carreira Y

Carreira Y é a opção que se dá para as pessoas optarem pela carreira gerencial ou seguir na carreira de especialista. Alguns PMs mais seniores podem não querer gerir pessoas, só produtos. Isso significa que não há espaço para ela evoluir na carreira, uma vez que o caminho de progressão visto acima passa pela liderança de outros PMs? Não necessariamente.

Em empresas com produtos mais complexos ou até mesmo com um portfólio de mais de um produto, pode haver espaço para um papel pouco conhecido no mercado brasileiro, mas que pode ajudar bastante nesse contexto, o Principal Product Manager. Esse é um papel que não gerencia pessoas mas que, pela sua senioridade, tem um impacto relevante na organização. Suas principais responsabilidades são:

Ajudar a conectar o trabalho dos GPMs: à medida que a empresa cresce e temos mais de um time de desenvolvimento de produto, cada um com seu GPM muitas vezes focado no dia a dia desse time, sem olhar muito para o que os outros times estão fazendo, normalmente é papel do CPO manter a conexão entre o trabalho dos diferentes times e seus GPMs mas, em algumas estruturas, pode fazer sentido ter algum PM bem sênior fazendo esse papel.

Garantir a sincronia e consistência entre os times de produto: por independentes que tentemos fazer a estrutura de times de produto, sempre haverá situações em que um time dependerá do trabalho de outro time. Um exemplo no Gympass são os times de produto para academia e para usuário final. O time de academia faz uma funcionalidade que permite ao gestor da academia criar o horário de aulas, e o time focado no usuário final precisa colocar esse horário de aulas disponível no app para que os usuários passam ver e agendar aulas. Essa coordenação normalmente é feita pelos próprios PMs desses dois times, mas eles podem se beneficiar de ter uma terceira pessoa ajudando nessa coordenação. Essa terceira pessoa pode ser um GPM, o CPO ou mesmo um PM mais sênior, nesse papel de Principal Product Manager.

Note que essas responsabilidades são um subconjunto das responsabilidades de um head de produto ou mesmo de um CPO, sem a responsabilidade pela gestão e desenvolvimento dos PMs, o que pode ser atraente como progressão de carreira para pessoas que não queiram gerir outras pessoas. Esse papel ainda é novo. Algumas empresas o enxergam como sendo somente um PM muito sênior, mas acho que faz sentido pensar nesse papel com uma contribuição maior do que somente em um time.

Resumindo

  • A carreira de produto tem a progressão de Associate Product Manager (APM) para Product Manager (PM) para Group Product Manager (GPM) para Chief Product Officer (CPO). Existem algumas variações de nomenclatura a depender da empresa e do país, mas em geral segue essa progressão. O importante é essa estrutura e progressão de carreira estarem claras para toda a empresa.
  • Quando se fala da liderança mais sênior de produto em uma empresa, há duas opções com seus prós e contras. Uma opção é a liderança única de todo time de desenvolvimento de produtos (PM, UX e engenharia), que funciona bem para times maiores, mas pode sobrecarregar quando são times de mais de 100 pessoas. A vantagem é ter todo o time alinhado com uma única liderança. A outra opção é a liderança compartilhada com CPO e CTO, que evita a sobrecarga em times grandes, mas pode causar uma diminuição de colaboração caso não haja boa sintonia entre esses dois ou mais líderes.
  • Para PMs que não querem seguir a carreira de gestão, é importante dar a opção da carreira em Y, com o papel de Principal Product Manager, que ajuda na integração e sincronia do trabalho dos diferentes times.

No próximo capítulo vamos olhar uma das principais responsabilidades do head de produtos, a criação da visão e da estratégia de produto.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Vision, strategy, objectives, and team structure

This is the beginning of Part III of the book, about Tools, I’ll talk about the tools I’ve been using in my almost 30 years of product development leadership career and passing them to other leaders so they can use them with their teams. The tools I’ll talk about include vision, strategy, objectives, metrics, relationships, hiring, feedback, and ceremonies.

You will notice that the tools that I’ll comment on here are not software such as spreadsheets, presentations, documents, Slack, JIRA, Confluence, etc. These apps are normally very useful, but they are only a vehicle for documentation, communication, and metrification of the tools that we will see in the following chapters.

Vision, strategy, objectives, and team structure

All of these items are, in addition to very important concepts, essential tools for any head of product. In all the opportunities that I started as head of product, these were the first topics that I dealt with, always starting with a product vision and then moving on to the themes of strategy, objectives, and team structure. This is also my first focus when I start any advisory work. I try to understand what’s the vision, strategy, objectives, and team structure. If any of these elements is missing, I help people in the company to create them.

I have already explained what they are and how to create each of these items in their respective part I chapters, so I will just do a quick review of these tools.

Vision

As I explained in the chapter Product vision, to make the product vision, it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product. The 6 steps to build a product vision are to obtain strategic objectives of the company, gain an understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

I usually document and communicate the product vision in a presentation. If necessary, I put some theoretical introduction explaining the concepts of platform and marketplace. In every presentation I make, I usually present the product vision as an introductory topic to set the context and to make it clear to everyone.

Strategy and objectives

The product strategy is nothing more than the path you will take to reach your product vision. To create your product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of that market, if there are disruptors, and how it is regulated. You also need to understand your strengths and weaknesses, opportunities and threats. A SWOT analysis can help. With this information in hand, you define what you and your team will do to achieve the product vision, what goals you need to achieve, and what metrics will tell you that you are achieving those goals. OKRs are a great tool for working on your goals and metrics.

There are some books and courses talking about how to define and use OKRs. So I’m not going to go into too much detail here. In a very succinct way, you define together with the team some objectives for a period – usually a quarter or a year – and define which metrics you will use to show that the objective is being reached.

I usually document the OKRs in spreadsheets, which I use to follow the evolution every week with leaders of my product development team, and also present and discuss the OKRs with other leaders and areas of the company. The following is an example:

Exemple of an OKR worksheet

Note that every week the KRs are updated. Each team leader updates their KRs with their teams every Monday, and then leaders and heads of product go through the KRs to see how they are doing and if there are any impediments where energy can be put in to remove. I like to do it on Monday because it helps the team organize the work of the week. The weekly cadence is essential to help the team review performance at least weekly and make adjustments if necessary. If the cadence is higher (biweekly or monthly), valuable opportunities to correct problems and remove impediments are lost.

The column T0 indicates the initial value of the metric. The responsible column has the name of the person who is responsible for that KR and who will lead the effort to make it happen. And the support column lists the people or areas that will help the person in charge.

It is worth remembering that the closer to the company objectives and business metrics the OKRs are, the better it will be for the team, as they will be working to help the company with its objectives and results.

Team structure

In the chapter Team Structure I said that product development teams are organized into minimal teams, also called squads, composed of engineers, product designers, and product managers. It is important to keep the team as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.

There are 4 ways to organize product teams: by product or functionality, by type of user, by journey or by objective. You can also use two different types of organization to create a hybrid organization. There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering and Professional Services.

To help organize the team, I usually use a simple spreadsheet template like the following:

Example of team structure worksheet

This worksheet contains the team structure and the people who are part of it. Note that we are not documenting functional leadership, but the leadership of each team. In the example, we have John as GPM leader of PM Lucy and PD/UX Patricia, Mary as GPM leader of PD Rafa and Sandra as leader of the structural teams of SRE / IT, Data and Peter, who leads the engineering of 2 squads of the tribe A and tribe B squad.

An important point is that it is not enough to just create these elements and then not use them. These tools are useful the more you use them. I use OKR worksheet at least every week. Whenever I have the opportunity I talk about Vision and strategy. Whenever I talk with my leaders about hiring or changes in the team, I use the team structure spreadsheet I showed above.

Summing up

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

In the next chapter, we’ll look at how to measure and increase the productivity of a product development team.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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

Papéis, responsabilidades e senioridade

No capítulo anterior acabamos de rever alguns conceitos básicos de produtos digitais. Agora vamos entender o que é ser head de produto, quais os seus papéis e suas responsabilidades.

Gerenciamento de expectativas

Qualquer que seja o caminho que o leve à possibilidade de ocupar um cargo de liderança de produto, seja por considerar esse o seu próximo passo na carreira ou por ter a tarefa de encontrar alguém para ocupar esse cargo, é importante esclarecer qual é a principal responsabilidade deste papel: gerenciamento de expectativas. Será algo entre 50 a 80% do seu tempo.

Ouço de alguns gestores de produto que querem se tornar head de produto porque veem essa posição como uma grande oportunidade de ter uma opinião forte sobre, ou até mesmo de liderar, a construção da visão e estratégia do produto e, consequentemente, da empresa, especialmente se você estiver em uma empresa que é puramente digital ou tradicional nascida digital.

Isso realmente acontece, e é parte de sua responsabilidade, mas devo dizer que isso não representa mais de 10% do trabalho de head de produto. E mesmo esses 10% não são um empreendimento solo. Você precisará construir a visão e estratégia de produto em colaboração com as principais partes interessadas em seu produto, especialmente os fundadores da empresa, que são os primeiros gestores de produto de qualquer empresa e a diretoria, os C-level.

Os outros 90% da responsabilidade do head de produto são compartilhados entre ajudar gestores de produto em seu desenvolvimento – algo entre 10% a 40%, dependendo da senioridade desses gestores de produto – e o gerenciamento de expectativas, que vai tomar de 50% a 80% do seu tempo.

Por gerenciamento de expectativas, quero dizer gerenciar a ansiedade de todos os interessados no produto, internos e externos, em saber quando e como o produto vai ter essa ou aquela funcionalidade para trazer aquele resultado para atingir aquele objetivo.

É importante ter essa divisão de tarefas e responsabilidades clara antes de decidir aceitar a função de head de produto, para entender o que outras áreas e sua equipe vão esperar de você, caso você decida aceitar o trabalho.

Normalmente, tenho visto pessoas preenchendo uma posição de head de produto vindo com três históricos principais: ou é uma gestora de produto que começará a gerenciar outros gestores de produto ou é uma pessoa que lidera design ou marketing ou é uma pessoa que lidera engenharia.

Gerente de produto preenchendo a posição de head de produto

Esse pode ser um passo natural na carreira de uma gestora de produto. À medida que se torna mais experiente, ela pode se tornar a pessoa preferida de outros PMs em busca de conselhos. Portanto, os 10% a 40% de ajudar outros gerentes de produto a fazer parte da posição de chefe de produto podem vir naturalmente para ela. No entanto, ainda há 10% da construção da visão e 50% a 80% do gerenciamento de expectativas a serem considerados.

A construção da visão também não deve ser algo novo para um gestor de produto sênior. Ele já deve fazer isso para o produto ou parte do produto que cuida, portanto não deve ser novidade, apenas ter um escopo maior. Lembre-se de trabalhar na construção de uma visão de alto nível e dar espaço para que os detalhes sejam trabalhados pelos PMs que o head de produto lidera. Construir esses detalhes de uma visão de produto é uma responsabilidade e oportunidade desenvolvimento importante para gestores de produto.

Os 50% a 80% restantes do tempo gasto no gerenciamento de expectativas também não devem ser estranhos ao gestor de produto que aspira a se tornar head de produto. Na verdade, ele já faz isso com o produto ou parte do produto de que cuida. Desde os membros de sua equipe, as pessoas de outras áreas, os C-level, até o fundador da empresa. Aqui, novamente, estamos falando de um aumento de escopo. E, novamente, precisamos permitir que os PMs liderados pelo head de produto também gerenciem a ansiedade das partes interessadas, para que possam desenvolver essa habilidade. Mas não se esqueça de que, como head de produto, você será o responsável para gerenciar as expectativas do C-level, dos fundadores e do conselho.

Se você não deseja gerenciar outras pessoas, tudo bem. Sempre é possível ter espaço em sua equipe para uma posição de gerente de produto mais sênior. Algumas empresas chamam isso de principal product manager. Falarei mais sobre esse papel ao longo do livro.

O primeiro passo para um gestor de produto se tornar head de produto é quando continua trabalhando com sua própria equipe (engenheiros e designers de produto) e supervisiona o trabalho de um gestor de produto em outra equipe. Um nome possível para essa nova posição é group product manager (GPM), pois ela está gerenciando um grupo de produtos ou um grupo de partes de um produto. Indo tudo bem, o próximo passo é contratar seu substituto para a função existente que ele ainda desempenha como gestor de produto. Livre de seu trabalho diário de gerenciar um produto, ele poderá gerenciar dois ou mais gestores de produto.

Líder de UX ou líder de marketing

UX e marketing são duas áreas muito próximas à gestão de produtos. Enquanto o UX trabalha em conjunto com gestão de produtos em atividades de discovery, o marketing trabalha em conjunto com gestão de produtos em atividades para contar ao mundo sobre o produto e o problema que ele resolve e para aumentar sua base de usuários. Ou seja, ambos entendem bem o trabalho de gestão de produtos por trabalharem diariamente com isso.

Tanto para um líder de UX quanto para um líder de marketing que assume essa posição de head, é importante que essa pessoa entenda não apenas as semelhanças, mas também as diferenças entre as duas funções e seu papel e responsabilidades no sucesso do produto.
 

CTO / Head de Engenharia

Se você é um CTO ou um líder de engenharia e foi convidado para liderar a área de produto, é provável que você tenha sido solicitado a preencher essa posição em adição das suas responsabilidades existentes em engenharia. Existem prós e contras em combinar os dois papéis. Como ponto positivo, desenvolvimento de produto é uma área só que tem por objetivo entregar o melhor produto para atingir os objetivos da empresa enquanto resolve problemas dos usuários. Ter uma única pessoa liderando a área facilita o alinhamento do time.

Por outro lado, especialmente com time maiores, juntar esses dois papéis pode gerar uma sobrecarga considerável na sua agenda e no dia a dia de trabalho. É importante conseguir priorizar e ter boas pessoas no time para você delegar algumas de suas tarefas.

Tanto na Locaweb quanto na Conta Azul eu tive esse papel de liderar todo o time de desenvolvimento de produto, ou seja, gestores de produto, product designers e engenharia. Apesar de ter background técnico, eu sempre tive pessoas seniores para me ajudar na gestão de engenharia assim como na gestão de design e de produtos. Já no Gympass rodamos durante 18 meses com um CTO, um head de produtos para consumers e eu como head de produtos para empresas e parceiros.

Papéis e responsabilidades

Como eu comentei acima, o papel do head de produto está dividido em 3 grandes áreas:

Visão e estratégia de produto: normalmente toma algo em torno de 10% do tempo de um head de produto. Definir a visão de produto é definir como será o produto no futuro. O que você quer que o produto seja quando ele crescer? E a estratégia é o caminho para chegar até a visão. Construir visão e estratégia de produto é um trabalho que o head de produto faz alinhado com os fundadores da empresa, a alta gestão e o conselho, com input de todas as áreas da empresa e do cliente. Vou falar mais sobre construção de visão e estratégia nos próximos capítulos.

Ajudar gestores de produto em seu desenvolvimento: a depender da senioridade do seu time, isso vai tomar algo em torno de 10% a 40%. Quanto mais júnior e inexperiente, mais tempo você terá que dedicar para o desenvolvimento do seu time. Falarei mais à frente sobre algumas das Ferramentas importantes: reuniões 1:1, reuniões de time, avaliação e feedback, product council, product update e organização de time.

Gestão de expectativas: pelo menos metade do seu tempo será dedicado à gestão de expectativas, podendo chegar a até 80%. Na área de produtos e, principalmente, na liderança de produtos digitais, não existe “comunicação em excesso”. Sempre haverá alguém que tem expectativas sobre o produto e que ainda não está ciente da sua visão e estratégia. Com muitas empresas com quem converso sobre produtos digitais ouço uma reclamação bastante comum, de que a área de desenvolvimento de produtos é uma caixa preta. E isso gera muita expectativa das outras áreas, que precisam que suas dores de produto sejam resolvidas. Por outro lado, o time de desenvolvimento de produto também tem expectativas, quer saber qual a visão de produto, qual a estratégia, qual o roadmap, quais as prioridades. A melhor maneira de gerir essas expectativas é por meio de comunicação. Como comentado, as Ferramentas que serão apresentadas mais à frente serão muito úteis para a gestão de expectativas.

Pessoas que querem crescer na carreira para serem head de produto costumam justificar essa progressão de carreira motivados pelo desejo de poder ter uma voz mais ativa e até mesmo guiar a definição de visão e estratégia do produto. Sinto frustrá-los. Como já mencionei, isso é apenas 10% do trabalho de um head de produto. Os outros 90% do tempo de um head de produtos são dedicados ao trabalho de ajudar os gestores de produto a se desenvolverem e à gestão de expectativas. Reforço que, quanto mais júnior e inexperiente for o seu time, mais tempo você terá que dedicar para o desenvolvimento do seu time, o que pode tomar até 40% do seu tempo. Por outro lado, se seu time for júnior e inexperiente, mais trabalho você terá com gestão de expectativas, que pode chegar a tomar até 80% do seu tempo.

Imagine que você tem um time júnior e inexperiente, que tome 30% do seu tempo, e que, em função disso, você tenha muita gestão de expectativa para fazer, tipo 70% do seu tempo. Ou seja, 100% do seu tempo será tomado com ajudar seu time a se desenvolver e em gerir expectativas. Por isso, é importante você tomar muito cuidado com a senioridade do seu time, caso contrário não sobrará tempo no seu dia a dia para cuidar da visão e estratégia do produto que você lidera.

Certa vez, ao explicar essa divisão de tempo, recebi a pergunta se gestão de resultados não seria também uma das responsabilidades do head de produto. Sim, é uma das suas responsabilidades, e cai na categoria de gestão de expectativas. Todos na empresa esperam que o produto ajude no atingimento das metas e nos resultados da empresa. Assim como os usuários do produto também têm a expectativa de atingir suas metas e resultados utilizando o seu produto. Então, uma forma de gerir as expectativas das pessoas da empresa e de seus usuários é ajudando-os a atingir seus resultados e deixando claro como o produto está tornando isso possível.

Níveis de senioridade

Este é um tópico que ouvimos quase diariamente em todas as empresas: níveis de senioridade. Existem muitas situações em que esse assunto surge, como em contratação, avaliação de desempenho, aumentos, promoções, bônus etc. Quanto mais sênior é uma pessoa, mais você espera dela. Afinal, ela tem experiência e conhecimento para lidar com as situações mais difíceis do trabalho. Minha experiência me mostrou que precisamos analisar a senioridade de uma pessoa com base em três dimensões:

Tempo

Normalmente avaliamos a senioridade com base no tempo. Por exemplo, se uma pessoa tem mais de 10 anos de experiência, ela é sênior. No entanto, o tempo sozinho não é suficiente. Se ela fez a mesma coisa nesses 10 anos, sem se questionar e sem continuamente buscar melhorar e experimentar coisas novas, ela não evoluiu como profissional. Ela não colocou novas ferramentas em seu cinto de utilidades. E terá bastante dificuldade ao enfrentar novas situações uma vez que não tem as ferramentas necessárias.

Conhecimento

Portanto, além do tempo, também devemos considerar o conhecimento. Podemos traduzir o conhecimento como o conjunto de ferramentas que um profissional possui em seu cinto de utilidades. Se uma pessoa conhece apenas uma ferramenta, ela a usará para resolver todos os problemas. É como diz a lei do martelo: para um martelo, tudo parece um prego. Essa lei é atribuída a Abraham Maslow, psicólogo americano bastante conhecido pelo conceito da pirâmide de hierarquia de necessidades.

Quanto mais ferramentas alguém tiver, mais fácil será enfrentar novas situações e encontrar soluções. Essa é a razão pela qual os consultores são tão versáteis. Eles trabalham por curtos períodos de tempo em clientes diferentes, enfrentando problemas diferentes e precisam criar maneiras de resolver novos problemas, já que cada novo cliente em que trabalha tem problemas e contextos diferentes.

Às vezes, uma consultora com 3 anos de experiência, trabalhando em 6 clientes diferentes, terá muito mais ferramentas em seu cinto de ferramentas do que alguém que permaneceu na mesma empresa por 10 anos. A consultora provavelmente será mais sênior do que a pessoa que ficou por 10 anos na mesma empresa, fazendo o mesmo trabalho e resolvendo os mesmos problemas sem se questionar e buscando continuamente melhorar, melhorar e experimentar coisas novas.

Para avaliar a antiguidade de alguém – inclusive quando estamos autoavaliando nossa própria senioridade – precisamos olhar para anos de experiência e a qualidade do conhecimento acumulado durante esses anos. Contudo, isso não é suficiente.

Comportamento

O comportamento é uma dimensão da senioridade que normalmente não é discutida quando avaliamos a senioridade de alguém, mas é tão importante quanto tempo e conhecimento. Às vezes tenho a impressão de que é ainda mais importante que tempo e conhecimento.

A senioridade comportamental significa que a pessoa sabe como se comportar adequadamente:

  • ser ético, ser uma pessoa íntegra e com a intenção correta;
  • ter alinhamento com os valores e a cultura da empresa;
  • ter alinhamento e comprometimento com o propósito da empresa;
  • ter alinhamento e comprometimento com os objetivos estratégicos da empresa.

Vou dar alguns exemplos e contraexemplos de senioridade comportamental para tornar o conceito mais claro:

  • Metas: todas as empresas têm metas. Todas as empresas têm objetivos quantificados e metas são definidas para ajudar a atingir esses objetivos. Um método muito conhecido para definir objetivos e quantificar os resultados é o OKR (Objective and Key Results ou objetivos e resultados chaves). Algumas empresas ainda usam essas metas para definir a remuneração variável de seus funcionários, também conhecida como política de bônus. Invariavelmente, depois que os objetivos são definidos, as coisas mudam. E mesmo quando tudo estiver estável, pode ser necessário fazer um trabalho não relacionado aos objetivos. Alguém com senioridade comportamental entende que as coisas mudam e que seu trabalho não se limita às metas previamente acordadas e fará o que for necessário. Alguém sem senioridade comportamental dirá que ela não pode mudar ou fazer qualquer outra coisa além do que é definido como sua meta.
  • Reclamar: como todos sabemos, às vezes as coisas não andam como esperamos. É assim que a vida é. E sempre há pessoas que reclamam. E a culpa é sempre de outra pessoa e sempre há muitas desculpas para explicar por que as coisas não aconteceram como esperamos. Reclamar sem fazer nada para ajudar a resolver a situação é um comportamento típico de alguém que não tem senioridade comportamental. Uma pessoa sênior, quando enfrenta problemas, tenta entender o que aconteceu, sem procurar culpados. Procura uma solução para os problemas e procura entender como evitar que esses problemas ocorram novamente.

Acredito que com esses dois exemplos e contraexemplos fica mais claro o que significa senioridade comportamental.

Na minha opinião, esta é a dimensão mais importante de senioridade. Se você tem alguém com senioridade em conhecimento e muitos anos de experiência, mas sem senioridade comportamental, ela não só terá maiores chances de ter um desempenho ruim, como também interferirá no desempenho de sua equipe.

Qual a sua senioridade?

Portanto, da próxima vez que você estiver avaliando o nível de senioridade de alguém – inclusive quando estiver avaliando sua própria senioridade –, avalie anos de experiência, qualidade do conhecimento acumulado durante esses anos e a senioridade comportamental. Somente então você poderá avaliar completamente o nível de senioridade dessa pessoa.

Resumindo

  • O head de produto é responsável por coordenar a definição da visão e estratégia de produto, por ajudar os gestores de produto em seu desenvolvimento e por gerir as expectativas de todas as pessoas que têm interesse em seu produto.
  • Um conceito muito importante para ajudar uma head de produto com suas responsabilidades é o conceito de senioridade, que tem 3 dimensões, duas bem conhecidas, o tempo e o conhecimento e uma terceira não tão conhecida, mas tão importante quanto às outras, a senioridade de comportamento.

No próximo capítulo vamos entender um pouco mais sobre a carreira de produtos.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Ecosystem mindset

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

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

Ecosystem mindset

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

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

Diversifying – and digitizing – a product portfolio

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

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

Below I explain how we did it.

Product Vision

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

Gympass product vision

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

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

Gympass expansion opportunitties

There are 3 types of elements in a market:

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

These three elements are related as follows:

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

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

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

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

New endeavor

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

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

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

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

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

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

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

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

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

COVID-19

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

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

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

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

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

Gympass Wellness, the first digital product

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

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

Live Classes, the second digital product

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

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

Personal Trainers, the third digital product

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

Summing up

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

There, with this chapter we conclude the second part of the book, on Principles. Here we saw my personal leadership principles:

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

We also saw what corporate culture is, a set of ways shared by a group of people working together on how to solve problems and react to situations. We also saw the 5 values ​​needed to create successful digital products:

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

Finally, we saw a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is the set of behaviors of the digital product development teams that produce the best results:

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

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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