Como trabalhar com devs sem entrar em conflito

Nível: Iniciante | Duração estimada de leitura: 18 minutos | Categoria: Trilha Iniciante — Módulo 6

Introdução

De todos os relacionamentos que o Product Owner precisa construir e manter, o mais determinante para o sucesso do produto não é com o CEO, não é com os stakeholders, não é com os clientes.

É com o time de desenvolvimento.

Essa afirmação surpreende muita gente. Mas pense: o CEO define a direção. Os stakeholders expressam as necessidades. Os clientes validam o resultado. O time de desenvolvimento é quem transforma tudo isso em realidade. Sem o time, não existe produto.

E aqui está o paradoxo central do papel: o PO depende completamente do time para entregar — mas não tem nenhuma autoridade hierárquica sobre ele. Você não contrata, não demite, não promove. Você lidera pela influência, pela credibilidade e pela qualidade das decisões que toma.

Isso significa que cada conflito mal resolvido, cada decisão imposta sem explicação, cada vez que você muda o escopo no meio da sprint sem conversa — tudo isso vai erodindo a confiança que é o único ativo real que você tem com o time.

Este módulo é sobre como construir e proteger essa confiança. Como comunicar decisões difíceis. Como resolver conflitos — com o time, com stakeholders e no espaço entre os dois. E como ser o tipo de líder que o time quer seguir, não o que o time apenas tolera.

Por que os conflitos acontecem

Antes de falar em resolução, é preciso entender as raízes. A maioria dos conflitos entre PO e time de desenvolvimento não nasce de má vontade — nasce de perspectivas legítimas e diferentes sobre o mesmo problema.

O dev pensa em sustentabilidade técnica. O PO pensa em valor de negócio.

Para o desenvolvedor, uma decisão que ignora a qualidade do código hoje vai criar dívida técnica que vai tornar o trabalho mais lento amanhã. Para o PO, a pressão por entrega é real e o mercado não espera. Nenhuma das duas perspectivas está errada — e o conflito surge quando nenhuma das duas é ouvida de verdade.

O dev pensa em viabilidade. O PO pensa em desejo do usuário.

"Não dá para fazer" e "mas o usuário precisa disso" são frases que colidem toda semana em times de produto. A tensão é legítima. O problema é quando a conversa para aí, sem que os dois lados busquem entender a perspectiva do outro.

O dev pensa no que está no card. O PO pensa no que imaginou.

Se o critério de aceitação não estava claro, o dev vai implementar o que entendeu. Se o PO esperava outra coisa, o conflito no momento da entrega é certo — mas a origem foi no momento da escrita da história, não na implementação.

O dev reage a mudanças de última hora. O PO reage a pressões externas.

O stakeholder muda a prioridade. O CEO pede uma feature nova. O cliente reclama de algo urgente. O PO absorve essas pressões e às vezes as repassa ao time sem filtro, sem contexto, sem negociação. O time sente a instabilidade e perde confiança no processo.

Entender essas raízes é o primeiro passo para não tratar os sintomas enquanto a causa continua produzindo conflito.

Liderança sem autoridade: o que isso significa na prática

Liderança sem autoridade é a habilidade de influenciar pessoas e resultados sem usar poder hierárquico. É o modelo central de atuação do PO — e é muito mais difícil do que parece.

Quando você tem autoridade formal, você pode dar uma ordem e esperar que ela seja cumprida. Quando você não tem, precisa que as pessoas queiram seguir sua direção. Isso exige algo muito mais valioso e mais frágil: credibilidade.

Credibilidade com o time técnico se constrói em quatro pilares:

Competência visível — O time precisa perceber que você entende o suficiente do negócio, do usuário e do produto para tomar boas decisões. Você não precisa saber programar. Mas precisa entender o impacto técnico das suas decisões de produto. Quando você prioriza algo, o time precisa acreditar que você pensou nas consequências.

Consistência — O que você diz é o que você faz. Se você combinou que o escopo da sprint não muda depois do planning, você não muda. Se você prometeu trazer uma resposta até amanhã, você traz. Pequenas inconsistências acumulam e destroem a confiança antes que você perceba.

Transparência — Quando você não sabe, fala que não sabe. Quando a decisão foi difícil e podia ter ido de outro jeito, você explica o raciocínio. Times que entendem o "por quê" por trás das decisões aceitam muito melhor decisões com as quais não concordam totalmente.

