Product Managers precisam saber escrever códigos?
Encontrar o equilíbrio entre conhecimento técnico e uma visão ampla de negócios pode ser um diferencial na gestão de produtos.
Por Manos Kyriakakis (publicado originalmente aqui, em inglês)
Uma (tentativa de) resposta curta
Esta é uma das perguntas que estão surgindo com bastante frequência ultimamente e, pessoalmente, como PM não-técnico (pelo menos em termos de educação formal) já pensei bastante sobre isso. Acho que esse é o caso da maioria dos gerentes de produto sem experiência em tecnologia, que estão trabalhando em produtos técnicos.
A resposta curta para mim é “não”.
O trabalho principal de PMs e onde devem colocar a maior parte de sua energia e inteligência é escutar e compreender o mercado, definindo a estratégia e a visão do produto e comunicando requisitos claros para a equipe de Produto.
Ser capaz de desenvolver códigos ou criar arquiteturas de software ou qualquer outra habilidade similar é apenas uma vantagem, mas definitivamente não é o trabalho do gerente de produto.
Acredito que as habilidades de desenvolvimento de código absolutamente necessárias que PMs devem possuir são aquelas necessárias para extrair e processar dados relacionados à adoção e uso do produto e comportamentos de clientes, para que possam adquirir insights e tomar decisões baseadas em dados sobre o futuro do produto.
Por exemplo: ser capaz de usar o SQL de forma eficaz para puxar dados ou qualquer linguagem de programação para manipulá-los são habilidades super valiosas e, como eu disse, necessárias.
Por que PMs não precisam saber codar?
Dito isto, quanto mais profunda a compreensão técnica que você conseguir ter sobre o produto e tecnologias existentes, melhor — mas isso não significa que você precisa ter um histórico de engenharia de software. Você pode adquirir esse tipo de conhecimento mantendo-se curioso sobre os pequenos detalhes, lendo sobre tecnologia, estruturas, seus prós e contras e, obviamente, trabalhando em produtos técnicos e tendo o máximo de comunicação relevante possível com os engenheiros e engenheiras que estão construindo o produto.
Pela minha experiência, profissionais de engenharia estão sempre dispostos a explicar e compartilhar ideias para pessoas não técnicas sobre o que estão desenvolvendo, como estão desenvolvendo e por que fizeram certas escolhas em termos de tecnologia.
No começo, eu era relutante em percorrer o “quilometro extra” e começar a disparar essas perguntas, já que não queria ser o cara visto como “distração constante”. O que eu percebi, porém, foi que a grande maioria dos colegas não só estavam lá para responder minhas perguntas, mas eles e elas também me davam mais detalhes do que eu pedia, compartilhando um conteúdo útil que acabava inclusive orientando de maneira mais profunda minhas perguntas.
Como eu disse, você não deve ficar relutante em perguntar — no entanto, tenha sempre cautela para não cruzar o limite. Antes de continuar com as perguntas, verifique se você fez sua própria pesquisa primeiro. Se você já fez uma lição de casa e não consegue encontrar resposta satisfatória ou se precisa de ideias mais profundas, então vá em frente e pergunte.
Mas e se eu for PM com formação técnica?
Por outro lado, há muitas pessoas migrando do lado técnico da engenharia de software para o lado da gestão de produtos. Não há dúvidas de que seu conhecimento técnico é um benefício incrível. Mas, ainda assim, você deve ter em mente qual é seu principal objetivo como gerente de produto. Eu sei que quando você encara o desafio de desenvolver um produto é muito tentador envolver-se o máximo possível nas especificações técnicas e escolhas de tecnologia — e você deve mesmo (ainda que não tenha experiência em engenharia de software).
Ainda assim, exercendo esse papel, não cabe tomar as decisões finais sobre como deve ser a arquitetura técnica do produto ou quais tecnologias serão usadas, já que não é você a pessoa que vai construir de fato o produto. São profissionais de engenharia da sua equipe que farão esse trabalho e a palavra final sobre essas escolhas deve ser delas. Sua experiência pode ser diferente da delas e as tecnologias que dominam não são necessariamente as mesmas que as suas.
E certamente não há apenas um caminho certo para construir algo. Claro, você pode e deve contribuir nessas discussões, mas não deixe que o seu ego de engenharia fique à frente do seu trabalho.
E se eu quero aprender a codar?
Voltando àqueles gerentes de produto sem experiência em engenharia de software, aprender a escrever código obviamente pode ser mais do que apenas útil. Para mim, pessoalmente, não é apenas útil; é algo que eu gosto. Em primeiro lugar, estou aprendendo algo novo, que é excitante por si só. Embora a parte mais surpreendente não seja apenas aprender um novo framework ou novos princípios de engenharia de software.
É o efeito que princípios da engenharia de software têm na maneira como você pensa, lida com um problema, analisa seu processo e estrutura seus pensamentos.
Como bônus, você pode sempre iniciar seu próprio “projeto X”, que talvez comece como um simples conceito que você quer testar e acabe virando um MVP que será a próxima grande funcionalidade do seu produto. E isso é incrível.
Em resumo
Não importa quão divertida e útil seja a engenharia de software — como gerente de produto, você deve sempre ter em mente quais são suas principais responsabilidades. Elas não estão voltadas para construir o produto você mesmo(a). Estão voltadas à definição ampliada do produto.
Sim, alguns conhecimentos a respeito de estruturação e uso de código são definitivamente benéficos. Mas tomar as decisões certas sobre o que o produto deve ser e em qual produto ele deve evoluir são a essência do trabalho de gerentes de produto.
Você tem sua equipe de profissionais de engenharia de software para cuidar do resto. Reconheço que, em alguns casos, é necessário, por natureza, para gerentes de produto, ter um background altamente técnico. Mas acredito que, na grande maioria dos casos, isso é apenas uma vantagem e não um must-have.
