Existe uma versão de PM que engenheiros adoram trabalhar junto. Esse PM chega com problema claro, dá contexto suficiente, está disponível quando surgem dúvidas, e confia no julgamento técnico do time. Existe uma versão oposta. E a diferença entre os dois raramente é conhecimento técnico do PM.

É sobre como o PM trata o trabalho e as pessoas.

O que o time de engenharia mais reclama dos PMs

Depois de conversar com dezenas de engenheiros sobre isso, os padrões são consistentes.

Escopo que muda no meio do desenvolvimento. Você define o que vai ser feito, o time começa a construir, e uma semana depois você adiciona "só mais um detalhe" que na prática muda a arquitetura. Isso não é um problema de comunicação. É um problema de PM que não fez o trabalho de esclarecer o escopo antes do desenvolvimento começar.

Falta de contexto sobre o porquê. "Adiciona esse campo no formulário de cadastro" sem explicar por que o campo existe, quem vai usar, e em qual situação gera decisões técnicas ruins. O time de engenharia precisa entender o problema para tomar boas decisões técnicas. Quem não dá contexto recebe soluções que resolvem literalmente o que foi pedido — mas não o problema de fundo. Isso é exatamente o que um bom PRD resolve: dar o contexto certo antes do desenvolvimento começar.

PM que some durante o desenvolvimento. Você enviou o PRD, o time começou, e agora você está em reuniões o dia todo e responde mensagens horas depois. O time trava numa decisão que precisa de contexto de produto, espera, e avança com um julgamento que pode estar errado. Quando isso acontece toda sprint, o custo se acumula.

O que separa boas parcerias de ruins

Clareza antes de velocidade

A pressão para "começar logo" é constante. Mas sprint iniciada com história mal definida custa mais do que o tempo que você "economizou" não fazendo refinamento. Uma hora de conversa que esclarece critérios de aceite antes do desenvolvimento evita dois dias de retrabalho depois.

A pergunta que você deve responder antes de qualquer história entrar no sprint: se o engenheiro terminar isso e eu não gostar do resultado, a responsabilidade é minha (critério de aceite mal definido) ou é dele (não seguiu o que foi combinado)? Se a resposta não for clara, a história não está pronta.

Separar problema de solução

PM define o problema. Engenharia define como resolve. Quando PM especifica a solução técnica sem entender as implicações, cria atrito desnecessário e frequentemente resulta num produto pior do que se o time técnico tivesse espaço para propor a abordagem.

Isso não significa que PM não pode ter opiniões sobre UX ou fluxo. Significa que "quero que o usuário consiga fazer X sem precisar sair da tela" é uma restrição de produto legítima; "implementa usando modal com fetch assíncrono" é micro-gerenciamento técnico.

Estar presente de forma útil

Presente não significa em todas as reuniões. Significa disponível quando o time precisa de decisão. PM que responde dúvidas de produto em minutos, não em horas, é PM que o time de engenharia confia para começar trabalho sem medo de precisar refazer.

Estabeleça um canal claro de comunicação. "Para dúvidas de produto durante o desenvolvimento, me manda mensagem direto que respondo em até uma hora" é uma promessa simples que muda como o time te vê.

Decisões técnicas com implicação de produto

Às vezes engenharia precisa tomar uma decisão que tem consequências de produto: "podemos implementar isso em dois dias com essa limitação, ou em duas semanas sem a limitação — qual prefere?" PM precisa entender o suficiente sobre a limitação para tomar essa decisão com critério real.

Você não precisa saber programar para isso. Precisa perguntar: "se eu escolher a versão rápida com a limitação, quais casos de uso ficam comprometidos?" Essa pergunta conecta a decisão técnica ao problema de produto — e é a única forma de responder com critério.

Quando discordar de uma decisão técnica

Se você acredita que uma decisão técnica está criando um problema de produto futuro, diga. Mas diga como problema de produto: "preocupa que essa abordagem vai tornar difícil adicionar suporte a múltiplas moedas daqui a seis meses, e isso está no roadmap". Deixe o time técnico avaliar se sua preocupação faz sentido tecnicamente.

Engenheiros bons ouvem quando o problema está bem articulado. O que eles não ouvem — com razão — é PM dizendo o que é certo tecnicamente sem ter base para isso.

Construir confiança demora, mas vale

A reputação de PM é construída sprint a sprint. Times que trabalham com PM que respeita o trabalho deles, dá contexto real e mantém escopo estável produzem mais e melhor do que times que trabalham no modo defesa constante contra mudanças de última hora. Um roadmap bem comunicado também ajuda a reduzir esse atrito: quando o time tem visibilidade do horizonte, as mudanças de última hora diminuem naturalmente.

Pergunte para um engenheiro do seu time o que tornaria o trabalho com você mais fácil. As respostas vão ser específicas e, na maioria das vezes, imediatamente aplicáveis. É a pesquisa de usuário que a maioria dos PMs nunca faz.

Da mesma forma que a relação com engenharia define muito da qualidade do produto, a parceria com design é igualmente central. Para entender como construir essa colaboração — quando influenciar, quando recuar e como dar feedback útil — veja o artigo sobre como PM e designer trabalham bem juntos.

Na comunidade mágica, temos engenheiros e PMs discutindo esses pontos juntos. A perspectiva do outro lado é sempre reveladora.