Como falar a mesma lingua dos desenvolvedores

Gerentes de produtos. A cola que liga os times. A Ponte. Reunindo muitos profissionais e departamentos da empresa, cada um com suas próprias especialidades, e criando uma uma unica equipe com um objetivo: entregar um ótimo produto ao mercado. Mas se você é gerente de produto há algum tempo, provavelmente sabe que além de todas as dificuldades logísticas na criação de um time de produto, também há uma barreira de “idioma”. Aprenda nesse artigo a falar a mesma lingua dos desenvolvedores e saber o que eles querem dizer para você!

O que quero dizer com “idiomas”? Não é que as pessoas falam idiomas diferentes, mas sim, que falam diferentes dialetos. Há lingua-do-Marketing, lingua-da-Venda, lingua-do-executivo, lingua-do-investidor, lingua-do-produto,… e, é claro, a lingua-dos-desenvolvedores – meu favorito. (Afinal, minha formação formal é em ciência da computação).

Isso pode explicar, em parte, por que tantas empresas escolhem focar no dinheiro: pelo menos a lingua dos números é universais. Quando falamos sobre projeções de receita, custos e lucros, estamos todos na mesma página. Todos na sala sempre sabem o que está sendo discutido quando a conversa se volta para GAR ou QoQ ou YoY ou MQL ou CAC ou CPM ou SQL ou TAM ou SAM ou SOM. Certo? (To brincando hahahah)

A menos que você tenha passado a última década em áreas de marketing, provavelmente não sabe o que significam todos esses acrônimos – e todos eles se relacionam de uma maneira ou de outra a um único assunto, dinheiro. Esse é o ponto desta postagem. Todo departamento de toda empresa tem suas próprias maneiras de entender, mesmo algo aparentemente universal como dinheiro.

E, a propósito, veja esse “SQL” na lista acima? Estávamos nos referindo à versão Lingua-da-Venda, que significa Sales Qualified Lead (Lead qualificado para vendas) – e não o que você provavelmente estava pensando, a Linguagem de consulta estruturada usada na lingua-do-desenvolvedor.

Portanto, se seu trabalho como PM é reunir todas essas equipes diferentes e fazê-las trabalhar em direção a um objetivo comum – mas mesmo um pequeno acrônimo de três letras como SQL significará algo completamente diferente para Vendas e Desenvolvimento.

Como você deve ter sucesso? Você precisará preencher essa lacuna de dialeto.

Desvendar os detalhes do jargão e dos idiomas falados em toda a empresa está além do escopo desta publicação. Então, vamos começar com provavelmente o dialeto mais importante que você precisará decodificar (trocadilho!) Como gerente de produto: Lingua do desenvolvedor (e o que eles querem dizer)

– “Isso não está acontecendo em nossa máquina”.

O que o desenvolvedor quer dizer:“Olha, não podemos consertar isso. Nem sabemos que problema você está vendo. Que pena – você está olhando para a tela certa? Talvez reinicie o seu computador? Vamos apresentar isso para mais tarde. Desculpa.”

Na maioria dos casos, seus desenvolvedores querem ser úteis. Eles realmente querem. Afinal, eles fazem parte da equipe e sabem que o produto que você lança no mercado reflete tanto nas habilidades deles quanto nas suas ou de qualquer outra pessoa da empresa. (Todo querem lançar e focar em um bom produto)

Mas se você receber a declaração “Não estamos vendo isso em nossa máquina” de seus desenvolvedores quando tentar descrever a eles um problema que encontrou, geralmente é um sinal de que você tem mais do que uma falha no produto – você tem uma falha na comunicação.

Não fique bravo. Não confronte seus desenvolvedores. O melhor conselho aqui é encontrar outra maneira de comunicar o problema que você está enfrentando. Idealmente, você deseja colocar todos na mesma sala, para que todos olhem para a mesma tela.

Se isso não for possível devido à geografia, faça uma captura de tela do problema (ou uma gravação em vídeo da sua experiência do usuário, se ela cobrir mais de uma única tela) e envie-a para eles.

– “Isso não é um defeito; é uma nova história. “

