Português

Seus primeiros 30/60/90 dias como novo gerente de produto

Você vai receber a mensagem na semana 2. Às vezes no dia 4. Ela chega pelo Slack, de alguém sênior, normalmente um lead de vendas ou o CEO, e diz algo como: "ei, dá pra escopar isso para o próximo sprint? Cliente grande pedindo."

Dizer sim parece ser o trabalho. É a armadilha.

Os PMs que entregam na semana 2 são os PMs que são desfeitos no mês 6. Não porque entregaram a coisa errada (embora geralmente tenham entregado), mas porque gastaram sua credibilidade na primeira funcionalidade que alguém pediu, em vez de comprá-la de volta pela descoberta. Quando descobrem o problema de verdade, já queimaram um sprint e meio de boa vontade da engenharia numa funcionalidade que 11% dos clientes vão tocar algum dia.

Este é o playbook para o outro caminho. É como eu rodaria meus primeiros 90 dias se estivesse começando na segunda.

Por que 30/60/90 importa mais para PMs do que para qualquer outro cargo

Um novo engenheiro entrega um PR na semana 1 e o time agradece. Um novo designer sobe um arquivo do Figma na semana 2 e o time elogia o capricho. Um novo PM entrega uma funcionalidade na semana 2 e o time... espera para ver se funciona, e então silenciosamente rebaixa a pontuação de confiança quando não funciona.

PMs não têm autoridade direta. Não escrevemos o código, não desenhamos as telas e não assinamos os contratos. A única moeda que temos é confiança + evidência. A janela de 90 dias é a janela em que seu lead de engenharia, seu designer, seu gestor e seus 2 principais stakeholders silenciosamente decidem se você é um estrategista que por acaso usa Jira, ou um mexedor de Jira que por acaso se chama de estrategista.

Os primeiros 30 dias são quando você compra essa credibilidade. Os 30 seguintes são quando você começa a gastá-la com cuidado. Os últimos 30 são quando você começa a compô-la.

Pule a fase um e o resto desmorona.

Dias 1 a 30: escute, não entregue

O primeiro mês tem um único trabalho: construir uma teoria privada do produto, dos clientes e do time que seja melhor do que a do seu gestor. Você não consegue fazer isso da sua mesa.

Marque 10 entrevistas com clientes nos primeiros 21 dias

Cinco power users. Três clientes que deram churn. Dois prospects que não compraram. Essa é a mistura.

Peça ao seu time de CS os power users, os que renovam sem negociação e respondem no Slack em até 10 minutos. Peça a quem é dono da retenção a lista de churn, e então peça especificamente os que saíram nos últimos 90 dias, não no ano passado. Peça a vendas os prospects que chegaram ao demo e sumiram.

O objetivo dessas calls não é validar soluções. É achar a linguagem que seus clientes usam quando ninguém está escutando. Power users vão te contar os workflows que eles improvisaram com fita adesiva. Clientes que deram churn vão te contar o que finalmente os fez desistir. Prospects vão te contar o que faltou no demo que ninguém do time de deal percebeu.

Algumas regras que aprendi do jeito difícil:

  • 30 minutos no máximo. Você não está tocando um projeto de pesquisa enterprise. Disciplina de calendário vence profundidade no primeiro mês.
  • Grave com consentimento, transcreva com Otter ou Granola. Reescutar a 1,5x é onde os padrões aparecem.
  • Pergunte "o que você tentou antes disto?" de cinco jeitos diferentes. É ali que vivem os gatilhos de compra e as gambiarras.
  • Não venda nada. Nem sutilmente. Seu trabalho é escutar, não testar ideias que você ainda não tem.

Na entrevista 7, você vai começar a ouvir a mesma reclamação formulada de três jeitos diferentes. Isso é sinal. Anote literalmente. Copie as palavras do cliente, não a sua tradução delas. Os PMs perdem 60% do significado original no momento em que parafraseiam.