Respeito pela expertise técnica — O time sabe coisas que você não sabe. A arquitetura do sistema, as limitações da infraestrutura, o impacto de uma mudança em cascata. Quando você demonstra genuíno respeito por esse conhecimento — não como protocolo, mas como postura real — o time retribui com respeito pelo seu conhecimento de produto e negócio.

O que os devs mais reclamam dos POs (e como não ser esse PO)

Esta é provavelmente a seção mais importante do módulo. Não é pesquisa acadêmica — é o que aparece repetidamente em conversas com desenvolvedores de times de produto.

"O PO muda de ideia toda hora."

Nada destrói a confiança do time mais rapidamente do que instabilidade de decisão. Quando a prioridade muda a cada semana sem explicação clara, o time para de acreditar no backlog — e sem acreditar no backlog, o comprometimento no planning vira protocolo vazio.

Como evitar: Mudanças de prioridade são inevitáveis. O que não é inevitável é comunicá-las sem contexto. Quando a prioridade muda, explique o porquê. "Mudei a prioridade do item X porque recebemos dados que mostram que Y está gerando mais churn" é completamente diferente de simplesmente mover um card para o topo do backlog.

"O PO some quando a gente precisa de resposta."

O time está no meio do desenvolvimento, surgiu uma dúvida sobre a regra de negócio, e o PO leva 2 dias para responder. Enquanto isso, o dev ou fica parado ou toma uma decisão que talvez não seja a que o PO queria.

Como evitar: Defina um tempo máximo de resposta para dúvidas do time durante a sprint e cumpra. Na maioria dos contextos, 2-4 horas é razoável para dúvidas que bloqueiam desenvolvimento. Se você vai estar em reunião o dia todo, avise o time e deixe um canal alternativo (Slack, Whatsapp do time) com atenção especial.

"O PO escreve histórias que não dá para entender."

Histórias sem contexto, sem critérios de aceitação, com título de uma linha e nada mais. O time entra no refinamento sem ter o que refinar — porque a história não tem informação suficiente para gerar discussão produtiva.

Como evitar: O que você aprendeu no Módulo 2 é exatamente isso. Histórias com dor, objetivo, User Story e critérios de aceitação claros chegam ao refinamento prontas para conversa, não prontas para retrabalho.

"O PO não defende o time para os stakeholders."

Quando o stakeholder pressiona por uma entrega impossível, o PO repassa a pressão ao time sem filtrar. Quando algo atrasa, o PO culpa o time publicamente. Quando o time pede tempo para pagar dívida técnica, o PO nega porque "o negócio precisa de features".

Como evitar: O PO é o escudo do time para pressões externas, não o condutor dessas pressões. Isso não significa esconder problemas reais dos stakeholders — significa negociar expectativas antes de comprometer o time com prazos impossíveis. O time que sente que o PO os protege trabalha diferente do time que sente que o PO é mais um vetor de pressão.

"O PO trata o time como recurso, não como parceiro."

"Quando vocês vão terminar isso?" em vez de "tem algum impedimento que eu posso ajudar a remover?". "Precisa entrar nessa sprint" em vez de "o que vocês acham que precisamos para isso funcionar bem?". A diferença de postura é enorme.

Como evitar: Envolva o time nas decisões que os impactam. Peça opinião técnica antes de fechar escopo. Pergunte o que pode ser simplificado sem perder o valor essencial. Um time que sente que tem voz nas decisões de produto é um time que tem ownership — e ownership gera qualidade.

Como comunicar decisões difíceis

Algumas decisões vão desagradar o time. Prioridade que muda. Feature que o time amou sendo cortada. Prazo que foi fechado sem consulta. Essas situações são inevitáveis — o que você controla é como as comunica.

O framework dos quatro elementos:

Toda comunicação de decisão difícil fica melhor quando inclui esses quatro elementos:

1. O quê — O que foi decidido, sem ambiguidade. Não enrole. "Decidimos não incluir a feature X nesta versão" é melhor do que três parágrafos que chegam nessa conclusão só no final.

2. Por quê — O raciocínio por trás da decisão. Dados, contexto de negócio, restrições, trade-offs considerados. Quanto mais o time entender o raciocínio, mais vai confiar no processo mesmo discordando do resultado.

3. O impacto — O que isso muda para o time agora. Escopo, sprint, backlog. Seja específico sobre as consequências práticas.

