E se o mundo da gestão de produtos fosse perfeito?
Algumas diretrizes nas quais eu acredito para a gestão de produto dos sonhos.
Antes de mais nada, aquele disclaimer básico: cada empresa é uma empresa, cada contexto é diferente, cada estágio do negócio molda as possibilidades que temos na área de produto, e os recursos disponíveis, idem. Startups em estágio inicial, por exemplo, obviamente não vão ter esse luxo todo que proponho abaixo, e está tudo certo.
Mas, seguindo a lógica do título: e se estivéssemos na Disney? (Pelo menos na Disney da Martina).
Alerta de polêmicas em potencial, mas vamos lá. No meu mundo perfeito da gestão de produto…
…as pessoas PMs teriam poucas reuniões.
Calma. Eu sei que é parte inerente do nosso trabalho participar de reuniões. Mas não falo aqui de entrevistas com clientes, testes de usabilidade ou aquela conversa com o time de atendimento para pegar insights e percepções de clientes. É justamente para conseguir fazer esses papos que é importante a agenda da pessoa PM ter espaço.
Outro fator para colocar nessa equação: já temos as dailies, retrospectivas e 1–1s (eu, por exemplo, gosto de manter 1–1s semanais com o designer minha dupla, team leader e minha liderança direta).
Se queremos bons processos de discovery, decisões baseadas em dados, hipóteses de alavancas que vão além daquilo que o cliente pediu, frentes que entram em roadmap bem validadas e afins, precisamos dar à pessoa PM tempo. E falo aqui daquele tempo de qualidade, para sentar e se concentrar.
Isso significa: menos syncs em geral e mais comunicação assíncrona. Fóruns para trocar experiências, expor cases, divulgar lançamentos (ou se explicar sobre a falta deles), acompanhar com periodicidade o status dos OKRs da empresa toda e afins são muito legais, mas precisamos aceitar que o tempo é finito.
Ah, mas é só uma vez por mês.
Somando cada reunião mensal, a agenda fica toda azul. Defendo 80% do tempo e energia da pessoa PM para a geração e validação de hipóteses, então a agenda precisa ajudar para isso.
…o acesso aos dados não seria uma questão.
Nesse post eu descrevo o processo de gestão de produto (que eu considero ideal) completo. Pois é, já é bastante coisa para uma agenda só.
Seguindo a linha do tópico acima, sobre reuniões, aqui também é sobre investirmos menos tempo na caça aos dados, para termos tempo para o que é mais importante: descobrir o que construir a seguir para entregar valor para o cliente e atingir os objetivos da empresa.
Algumas pessoas PMs têm mais familiaridade com bancos de dados, linguagens de programação para trabalhar com eles, formas de extrair e cruzar esses dados, e isso é ótimo. Porém, pessoalmente, considerando o tanto de skills que uma pessoa PM precisa ter, acho que essa demanda poderia ser resolvida de uma maneira mais inteligente. Mesmo que a pessoa PM seja uma gênia nesse ponto, sempre que houver esforço para caçar um dado que a gente não sabe bem onde está, os dados estiverem espalhados em diferentes lugares, e a forma de extração e consumo não for facilitada, é lentidão que acrescentamos às nossas validações.
De maneira geral, resumo em dois os caminhos mais óbvios para simplificar as coisas: (1) contar com um time/pessoa para dar suporte às pessoas PMs com isso, ou (2) a estrutura de dados da empresa é amigável e organizada o suficiente para que o time de produto, com um conhecimento básico e baixo esforço, consiga achar e consumir o dado de que precisa sozinho, além de contar com atualizações automatizadas de seus dashboards.
…o driver/objetivo sempre seria uma métrica.
E, nessa frase, o "uma" é tão importante quanto o "métrica".
Uma vez escutei um podcast onde a Liza Mello falou sobre como ela gosta de trabalhar (dando o exemplo da PlayKids para isso): a empresa dá o máximo de autonomia para os times, um único KPI e deixa as pessoas acharem seu jeito de mexer esse ponteiro.
Sobre o "métrica":
Na maioria dos casos, o que eu vejo são muitos objetivos que simplesmente dizem o que as squads têm que fazer. Implementar ou evoluir uma feature, por exemplo, é dizer o que o time precisa fazer. Reduzir churn, aumentar adoção, aumentar retenção ou MRR, é dizer o que o time precisa atingir (independente do que ele decida fazer para isso). Vai na velha linha do "output vs. outcome". (Para quem quer ler mais sobre isso, indico Melissa Perri).
Sobre o "uma":
Por fim, sobre foco: é muito difícil, em um curto espaço de tempo, todas as tribos olharem para vários objetivos ao mesmo tempo. Simplesmente não acho produtivo. Os efeitos colaterais disso são vários, mas cito alguns:
- Débitos (técnicos ou de experiência), porque tudo tem que sair rápido para ser possível cobrir todas as metas do ano.
- As coisas podem ser mal validadas, pelo mesmo motivo acima.
- Cada time vai escolher uma ou duas prioridades para colaborar, e vai tentar atropelar o roadmap dos outros para que as demais prioridades aconteçam, sem necessariamente pararem para entender para quais prioridades o outro time está olhando.
- E o que eu acho pior: nada ganha força. Os esforços ficam pulverizados. Geralmente, é preciso várias alavancas juntas, em um mesmo sentido, para mexer um número de forma robusta.
…o apoio da PM ao go-to-market seria realmente só um apoio.
Potencialmente ninguém sabe mais sobre uma melhoria que está sendo implementada no produto do que a pessoa PM. Portanto, é lógico que essa pessoa precisa apoiar a divulgação da mesma. Mas apoiar é diferente de fazer.
Brifar (de forma completa e acessível) e estar disponível para dúvidas é apoiar. Gravar vídeos, preparar tutoriais, materiais de divulgação, escrever conteúdos e dar treinamentos é fazer.
Em empresas que estão em estágios mais iniciais, a pessoa de produto vai, sim, fazer tudo isso e mais um pouco, e é isso aí. Mas, em uma empresa mais madura, o mundo maravilhoso seria a pessoa PM não precisar fazer tudo isso, para ter tempo para… bom, vocês já sabem.
…a pessoa de produto estuda sobre produto.
Em uma área extremamente dinâmica, tirar os olhos do seu próprio board do Jira e saber sobre o que está rolando no mercado é de grande valor. Apesar de ser uma grande fã de ouvir podcast enquanto pedalo, essas 3 horinhas semanais são poucas, e às vezes eu só preciso de uma pedalada ouvindo música mesmo.
Esse ano tenho buscado reservar as manhãs de sexta-feira para sair da bolha, digo, ler livros e artigos sobre gestão de produto. Mas nem sempre dá tempo. No meu mundo conto de fadas do produto, daria! :)
Isso reforça a importância de todos os itens desse post que falam sobre economia de tempo. Vejo como essencial que a empresa e a área de produtos se organizem de forma a permitir a atualização das suas pessoas de produto (ou todas as suas pessoas, né).
Isso não só faz com que as pessoas aprendam sobre novas práticas, como também ganhem o respiro necessário para chegarem à novas e melhores formas de resolver seus problemas.
…a pessoa de produto não faz CSI de bug.
Porque, simplesmente, ela não é a pessoa mais indicada para isso.
A pessoa PM fica sabendo dos bugs de forma ordenada, entende com o time a melhor forma de resolvê-los, ajuda a determinar a urgência em resolvê-los, todas essas coisas. Mas ela não recebe uma mensagem do cliente no seu WhatsApp cedo de manhã reportando sobre um problema e sai desesperada tentando entender por que ele está ocorrendo.
Como exemplo, a RD Station faz isso de uma maneira incrível. Temos diferentes níveis no suporte, pelos quais o cliente vai escalando caso o seu problema seja mais ou menos complexo de resolver. Muitas vezes, o cliente só não entendeu como usar alguma coisa (alôu PM e designer, heheh — nesses casos, ter uma classificação que indique isso nos chamados nos ajuda muito a usar isso como material para priorizar melhorias). Para essas situações, o primeiro nível de suporte consegue ajudar. Mas, se as pessoas do suporte forem identificando que realmente há um problema, e elas não conseguem resolver, uma única pessoa do nível final do suporte é responsável pela interface com o nosso time, que por sua vez faz rotação para que cada semana uma pessoa de engenharia esteja disponível para isso. Ou seja: quando a situação chega à pessoa PM, já sabemos que o problema de fato é um problema, do que se trata, e às vezes até já recebemos recomendações de como resolver.
É muito improdutivo que a pessoa de produto tenha que receber as reclamações e investigar se elas de fato decorrem de um bug, para daí priorizar correções.
…a pessoa PM não é a principal responsável pela data ou atraso da entrega.
É lógico que temos responsabilidade nisso, e sempre teremos. Só por termos total relação com o escopo do que é construído, já temos também muita relação com o tempo que isso leva para ficar pronto.
No entanto, eu acredito que uma squad saudável deva contar com uma liderança de engenharia e uma pessoa de agilidade designados. Essas pessoas, ao meu ver, devem responder tanto ou mais por prazos do que a pessoa PM. Isso porque, se o time encontra obstáculos que o impede de andar na velocidade que havia sido prevista, essas são as melhores pessoas para ajudá-lo a contornas esses imprevistos, e também explicá-los externamente para as pessoas de interesse.
…todos os times têm uma visão de produto.
Parece óbvio, mas vejo bastantes times de produto trabalhando sem uma visão para chamar de sua.
Seja lá como as tribos de uma empresa se organizem, vejo como essencial cada uma ter a sua visão própria. Porque, sem isso, penso que os times tendem a se guiar 100% pelos drivers da empresa que, por serem generalistas como se espera deles, não preveem as dores específicas de cada parte do produto, ou de cada produto da companhia, ou de cada persona, etc.
E aí está o grande valor de uma visão por feature/tribo/afins: ela pensa na evolução específica do tema da tribo, e então a pessoa PM pode combinar essa evolução aos drivers da companhia, e chegar num ganha-ganha excelente.
…as squads têm os recursos necessários para entregar o que se espera delas.
Talvez esse seja o ponto de maior polêmica, porque sabemos o que — especialmente nos dias de hoje — significa financeiramente para uma empresa esses "recursos necessários" de que falo.
O que quero dizer é que: se temos menos recursos que gostaríamos (e, não importa a quantidade de pessoas, uma empresa sempre tem menos pessoas que sonha ter), deveríamos ter menos squads. Vai na linha do que já falei em algum ponto acima: fazer escolhas e concentrar mais recursos nelas, em vez de dispersar.
Se não podemos ter mais pessoas, e não queremos ter menos squads, podemos também revisitar quais são nossas expectativas sobre cada um desses times. Só o que não faz sentido é querer tudo ao mesmo tempo, pois geralmente isso resulta em frustração (para todos os lados envolvidos).
…os itens só iriam para roadmap após serem completamente validados (a menos que dispensem validação).
Quem nunca, né? Eu por várias vezes já inseri "mais para frente no roadmap" itens que não estavam 100% validados para ir validando até chegar lá, e às vezes — por uma série de razões — ainda acontece. Vida que segue. O que não pode acontecer é um item que precisava ser validado acabar sendo construído sem ter passado por essa validação.
No entanto, idealmente, todas as validações devem ocorrer antes dos itens irem parar no roadmap. Algumas razões:
- Por mais que sejam feitos todos os disclaimers sobre a natureza flexível de um roadmap, ele é uma ferramenta de comunicação. Depois de comunicar uma coisa, pode ficar bem difícil de mudarmos essa comunicação. Colocando no bom português, a pessoa X vê lá um item Y no roadmap e se apaixona. Mas, no processo de validação, a pessoa PM descobre que Y não era uma boa aposta, e decide tirar do roadmap. Vai por mim: a pessoa X vai ter muita dificuldade de entender isso.
- A pessoa PM pode ir para o processo de validação com muitos vieses. Se algo já foi para o roadmap, significa que a pessoa de produto já acredita tanto naquilo que quererá validar a hipótese de todo jeito. Além disso, tem a problemática acima, de divulgar uma mudança de roadmap, o que também faz a pessoa PM ir para esse processo muito mais determinada a escrever requisitos para passar para delivery do que da fato validar qualquer coisa.
Para fechar esse item, reforço a última parte dele: nem tudo precisa de validação! Uma pessoa PM tem conhecimento acumulado suficiente sobre a sua feature ou área de atuação do produto para entender quando algo simplesmente não precisa ser validado para sabermos o valor que entrega e a viabilidade de construirmos.
***
Ao ler o texto, pensou várias vezes "pfff, que pessoa mais desconectada da realidade"? Confesso que, relendo o conteúdo para revisar, até eu pensei isso (risos). De fato, conseguir seguir todas essas diretrizes acima ao mesmo tempo beira o impossível.
De toda forma, como promete o título, a intenção foi justamente pintar o quadro do extremo ideal para que, como comunidade de product management, possamos repensar algumas práticas e — um item por um — irmos construindo um contexto que nos permita irmos mais longe, mais rápido e de forma mais sã com nossos produtos.
Seu mundo maravilhoso da gestão de produtos também seria assim? Deixe seus comentários!