Audite as 3 métricas pelas quais seu produto é medido, e ache uma em que você não confia

Todo produto tem 3 números pelos quais é julgado. Ativação. Retenção. ARR. Ou alguma variante. Ache-os. Depois vá achar as queries de SQL, os dashboards e as pessoas que são donas deles.

Você está procurando uma coisa específica: uma métrica que ninguém consegue explicar por completo. Talvez seja "usuários ativos semanais" mas a definição foi atualizada pela última vez há 14 meses e exclui um segmento de cliente que agora é 30% da base. Talvez seja uma taxa de ativação que conta contas de demo. Talvez ninguém consiga te dizer o que "engajado" significa.

Ache essa métrica. Não a conserte ainda. Apenas anote a pergunta e leve-a ao seu check-in de dia 30 com o gestor. Quando entrei na minha última empresa, a métrica em que eu não conseguia confiar acabou sendo a North Star à qual o roadmap inteiro estava ancorado. Trazer à tona aquela única pergunta me comprou três meses de credibilidade antes de eu ter entregado qualquer coisa.

Sente com eng por um sprint, com design por uma crítica, com suporte por um dia

Convites de calendário, não DMs no Slack. Especificamente:

  • Engenharia: peça para participar do sprint completo deles (planning, daily stand-ups, retro). Não fale a menos que seja chamado. Você está aprendendo a arquitetura, as mágoas de dívida técnica e quais tickets fazem o time resmungar.
  • Design: participe de uma crítica de design, ou duas. Você está aprendendo o vocabulário de design do time, como é o bom trabalho e de quais partes do produto os designers estão silenciosamente envergonhados.
  • Suporte: acompanhe um agente de suporte por um dia inteiro, idealmente uma quarta-feira (pico de volume de tickets em B2B SaaS). Você vai ver os mesmos 4 problemas aparecerem 30 vezes. Esses problemas são o seu roadmap oculto.

Este é o reconhecimento mais barato que você jamais vai rodar. A maioria dos PMs pula porque não gera artefatos. É esse o ponto.

Aprenda o domínio do codebase, não o código

Você não precisa escrever um PR. Você precisa conseguir ler um sem entrar em pânico.

Consiga acesso ao repo no dia 3. Peça ao seu lead de eng para te guiar pela arquitetura de alto nível em 30 minutos. Leia os últimos 10 PRs mesclados. Marque o modelo de dados. Saiba os nomes dos três serviços centrais e mais ou menos o que eles fazem.

A régua é: quando um engenheiro diz "teríamos que mexer no serviço de billing para fazer isso", você sabe se isso significa uma terça-feira ou um trimestre.

Uma regra dura: não proponha nada no seu primeiro all-hands

Não compartilhe uma visão. Não apresente um roadmap. Não largue um "hot take" no seu Slack de apresentação. Cada palavra que você diz nos primeiros 30 dias está sendo calibrada contra evidência zero, e assim que você coloca uma posição na mesa, vai passar os 60 dias seguintes defendendo-a em vez de refiná-la.

Apresente-se. Diga o que você está escutando. Prometa uma opinião no dia 60. Depois vá escutar.

Dias 31 a 60: conquiste sinal

No dia 31, você tem uma teoria privada do produto. Os 30 dias seguintes são sobre pressionar essa teoria sem apostar sua credibilidade inteira nela.

Entregue uma pequena aposta que você não propôs

Este é o truque: herde algo que já está escopado. Uma funcionalidade que seu antecessor especificou. Um projeto de caça a bugs que está parado no backlog. Uma pequena migração que o time concordou ser necessária mas ninguém é dono.

Escolha algo com uma definição clara de pronto, entregue em até três semanas, e use o projeto como sua jogada de credibilidade rápida. Você não está apostando seu julgamento nele (você não o escolheu), mas está demonstrando que consegue rodar um sprint sem deixar cair o bastão. Leads de eng notam isso. Eles notam mais do que notam seu trabalho de descoberta, porque é tangível.

