Português

Armadilhas comuns do gerente de produto (e como sair delas)

Por volta do mês 18, algo silencioso acontece com a maioria dos PMs. A cadência de entregas está bem. As standups estão bem. O deck do roadmap ganhou uma atualização no trimestre passado. Mas as vitórias não compõem do jeito que compunham no mês seis. Vendas continua interrompendo com pedidos de contas nomeadas. A engenharia parou de contestar no refinamento, o que soa como vitória e não é. Você não consegue dizer se é o cargo, a empresa ou você.

Isso é identificável por padrões. Vemos isso em toda organização de PM com que trabalhamos, e os padrões são quase sempre os mesmos sete. Aqui estão eles, com o sintoma que entrega cada um, o número que torna o custo real, e uma correção que você pode rodar esta semana. Leia uma vez. Escolha a que doeu. Faça a correção. Releia em 30 dias.

Armadilha 1: modo fábrica de funcionalidades

Sintoma: Você mede sucesso em tickets fechados. Seu dashboard de lançamento conta funcionalidades entregues. Suas retros comemoram "batemos 14 de 15 compromissos neste trimestre". Ninguém no time consegue nomear a métrica que a última funcionalidade deveria mover, e ninguém pergunta.

Número real: A análise de Itamar Gilad sobre resultados em nível de funcionalidade, sustentada pelos dados publicados pela Microsoft sobre experimentos do Bing e pelos estudos de testes do Google, chega mais ou menos ao mesmo lugar: cerca de um terço das funcionalidades entregues move métricas-alvo positivamente, um terço as move negativamente, e o resto fica estagnado. Traduza isso para uma fábrica de funcionalidades e você está entregando a uma taxa de cerca de 70% sem resultado. Se o seu time entrega 30 funcionalidades por ano, vinte delas não conquistam nada ou ativamente prejudicam o produto.

Correção: Mate o dashboard de lançamento. Substitua-o por um dashboard de resultados, mesmo que ele tenha três linhas por enquanto. Toda funcionalidade, antes de entrar na fila de construção, recebe uma previsão de métrica pré-registrada por escrito. Formato: "Se entregarmos X, esperamos que a métrica Y se mova de A para B em 30 dias. Confiança: média." Se você não consegue escrever essa frase, a funcionalidade não está pronta para ser construída. A disciplina não é a previsão estar certa; é a previsão existir. A calibração vem de comparar o que você escreveu com o que aconteceu.

Armadilha 2: pular a descoberta

Sintoma: Zero entrevistas com clientes no seu calendário neste trimestre. Você diz a si mesmo, e ao seu gestor, que está "ocupado demais executando". Você lê tickets de suporte às vezes. Você assistiu a um demo de vendas mês passado. Isso é descoberta, certo?

Número real: O benchmark de descoberta contínua de Teresa Torres (o que a maioria das organizações sênior de PM referencia) fica em um ponto de contato com cliente por semana, no mínimo, feito pelo PM pessoalmente. A maioria dos PMs que se sente travada está rodando de 0 a 2 pontos de contato por trimestre. É uma diferença de 12x a 50x entre saudável e travado.

Correção: Antes de ler qualquer linha a mais deste artigo, abra seu calendário e marque três entrevistas com clientes de 30 minutos para esta semana. Recrute por tickets de suporte e product analytics, não por repasses de vendas. (Entrevistas apresentadas por vendas pendem para prospects enterprise que querem funcionalidades, não padrões.) A primeira entrevista vai parecer inútil. A terceira vai trazer à tona algo que você não sabia na segunda-feira. Se três parece pesado, você achou sua armadilha.

Armadilha 3: entregar e esquecer

Sintoma: Revisões de lançamento existem no calendário do time. Revisões pós-lançamento de 30/60/90 dias não. A única vez em que alguém olha para uma funcionalidade depois do lançamento é quando ela quebra ou quando vendas reclama que é confusa.

