O relacionamento PM-designer é uma das parcerias mais importantes em uma equipe de produto e uma das mais frágeis. Quando funciona, você obtém produtos estrategicamente sólidos e genuinamente bem elaborados. Quando ele quebra, você obtém produtos bonitos de que ninguém precisa ou produtos úteis que ninguém deseja usar.
O colapso costuma ser silencioso. Os designers começam a se sentir como recebedores de pedidos – entregando soluções para embelezar em vez de problemas para resolver. PMs comece a sentir que os designers são preciosos em seus processos - bloqueando o progresso com exploração interminável quando a janela do mercado está se fechando. O ressentimento aumenta em ambos os lados, e nenhum deles diz nada até que transborde em uma revisão do sprint.
Uma retrospectiva regular do design do produto dá a esse relacionamento um espaço dedicado para conversas honestas. Não inserido em um sprint retrô onde todos são educados. Não enterrado em um 1:1 onde se trata de indivíduos. Uma sessão estruturada onde ambas as funções examinam como trabalham juntas e se comprometem com mudanças específicas.
As três tensões que definem esta relação
Pesquisa e descoberta
Os designers normalmente desejam mais pesquisas antes de se comprometerem com soluções. PMs normalmente deseja se mover mais rápido com base nos sinais existentes. Ambos os instintos têm valor.
O atrito aparece quando os designers conduzem pesquisas que PMs nunca veem, ou quando PMs tomam decisões sobre produtos sem incorporar insights de design. O resultado são trilhas paralelas: o PM faz apostas com base em dados de negócios enquanto o designer descobre comportamentos do usuário que contradizem essas apostas, e os dois nunca se conectam.
Linha do tempo e exploração
O design precisa de tempo para explorar. Um bom design raramente vem da primeira ideia – vem da geração de múltiplas abordagens e da sua avaliação. Mas PMs estão gerenciando as expectativas das partes interessadas, os compromissos do sprint e os cronogramas de lançamento que deixam pouco espaço para exploração aberta.
Essa tensão se torna destrutiva quando o PMs se compromete com datas de entrega antes do projeto ter sido explorado, ou quando os designers tratam cada recurso como uma oportunidade para uma repensação completa, independentemente do escopo.
Direitos de decisão
Quem toma a decisão final sobre a experiência do usuário? Em teoria, é colaborativo. Na prática, PMs muitas vezes substituem as decisões de design porque são “donos do produto”. Os designers se sentem ignorados em assuntos de sua especialidade. PMs sentem que não conseguem levar o produto adiante sem lutar.
A questão subjacente raramente é sobre uma escolha específica de design. É uma questão de saber se o design tem autoridade real ou apenas uma contribuição consultiva.
Executando a retrospectiva
Frequência e tempo
Execute isso a cada 6 a 8 semanas ou após concluir um recurso significativo. Não vincule isso aos limites do sprint – o relacionamento PM-design opera em uma cadência mais longa do que sprints de duas semanas.
Quem deveria estar lá
Seja pequeno: o PM e o(s) designer(es) que trabalham juntos diretamente. Se você trabalha em um modelo de trio de produtos (PM, designer, líder técnico), inclua o líder técnico - eles geralmente veem atritos entre PM e design que nenhum dos lados reconhece.
Máximo de cinco pessoas. Esta é uma sessão de trabalho, não uma apresentação.
Formato: Três Rodadas
Rodada 1: O que cada lado valoriza (15 minutos)
Comece com apreciação, mas seja específico. Cada pessoa anota uma ou duas coisas que a outra função fez neste ciclo que tornou o trabalho melhor. Leia isso em voz alta.
Este não é apenas um exercício para se sentir bem. Revela o que cada lado realmente valoriza na parceria, o que muitas vezes revela expectativas incompatíveis. Um PM pode apreciar o “retorno rápido nas maquetes”, enquanto o designer estava mais orgulhoso da “síntese da pesquisa que remodelou a direção do recurso”. Essa lacuna lhe diz algo importante sobre o que cada função pensa que é seu trabalho.
Rodada 2: Mapeamento de Fricção (30 minutos)
Cada pessoa escreve cartões sobre momentos em que a colaboração pareceu difícil. Seja específico – nomeie o projeto, a decisão, a reunião. Reclamações vagas (“a comunicação poderia ser melhor”) não são acionáveis.
Organize os cartões em torno dos estágios do fluxo de trabalho onde ocorreu o atrito:
- Descoberta -- Ambas as funções estavam envolvidas na definição do problema?
- Exploração -- O design teve tempo e espaço suficientes para gerar opções?
- Tomada de decisão -- Como as escolhas de design foram avaliadas e finalizadas?
- Transferência -- A transição do design para a engenharia foi tranquila?
- Iteração -- Como o feedback e as alterações foram tratados após a transferência?
Para cada ponto de atrito, resista ao impulso de resolver imediatamente. Primeiro, certifique-se de que ambos os lados entendam a experiência do outro no mesmo momento. Um PM que sentiu que o design estava “bloqueando o progresso” e um designer que se sentiu “apressado para uma solução incompleta” pode estar descrevendo exatamente a mesma reunião.
Rodada 3: Acordos de Trabalho (15 minutos)
Escolha os dois pontos de atrito mais impactantes e crie acordos específicos para resolvê-los. Dois é o número certo. Mais do que isso e nada muda.
Acordos que realmente funcionam
Aqui estão os padrões que melhoram consistentemente a colaboração de design PM.
Enquadramento de problemas conjuntos. Antes de qualquer trabalho de design começar, PM e o designer passam 30 minutos juntos definindo: Qual é o problema do usuário? Qual é o objetivo do negócio? Quais são as restrições? Como é o sucesso? Esta prática única elimina uma quantidade surpreendente de atrito posterior, porque ambos os lados partem do mesmo entendimento do que estão resolvendo.
Tempo de exploração estruturado. Combine uma fase de exploração padrão para recursos de tamanhos diferentes. Um pequeno recurso pode levar dois dias de exploração. Um grande pode durar uma semana. A chave é que isto seja acordado antecipadamente e não negociado sempre sob pressão. Durante a exploração, o designer gera opções. O PM não avalia soluções específicas até que as opções sejam apresentadas em conjunto.
Decisões de design com fundamentação. Quando o PM precisa substituir uma recomendação de projeto, eles explicam o motivo comercial. Quando o designer rejeita uma solicitação PM, ele explica o impacto no usuário. Nenhum dos lados pode simplesmente afirmar autoridade – o raciocínio tem de ser visível.
Loops de feedback de baixa fidelidade. PMs dê feedback sobre esboços e wireframes antes que o designer invista em um trabalho de alta fidelidade. Isto parece óbvio, mas rotineiramente não acontece. O PM está ocupado, adia a revisão até que o designer apresente modelos sofisticados e, em seguida, solicita alterações que exigem um recomeço. O feedback inicial e em estágio difícil evita isso completamente.
Exposição compartilhada do usuário. Tanto PM quanto o designer participam de sessões de pesquisa de usuários ou revisam gravações juntos. Quando ambos os lados ouvem o mesmo usuário dizer a mesma coisa, os debates sobre “o que os usuários querem” diminuem drasticamente.
Antipadrões comuns a serem observados
O PM como Diretor de Arte. Se o PM estiver fornecendo feedback detalhado sobre as opções de design visual – cores, espaçamento, estilos de ícones – algo deu errado. PMs deve avaliar se o design atinge o objetivo do produto, não direcionando a execução visual. Se você estiver fazendo isso, pergunte: estou reagindo porque isso não atende à necessidade do usuário ou porque não corresponde ao meu gosto pessoal?
O Designer como Pixel Pusher. Se o designer receber consistentemente soluções totalmente especificadas e for solicitado a "fazer com que pareça bonito", a função do design será esvaziada. Os designers devem estar envolvidos na definição do problema, não apenas na renderização da solução. Se esse padrão continuar aparecendo nas retrospectivas, é um sinal de que o processo da equipe precisa mudar, e não apenas o comportamento dos indivíduos.
Pesquisa que não leva a lugar nenhum. Os designers investem tempo na pesquisa do usuário, produzem insights e nada muda porque o roteiro já estava definido. Se a pesquisa não puder influenciar as decisões, pare de fazer pesquisas – ou mude quando a pesquisa acontece, para que ela seja alimentada no planejamento, em vez de chegar depois que os planos estiverem bloqueados.
O ciclo de revisão sem fim. Os designs passam por sete rodadas de feedback porque o PM continua mudando de ideia sobre o que deseja. Isso geralmente significa que o problema não estava bem definido no início. A solução é upstream, não downstream: um melhor enquadramento do problema reduz os ciclos de revisão.
Medindo Melhoria
Após várias retrospectivas, procure estes sinais:
- Menos alterações de projeto em estágio final porque o alinhamento acontece mais cedo
- Designers participando na definição de problemas, não apenas na criação de soluções
- PMs capaz de articular a lógica do design às partes interessadas, não apenas a lógica do negócio
- Insights de pesquisa influenciando visivelmente as decisões de produtos
- Ambos os lados dispostos a dizer “Eu estava errado sobre isso” sem parecer uma concessão
A parceria PM-design sempre envolverá tensão criativa. A retrospectiva não elimina a tensão – ela oferece uma prática regular para converter essa tensão em produtos melhores, em vez de relacionamentos piores.
Experimente NextRetro grátis -- Execute retrospectivas focadas com sua equipe de produto e design usando feedback anônimo e fases de discussão estruturadas.
Última atualização: Fevereiro de 2026
Tempo de leitura: 7 minutos
