PM não tem autoridade formal sobre o time. Não contrata, não demite, não dá aumento. O que o PM tem é influência — e feedback é uma das ferramentas mais poderosas para exercê-la de forma construtiva. Um PM que sabe dar e pedir feedback constrói time mais forte e toma decisões melhores.

Por que feedback em produto é diferente

O feedback típico de carreira — dado pelo gestor no ciclo de performance — é sobre comportamentos e competências. Feedback em produto é sobre decisões, processo e qualidade de trabalho. São camadas diferentes, e confundir as duas cria problemas.

Quando um PM diz para o designer "você não está colaborando com o time", está dando feedback de comportamento sem autoridade formal para isso. Quando diz "esse fluxo de onboarding tem três etapas que não sei se o usuário vai entender — posso te mostrar o que me preocupa?", está dando feedback de produto de forma que abre diálogo sem criar defesa.

Como dar feedback para design

O erro mais comum de PM ao dar feedback para design é falar de solução em vez de problema. "Esse botão deveria ser mais azul" é feedback de solução. "Não tenho certeza se o usuário vai entender que esse é o próximo passo — podemos testar com alguém?" é feedback de problema que convida o designer a resolver.

PM tem perspectiva de negócio, de usuário e de dados. Designer tem perspectiva de experiência, de consistência visual e de comportamento de interface. O feedback mais útil que PM pode dar para design é trazer a perspectiva que o designer não tem — não substituir a perspectiva do designer com a sua. Para entender como essa parceria funciona na prática, veja o artigo sobre como PM e designer trabalham bem juntos.

Como dar feedback para engenharia

Engenheiros e engenheiras respondem bem a feedback baseado em critérios claros. "Isso não está certo" sem critério cria atrito. "Esse comportamento diverge do critério de aceite que definimos — aqui está o que esperávamos e aqui está o que está acontecendo" é feedback acionável.

Feedback para engenharia também inclui reconhecer quando uma decisão técnica foi boa — quando o time escolheu uma abordagem que facilitou a manutenção, evitou um problema que teria aparecido depois, ou entregou com qualidade acima do esperado. PM que só dá feedback negativo constrói um ambiente onde a equipe faz o mínimo para evitar crítica, não o máximo para gerar impacto.

Como pedir feedback sobre suas próprias decisões

PM que não pede feedback opera em bolha. As decisões de priorização, as hipóteses de discovery, as escolhas de escopo — todas elas têm pontos cegos que outras pessoas no time podem enxergar.

Pedir feedback de forma eficaz é diferente de pedir validação. "O que vocês acham?" convida concordância. "O que estou deixando de considerar nessa priorização?" convida crítica construtiva. "Qual é o risco que vocês enxergam que eu não estou vendo?" convida perspectiva diferente da sua.

O ritual de revisão de decisão

Uma prática útil é criar um momento regular — quinzenal ou mensal — onde o PM apresenta uma decisão recente e pede explicitamente para o time e stakeholders identificarem o que poderia estar errado. Não é para mudar a decisão (que já foi tomada), mas para aprender e ajustar o processo para a próxima.

Como receber feedback difícil

Receber feedback sobre uma decisão que você tomou com convicção é desconfortável. O impulso é defender. A resposta mais útil é perguntar. "Me conta mais sobre o que você está observando que me deu essa impressão" mantém o diálogo aberto e frequentemente revela informação que você não tinha quando tomou a decisão.

Feedback difícil não precisa ser implementado imediatamente — precisa ser considerado seriamente. A diferença entre PM que aprende rápido e PM que fica estagnado frequentemente é essa: um usa o feedback para questionar seus próprios modelos mentais, o outro usa para confirmar o que já acredita.