Um dia na vida de um gerente de produto (B2B SaaS, edição honesta)

A descrição de cargo dizia que você iria "ser dono da estratégia de produto, impulsionar resultados e fazer parceria com a engenharia num roadmap unificado". São 8h47 de uma terça-feira e a sua realidade são três threads do Slack empilhadas uma sobre a outra: Vendas quer saber se você pode "só adicionar" SSO para um deal que fecha na sexta, um engenheiro sênior está perguntando se as exclusões devem ser em cascata ou soft-delete no novo log de auditoria, e o CEO largou um áudio com um "pensamento rápido de ontem à noite" sobre o dashboard. Um designer também está esperando o texto de um estado vazio. Você ainda não abriu o documento do seu roadmap e provavelmente não vai abrir pelos próximos noventa minutos.

Isso não é um modo de falha. Isso é o cargo neste estágio. Um PM de B2B SaaS em algum ponto entre Série A e o final da B não está tocando o tipo de organização de produto sobre a qual você lê em livros de empresas cinco rodadas à sua frente. Você está fazendo trabalho de PM, um pouco de trabalho de PMM, um pouco de desvio de reuniões de suporte, e uma boa dose de "dono da coisa que mais ninguém é dono". Se você está na cadeira há seis meses e sente que está atrasado no seu "trabalho de verdade" todos os dias, o problema não é você. O formato do trabalho é o formato.

O que este guia faz: percorre uma terça-feira real numa empresa de US$ 5M a US$ 100M de ARR, dá nome aos padrões e te entrega uma estrutura semanal defensável por cima do caos.

Por que o seu dia parece assim

A matemática do headcount é implacável. Na Série A, você costuma ser o único PM para 8 a 15 engenheiros divididos em dois squads, mais um time de GTM de 4 pessoas que todos querem dar input no roadmap. Na Série B, você pode ter um segundo PM, mas a área de superfície triplicou. Agora você também é dono das ferramentas internas, de um fluxo self-serve e de tudo o que o fundador entregou antes de você entrar e ninguém tocou há um ano.

Você ainda não tem um Product Marketing Manager, então o texto de lançamento cai no seu colo. Você não tem uma pessoa de Product Ops, então o framework de priorização, o template de release notes e o conselho de clientes vivem todos no seu Notion. O time de CS escala tudo o que não consegue responder em duas respostas, que é muita coisa. O CEO te usa como caixa de ressonância porque você é a única pessoa no prédio com contexto suficiente em produto, cliente e engenharia para dar uma resposta útil em menos de cinco minutos.

Meio PM, meio PMM, meio desviador de reuniões soma mais de 100% de propósito. É essa a matemática. A habilidade não é encaixar tudo em 40 horas; é decidir o que recebe a sua atenção de verdade e o que recebe uma passada "boa o suficiente".

8h00: revisão de call com cliente (20 minutos, inegociável)

Antes da standup, antes do Slack, você abre o Gong ou o Chorus e escolhe uma call de ontem. Geralmente uma call de descoberta ou uma saída de cliente que deu churn. Você passa o olho nas partes em que o cliente fala por mais de 30 segundos seguidos. É ali que está o sinal de verdade. O resumo do rep de Vendas é quase sempre generoso demais ("eles adoraram o demo!") ou filtrado por qualquer objeção com que o rep está mais preocupado naquele trimestre.

Já vi um PM perceber que o que Vendas descreveu como "eles querem relatórios melhores" era, na verdade, o prospect dizendo "não consigo mostrar ao meu CFO por que compraríamos isso em vez de manter a planilha". Problema diferente. Funcionalidade diferente. A funcionalidade teria sido entregue errada.

Você registra o insight no Productboard ou no Aha, normalmente como uma nota de uma linha marcada na iniciativa certa, com o timestamp da call linkado. Vinte minutos, todo dia útil, sem exceções. Esse é o hábito de maior alavancagem do cargo e é a primeira coisa que cai quando a semana fica barulhenta. Não largue.

Meio da manhã: async com a engenharia sobre dúvidas de spec

A standup é às 10. Você passa vinte minutos depois dela respondendo comentários no Linear ou no Jira. Metade é limpa: "sim, trate esse caso como um no-op." A outra metade é o imposto da ambiguidade de spec: perguntas que parecem esclarecimentos mas são, na verdade, mudanças de escopo vestidas de esclarecimento.

Uma real da semana passada: "Só esclarecendo, quando um usuário é removido de um workspace, a gente também revoga os tokens de API dele?" Isso não é um esclarecimento. A spec não cobriu porque ninguém pensou nisso. A resposta "sim, revogue" são doze horas de trabalho, uma security review e uma nota de comunicação voltada ao cliente. A resposta "não, deixe" são três linhas de código e um futuro ticket de suporte. Qualquer uma é defensável. Nenhuma é o que a spec dizia.