Número real: Nas comunidades de PM que pesquisamos informalmente, cerca de 80% dos post-mortems de funcionalidades acontecem só em modo de falha: queda, regressão, queda de NPS. As funcionalidades que silenciosamente têm desempenho abaixo do esperado (entregues, usadas por 4% dos usuários pretendidos, sem ganho de métrica) não recebem post-mortem porque ninguém notou. Essas são as funcionalidades das quais você mais se orgulha na sua avaliação anual e que não fizeram nada pela empresa.

Correção: No momento do lançamento, antes de a funcionalidade ir ao ar, coloque um convite no seu próprio calendário com data de 30 dias à frente. Dono: você. Participantes: você e um engenheiro. Pauta: matar, iterar ou escalar. Escreva a decisão em um parágrafo e poste-a onde o resto do time possa ver. Se a resposta for matar, mate de forma visível. PMs que matam funcionalidades publicamente conquistam mais confiança do que PMs que nunca têm uma falha a relatar, porque o segundo grupo está mentindo ou não está medindo.

Armadilha 4: teatro de gestão de stakeholders

Sintoma: Você passa mais de 12 horas por semana em reuniões de alinhamento. As decisões tomadas nas reuniões não se sustentam. O mesmo tópico volta na semana seguinte. Você sai de cada reunião com itens de ação e nenhuma decisão. Você está exausto e seu roadmap não se moveu.

Número real: A pesquisa de PM de 2024 da ProductPlan colocou o PM médio em 23 horas/semana em reuniões; o quartil superior (por impacto autorrelatado e velocidade de promoção) ficou em 14. São nove horas de diferença por semana, toda semana, entre ocupado e eficaz. Anualizado, são 450 horas, cerca de 11 semanas de trabalho de tempo recuperado.

Correção: Escolha o sync recorrente de stakeholders com a menor densidade de decisão e cancele-o por duas semanas. Substitua-o por uma atualização escrita de sexta com três seções, no máximo meia página: o que foi entregue, o que está bloqueado, o que preciso até a próxima sexta. Poste onde os stakeholders possam comentar de forma async. Depois de duas semanas, conte quantos stakeholders cobraram você pela reunião cancelada. O número é quase sempre zero. Os que cobraram têm uma necessidade real; construa uma cadência menor e mais específica só com eles.

Armadilha 5: especificar demais e validar de menos

Sintoma: Seus PRDs têm 12 páginas. Você gastou dois dias no último. A engenharia lê a primeira página e passa o olho no resto. Zero protótipos foram colocados na frente de um cliente no último mês.

Número real: Escrever uma seção minuciosa de PRD que ninguém lê custa cerca de três horas de tempo focado de PM. Construir um clickthrough no Figma que gera reações reais de três clientes custa cerca de 30 minutos se você puder usar componentes existentes, uma hora se não puder. O clickthrough produz sinal; a seção do PRD produz um rastro de papel.

Correção: Limite seus PRDs a duas páginas. Seções permitidas: declaração de problema, resultado-alvo (com a previsão de métrica da Armadilha 1), solução proposta em três tópicos, o que explicitamente NÃO vamos fazer, perguntas em aberto. Qualquer coisa que você quis escrever além da página dois é um sinal de que você está evitando uma conversa com cliente. Construa o protótipo em vez disso, e deixe o protótipo responder as perguntas sobre as quais você ia escrever parágrafos.

Armadilha 6: dizer sim a todo pedido de vendas

Sintoma: Seu roadmap parece uma lista de contas nomeadas. Um ticket a cada dois tem um deal anexado. A frase "isto está comprometido com a Acme" aparece em três das suas últimas cinco reuniões de planejamento. Você não construiu nada para seus clientes existentes em dois meses porque o pipeline de deals devorou o trimestre.

Número real: Estudos da Intercom, da Pendo e de várias organizações de produto financiadas por VC chegam a uma faixa consistente: funcionalidades construídas especificamente para pedidos de contas conduzidos por vendas convertem em receita de expansão a cerca de 8% a 15%. A mesma capacidade de engenharia, redirecionada para funcionalidades de retenção ou ativação para a base existente, converte a 30% a 40% de impacto em NRR. Você está trocando um retorno de 3x por um retorno de 1x porque o 1x é mais barulhento na sala.

