Algumas das tensões mais comuns em times de produto acontecem entre PM e designer. O PM acha que o designer está iterando demais numa solução simples. O designer acha que o PM está impondo soluções sem entender o problema de experiência. Os dois têm razão — e nenhum está resolvendo o problema real.

O que PM e designer são responsáveis por (separado)

PM é responsável por definir o problema: qual usuário, qual dor, qual métrica de sucesso, quais restrições de negócio e de tempo. Designer é responsável por definir a solução de experiência: como o produto vai comunicar, guiar e responder ao usuário de forma que resolva aquele problema.

Quando o PM entra na solução de experiência sem base, gera atrito. Quando o designer define o problema sem dados ou contexto de negócio, cria soluções bonitas que não movem nada. Os dois papéis se complementam melhor quando cada um respeita a expertise do outro.

Onde os papéis se sobrepõem

A zona de sobreposição — onde PM e designer precisam trabalhar juntos — é o espaço entre o problema e a solução: entendimento do usuário, definição de critérios de sucesso da experiência, priorização de fluxos a serem trabalhados. Aqui, as melhores decisões vêm da colaboração, não da hierarquia.

Quando o PM deve influenciar o design

Quando a solução proposta não resolve o problema definido. Quando há uma restrição de tempo ou de engenharia que precisa ser considerada na solução. Quando o feedback de usuário indica algo que o design atual não está endereçando. Quando há uma inconsistência entre o que foi acordado no brief e o que está sendo entregue.

Em todos esses casos, a forma de influenciar importa tanto quanto o conteúdo. "Isso não funciona" é feedback que fecha. "Qual é o comportamento que você está tentando criar nesse fluxo?" é uma pergunta que abre. Para entender como dar feedback que funciona, o princípio é o mesmo de qualquer relação com stakeholder: comece pelo problema antes de propor a solução.

Quando o PM deve confiar e recuar

Quando a discussão é sobre escolha visual que não tem impacto direto no comportamento do usuário. Quando o designer tem dados de usabilidade ou de pesquisa que você não tem. Quando o desacordo é sobre preferência estética — que raramente é o terreno certo para PM.

PM com boa relação com designers aprendeu a distinguir entre "eu não gosto desse design" e "esse design não resolve o problema que definimos". A primeira objeção raramente deve ser verbalizada. A segunda é legítima e precisa de conversa.

Como dar feedback de design útil

Feedback útil de design é sempre ancorado no problema. Não em preferência. Não em comparação com outro produto. Na pergunta: esse design resolve o problema que definimos para o usuário que identificamos?

A estrutura que funciona

"Minha preocupação é que o usuário pode não entender [X] nessa interface porque [razão baseada em dados ou comportamento]. Faz sentido explorar uma versão que [sugestão de direção, não de solução]?" Isso é diferente de "eu mudaria esse botão de lugar".

A diferença entre feedback de direção e feedback de solução é fundamental. PM que dá feedback de direção mantém o designer como dono da solução — o que produz melhores resultados e mantém a relação saudável. PM que dá feedback de solução assume o papel de designer — o que desgasta e frequentemente produz soluções piores.

O brief de produto como ferramenta de alinhamento

Antes de qualquer projeto de design começar, o PM precisa passar contexto suficiente para o designer tomar boas decisões. Esse contexto é o brief: qual é o problema que estamos resolvendo, para qual usuário, com quais restrições de tempo e de engenharia, e qual é a métrica que vamos usar para saber se funcionou.

Um brief bem escrito não diz ao designer o que fazer — diz por que algo precisa ser feito. A diferença parece sutil mas muda tudo. Brief que especifica a solução tira o designer do papel criativo. Brief que especifica o problema dá ao designer o espaço para propor a solução certa. Os mesmos princípios valem para as user stories que PM e designer refinam juntos — o contexto do problema precisa estar explícito para que o time possa tomar boas decisões durante o desenvolvimento. Para saber como estruturar esses documentos de forma que o time realmente leia, veja o guia sobre como escrever um PRD.

Discovery compartilhado como base da parceria

As melhores parcerias entre PM e designer acontecem quando os dois fazem entrevistas com usuários juntos, analisam os dados juntos e definem o problema juntos. Quando os dois chegam à fase de solução com o mesmo entendimento do problema, os conflitos diminuem drasticamente.

Quando o PM faz o research sozinho e passa um brief para o designer, perde a riqueza da perspectiva de experiência no momento em que ela mais importa — na definição do problema. E quando o designer parte direto para a solução sem ter participado do discovery, cria soluções sem o contexto que o PM tem.

O que fazer quando a parceria não está funcionando

Quando a relação entre PM e designer tem atrito constante, geralmente há um problema de acordos: o que cada um espera do outro não foi explicitado. Uma conversa direta sobre expectativas — "o que você precisa de mim para trabalhar bem?" — resolve mais do que qualquer processo ou framework.

Se o atrito vem de divergência de visão sobre o produto, essa é uma conversa mais estrutural que envolve liderança. Mas a maioria das tensões entre PM e designer vem de expectativas não alinhadas — e isso é tratável com uma conversa honesta.