Se você é sênior ou staff, o projeto herdado pode ser uma pequena migração ou a aposentadoria de uma funcionalidade obsoleta. O formato importa menos que o prazo. Três semanas. Pronto. Visível.

Rode um sprint de descoberta sobre um problema que você achou nas entrevistas

Agora você gasta um pedaço de credibilidade, deliberadamente. Escolha o sinal mais forte das suas entrevistas com clientes (o que você ouviu de pelo menos 6 dos 10) e rode um sprint de descoberta estruturado sobre ele.

Duas semanas. Um PM (você), um designer, um engenheiro por uma hora ao dia. Saídas: uma declaração de problema, três esboços de solução e uma decisão sobre investir um sprint completo em algum deles.

O objetivo não é entregar. O objetivo é tornar a descoberta legível para o seu time. Eles nunca te viram rodar uma antes. Mostre a eles como é o bom trabalho. (Temos um playbook de sprint de descoberta que percorre a estrutura, caso você queira um template.)

Proponha a v1 da sua árvore de oportunidades e soluções, só para o seu gestor

No dia 50, você ouviu 10 clientes, auditou 3 métricas, sentou com eng e rodou um sprint de descoberta. É material suficiente para construir uma v1 de árvore de oportunidades e soluções: o resultado desejado no topo, as oportunidades (problemas) que você validou embaixo, e algumas soluções candidatas na base.

Mostre-a ao seu gestor primeiro. Não ao time. Não aos stakeholders. Ao seu gestor, num 1:1, com o pedido explícito: "me diga onde isto está errado antes de eu socializar."

Dois motivos. Um: árvores construídas no vácuo são torpedeadas em público. Dois: seu gestor conhece o mapa político que você não conhece. Ele vai te dizer qual oportunidade pertence a outro time, contra qual o CEO tem uma birra pessoal, e qual está prestes a ser morta por uma reorganização do board.

Refine a árvore, depois planeje um walkthrough mais amplo para o dia 75. (Se você quer a introdução estrutural, a árvore de oportunidades e soluções explicada para PMs de B2B cobre isso.)

Comece a escrever notas de produto semanais: achados de descoberta, não atualizações de status

Toda sexta, envie um documento curto ao seu gestor e ao seu lead de eng. Não uma atualização de status extraída do Jira. Uma nota de descoberta. O que você ouviu dos clientes nesta semana. Qual métrica você investigou. Sobre o que você mudou de ideia.

300 a 500 palavras. Sem lista de projetos. Sem burndown de sprint. A nota te posiciona como alguém com um ponto de vista, não como alguém com um backlog.

Esse hábito compõe. No mês 6, seu lead de eng vai ler suas notas antes da standup. No mês 12, seu CEO vai encaminhá-las a candidatos como um artefato de recrutamento.

Dias 61 a 90: assuma a propriedade

Propriedade em PM significa três coisas: uma métrica pela qual você é publicamente responsável, um roadmap com uma lista explícita de "não", e disposição para matar coisas que não conquistam o seu lugar.

Seja dono de uma métrica publicamente, e escolha um insumo, não um output

No dia 65, poste no canal do Slack do seu time: "Estou assumindo a taxa de ativação semanal para novos signups self-serve. Meta: elevá-la de 22% para 30% até o fim do Q3. Vou postar semanalmente."

Duas observações sobre a escolha de métrica:

  1. Escolha um insumo, não um output. A taxa de ativação é um insumo da retenção. A retenção é um output. Insumos são coisas que você consegue mover diretamente com mudanças de produto. Outputs são coisas pelas quais você vai ser culpado quando vendas tiver um trimestre ruim. Seja dono do insumo. (Aprofundamos isso em Métricas de PM: resultado versus entrega.)
  2. Escolha algo que não vá se mover por causa de uma campanha de marketing. Se sua métrica pode ser turbinada por um disparo de e-mail, você não é dono dela. Marketing é.