O trabalho do PM aqui é reconhecer que a pergunta é uma bifurcação, não uma placa de orientação, e ou decidir rápido ou escalar para uma call de decisão de 15 minutos com o engenheiro lead e a pessoa de segurança. O que mata os times é o PM dizendo "ah, faz o que for mais fácil" porque está atrasado no Slack, e descobrir dois sprints depois que o caminho "mais fácil" criou uma lacuna de compliance.

Respostas em Loom são uma boa ferramenta aqui. Um Loom de 90 segundos respondendo "é assim que estou pensando, é este o trade-off, me contesta se eu estiver errado" te dá uma resposta mais rica do que digitar, e o engenheiro pode reassistir.

Meio do dia: uma call de descoberta que não é votação de funcionalidades

Você bloqueia das 12h00 às 12h45 para uma call com cliente ou prospect. Não uma call conduzida por Vendas em que você é o fechador; uma conversa de descoberta de verdade. Documento do Notion aberto, duas perguntas pré-escritas e disposição para seguir o fio.

A maioria das calls de descoberta é ruim porque são votação de funcionalidades disfarçada. Você pergunta "você usaria uma integração com Salesforce?" e a pessoa diz "sim, claro", porque dizer sim não custa nada a ela e ela quer ser prestativa. Isso não é dado. A boa pergunta de descoberta é anterior às funcionalidades: "Me conte a última vez que você tentou fazer X. O que você de fato fez? O que quebrou? O que você fez em vez disso?" Você quer a história recente e específica, não a preferência abstrata.

A armadilha é tratar a call como uma sessão de feedback. Não é. É uma sessão de pesquisa, e pesquisa tem uma pergunta que você entrou tentando responder. Escreva a pergunta no topo do documento do Notion antes de a call começar. Depois da call, escreva três coisas: o que você ouviu, o que te surpreendeu, o que isso muda no próximo item que você vai construir. Se nada muda, a call não foi útil, o que em si é útil, porque significa que você está num ponto em que deveria validar com protótipos, não com entrevistas.

Para uma versão mais aprofundada disso, com roteiro, veja Conduzindo calls de descoberta que não são votação de funcionalidades.

Tarde: sync semanal com stakeholders

14h00. Lead de Vendas, lead de CS, lead de Marketing, você, numa sala de 45 minutos. Esta é a reunião em que as solicitações de "será que dá pra só adicionar" são arquivadas, priorizadas ou mortas. Se você não tem essa reunião num dia fixo, você a tem em fragmentos pelo Slack a semana inteira e perde três horas com ela em vez de quarenta e cinco minutos.

Você mostra o roadmap no Productboard ou no Aha, não em slides. Slides sugerem finalidade; o roadmap ao vivo sugere "este é o estado atual, ele pode se mover, aqui estão os trade-offs." Você percorre o que está em andamento, o que vem em seguida, e quais itens se moveram nesta semana e por quê. Depois você pega de três a cinco solicitações novas, faz a pergunta que as decide ("qual é a contagem de clientes e o peso em ARR por trás disso?"), e ou se compromete a avaliar, recusa com um motivo, ou estaciona.

Dizer não sem ser o PM-do-não é, na maior parte, dar ao não um formato claro. "Não vamos fazer isso no Q3 porque nos comprometemos com a velocidade de onboarding e isso atrasaria em três semanas; vamos rever no próximo planejamento trimestral" é um não que o seu lead de Vendas consegue vender internamente. "A gente não consegue fazer isso agora" é um não que volta como uma DM no Slack amanhã.

O enquadramento ao qual eu sempre volto: todo sim também é um não a outra coisa. Torne a outra-coisa visível. Mostre o trade. Os trades são a conversa.

Fim do dia: grooming do backlog

16h30. Quarenta e cinco minutos no Linear ou no Jira fechando tickets parados, puxando candidatos para o próximo sprint e revisando o release de ontem no Amplitude ou no Mixpanel. Figma aberto na aba ao lado para comentários de design sobre o que entra no sprint depois deste.

Higiene de backlog é pouco glamorosa e é a diferença entre um time de engenharia que confia na sua priorização e um que não confia. Se um ticket está aberto e parado há seis semanas sem movimento, feche-o com um comentário explicando por quê. Tickets parados num backlog são ruído que afoga o sinal do que de fato vem em seguida. Os engenheiros param de ler o backlog quando o backlog deixa de ser confiável, e quando isso acontece você volta a tocar tudo pelo Slack.