4. O espaço para contribuição — "Isso está decidido, mas quero ouvir preocupações que eu possa não ter considerado." Não é fraqueza — é inteligência. O time tem perspectivas que você não tem. Uma decisão revisada com input do time é quase sempre melhor do que uma decisão tomada em isolamento.

O que não fazer ao comunicar uma decisão difícil:

Não minimize a reação do time. "Eu sei que isso é difícil, mas..." seguido de uma justificativa que encerra a conversa não é empatia — é protocolo. Deixe o time expressar a discordância.

Não decida e desapareça. Tomar uma decisão impopular e não estar disponível para conversa é a receita para o ressentimento se instalar silenciosamente.

Não use a pressão externa como único argumento. "O CEO pediu" não é raciocínio — é transferência de responsabilidade. Se você concorda com a decisão, assuma. Se não concorda, diga isso também — e explique por que está seguindo mesmo assim.

Situações reais de conflito e como resolver

"Isso não dá para fazer no prazo"

Esta é a frase mais comum — e a mais mal interpretada. Quando um dev diz "não dá para fazer", raramente significa "é impossível". Quase sempre significa: "não dá para fazer do jeito que você está pedindo, no prazo que você está colocando, com a qualidade que o produto precisa".

O que não fazer: Pressionar. "Mas precisa entrar nessa sprint" sem contexto adicional não ajuda ninguém — só cria um acordo de boca que vai resultar em entrega de baixa qualidade ou não entrega.

O que fazer: Pergunte o que tornaria possível. "O que precisaria mudar para isso caber na sprint?" A resposta geralmente revela um de três caminhos: reduzir o escopo da história (MVP antes do ideal), mover para a próxima sprint, ou trazer mais clareza sobre algum ponto que está gerando incerteza técnica.

Às vezes o caminho certo é mover para a próxima sprint. Isso não é falha — é gestão honesta de capacidade.

"O dev entregou algo diferente do que eu queria"

Antes de concluir que o dev errou, releia o critério de aceitação que você escreveu. Na maioria das vezes, o dev implementou exatamente o que estava escrito — o problema é que o que estava escrito não capturou o que você tinha em mente.

O que não fazer: Rejeitar na review sem conversa. "Isso não é o que eu pedi" dito publicamente na sprint review é humilhante e cria hostilidade.

O que fazer: Converse antes da review. Se durante a sprint você perceber que algo está sendo desenvolvido diferente do esperado, entre em contato o quanto antes — não espere a review. Quanto mais cedo o ajuste é feito, menor o custo para todo mundo.

Se chegou à review diferente do esperado, reconheça a ambiguidade da história, refine o critério e coloque o ajuste como nova história ou subtarefa — não como "correção de erro do dev".

"O dev questiona a prioridade de tudo que você coloca no topo"

Existe uma diferença importante entre o dev que questiona a prioridade porque quer entender e o dev que questiona porque discorda estrategicamente. O primeiro é saudável — é exatamente o tipo de conversa que o refinamento deve provocar. O segundo precisa de atenção.

Para o primeiro caso: Explique o raciocínio. Se o time entende por que X está no topo, as perguntas diminuem naturalmente — porque o contexto está claro.

Para o segundo caso: Ouça com atenção. O dev pode estar vendo algo que você não vê — uma dependência técnica, uma limitação de sistema, um impacto não óbvio. Se depois de ouvir e considerar você mantém a prioridade, explique por quê e siga em frente. Se o dev continua questionando após a explicação, é momento de conversa franca sobre papéis: a decisão de prioridade é do PO, e o comprometimento de seguir essa prioridade é do time.

"Conflito entre dois membros do time"

Conflitos interpessoais dentro do time não são problema do PO para resolver diretamente — isso é papel do Scrum Master e, em última instância, da liderança de pessoas. Mas o PO é impactado quando conflitos no time afetam a entrega.

O que fazer: Observe sem interferir inicialmente. Se o conflito começa a afetar cerimônias, entrega ou clima, converse com o Scrum Master. Se não há Scrum Master, converse separadamente com as partes envolvidas — nunca tente mediar conflito pessoal em grupo.

"O stakeholder pressiona por uma entrega que o time disse que não é possível"

Este é o conflito mais delicado — porque você está no meio.

O que não fazer: Voltar para o time e dizer "o stakeholder quer assim". Isso posiciona você como mensageiro da pressão, não como liderança de produto.

