Seus Primeiros 30/60/90 Dias como Novo Designer de Produto

Dia 4. Seu PM solta um arquivo do Figma no DM com "você pode polir isso para sexta-feira?" Você poliu. Parece bom: você entregou algo no quarto dia, o PM te agradeceu no standup, o EM mandou um emoji de joinha. Bem-vindo ao time.

Você também acabou de perder a única janela que tinha para questionar o problema subjacente. Quando estiver três meses dentro, terá polido dezesseis specs, não consegue nomear um único cliente com quem conversou, e seu gestor está perguntando o que você de fato lançou que seja seu. A resposta honesta é: nada. Você foi um operador de Figma com o título de Sênior.

Essa é a trajetória padrão. O padrão do PM-como-lançador-de-specs é a gravidade da organização, e você não escapa por acaso. Você escapa com um plano de 90 dias, executando-o deliberadamente e tendo uma pequena vitória inicial que te dá a credibilidade para continuar dizendo não.

Por Que os Primeiros 90 Dias São Inegociáveis

Não existe período neutro em uma empresa de B2B SaaS. Reorganizações acontecem. Resets de OKR chegam na semana 8. O ciclo de avaliação de desempenho referencia o que você fez no seu primeiro trimestre. Os designers que são promovidos no segundo ano são os que abriram espaço para descoberta antes que a fila do Jira os prendesse.

Uma vez me juntei a uma empresa em fase Série C onde o PD anterior durou nove meses e saiu "esgotado". Li o histórico do Figma. Ele lançou 47 specs. Fez zero ligações com clientes. Não contribuiu nada para o design system. Quando a organização foi reorganizada no mês sete, a liderança não conseguia articular o que ele era responsável, então foi realocado para um produto em descontinuação. Esse é o custo de pular os primeiros 30 dias.

O padrão abaixo é o que eu rodaria no primeiro dia de um novo cargo. É opinativo. Ajuste os números, não a estrutura.

Dias 1-30: Ouça e Mapeie

O único objetivo do mês um é entender o sistema antes de mudá-lo. Você vai ser tentado a lançar algo na semana 2. Não faça. O lançamento acontece no mês dois, e será melhor se você passar o mês um fazendo quatro coisas específicas.

Faça 10 ligações com clientes

Não "entrevistas com usuários". Ligações. Acompanhe o CS em três ligações ao vivo com clientes. Sente em duas demos de vendas. Leia 50 tickets de suporte e escolha cinco para ligar de volta. Participe de uma conversa de renovação se sua empresa permitir. Total: 10 conversas com clientes pagantes, registradas com citações.

Você não está rodando um processo de descoberta aqui. Está calibrando. Quer ouvir a linguagem que os clientes usam, as gambiarras que criaram, as telas que amaldiçoam, as funcionalidades que acham que existem mas não existem. Pela décima ligação, você deve conseguir terminar a frase de um cliente sobre seu produto.

Um script prático para as ligações que você inicia:

Oi [nome], acabei de entrar como designer de produto trabalhando em [área]. Estou passando o primeiro mês conversando com 10 clientes para entender como você usa o produto de verdade. Isso não é uma sessão de feedback e não vamos lançar nada a partir desta ligação. Adoraria 30 minutos para te ver fazendo [tarefa] e fazer algumas perguntas. Terça ou quinta funciona?

Três coisas que este script faz: é honesto sobre o seu papel, remove a ansiedade do "vão tentar me vender algo?", e pede comportamento (te ver fazendo X), não opiniões.

Audite as três telas com mais tráfego

Puxe os dados de produto. Escolha as três telas com mais usuários ativos semanais. Para cada uma, documente: o trabalho que o usuário está tentando fazer, o fluxo atual, os pontos de atrito e os dados da tela (rage clicks, abandono, tempo na tela).

Não proponha redesigns ainda. Nem esboce. A auditoria é um documento de referência que você vai usar nos meses dois e três quando alguém perguntar "deveríamos redesenhar o dashboard?" Você já terá a resposta.

Aprenda o design system do início ao fim

Cada token. Cada componente. Cada exceção documentada. Se o DS tem 80 componentes, você precisa conhecer todos os 80 até a semana três. É um trabalho sem glamour. Faça assim mesmo.