A checagem no Amplitude é curta: a funcionalidade que você entregou semana passada moveu a métrica que você disse que ela moveria? Se sim, escreva uma nota de uma linha no ticket de lançamento e siga em frente. Se não, pergunte por quê antes de entregar a próxima coisa por cima dela. A maioria dos PMs entrega a próxima coisa sem checar a última, e é assim que nascem as fábricas de funcionalidades.

As duas armadilhas

A fábrica de funcionalidades. A velocidade está alta. O time está entregando. As standups parecem produtivas. Mas quando você checa as métricas de resultado (ativação, retenção, expansão, as que o roadmap prometeu mover) elas estão estagnadas ou indo na direção errada, e ninguém no time teve uma hora tranquila para pensar no porquê em três meses. O teste de cheiro: se você perguntasse ao seu engenheiro sênior "qual problema estamos resolvendo neste sprint e como vamos saber que resolvemos", ele teria uma resposta limpa? Se a resposta for "estamos entregando a spec", você está numa fábrica de funcionalidades.

A correção não é desacelerar. A correção é colocar métricas de resultado ao lado de cada iniciativa no roadmap e se recusar a começar a próxima até checar se a última funcionou. Dez minutos de "moveu o número?" antes de cada kickoff. Barato de fazer. Quase ninguém faz. Veja Escapando da fábrica de funcionalidades para a versão mais longa.

Vendas sequestra o roadmap. Todo deal vira um compromisso customizado. O produto se fragmenta porque o cliente A ganhou um workflow que o cliente B não tem, e agora você está entregando lógica condicional em oito lugares diferentes. Seis meses depois você tem uma dívida técnica que não consegue pagar porque cada pedaço dela tem o nome de um cliente colado.

O sinal precoce: se as suas últimas três mudanças de roadmap vieram cada uma de um único deal, você está sendo sequestrado. A correção é uma regra clara que a empresa inteira conhece. A minha é "só vamos considerar um compromisso customizado se o deal for mais de 5x o ACP atual e se a mesma solicitação tiver vindo de três clientes distintos." Ajuste os números ao seu estágio. O ponto é ter uma regra, por escrito, que Vendas possa citar de volta a um prospect sem precisar escalar para você. Veja Dizendo não para Vendas sem virar o PM-do-não.

A stack que você vai tocar todo dia

Você não precisa de toda ferramenta. Você precisa de uma em cada categoria, e precisa que os dados fluam entre elas.

Para a comparação mais longa e o que escolher em cada estágio, veja Ferramentas e tech stack do gerente de produto.

Um formato semanal defensável

Você não consegue controlar cada ping do Slack. Você consegue decidir quais blocos defende e quais deixa o caos devorar.

Aqui está um formato semanal que sobrevive ao contato com a realidade na maioria das empresas de B2B SaaS:

Protegido significa que vai para o calendário antes de qualquer outra coisa e você o defende como uma reunião com um cliente. O bloco de tempo para pensar é o que a maioria dos PMs pula, e também é o que decide se você está operando um trimestre à frente ou sempre uma semana atrás. Duas horas, sem Slack, uma pergunta para pensar, um documento para escrever no fim. Proteja-o.

Comprimido significa que você atende, mas atende rápido. Reuniões de status migram para async. Pedidos de "tem um segundo?" recebem um "me manda um Loom ou um documento e respondo até o fim do dia." O ponto não é ser indisponível; é fazer com que o custo de te puxar para algo seja o mesmo de puxar qualquer outra pessoa.

Encerramento

O trabalho tem este formato porque a empresa tem este formato. Um PM numa empresa de 12 pessoas com quatro clientes tem um dia diferente de um PM numa empresa de 200 pessoas com quatrocentos clientes, e fingir o contrário é como você acaba tentando copiar um processo de um deck que não se aplica ao seu estágio.

O que sobrevive entre estágios: proteja o ritual da call com cliente, dê nome ao imposto da ambiguidade de spec quando você o vir, conduza calls de descoberta com uma pergunta e não com uma lista de funcionalidades, mostre o seu roadmap como um trade-off ao vivo e não como um slide, e cheque se a última coisa funcionou antes de entregar a próxima.

Uma frase para colar na sua revisão de calendário amanhã de manhã: o que recebeu atenção de verdade nesta semana, o que recebeu uma passada "boa o suficiente", e é isso que eu escolheria se estivesse começando a semana de novo?

Se a resposta for não por duas semanas seguidas, o formato precisa mudar.

Saiba mais

• Modelo de descrição de cargo de gerente de produto
• PM versus Product Marketing Manager: onde a linha de fato está
• Conduzindo calls de descoberta que não são votação de funcionalidades
• Dizendo não para Vendas sem virar o PM-do-não
• Escapando da fábrica de funcionalidades