Antes de começarmos, vamos exercer um pouco a nossa imaginação.
Imagine um mundo onde desenvolvedores e gerentes de produto trabalham em perfeita harmonia, onde as ideias fluem livremente, os produtos são lançados sem contratempos e todos estão sempre sorrindo. Nesse mundo, trabalhamos em perfeita compreensão, alta produtividade e satisfação profissional.
Agora já podemos acordar desse sonho. A realidade do dia a dia é completamente diferente.
De um lado, temos os desenvolvedores, imersos em seu código, transformando café em linhas de código que dão vida às ideias, muitas vezes trabalhando em horários completamente diferentes dos nossos. Do outro lado, estão os PMs, com a visão do produto na cabeça, tentando equilibrar as necessidades dos usuários, as metas de negócios e os prazos.
Em um dia ideal, esses dois grupos estão em sintonia, mas, na realidade, às vezes parece que eles estão em mundos diferentes. Na maioria dos casos, estão de fato em CEPs diferentes.
Como tudo tem uma solução, as interações e fluxos de trabalho entre desenvolvedores e product managers também podem ser melhoradas.
Por que se importar com o alinhamento entre desenvolvedores e product managers?
Você não precisa conviver com cenas como:
Um PM chega com uma “pequena mudança” que, na verdade, requer uma reestruturação significativa do código. Os desenvolvedores suspiram, imaginando como vão encaixar isso no sprint atual e mil coisas rodando em paralelo.
Por outro lado, os desenvolvedores lançam uma nova funcionalidade que é tecnicamente impressionante, mas desvia um pouco da visão original do produto. Todos tentam entender como essa surpresa aconteceu, pois tudo foi explicado direitinho, todos os detalhes foram documentados, e todos concordaram com o escopo da iniciativa.
Mas, mesmo assim, falhamos em nos alinhar.
Essas situações são comuns, mas não precisam ser normais. A chave para transformar esses desafios em oportunidades de crescimento e inovação está no alinhamento eficaz entre desenvolvedores e PMs.
Você, enquanto líder de produto, líder de tecnologia, ou mesmo um PM ou desenvolvedor em nível operacional, precisa de estratégias práticas para garantir que todos estejam na mesma página.
Ambas as equipes precisam trabalhar juntas para criar produtos incríveis que atendam às necessidades dos usuários e superem as expectativas do mercado.
1. O básico além de ser dito, tem que ser bem feito
Antes de indicar qualquer tipo de framework, processo estrutural de comunicação ou estratégia de oratória, o básico tem que ser bem feito. O que eu quero dizer com isso?
É necessário ter a habilidade de se comunicar de maneira clara, assertiva e empática para que as conversas cruciais melhorem os relacionamentos entre as pessoas que você lidera.
E quando eu falo liderança, não estou falando de assinar o contra-cheque ou as férias de alguém, estou falando de influência, pois é exatamente esse tipo de liderança que o gerente de produto exerce diariamente.
Relacionamentos sólidos, carreiras bem-sucedidas, times e organizações fortes, todos bebem da mesma fonte: capacidade de falar abertamente sobre temas delicados e controversos.
E qualquer início de conversa sobre contexto de iniciativa é justamente isso. Sem o fortalecimento dos relacionamentos que você tem com os membros da equipe que você está alocado, nada do que você vai falar vai se conectar emocionalmente com eles, logo vai gerar desalinhamento e pouca motivação para dar certo.
Comunicação clara é a fundação de relacionamentos fortes entre equipes
Um dos pontos que mais vejo gerentes de produto se destacando nas suas carreiras é o fato de poder abordar temas que são emocionais e politicamente delicados. Vamos ao exemplos:
- Desenvolvedores falam que não entendem o porquê estão fazendo tal iniciativa;
- Desenvolvedores afirmam que a data acordada não condiz com a realidade e capacidade de entrega da equipe;
- Desenvolvedores reclamam que estão trabalhando além do horário de trabalho e não conseguem ter um equilíbrio da sua vida pessoal e profissional;
- Desenvolvedores cobram de que a iniciativa não condiz com a responsabilidade do time ou que não está conectada com a visão passada anteriormente para eles.
Se você evita esse tipo de conversa ou atua apenas tentando justificar e contrapor aquilo que foi posto como problema, é a receita para o fracasso.
Por outro lado, acredito que você já tenha pensado em uma ou duas pessoas que se destacam justamente por saber dizer a verdade preservando os relacionamentos criados. Garanto que tal pessoa é admirada pela sua competência e visão.
Normalmente, ficamos maravilhados com a sua forma de iniciar conversas que fortaleceram as relações de trabalho, não “sabonetam” e são vulneráveis e humildes em seus posicionamentos. Escutam para compreender e acolher, não para pragmaticamente oferecer um plano de ação superficial.
Esse é o básico, não fuja disso. Estamos lidando com seres humanos acima de tudo.
2. A chave é a adaptabilidade
Como falei anteriormente, estamos lidando com seres humanos. E, por natureza, todos são diferentes uns dos outros. O nível de detalhamento e apresentação de contexto muda para cada um.
Além disso, a habilidade de fácil compreensão muda de cargo, senioridade, interesses e o respectivo momento da interação.
Por exemplo, você precisa saber trazer diferentes informações para diferentes contextos. Você vai falar sobre o planejamento do ciclo (seja quarter ou semestre)? Da sprint? Do roadmap?
Desses provavelmente o mais difícil é o planejamento de ciclos. Uma vez que são os que mais possuem interações entre diferentes tipos de disciplinas. Nesses casos você precisa deixar claro o contexto de negócio, os objetivos macros, OKRs e direcionamentos estratégicos.
Tudo isso conectado com o impacto que o trabalho deles vai trazer. Ser um tradutor do aparente caos é uma habilidade essencial.
Lembre, você está navegando no mar de informações inerentes que acompanha a evolução da dinâmica do mercado, das estratégias da empresa e das complexidades do gerenciamento da liderança.
Ser apenas um menino de recados, te faz perder toda e qualquer credibilidade da sua influência e possível motivação dos membros da sua equipe. O seu trabalho é fazer com que o trabalho deles seja o mais fácil possível, fornecendo todas as informações necessárias de forma organizada.
O objetivo aqui não é protegê-los de toda e qualquer interrupção, você não é a mãe deles. Mas, sim compartilhar os problemas com a maior quantidade de informação refinada possível.
3. Organização facilita a comunicação
Um fato é: a comunicação constante gera previsibilidade, e previsibilidade gera alinhamento que por consequência gera motivação.
Nada como um roadmap atrelado às metas, uma sprint bem planejada e refinada, ou lideranças previamente compradas com as oportunidades.
E, como eu falei, assim como a comunicação varia de interlocutor e momento, também varia o seu tipo. Existem diversas maneiras de garantir aquilo que está alinhado seja de fato absorvido.
O que eu normalmente faço:
- Escreva ótimos PRDs (Product Requirement Document): escrever especificações concisas, claras e completas é uma arte por si só. Não só pelo registro, mas para garantir que o seu pensamento de produto faz sentido da perspectiva mínima de requerimentos.
- Check-ins regulares: Aqui estou falando de reuniões de refinamento com templates pré-definidos, plannings participativas e retrospectivas.
- Notas de decisões eficazes: é fácil (necessário!) registrar as decisões e os itens de ação – digamos, Slack, Jira, Notion e Asana. Manter todos os itens de ação consolidados em um único espaço (canal em comum com o time ou Jira) evita que o engenheiro tenha um esforço cognitivo de lembrar do que foi decidido e garantir a sua implementação.
4. Tangibilizando o impacto
Quando falamos da vida profissional, após méritos e promoções, provavelmente não há um maior motivador que saber que seu trabalho vale a pena ser feito.
Dentro dessa conexão entre impacto e código, está provavelmente a relação mais importante para o sucesso do produto: a do gerente de produto com seus desenvolvedores.
Essa relação começa com você! Sim, estou falando com gerentes de produto. Você precisa fazer o seu dever de casa e trazer para o time o conhecimento e habilidades que vão tornar o trabalho deles melhor.
Engenheiros são tipicamente muito inteligentes e ocasionalmente céticos por natureza. Ou seja, quando você for falar como o trabalho deles está impactando a empresa, ou porque temos que fazer o que temos que fazer, é melhor ser honesto sobre a informação do que tentar “passar o migué”.
Nunca chegue para uma equipe não convencida previamente com a oportunidade que você está colocando a mesa, pois desmotivação é igual gripe, passa de um para outro rapidamente.
Além disso, é extremamente crítico que você compartilhe abertamente o que você sabe sobre os seus usuários, especialmente suas dores, seus dados e restrições de negócio.
Torná-los missionários dos seus produtos é sua responsabilidade (pai Cagan ficaria orgulhoso). Você faz isso ao envolvê-los profundamente nas dores que eles estão resolvendo e no impacto de negócio que eles buscam.
Portanto, lembre-se, estabelecer objetivos comuns é mais do que apenas definir metas; é sobre criar uma ponte entre o desenvolvimento técnico e o impacto real que seu produto tem no mundo.
E quando essa conexão é clara, todos na equipe se sentem mais engajados e focados em fazer a diferença.
5. Entender os conceitos técnicos básicos
Você ja sentou com um bando de gringo onde todos falavam uma lingua que você não tinha a menor ideia do que estava sendo discutido? É assim que você não pode se sentir em uma sala somente com Engenheiros.
No início, está tudo bem, imaginamos que você seja um profissional júnior. Porém, no mínimo, ao longo do tempo, essa língua estrangeira que a galera está falando tem que parar de ser completamente irreconhecível.
Por exemplo, ao invés de ouvir em chinês, esse chinês se transforma em um grego, depois em um francês, italiano, espanhol e, eventualmente, um português de Portugal que você tem que prestar muita atenção, mas entende 95% do contexto.
Eu sempre recomendei profissionais juniores a começarem um pequeno projeto de código como hobbie paralelo mesmo, sem objetivo nenhum, para pelo menos abrir um VScode pela primeira vez na vida e “ver qualé”.
Pois, é de extrema importância que você demonstre grande apreciação pelas demandas e complexidades do trabalho de engenharia.
O objetivo de desenvolver uma mínima “alfabetização em programação” não é para dizer como os engenheiros fazem seu trabalho, mas para aumentar substancialmente a sua capacidade de se conectar e colaborar com eles.
Você quer dar aos engenheiros o maior lastro possível para explorar a solução dentro das restrições de negócio. Assim criando o cenário em que você é capaz de compreender melhor os trade-offs e, por sua vez, ajudá-los com uma melhor priorização.
Tudo isso também contribui para o tamanho do esforço empregado. Por exemplo:
- O quão resiliente essa aplicação tem que ser?
- É um serviço crítico, ou seja, não podemos ter uma eventual perda de dados?
- O quanto precisamos manter essas informações salvas?
- Precisamos expor uma informação, temos ela na aplicação, onde precisamos buscar, é facilmente disponível?
Eu nunca vi um engenheiro que não estivesse disposto a explicar um emaranhado técnico. Claro, existem aqueles que possuem uma maior didática, porém todos se esforçam para serem compreendidos.
6. Ser um pouco mais “venha a nós o vosso reino” do que “seja feita a vossa vontade”
Agora eu falo diretamente com os Engenheiros de software.
Toda e qualquer comunicação só é efetiva se resultar em um feedback sobre a sua compreensão. Ainda não temos capacidade de ler mentes. Mas, para saber se todos compreenderam sobre o que foi passado, é necessário que estejamos dispostos em incomodar, e está tudo bem.
É sua responsabilidade cobrar do seu gerente de produto tudo o que foi descrito até agora.
O silêncio mata qualquer tipo de relacionamento. O verdadeiro problema está no fato de não falarmos nada ao notar os desvios ou infrações sendo cometidas.
Quando todos podem e sabem falar francamente e de modo eficaz sobre qualquer questão em aberto, os riscos de fracasso do projeto caem pela metade. Ou seja, é menos frustração, bugs e códigos legados para você resolver depois.
Essa desconexão diminui seu próprio desempenho, aumenta os custos, atrasos na entrega e indisposição geral.
E aí o que fazemos? Vamos erroneamente tentar atuar em processos que deveriam aumentar a velocidade de desenvolvimento. Quando na verdade deveríamos trabalhar na comunicação do time.
“Ah, mas eu não sei o que falar nesses momentos”.
Tudo bem, eu acredito, se você for um profissional júnior. Cabe a você escutar e aprender a repetir essas perguntas ao longo do tempo, sim os problemas normalmente são os mesmos, essa é a parte fácil.
Agora, se você é um profissional sênior, mude a sua atitude agora!
Conclusão
Retomando o sonho inicial, cada produto lançado deve ser um pequeno passo na direção desse ideal, mostrando que é possível quando uma equipe de produto trabalha com empatia, assertividade e uma compreensão profunda tanto da tecnologia quanto do impacto que ela gera.
Ao abraçar essa visão e trabalhar com dedicação e clareza, nos aproximamos cada vez mais de um futuro onde cada lançamento é uma celebração daquilo que alcançamos juntos: um passo adiante em direção à realização do nosso sonho coletivo.
Você pode se aprofundar neste assunto e outros tópicos sobre liderança de produto em nossa formação de Product Leadership. Matricule-se e prepare-se para dar os próximos passos em sua carreira de product management!