Por quê: a maneira mais rápida de perder a confiança da engenharia é projetar algo "ligeiramente diferente" porque você usou uma sombra customizada quando havia um token para isso. A maneira mais rápida de ganhar confiança é lançar um arquivo do Figma onde a nota de revisão de eng diz "sem mudanças, todos os componentes do DS." Isso acontece uma vez, e você acumula crédito que vai gastar no mês três.

Sente com engenharia e produto

Dois sprints completos com eng. Isso significa standups, planejamento, retrospectiva e pelo menos uma revisão de PR onde alguém te leva pelo codebase. Objetivo: entender o que é caro de mudar e o que é barato.

Dois ciclos de planejamento e grooming com PM. Objetivo: entender como o roadmap é feito de verdade, de onde vem a pressão (vendas? liderança? um cliente específico?), e quais batalhas já estão perdidas.

Ao final da semana quatro, você deve conseguir desenhar no quadro branco o grafo de tomada de decisão da organização. Quem realmente decide o que é lançado. Quase nunca é quem você imaginaria pelo organograma.

Semana a Semana, Mês Um

Aquele último entregável é a ponte para o mês dois.

Dias 31-60: Lance Pequeno, Construa Confiança

O mês dois é onde os novos PDs perdem o rumo. A tentação é pegar o resumo de uma página da semana quatro e apresentar uma visão de redesign de seis meses. Não faça. Apresente uma aposta pequena. Rode um sprint de descoberta. Contribua com um padrão para o DS. Três coisas, todas pequenas, todas lançadas.

Rode um sprint de descoberta em um problema delimitado

Não o épico do roadmap. Algo adjacente: um sprint de 2 semanas em um problema que tem sido ignorado por ser "pequeno demais para priorizar", mas que você notou nas ligações com clientes. A régua para o problema: você tem pelo menos três citações de clientes sobre ele, e a correção provavelmente custa menos de duas semanas de engenharia.

Exemplos que funcionam:

• A página de configurações onde 4 dos seus 10 clientes disseram que não conseguiam encontrar o botão de exportação
• O estado vazio de uma funcionalidade que está vendo apenas 12% de ativação
• O breakpoint mobile de um fluxo que converte 40% no desktop, mas 8% no mobile

O resultado do seu sprint de descoberta é uma página: problema, evidência, direção proposta, métrica de sucesso, estimativa de custo de engenharia. Mostre ao PM e ao EM. Peça duas semanas de engenharia.

Quando o PM disser "mas o roadmap..." (e vai dizer), use o script:

Entendo, o épico do roadmap é a prioridade. Não estou pedindo para trocar. Estou pedindo duas semanas de engenharia nesta correção delimitada que tem [X citações de clientes] por trás, vai mover [métrica] em um estimado [Y%], e me dá algo a apontar no relatório de 90 dias. Se lançarmos e não mover o indicador, redireciono 100% para o roadmap no T3.

Isso funciona porque é pequeno, com prazo definido, embasado em evidência, e dá ao PM uma saída. A maioria vai dizer sim. Os que dizem não estão te dizendo algo útil sobre se esse time vai te deixar fazer design.

Lance uma aposta pequena do início ao fim

O sprint de descoberta gerou uma página. Agora lance. Do início ao fim significa: você escreveu a spec (com o PM, não para ele), projetou em componentes do DS, passou pelo code review, definiu a métrica de sucesso antes do lançamento, e está monitorando.

Escolha algo onde o antes/depois seja mensurável em 30 dias. Uma correção de padrão. Uma simplificação de fluxo. O redesign de uma tela. A régua não é "transformador". A régua é "lançado, medido, e você consegue contar a história."

Um exemplo real de uma PD que orientei: ela lançou um redesign do estado vazio de uma funcionalidade de automação de fluxo de trabalho. Antes: 12% dos novos usuários construíam o primeiro fluxo na semana um. Depois: 31%. O redesign foram quatro telas. Duas semanas de engenharia. Ela usou aquele único gráfico em todas as conversas pelo próximo ano.

Contribua com um padrão reutilizável do DS

O design system tem lacunas. Você as identificou na auditoria do mês um. Escolha uma, de preferência uma que surgiu enquanto você projetava a aposta pequena, para ser algo real e não especulativo.

O fluxo de contribuição:

1. Abra uma proposta do DS no repositório do design system do time (ou arquivo do Figma). Documente a lacuna, três lugares onde seria usado, e um rascunho do padrão.
2. Obtenha a revisão do líder do DS antes de qualquer envolvimento de eng. O trabalho dele é dizer não a 80% das propostas. O seu é facilitar o sim mostrando que a lacuna é real.
3. Obtenha uma revisão de eng sobre viabilidade técnica. O padrão precisa ser barato de implementar e manter.
4. Lance como parte da sua aposta pequena, ou como um acompanhamento independente.

Um padrão no mês dois. Não um redesign do DS. Um padrão. Designers que tentam "consertar o design system" no primeiro trimestre são educadamente afastados da conversa do DS, de forma permanente.

Checklist do Mês Dois

• Uma página do sprint de descoberta, compartilhada com PM e EM
• Uma aposta pequena lançada, com métrica de sucesso definida e sendo rastreada
• Uma proposta de padrão do DS, revisada e incorporada
• PM e EM têm coisas positivas a dizer sobre trabalhar com você sem que você tenha pedido

Aquele último é qualitativo, mas importa. Em um 1:1, pergunte ao seu gestor: "qual é a percepção do time até agora?" Se a resposta for "você é fácil de trabalhar e lança coisas", você está no caminho certo. Se a resposta for "você está quieto" ou "você empurra muito", corrija no mês três.

Dias 61-90: Seja Dono de um Espaço de Problema

O mês três é onde você para de ser o designer novo e se torna um designer que é responsável por algo. Três entregáveis.

Escolha uma métrica de produto que você vai influenciar

Taxa de ativação. Tempo até o primeiro valor. Adoção de funcionalidade em uma superfície específica. Retenção de um segmento específico. Combine com o PM para escolhê-la. Isso é inegociável, porque se o PM não concordar que a métrica é dele influenciar, você vai trabalhar em um objetivo paralelo que ninguém vai se importar na avaliação.

Os critérios para a métrica:

• Ela se move em um horizonte de 4 a 12 semanas (não 2 dias, não 12 meses)
• Seu trabalho de design pode plausivelmente movê-la em 5%+
• PM e EM vão dizer "sim, essa é uma métrica real para o nosso time" sem hesitar
• Ela mapeia para um resultado do cliente, não um número de vaidade

Apresente um relatório de 90 dias

Um deck curto. Cinco slides. Não uma lista de arquivos do Figma.

1. O que aprendi. Top 3 insights das 10 ligações com clientes. Uma frase cada.
2. O que lancei. A aposta pequena, com a métrica antes/depois. O padrão do DS, com onde é usado.
3. No que estou apostando. O espaço de problema que você está reivindicando para o 2S.
4. A métrica. A única métrica de produto, com baseline atual e meta para 90 dias.
5. O que preciso. Capacidade de engenharia, tempo de pesquisa, decisões que preciso da liderança.

Apresente para o seu gestor, seu PM e seu skip-level. 25 minutos. O objetivo não é aplausos. O objetivo é que, três meses depois, quando alguém perguntar "o que [seu nome] faz?", três pessoas diferentes deem a mesma resposta.

Proponha seu plano de design para o 2S

Uma página. Duas ou três áreas de problema em que você vai trabalhar nos próximos seis meses. Para cada área: hipótese, métrica de sucesso, o trabalho de descoberta que você vai precisar fazer, a estimativa de custo de engenharia.

Este é o documento que protege o seu tempo. Quando o PM tentar jogar um ticket de "polir esta spec" no mês cinco, você aponta para o plano do 2S e pergunta "isso está no plano?" Se não estiver, a conversa se torna uma decisão real de priorização em vez de um sim automático.

Armadilhas Comuns e Como Evitá-las

Estas são as quatro formas como um plano de 90 dias falha. Já vi todas acontecerem.

Aceitar o ciclo de polir-a-spec na semana 1

O PM te passa um arquivo do Figma no dia quatro. Você poliu. Agora você é a pessoa do polimento. A solução não é recusar, porque isso queima o relacionamento. A solução é o redirecionamento suave:

Fico feliz em dar uma passada. Antes de tocar nos visuais, podemos passar 15 minutos no fluxo subjacente? Quero ter certeza de que entendi o problema para que o polimento realmente ajude. Se o fluxo estiver sólido, te devolvo até o final da semana.

