O que devs precisam saber sobre produto

Do código ao produto: por que todo dev precisa de uma visão de negócio

A velha rivalidade entre desenvolvimento e produto já não faz sentido. O desafio atual é romper a bolha técnica e criar softwares que não apenas funcionam, mas que resolvem problemas reais e acompanham o crescimento do negócio.

Essa foi a principal provocação de Diego Eis, Head de Produtos na Frota162 e Co-Founder da Product Oversee. Ele fala com a experiência de quem já esteve dos dois lados: começou como desenvolvedor e hoje é especialista em produto. Para Diego, o perfil introspectivo, típico do dev, precisa evoluir para acompanhar a complexidade do mercado. Enquanto áreas como design se fragmentaram em dezenas de disciplinas, a carreira de desenvolvedor manteve-se, em essência, a mesma. Isso acabou reforçando a ideia de que gestão de pessoas e processos é “coisa de outros”, quando na prática deveria ser vista como progressão natural da carreira.

O PM: um “bug no sistema”?

Segundo Diego, o Product Manager pode ser visto como um “bug no sistema”. Muitas vezes, o PM atua como intermediário entre negócio e tecnologia, justamente porque essas áreas não se comunicam diretamente. Diego pontua: “ele nasceu (o Product Manager) por causa de uma falta de comunicação entre designers com os programadores”.

Num cenário ideal, o time de negócio traria o problema ou a oportunidade, e tecnologia, liderada por um Tech Lead, que junto ao designer teriam autonomia para encontrar a melhor solução para o projeto. É assim que empresas como a Basecamp inovam: estruturas mais enxutas, sem depender da figura tradicional do PM.

O desenvolvedor, por estar tão próximo da implementação, conhece detalhes valiosos do negócio, que vão desde as regras específicas de um gateway de pagamento até as nuances de uma integração. Esse conhecimento, muitas vezes não percebido pelo PM, é um ativo estratégico que pode (e deve) influenciar decisões de produto.

O caminho para a visão de produto

A boa notícia é que para desenvolver a mentalidade de produto não significa precisar mudar de carreira, mas sim mudar de postura. É um exercício de curiosidade: vá além do ticket, questione o “porquê” de determinada tarefa, entenda o problema que resolve e o impacto que vai ter no negócio a longo e médio prazo. Segundo Diego “o que o dev precisa aprender sobre o produto, é o traquejo do negócio, entender um pouco mais o teórico”, ou seja, entender com quais objetivos foram tomadas determinadas ações e onde e quando aquela decisão vai ser refletida no negócio.

Isso passa também por entender o usuário. Pesquisas, conversas ou ferramentas de análise ajudam a enxergar como as pessoas realmente usam o que você construiu. E, além das métricas técnicas, é essencial acompanhar os números do negócio: seu código ajuda a aumentar receita? Melhora retenção?.

O dev que foca apenas no código corre o risco de se perder na obsessão pela perfeição técnica. Um exemplo disso é querer refatorar um index.php antigo, por exemplo, que continua atendendo bem os usuários. Para o cliente, não importa se o código é bonito só importa se resolve o problema. A viabilidade técnica, lembra Diego, é um dos pilares de um produto de sucesso, e está nas mãos dos desenvolvedores.

Em resumo, a força de um dev não está apenas no código que escreve, mas na sua capacidade de conectar tecnologia à estratégia da empresa.

Quer saber mais?

Esse foi o tema de um episódio do episódio #61 do Escovando Bits. Ouça a entrevista completa no seu agregador de podcasts favorito.