O que fazer: Seja o filtro. Antes de levar a demanda ao time, negocie com o stakeholder: qual é a parte essencial dessa entrega? O que pode ser simplificado? Qual é a consequência real de não ter isso agora? Muitas vezes, quando você aprofunda a conversa com o stakeholder, o "preciso disso na próxima semana" vira "o essencial é a parte X — o resto pode esperar".

Quando você leva ao time uma demanda já filtrada e contextualizada, a conversa é completamente diferente.

A postura do PO em situações de pressão

Pressão é constante na vida do PO. A forma como você se comporta sob pressão define a cultura do time.

Não transfira o estresse.

Quando o CEO pressiona, você fica estressado. Quando você fica estressado, é tentador repassar esse estresse ao time como urgência artificial. Resista. O time que trabalha cronicamente sob pressão artificial aprende a ignorar urgência — inclusive quando ela é real.

Seja honesto sobre restrições.

"Existe uma pressão de negócio para que isso entre nesta sprint. Quero ser transparente sobre isso e discutir juntos o que é viável" é muito mais respeitoso do que fabricar urgências falsas. O time que confia no PO trabalha diferente do time que aprende a suspeitar de tudo.

Assuma decisões com as quais você não concorda 100%.

Em algum momento, você vai precisar comunicar uma decisão que foi tomada acima de você e com a qual não concorda totalmente. Isso faz parte do papel. O que não faz parte é jogar a decisão no time como se fosse deles o problema. Se a decisão veio da liderança, seja transparente: "Esta foi uma decisão da diretoria. Eu trouxe as preocupações do time, o contexto foi ouvido, e seguimos com essa direção. Aqui está o raciocínio."

Saiba quando dizer "não sei".

POs que fingem ter certeza de tudo perdem credibilidade. O time respeita muito mais quem diz "não sei, mas vou descobrir e te dou uma resposta hoje" do que quem inventa uma resposta segura na hora.

Como construir uma relação de confiança de longo prazo

Confiança não se constrói em uma conversa difícil bem resolvida. Ela se constrói no acúmulo de pequenas atitudes consistentes ao longo do tempo.

Esteja presente.

PO que aparece só nas cerimônias e some o resto da sprint não constrói relação com o time. Esteja disponível. Participe dos momentos informais. Conheça as pessoas, não só os papéis.

Demonstre curiosidade técnica genuína.

Você não precisa saber programar, mas se importar em entender como o sistema funciona — mesmo superficialmente — demonstra respeito pela expertise do time. "Me explica como isso funciona por baixo" dita com curiosidade real abre conversas que revelam oportunidades e riscos que você nunca veria de fora.

Comemore as entregas.

Quando o time entrega algo importante, reconheça. Não de forma performática — de forma genuína e específica. "A forma como vocês resolveram o problema de performance foi impressionante" é diferente de "bom trabalho, time".

Admita quando você errou.

Uma história mal escrita que gerou retrabalho. Uma prioridade que você mudou sem consulta e que impactou a sprint. Uma promessa que não cumpriu. Reconhecer erros sem se defender em excesso constrói mais confiança do que qualquer acerto.

Proteja o time das guerras que não são deles.

Quando stakeholders entram em conflito por prioridade, quando a diretoria pressiona por datas impossíveis, quando clientes querem mudanças de última hora — resolva isso antes de chegar no time. O time que sente que o PO absorve e filtra as pressões externas desenvolve um nível de confiança e comprometimento que nenhum processo ágil consegue criar artificialmente.

Os sinais de que a relação com o time está se deteriorando

Existem sinais sutis que aparecem antes do conflito aberto. Reconhecê-los cedo permite corrigir o curso antes que o dano seja maior.

• O time para de fazer perguntas no refinamento — não porque está tudo claro, mas porque desistiram de tentar entender
• O planning termina rápido demais, com comprometimentos que parecem automáticos — o time está concordando para acabar logo, não porque acredita no objetivo
• A retrospectiva fica superficial — o time não se sente seguro para falar sobre os problemas reais
• Os devs começam a tomar decisões de produto por conta própria sem consultar o PO — perderam a confiança de que a consulta vai resultar em algo útil
• O humor do time muda visivelmente durante cerimônias que envolvem o PO