Oito vezes em dez, a conversa de 15 minutos revela que o fluxo tem problemas, e você acaba fazendo trabalho real de design. Duas vezes em dez, o fluxo está genuinamente ok e você poliu. De qualquer jeito, você estabeleceu que "PD = colaborador pensativo", não "PD = finalizador de pixel".

Pular as ligações com clientes porque o PM já fez pesquisa

O PM fez entrevistas. Talvez as tenha feito bem. Não importa. A interpretação dele da dor do cliente é filtrada por um cérebro de PM. A sua precisa ser filtrada por um cérebro de designer. Faça as 10 ligações de qualquer jeito. O custo é 10 horas ao longo de um mês. O valor é ter seu próprio modelo do usuário que você pode defender contra o modelo do PM quando discordarem.

Redesenhar o design system antes de ganhar o direito

Seu DS está "desatualizado". Os tokens estão "bagunçados". Os componentes são "inconsistentes". Talvez. Também: você está aqui há três semanas. Todo PD que durou mais do que você tentou consertá-lo. Alguns tiveram sucesso em pequenas coisas. Alguns foram demitidos.

O direito de redesenhar o DS é conquistado, não concedido. Vem depois de você ter lançado 3-5 vitórias pequenas, contribuído com 2-3 padrões, e o líder do DS confiar no seu julgamento. Isso é um processo mínimo de um ano. No mês três, seu trabalho é um padrão, não um deck de visão.

Apresentar o relatório de 90 dias como uma lista de arquivos do Figma

"Aqui estão 23 telas em que trabalhei." Ninguém liga. A liderança se importa com: o que você aprendeu, quanto custou, o que retornou, o que você vai fazer a seguir. Resultados, não artefatos. Se o seu relatório de 90 dias tem mais telas do que frases, você está fazendo errado.

Templates para Aproveitar

Uma lista curta de artefatos que você deve ter até o dia 90:

• Script de entrevista de 10 ligações (variante B2B SaaS). Perguntas baseadas em comportamento, não em opinião. "Me leve pela última vez que você fez X" bate "o que você acha da funcionalidade Y" toda hora.
• Template de auditoria de fluxo. Uma página por tela: trabalho, fluxo atual, pontos de atrito, dados, top 3 hipóteses de melhoria.
• Página de "por que isso é um sprint de descoberta, não uma spec de funcionalidade" para o PM. Use quando precisar defender trabalho exploratório contra a pressão do roadmap.
• Roteiro do deck de relatório de 90 dias. Cinco slides. Resultados, não telas.
• Página do plano do 2S. Duas ou três áreas de problema, hipóteses, métricas.

Você não precisa que nenhum desses seja polido. Precisa que existam e sejam encontráveis no Notion ou Confluence do seu time.

Medindo o Sucesso no Dia 91

Cinco coisas. Se você conseguir marcar todas as cinco, o próximo trimestre começa em terreno sólido.

• 10 ligações com clientes registradas com citações que você consegue lembrar
• Uma aposta lançada com uma métrica antes/depois que o PM concorda que é real
• Um padrão do DS incorporado e usado em algum lugar fora do seu próprio trabalho
• PM e EM conseguem articular o seu espaço de problema sem você na sala
• Você tem uma resposta de uma linha para "no que você está trabalhando?" que não é um nome de funcionalidade, é um problema ou uma métrica

Se você conseguir atingir esses cinco até o dia 90, você não é mais um designer novo. Você é um designer que tem responsabilidade por um espaço de problema, lançou algo e tem um plano. Essa é a posição de onde você negocia no mês quatro. Essa é a história que seu gestor conta no check-in de desempenho do 2S.

O padrão do PM-como-lançador-de-specs não vai embora. Ele simplesmente para de ser a gravidade na qual você está preso. Você optou por sair, tem evidência de que consegue fazer o trabalho mais difícil, e os próximos 90 dias são seus para definir.

Saiba Mais

• Descrição de Cargo de Designer de Produto
• Trabalho de Descoberta como Designer de Produto
• Responsabilidade Ponta a Ponta: do Problema ao Lançamento ao Aprendizado
• Armadilhas Comuns do Designer de Produto