Ser dono de uma métrica publicamente é a jogada de maior alavancagem dos primeiros 90 dias. Ela muda como você é visto pelo time de eng, pelos seus pares e pelo seu gestor. Do dia 66 em diante, você não é "o novo PM". Você é "o PM que é dono da ativação".

Apresente seu roadmap de 6 meses com 3 apostas e 3 nãos explícitos

Dia 75 a 80. Você entra no seu time e apresenta o roadmap.

Não 12 funcionalidades. Três apostas. Cada aposta atrelada a uma oportunidade da árvore. Cada aposta com uma hipótese, um movimento-alvo de métrica e um critério de morte.

Depois (e esta é a parte que a maioria dos novos PMs pula) você lista três coisas que você explicitamente NÃO vai fazer. Não "chegamos lá depois". Não "está no backlog". Um "não" real com um motivo real. "Não vamos construir relatórios avançados neste semestre. Os dados nos dizem que os power users querem, mas os power users não dão churn. Vamos focar na ativação."

A lista de "não" é o que te dá o direito de dizer não na próxima vez que vendas pedir. Sem ela, todo pedido é território novo e você tem que relitigar prioridade toda semana.

Rode uma cerimônia de morte para 3 funcionalidades zumbis

Uma funcionalidade zumbi é algo que é entregue, não é usado, e ninguém tem a coragem de descontinuar. Todo produto B2B SaaS tem delas. O seu tem mais do que você imagina.

No dia 85, identifique três. Critérios: menos de 5% de adoção, sem desenvolvimento ativo nos últimos 9 meses, sem cliente enterprise com ela no contrato.

Depois rode uma descontinuação. Anuncie. Mande e-mail para os poucos clientes que a usam (serão menos do que você teme). Documente por que você a matou num documento público. Comemore na standup.

A cerimônia de morte faz três coisas. Sinaliza que você vai trocar escopo por foco. Limpa a carga mental da engenharia (zumbis custam mais em manutenção do que qualquer um admite). E estabelece o precedente de que nada no produto é sagrado.

Estabeleça seu log de decisões

No dia 90, você tem um único documento (Notion, Linear, onde for) que registra cada decisão de produto relevante: a pergunta, as opções consideradas, a escolha, a data, a justificativa.

O seu eu futuro vai agradecer ao seu eu presente. Na próxima vez que vendas entrar com um pedido-surpresa que mapeia para algo a que você disse não no mês 2, você vai ter o rastro de papel. "Tomamos esta decisão em 14 de maio. É isto que sabíamos, é isto que precisaríamos aprender para eu revisitar. O que mudou?"

As duas armadilhas que vão devorar seus 90 dias se você deixar

Dois padrões vão silenciosamente absorver o tempo de que você precisa para tudo acima. Dê nome a eles agora.

Armadilha 1: o pedido-surpresa de vendas

O Slack chega. "Ei, estou numa revisão de deal com US$ 80 mil de ARR em jogo. Eles precisam de [funcionalidade]. Dá pra entregar no próximo sprint?"

Não diga sim. Não diga não. Diga isto:

"Este é exatamente o tipo de pedido em que eu quero ser ótimo. Me manda o one-pager do deal e as duas maiores dores do prospect. Vou ter uma recomendação em 48 horas, não no próximo sprint, mas uma de verdade. Se dissermos sim, quero garantir que estamos resolvendo para eles, não só para este deal. Se dissermos não, quero que você tenha o enquadramento certo para o cliente."

Três coisas que esse roteiro faz:

  1. Te compra 48 horas, que é a diferença entre estratégia e estenografia.
  2. Força o AE a articular o problema por escrito, o que mata 30% dos pedidos na hora (o prospect estava bem, na verdade).
  3. Te reenquadra de "o PM que desbloqueia deals" para "o PM que melhora como lidamos com deals".

Você vai precisar desse roteiro de três a cinco vezes nos seus primeiros 90 dias. Salve num snippet. (Se você quer a versão mais aprofundada dessa conversa, dizendo não para vendas sem queimar o relacionamento percorre o playbook completo.)