Se você percebe esses sinais, não ignore. Peça feedback diretamente — individualmente, em conversa franca, não em grupo. "Como você acha que está nossa dinâmica de trabalho?" dito com intenção genuína de ouvir pode abrir conversas que mudam o rumo da relação.

O PO como líder de cultura de produto

O papel do PO vai além de gerenciar o backlog. Em times maduros, o PO é um dos principais responsáveis pela cultura de produto — o conjunto de valores, práticas e comportamentos que define como o time pensa sobre o trabalho.

Uma cultura de produto saudável tem algumas características:

Foco no problema, não na solução. O time questiona se está resolvendo o problema certo antes de debater como implementar. O PO alimenta essa cultura quando traz o contexto do usuário para o centro das discussões — não só os requisitos.

Dados como base de decisão. Hipóteses são levantadas, testadas e validadas ou descartadas. O PO alimenta essa cultura quando define métricas para cada entrega e compartilha os resultados com o time — tanto os sucessos quanto os fracassos.

Segurança psicológica para discordar. O dev que tem uma preocupação técnica importante precisa sentir que pode expressá-la sem ser ignorado ou descartado. O PO alimenta essa cultura quando demonstra consistentemente que discordâncias são bem-vindas — e quando age sobre elas com seriedade.

Aprendizado contínuo. Erros são analisados, não escondidos. Retrospectivas resultam em mudanças reais. O PO alimenta essa cultura quando é o primeiro a analisar o que poderia ter feito diferente quando algo não funciona.

Certificações e onde estudar

Comunicação e liderança:

• Conversas Difíceis — Douglas Stone, Bruce Patton e Sheila Heen (Harvard Negotiation Project): O livro de referência sobre como conduzir conversas de alto impacto sem gerar defensividade. Essencial para POs que querem melhorar a qualidade das suas conversas com time e stakeholders.
• Radical Candor — Kim Scott: Sobre como dar feedback honesto com cuidado genuíno pela pessoa. Diretamente aplicável à relação PO-time.
• A Cinco Disfunções de uma Equipe — Patrick Lencioni: Uma leitura rápida em formato de fábula que explica por que times falham — ausência de confiança, medo de conflito, falta de comprometimento, fuga de responsabilidade e desatenção aos resultados. Cada disfunção aparece na relação PO-time de formas muito reconhecíveis.

Liderança de produto:

• Inspired — Marty Cagan: A referência em gestão de produto moderna. O capítulo sobre a relação entre PO e time de desenvolvimento é obrigatório.
• Continuous Discovery Habits — Teresa Torres: Sobre como criar o hábito de discovery contínuo — e como envolver o time técnico nesse processo de forma que cria ownership compartilhado.

Certificações com componente de liderança:

• PSPO II (Scrum.org): O segundo nível do Professional Scrum Product Owner aprofunda exatamente os temas de liderança, influência e trabalho com stakeholders que este módulo cobre. Recomendado após 1-2 anos de experiência como PO.
• ICP-APO (ICAgile Certified Professional — Agile Product Ownership): Certificação com foco em comportamentos e mentalidade ágil aplicada ao papel do PO. Tem um componente forte de soft skills e trabalho em time.

Conclusão da Trilha Iniciante

Chegamos ao fim da primeira trilha.

Você passou por seis módulos que cobriram o que nenhum curso de certificação cobre de verdade: o trabalho do PO como ele é, não como o framework descreve.

Você aprendeu o que significa ser PO de verdade — além da definição do Scrum Guide. Aprendeu a escrever User Stories que chegam ao desenvolvimento com clareza e saem sem retrabalho. Entendeu como estruturar e manter um backlog que reflete estratégia, não acúmulo de demandas. Conheceu os frameworks Scrum e Kanban — e, mais importante, onde cada um faz sentido. Colocou as mãos nas ferramentas que o mercado usa. E agora, neste último módulo, entendeu que tudo isso só funciona se a relação com o time funcionar.

O PO que entrega produto com consistência não é o mais técnico, nem o mais certificado, nem o que conhece mais frameworks. É o que as pessoas do time acordam de manhã querendo trabalhar com — porque confiam no julgamento dele, porque sentem que suas vozes importam, porque sabem que ele vai protegê-las das pressões que não são delas resolver.

Essa confiança não vem do cargo. Vem do acúmulo de atitudes pequenas, consistentes e honestas ao longo do tempo.

Bem-vindo ao próximo nível. A trilha Júnior começa aqui.