Correção: Construa um formulário de intake por escrito. Campos obrigatórios: qual deal, qual ARR, qual a alternativa se dissermos não, qual evidência existe de que outros clientes querem isto, como vamos medir o sucesso pós-construção. Faça vendas preencher. Cerca de 80% dos pedidos "urgentes" morrem no formulário, porque a alternativa sempre foi "vamos contornar" e a evidência sempre foi "este único prospect mencionou". Os que sobrevivem ao formulário são reais, e você vai construí-los com o contexto adequado.

Armadilha 7: RICE sem confiança honesta

Sintoma: Você abriu sua planilha de RICE no trimestre passado. Cada iniciativa foi pontuada em 80% de confiança ou mais. Algumas tinham 90%. Nenhuma ficou abaixo de 70%. Seu resultado de priorização parecia rigoroso e produziu o mesmo ranking que seu instinto produziria.

Número real: PMs calibrados, o pequeno subconjunto que acompanha a própria precisão de previsão ao longo do tempo, do jeito que os superforecasters de Philip Tetlock fazem, ficam em cerca de 55% a 65% nas decisões de confiança sobre resultados de funcionalidades. Essa é a faixa realista para alguém com instintos de produto fortes e medição honesta. Qualquer pessoa pontuando acima de 80% em cada item do backlog está se ancorando a um ranking desejado, não estimando. O framework vira teatro.

Correção: Comece um diário de previsões. No momento da pontuação RICE, anote seu número de confiança E uma previsão de uma linha do que vai acontecer se a funcionalidade for entregue. No momento do resultado (use a revisão de 30 dias da Armadilha 3), pontue a si mesmo: a previsão estava certa, parcialmente certa ou errada? Recalibre trimestralmente. Depois de dois trimestres de diário, sua confiança média vai derivar para baixo, em direção a 60%, e sua priorização vai começar a produzir rankings que te surpreendem. É o framework de fato funcionando.

A meta-armadilha

Releia aquelas sete. Elas compartilham uma raiz: otimizar para atividade visível em vez de aprendizado invisível. Tickets fechados são visíveis. O reconhecimento de padrões de clientes é invisível. Páginas de PRD são visíveis. Uma funcionalidade morta é visível (desconfortavelmente), uma funcionalidade que silenciosamente tem desempenho abaixo do esperado é invisível. As recompensas dentro de uma empresa tendem a fluir para o lado visível dessa linha, e é por isso que os PMs derivam para comportamentos de fábrica de funcionalidades e teatro de stakeholders mesmo quando sabem melhor.

A correção não é um novo framework por cima dos sete. É uma revisão semanal de 30 minutos em que você se faz uma pergunta e escreve a resposta: "O que eu aprendi sobre nossos clientes, nosso produto ou nosso time que eu não sabia na última segunda?" Se a resposta for nada, esse é o diagnóstico. As sete armadilhas são rotas diferentes para o mesmo destino, e a meta-correção é um recibo semanal de que você foi a algum lugar novo.

O que fazer esta semana

Escolha a armadilha que mais doeu durante a leitura. Provavelmente aquela com a qual você discordou mentalmente. Rode a correção específica:

  • Fábrica de funcionalidades → Escreva uma previsão de métrica para a próxima funcionalidade da sua fila, antes de ela ser construída.
  • Pular a descoberta → Três entrevistas com clientes marcadas esta semana.
  • Entregar e esquecer → Uma revisão de 30 dias no seu calendário para o lançamento mais recente.
  • Teatro de stakeholders → Cancele a reunião recorrente de menor densidade de decisão, substitua por uma atualização escrita de sexta.
  • Especificar demais → Limite seu próximo PRD a duas páginas.
  • Sim a todo pedido de vendas → Entregue o formulário de intake ao seu par de vendas até o fim da semana.
  • RICE sem confiança → Comece o diário de previsões na próxima sessão de priorização.

Releia esta lista em 30 dias. As armadilhas não desaparecem; elas rotacionam. Os PMs que continuam subindo são os que nomeiam a armadilha atual mais rápido a cada vez.

Saiba mais