Armadilha 2: PM-como-gerente-de-projeto

Você vai saber que está acontecendo quando seu calendário for 70% standups, retros, sprint planning e "deixa eu dar um sync rápido com você". Sua contagem de tickets do Jira está subindo. Sua contagem de entrevistas com clientes está estagnada.

Esta é a versão de cozimento lento do cargo fracassando. Ninguém te mandou virar o gerente de projeto do time. Você foi parar lá porque o time tinha um vazio e você o preencheu.

Resete antes que grude. Três movimentos:

  • Recuse duas reuniões recorrentes nesta semana. Escolha as duas de menor alavancagem e simplesmente diga "acho que não preciso estar nesta". O mundo não vai acabar.
  • Passe a administração do sprint para o seu tech lead ou scrum master. Se você não tem um, peça um. O PM não é o dono do Jira.
  • Bloqueie 2 horas toda manhã para descoberta. Calls com clientes, transcrições, trabalho na árvore de oportunidades. Inegociável. Se você não tem 2 horas de descoberta no seu dia, você não tem um trabalho de PM. Você tem um trabalho de coordenação com um título de PM.

A armadilha é confortável. A coordenação é visível. A descoberta é invisível até o mês 4, quando deixa de ser. Escolha o trabalho invisível mais cedo do que parece seguro.

Templates: o check-in de dia 30 com o gestor

Quando você entrar no seu 1:1 de dia 30, leve este one-pager. Ele ancora a conversa para longe de "como você está se adaptando" e em direção a se você está construindo a teoria privada certa.

CHECK-IN DE DIA 30 : [Seu nome]

O QUE EU APRENDI
- 3 padrões de clientes que ouvi repetidamente:
  1. [literal]
  2. [literal]
  3. [literal]
- 1 métrica em que não confio: [métrica] ([por quê])
- 1 coisa que o time está resolvendo que eu reenquadraria: [observação]

O QUE ESTOU PROPONDO (NADA AINDA)
- Dia 60: árvore de oportunidades v1 para você
- Dia 75: proposta de roadmap para o time
- Dia 90: ser dono de uma métrica publicamente

O QUE PRECISO DE VOCÊ
- [pedido específico 1, normalmente uma apresentação a cliente]
- [pedido específico 2, normalmente um aviso sobre stakeholder]
- [pedido específico 3, normalmente o escopo de autoridade sobre uma decisão]

Envie 24 horas antes da reunião. Seu gestor vai ler duas vezes.

Como é o bom resultado no dia 90

Aqui está a calibração. Ao fim do dia 90, três coisas devem ser verdadeiras.

Um: você consegue nomear os 3 principais problemas que seus clientes de fato têm. Não os do roadmap. Os reais, na linguagem do cliente. Você consegue ranqueá-los por frequência e severidade, e consegue apontar para as entrevistas que validaram cada um.

Dois: seu lead de eng confia na sua priorização. Você vai saber porque eles param de perguntar "você tem certeza de que estamos trabalhando na coisa certa?" e começam a perguntar "o que vem depois disto?" Essa mudança é tudo.

Três: seu gestor não precisa perguntar no que você está trabalhando. Você está enviando a nota de descoberta de sexta. Você é dono de uma métrica pública. Seu roadmap tem uma lista de "não". Seu log de decisões é atualizado semanalmente. O "puxar" deixa de ser necessário porque o "empurrar" é confiável.

Se as três forem verdadeiras no dia 90, você conquistou o direito de dar tacadas maiores no mês 4. Se nenhuma for verdadeira, você não fracassou, mas comprou um trabalho de gerente de projeto, não um trabalho de PM, e você tem mais um trimestre para resetar.

A confiança compõe. O output decai. Gaste os primeiros 90 dias comprando a confiança que te deixa fazer o trabalho de verdade pelos próximos 900.

Saiba mais