O nosso cotidiano como pessoas de produto, passa inevitavelmente, em se relacionar com o time de UX e o time de engenharia. Acredito fortemente que quanto mais harmonioso é esse relacionamento, maior é a nossa capacidade de entregar resultados que superem as nossas expectativas, que tragam resultados concretos para a empresa e que gerem valor para os nossos usuários.
Acredito fortemente que como pessoas de produto, precisamos ser o elo de ligação entre esses dois universos, UX e engenharia. Afinal, aquilo que entregamos no final de uma sprint é o reflexo do trabalho de várias pessoas que juntas encontraram o melhor jeito de transformar em realidade aquilo que era uma necessidade ou mesmo uma ideia de alguém.
Quero dividir com você como nós, pessoas de produto, podemos contribuir para trazer o time de engenharia para mais perto. É um pouco da minha experiência e do meu dia-a-dia, não é uma regra, mas acredito que pode ser precioso e útil o que você vai ler agora.
Comece gerando pertencimento
Time. Essa é a palavra chave para destravar qualquer barreira de relacionamento.
Sabe a frase que diz que jogadores ganham jogos e times ganham campeonatos? É sobre isso. Não adianta se você sabe todas as técnicas, aplica todos os frameworks, leu todos os livros e fez todos os cursos, se o time de engenharia não está com você, o título do campeonato nunca vai chegar.
Desenvolvedores amam codificar, mas sabe o que eles amam ainda mais? Codificar com propósito.
Então é nesse momento que a pessoa de produto precisa aparecer.
Quem melhor do que nós podemos gerar esse propósito no time de engenharia? Quem melhor do que nós para evangelizar um grupo de pessoas a se sentirem parte viva e atuante de um processo enorme, mas que o trabalho dele faz a diferença nesse processo?
Realize encontros periódicos com o time de engenharia para alinhar objetivos e resultados. Mostre o impacto (com dados) de tudo que o time está fazendo. Traga feedback constante daquela nova feature que subiu em produção e melhorou a conversão de clientes ou aquela nova tela que diminuiu o percentual de abandono no carrinho.
Entenda com o tech lead a importância de atuar em débitos técnicos e como isso ajuda o produto na ponta final. Ouça as dores do time, se for preciso priorizar uma refatoração de código e adiar por uma sprint uma entrega de produto, por que não fazer, sabendo que vamos ter ganho no desenvolvimento de novas funcionalidades.
É preciso ter empatia para ouvir e humildade para explicar o que todos precisam saber para se sentirem ainda mais parte do time.
Compartilhe dados e gere sentimentos
Que métricas e dados são uma parte importante do nosso dia-a-dia, você já deve estar cansado de saber. Mas o grande ponto que eu quero trazer aqui é: todos os envolvidos no processo de construção do produto conhecem esses dados?
Não gosto de pensar que o time de engenharia é um grupo de pessoas com alta qualificação técnica que fica puxando cards num quadro. Como eu já disse, eles são parte do time e conhecer a estratégia por trás da ação é fundamental para que um time conquiste campeonatos.
Compartilhe as métricas de produto, explique como é medido o sucesso e o fracasso daquilo que o time está colocando em produção. Mostre que existe vida além do coluna “concluído” do card e que nossos objetivos ultrapassam a quantidade de linhas de código escritas para uma determinada funcionalidade.
Aproveite momentos como a review ou planning para gerar contexto através dos dados, durante as dailys, sempre que possível, faça updates sobre o andamento daquilo que foi colocado em produção. Se você criar uma rotina de feedbacks com todo o time de engenharia, com o tempo vai perceber um time muito mais engajado e conectado com o produto.
Entender e discutir sobre questões técnicas
Pessoas de produto precisam saber programar? Com certeza não.
Pessoas de produto precisam saber sobre tecnologia? Com certeza sim.
Explico. É parte do nosso cotidiano ouvir várias pessoas e orquestrar a materialização das necessidades que surgem de diversos locais. Além disso, setar a expectativa das pessoas é sim, algo que precisamos fazer constantemente.
Mas como podemos fazer isso sem o entendimento se temos capacidade técnica de fazer aquilo que nos é demandado?
Conhecer o produto que você trabalha, precisa superar o fit de mercado. Conhecer o produto também é entender quais são as tecnologias utilizadas, a arquitetura do sistema, integrações com sistemas de terceiros, APIs, possibilidades e limitações técnicas que ele tem.
O objetivo aqui não é dizer como o time de engenharia deve trabalhar, mas é entender como eles trabalham e ser sim, por que não, mais uma cabeça pensante na ideação de algumas soluções.
Tenho excelentes experiências onde eu e alguns membros do time de engenharia pensamos juntos na melhor lógica para resolver um problema em produção. Isso conecta, une mundos e mentes.
Além disso, conhecer a tecnologia dá a pessoa de produto independência e autonomia para muitas coisas no dia-a-dia. Você mesmo pode fazer consultas SQL para obter alguns dados importantes para tomada de decisão, consultar end points na API de homologação para validar o resultado de algum novo serviço que será disponibilizado para o cliente ou mesmo criar macros em Excel para automatizar planilhas.
Algumas boas soluções de produto podem ser puramente técnicas, aumentar o tempo de carregamento de uma página ou o tempo de resposta de uma requisição. As pessoas de produto podem colaborar com essas discussões, como eu disse, não é sobre dizer como fazer, é sobre ajudar a criar. Afinal, somos um único time.
Finalizando
Espero que eu possa ter ajudado você de alguma forma, se quiser continuar esse papo no Linkedin, será um prazer aprender e crescer com você.
É isso e até o próximo papo,
Mika