O que o desenvolvedor quer dizer: “Ei, você não nos disse para codificá-lo dessa maneira. Então você não pode nos dizer agora que está errado. “

Novamente, seus desenvolvedores neste caso estão identificando algo maior que o próprio defeito. Eles estão apontando falta de detalhes nas especificações por escrito e, de maneira mais geral, estão descobrindo uma falha na comunicação. E pode ser sua culpa.

Importante: Saiba quando as features estão prontas para entrar no seu roadmap

Esse é mais um motivo (como se você precisasse de um) para criar uma explicação estratégica clara de suas histórias de usuario e features no roadmap do produto. Simplesmente listar uma história em uma única frase – “O cliente clica no botão Exportar” – pode sugerir claramente em sua mente todas as etapas subsequentes às quais o clique levará, mas pode sugerir outras etapas na mente de seus desenvolvedores.

O que seus desenvolvedores estão tentando lhe dizer aqui, então, é que você precisa fazer um trabalho melhor de comunicar-lhes exatamente o que deseja que eles construam. E você pode fazer isso em suas reuniões, na lista de pendências e vinculando essas histórias ao roadmap do seu produto.

Dica: Conheça os melhores frameworks para priorização de feature.

– “Não é exatamente assim que o desenvolvedor funciona”.

O que o desenvolvedor quer dizer: “Por favor, leia o Guia completo dos idiotas sobre princípios básicos de programação? Nós até o compraremos do orçamento do Desenvolvimento. Em seguida, podemos ter uma conversa inteligente sobre o que é possível, o que é possível no prazo que você está solicitando e quantos recursos são necessários para fazê-lo. Apenas aprenda algumas codificações básicas primeiro para não parecer que estamos falando em Alien. Bonita por favor?

Um PM geralmente ouvirá uma declaração como “Isso não é exatamente como o desenvolvimento funciona” depois que ela disser algo para sua equipe de desenvolvimento ao longo das linhas de “Bem, isso não deve ser tão difícil de codificar, certo?” Ou “Eu posso” imagine que isso levará mais de alguns dias.

Sim, às vezes seus desenvolvedores exageram a dificuldade ou os requisitos das features de um determinado projeto porque, bem, eles preferem não trabalhar nele. E para conseguir isso, eles podem tentar assustá-lo com o jargão: “Bem, isso exigirá uma instância M1 adicional” ou “Precisamos contratar pelo menos mais dois especialistas em C# para fazer isso”.

Mas também é possível que, como PM, você realmente não tenha o conhecimento técnico para estimar com precisão a capacidade do desenvolvimento de realizar algo, com os recursos disponíveis, no tempo que você precisar.

Portanto, quando você ouvir “Não é exatamente assim que funciona”, não fique na defensiva ou frustrado.

Mas você também não deve deixá-los escapar com essa desculpa com uma explicação técnica que vai além da sua cabeça. Em vez disso, reduza a velocidade da conversa, peça aos desenvolvedores que lhe expliquem o problema nos termos do leigo – sem jargões! – e veja aonde isso leva você.

(Ah, e pode não ser uma perda de tempo ler o Guia Completo para Idiotas sobre o básico da programação).

O principal ponto desse artigo é simples e direto: todos estão no mesmo time e querem o mesmo objetivo – criar um produto de qualidade. O time de produto quer criar um bom produto que atenda as necessidades do cliente, os desenvolvedores querem criar um bom produto (estável, um código bem feito, etc), os vendedores querem um bom produto para que possam vender mais, etc…

Falar a mesma lingua dos desenvolvedores vai ajudar você, como PM, a melhor a comunicação entre todos os integrantes do time e stakeholders para garantir o alinhamento entre todos e garantir o objetivo final: Um BOM PRODUTO!

Dicas finais:

• Como manter o alinhamento entre vendas e produto– Essa questão é incrivelmente importante e vai ajuda-los a construir um produto mais alinhado com as necessidades do mercado.
• 12 características de um time de alta perfomance, afinal de contas, o que queremos fazer com uma boa comunicacão é aumentar a perfomance de todos os integrantes do time.