Trabalho de Descoberta como Designer de Produto (Não Apenas Executando Specs do PM)

Você passou três dias em um fluxo. Abriu o Figma às 9h da segunda-feira e só voltou à superfície na tarde de quarta. Entrega um único arquivo ao PM. Ele dá uma olhada, diz "ficou bom, pode lançar", e segue em frente. Nada na spec mudou. Nada no roadmap se alterou. Você se sente útil, mas invisível. E seis meses depois, a avaliação de desempenho diz "executa bem" em vez de "molda o roadmap."

Já vi designers culparem o PM por isso. O PM está ocupado. O PM não entende de design. O PM tem seus favoritos. Nenhum disso é o problema real. O problema real é o artefato que você entregou. Um design significa uma decisão: lançar ou não lançar. PMs não rejeitam opções únicas. Eles as aprovam automaticamente. Chamo isso de armadilha da opção única, e quase todo designer "só de execução" está preso nela sem perceber.

A solução não é trabalhar mais. É mudar o que chega na mesa deles.

Por Que Isso Importa Mais do Que Há Dois Anos

Duas tendências colidiram nos últimos 18 meses. Primeiro, designers de descoberta (os que moldam o que será construído, não apenas a aparência) ganham significativamente mais do que designers de execução no mesmo nível. Dos estudos salariais públicos mais recentes (Pencil & Paper's 2025 Product Design Salary Report, o Dribbble Salary Database e a thread de salários de design do Read the Docs), a diferença é de aproximadamente 18-30% no nível médio e se amplia após o sênior. Um designer de produto sênior em uma empresa Série B que molda a spec fica mais próximo de US$ 190 mil de remuneração total. O mesmo título, mesma empresa, mesmo nível, só de execução? Mais próximo de US$ 150 mil. Não é uma diferença pequena.

Segundo, PMs estão lançando produtos cada vez mais sem designers. Cursor, Linear, Lovable, v0 e a onda de ferramentas de design com IA significam que um PM com bom gosto consegue lançar um fluxo competente por conta própria. Os designers que sobrevivem a essa mudança são os que contribuem antes, na camada de definição do problema, não na camada de polimento. Se o único valor que você agrega é "deixa o arquivo do Figma bonito", você está competindo com IA numa corrida para o fundo.

Isso não é catastrofismo. É uma clarificação. O trabalho está se movendo em direção à descoberta, e os designers que já operam dessa forma estão se distanciando ainda mais. A mecânica de como eles fazem isso é aprendível. É o que o restante deste Playbook aborda.

Descoberta vs. Execução: a Divisão Real de Mentalidade

O modo de execução responde a uma pergunta: "Como isso deve parecer e funcionar?" Você recebe um problema, escopo e restrições. Faz uma coisa. Devolve.

O modo de descoberta responde a uma pergunta diferente: "Esse sequer é o problema certo a resolver?" Você recebe um briefing e o pressiona antes de abrir o Figma. Conversa com clientes. Esboça alternativas que não correspondem à spec. Traz evidências para a conversa.

Os dois modos importam. O erro não é fazer trabalho de execução. Execução é a maior parte da semana de qualquer designer, mesmo no nível staff. O erro é fazer somente trabalho de execução e se surpreender quando é tratado como um service desk.

Comportamentos concretos por modo:

Designer em modo de execução:

• Abre o Figma assim que recebe uma spec
• Pergunta "como deve ficar o estado vazio?"
• Entrega um arquivo
• Rastreia fluxos lançados no portfólio
• Reporta para cima: "Lancei X, Y, Z neste trimestre"

Designer em modo de descoberta:

• Lê a spec, fecha o laptop e vai caminhar
• Pergunta "para quem estamos construindo isso e o que sabemos sobre eles?"
• Entrega três opções com trade-offs
• Rastreia mudanças de spec que seu trabalho causou
• Reporta para cima: "Mudei a abordagem que tínhamos para X. Aqui está a evidência do cliente e o resultado."

Repare nos verbos. Designers de descoberta dizem "mudei," "redirecionei," "reformulei." Designers de execução dizem "lancei," "completei," "entreguei." O primeiro conjunto soa como responsabilidade. O segundo soa como throughput.

A Regra dos 3 Caminhos

Esta é a mudança mecânica única que faz mais diferença. Toda vez que você entrega um design ao PM, entregue três opções:

1. O caminho seguro: o mais próximo do que o PM especificou. Menor risco, menor recompensa. O que ele esperava.
2. O caminho ambicioso: o que você construiria se tivesse mais duas semanas e um pouco mais de escopo. Mesmo problema, solução mais arrojada.
3. O caminho inesperado: a opção que resolve um problema diferente, ou resolve o mesmo problema de um jeito que ninguém considerou. Geralmente inspirada por uma entrevista com cliente ou um movimento de flanco de concorrente.

Cada caminho vem com três labels: custo de tempo, risco e potencial. Só isso. Sem documento de 10 páginas no Notion. Uma página com três frames do Figma e uma tabela pequena.

Por que três? Por causa de como PMs realmente decidem. Com uma opção, o veredito é binário: lançar ou matar. PMs quase sempre lançam, e esse é o ciclo de aprovação automática. Com duas opções, você criou um falso binário. O PM escolhe a mais segura e você o treinou a esperar uma escolha seguro-vs-arriscado toda vez. Com três opções, você criou uma conversa real. O PM tem que articular por que prefere uma. E uma vez que ele articula o porquê, você saiu de "executar uma spec" para "co-decidir uma estratégia."

Nunca tive um PM rejeitar um handoff de 3 caminhos. Muitos escolheram o caminho seguro. Mas a conversa é diferente. Estamos discutindo trade-offs em vez de aprovar polimento.

Um template que uso:

Problema: [uma frase sobre o que estamos tentando fazer pelo usuário]

Caminho A: Seguro (1 semana)
  O quê: [o que o PM esperava, projetado de forma limpa]
  Risco: baixo
  Potencial: lança no prazo, atinge o OKR

Caminho B: Ambicioso (2 semanas)
  O quê: [solução mais arrojada para o mesmo problema]
  Risco: médio, requer mudanças no backend
  Potencial: aborda o problema de segunda ordem que vamos enfrentar no T3 de qualquer jeito

Caminho C: Inesperado (3 semanas)
  O quê: [resolve um enquadramento completamente diferente do problema]
  Risco: alto, não está claro se os clientes querem isso
  Potencial: 10x o impacto se estiver certo; aprendizados de qualquer jeito
  Evidência do cliente: [mencione uma entrevista com cliente que apontou para isso]

Uma página. Quinze minutos para escrever depois que você fez o design thinking. Adote isso em todos os handoffs por um trimestre e veja o que acontece com a sua avaliação de desempenho.

Árvore Oportunidade-Solução, Edição do Designer

A árvore oportunidade-solução de Teresa Torres é o framework mais limpo que encontrei para me manter antes da execução. A versão original: resultado no topo, oportunidades (dores e desejos dos clientes) no meio, soluções se ramificando de cada oportunidade na base.

A adaptação para designers: seu trabalho é popular a camada do meio, não só a base. A maioria dos designers vive inteiramente na camada de solução (esboçando, prototipando, polindo coisas que resolvem oportunidades conhecidas). PMs vivem principalmente na camada de resultado (OKRs trimestrais, métricas de negócio, narrativas para executivos). A camada do meio (os problemas reais dos clientes) é o território disputado. Quem a popula bem, domina o roadmap.

Um exemplo real. Trabalhei em um fluxo de checkout para um B2B SaaS que queria aumentar as taxas de ativação.

Camada de resultado (território do PM): Aumentar a ativação em 30 dias de 38% para 50%.

Camada de oportunidade (a disputa real):

• Usuários abandonam durante a atribuição de vagas porque ainda não sabem quem convidar
• Usuários pulam o passo de integrações porque acham que é opcional
• Usuários completam o cadastro mas nunca retornam porque o produto parece vazio até que convidem colegas de time
• Usuários convidam colegas, mas esses colegas ignoram o e-mail porque os assuntos são genéricos

Um designer júnior teria recebido "redesenhe a tela de atribuição de vagas" e a teria deixado mais bonita. O movimento de descoberta foi mapear as quatro oportunidades e depois rodar uma rodada rápida de entrevistas para descobrir qual era a restrição de fato. (Era a terceira, a sensação de produto vazio, e era 4x maior que as outras três combinadas. Ninguém havia especificado para isso porque ninguém havia perguntado.)

O artefato para isso é extremamente simples. Abra o FigJam. Três linhas: resultado, oportunidades, soluções. Post-its. A regra é que nenhuma solução é vinculada a uma oportunidade que não foi validada em pelo menos uma conversa com cliente. Só essa regra separa designers de descoberta de designers de execução.

Ritmo de Entrevistas com Clientes: 3+ por Semana É o Mínimo

Designers me dizem que "não têm acesso a clientes". Isso é quase sempre falso. Geralmente é um de três problemas reais:

1. Nunca pediram ao time de CSM por indicações (a 5 minutos de mensagem no Slack)
2. Acham que precisam da permissão do PM para agendar uma conversa (não precisam)
3. Estão preocupados com parecer que estão pisando no território do PM (também um equívoco, abordado abaixo)

Três conversas com clientes por semana é o mínimo. Não o teto. A pesquisa de designers de 2025 da Pencil & Paper mostrou a mediana para designers sênior e acima em cinco entrevistas por semana durante a descoberta ativa. Três é o mínimo para se chamar designer de descoberta.

Como chegar lá de verdade:

• Mande uma mensagem para os CSMs uma vez. "Ei, estou tentando falar com 3 clientes por semana sobre [área do problema]. Você pode me fazer algumas apresentações?" Essa única mensagem produz entrevistas pelas próximas 6-8 semanas. CSMs adoram porque os clientes se sentem ouvidos.
• Carona em ligações existentes. Se vendas faz ligações de descoberta ou CS faz QBRs, peça para acompanhar silenciosamente duas por semana. Metade de uma entrevista é melhor que zero.
• Mande mensagem direta para 5 clientes pelo chat do app. "Sou designer trabalhando em X. Tem 15 minutos esta semana para me contar o que está quebrando?" A taxa de resposta chega a 30-50% se o produto tem algum tipo de relacionamento com o usuário.
• Aproveite pesquisas pós-cancelamento. Quando churn acontece, o formulário de cancelamento é uma mina de ouro. Leia todos semanalmente. Puxe as 5 reclamações mais articuladas para a sua árvore.

Um banco de perguntas de amostra, o que eu mantenho em uma página do Notion e uso em toda entrevista:

1. Me leve pelo que aconteceu da última vez que você tentou fazer [tarefa]. O que aconteceu?
2. Onde você travou?
3. O que você tentava antes deste produto? Por que não funcionou?
4. Se eu deletasse esta funcionalidade amanhã, o que você faria?
5. O que precisaria ser verdade para você usar isso todo dia?
6. Quem mais no seu time usa isso? O que eles fazem diferente?
7. Qual é a pior parte da sua semana relacionada a [área do problema]?
8. Me conte sobre uma vez que este produto te surpreendeu (para bem ou para mal).
9. Se você tivesse uma varinha mágica, o que mudaria?
10. Tem algo que eu deveria ter perguntado, mas não perguntei?

Repare o que está faltando: perguntas sobre o seu design. Você não está perguntando "você gostou da cor deste botão". Está perguntando sobre o mundo deles. As perguntas sobre design vêm depois, na validação do protótipo.

Validação com Protótipo: Protótipo na Terça, Insights na Quinta

Uma vez que você tem oportunidades mapeadas e alguns esboços de solução, lance um protótipo antes que a spec seja finalizada. Sigo um ritmo que chamo de protótipo na terça, insights na quinta.

Segunda-terça: Construa um protótipo no Figma dos 1-2 caminhos mais promissores. Não precisa ser pixel-perfeito. Funcional o suficiente para clicar. No máximo 4-8 horas de trabalho.

Quarta: Envie para 5 clientes via Maze, UserTesting, ou simplesmente Loom + uma DM no Slack que diz "clique neste por 5 minutos e me diga o que você esperaria que acontecesse." Cinco usuários são suficientes para surfar o padrão de 80%; o estudo clássico de Nielsen foi validado quando o Maze o revalidou em 2024.

Quinta: Sintetize. Três slides: o que funcionou, o que quebrou, o que nos surpreendeu. Coloque no canal do PM.

Sexta: Atualize o documento de 3 caminhos com os dados do protótipo. Agora seu handoff não é "aqui estão três opções". É "aqui estão três opções, e a opção B foi testada com cinco clientes. Três completaram a tarefa, dois travaram no mesmo passo. Aqui está a gravação."

Isso muda a conversa. PMs discutem com opiniões. Não discutem com cinco gravações de clientes travando. Os dados do protótipo mudam você de "o designer acha" para "os clientes disseram", e essa é uma autoridade diferente.

Stack de ferramentas acessível para isso:

• Maze: melhor para testes quantitativos de protótipo não moderados. Aproximadamente US$ 99/mês.
• UserTesting: melhor para qualitativo moderado. Mais caro, mas vale para fluxos de alto risco.
• Loom + DM no Slack para 5 clientes: gratuito, surpreendentemente eficaz, só exige que você de fato aperte enviar.

O ponto não é a ferramenta. O ponto é que você testou antes que a spec fosse finalizada. Isso é descoberta. Qualquer coisa depois que a spec está travada é polimento de execução.

"Mas Você Não É o PM": o Equívoco que Mantém Designers Pequenos

Toda vez que oriento designers sobre isso, alguém traz o mesmo medo: "Meu PM não vai achar que estou exorbitando?"

O trabalho de descoberta não faz de você um PM. Faz de você um designer melhor. A distinção é real e vale manter. PMs têm a decisão sobre o que será construído. Designers têm o input que molda a decisão. Trazer evidência de cliente, três opções e dados de protótipo não é tomar o trabalho do PM. É fazer o seu com competência.

Scripts que funcionam, na minha experiência:

• Enquadramento adversarial a evitar: "Não acho que deveríamos construir o que você especificou." (Você tornou pessoal, você contra eles.)

• Enquadramento de descoberta que funciona: "Esboçei três caminhos para a gente escolher junto. O Caminho C veio de uma conversa com dois clientes que descreveram um problema diferente do briefing. Vale uma olhada?"

• Adversarial: "A spec está errada."

• Descoberta: "Testei a spec com cinco usuários na terça. Três travaram no passo dois. Aqui está a gravação. O que você acha?"

• Adversarial: "Eu deveria estar nas reuniões de roadmap."

• Descoberta: "Adoraria trazer os achados das entrevistas com clientes para o planejamento do roadmap. Quer que eu prepare um resumo de 5 minutos para a próxima sessão?"

O padrão: transforme opiniões em artefatos, transforme confronto em convites. PMs não querem brigar com designers. Querem menos coisas para descobrir sozinhos. Apareça com opções, evidências e uma postura de "vamos decidir juntos", e você será o colaborador mais fácil que eles têm. Apareça com "discordo", e você será o mais difícil. Mesmo conteúdo, enquadramento diferente, reputação completamente diferente.

Rastreie Suas Conquistas de Descoberta, ou Elas Não Existem

Aqui está a dura realidade sobre avaliações de desempenho na maioria das empresas de produto: influência que não está documentada não aconteceu. Você vai conhecer designers sênior que silenciosamente reformularam três roadmaps em um trimestre, e depois viram um colega que lançou dois produtos chamativos ser promovido antes deles. O colega contou uma história. O designer sênior não contou.

Mantenha um log de descoberta. Uma linha por conquista. Cinco colunas:

Três colunas são descritivas. Duas são evidência. A coluna "reconhecimento do PM" importa: é uma captura de tela do Slack, um comentário no Loom, uma edição no documento de roadmap. Algo com data e rastreável. Quando a avaliação de desempenho chegar, você não está implorando "acho que agreguei valor". Está mostrando os recibos.

Esse log leva 5 minutos por semana para manter. A maioria dos designers nunca começa um. Os que começam entram nas avaliações de desempenho com uma conversa diferente dos colegas.

A Mudança Mecânica

O que quero que você leve daqui. A mudança de execução para descoberta não é uma mudança de personalidade. Não é sobre ser "mais estratégico", seja lá o que isso signifique. É mecânica. Você muda cinco artefatos:

1. Entregue 3 caminhos, não 1 design
2. Mantenha uma árvore oportunidade-solução que você populou com entrevistas
3. Faça 3+ entrevistas com clientes por semana, toda semana
4. Rode o ciclo de protótipo na terça, insights na quinta em todo fluxo relevante
5. Mantenha um log de conquistas de descoberta e leve para a avaliação de desempenho

Cinco artefatos. Nenhum deles exige mudança de cargo, permissão do gestor, ou um novo emprego. Você pode começar todos na segunda-feira. O relacionamento com o PM muda como efeito colateral, não porque você conversou com o PM sobre isso, mas porque o que você coloca na mesa dele mudou.

Esse é o jogo inteiro.

Saiba Mais

• JD Complementar: Designer de Produto
• Um Dia na Vida de um Designer de Produto
• Seus Primeiros 30/60/90 Dias como Novo Designer de Produto
• Responsabilidade Ponta a Ponta: do Problema ao Lançamento ao Aprendizado
• Crítica de Design que Melhora o Trabalho
• Do Designer de Produto ao Designer Staff