PM deve saber programar??

A dúvida que não quer calar: os profissionais da área de produtos precisam dominar alguma linguagem de programação?

PM deve saber programar??

Por vezes às pessoas da área de produtos se questionam quais são as hard skills que elas devem aprender ou aprimorar, e uma tema sempre fica em aberto: PM precisa saber programar?

E se tem que programar: em qual linguagem? Python? Java? Flutter?

É melhor saber mais de back-end ou front-end?

Por onde deve iniciar?

E a minha pergunta é: por que um profissional de produtos precisa saber de programação?

SOBRE VAGAS

Há alguns meses recebi em um grupo de whatsapp uma vaga para Product Manager onde no descritivo tinha como requisito a pessoa saber programar em uma determinada linguagem. E com base nos requisitos começamos a debater e a discutir se PM deveria saber ou não programar, qual era o objetivo disso, o quanto isto é ou não útil, e claro houveram enxurradas de pessoas apoiando e outra enxurrada indo contra, então este texto é a minha (humilde) visão sobre este assunto tão polêmico onde não há veredicto.

Acredito que um bom ponto de partida é compararmos os requisitos de uma vaga de PM e outra de Dev:

  • Pessoa desenvolvedora

    • Requisitos e Responsabilidades

      • Experiência ou expertise comprovável via portfólio/github/etc

      • Lógica de programação e facilidade na aprendizagem de novas tecnologias

      • Experiência com pipelines de integração contínua / implantação contínua

      • Superior completo na área de TI/Tecnologia (Engenharia, Análise e Desenvolvimento de Sistemas e afins)

      • Experiência no desenvolvimento de Projetos Web

      • Capacidade de discussão técnica com times diversos

      • Conhecimento na construção de serviços REST e SOAP

      • Conhecimento com testes automatizados 

      • Conhecimento na linguagem Java. 

      • Conhecimento nos Framework: JSF, ANGULAR, EJB, CDI, JPA. 

      • Conhecimento em arquitetura em nuvem.

      • Experiência com banco de dados relacionais.

  • Product Manager

    • Requisitos e Responsabilidades

      •  Ensino superior completo em áreas correlatas

      • Certificação em métodos ágeis

      • Experiência em atendimento a stakeholders

      • Ajudar na construção da visão e na constante evolução do Produto

      • Planejar, priorizar e acompanhar o roadmap de desenvolvimento do produto em consonância com as estratégia

      • Definir e acompanhar o OKR’s

      • Trabalhar para evoluir a visão do seu produto, buscando formas de impactar o negócio e satisfazer o seu cliente

      • Gerenciar e otimizar o portfólio de produtos existentes

      • Desenvolver produtos novos que entregam um valor real para usuários

      • Realizar reuniões para apresentações de métricas de resultados

      • Graduação completa em marketing, tecnologia, administração ou estatística

      • Experiência prévia na função

      • Experiência no acompanhamento e desenvolvimento de produtos digitais.

É claro que estes requisitos e responsabilidades listados não são limitantes ou correspondem à totalidade dos cargos apresentados. Elas servem apenas de condutores para o debate. Algumas empresas podem ter mais ou menos requisitos variando conforme região, estratégia, necessidades, maturidade para vaga entre muitas outras variáveis.

PMs precisam ser canivetes suíços?

Uma coisa que salta aos meus olhos é o nível de complexidade, tamanho da expertise e da experiência de uma pessoa que cumpra com qualidade, maestria e com boa performance um escopo tão grande e variável, e então vem à minha mente: Esse profissional existe ou é um unicórnio?

Não que não possam existir profissionais com grandes qualificações, mas nosso cérebro fortalece as conexões neurais que são exercitadas pelo uso constante, enquanto as não exercitadas enfraquecem. É claro que o ato de aprender  é crucial para estimular novas conexões no cérebro. Viva a neuroplasticidade!

Essa diversidade de funções, tarefas e escopo  solicitado me deixam atenta para entender se não há outros motivos: Será que há dúvidas quanto a qualidade das entregas do time de desenvolvimento? Dúvidas quanto aos prazos informados? Ou ainda se o time infle alguma pontuação das histórias ou dê um prazo superestimado?

Neste cenário o PM estará limitado a um babysitter do time, e é possível se perder ao ponto de começar a microgerenciar cada pull request do time, a entrar em detalhes técnicos demais ou ainda  deixar a função de PM e acabar sendo mais um líder técnico.

Priorizar é difícil

Então ser uma pessoa de produtos com skill de programação é ruim?

Ruim é muito forte, contudo das habilidades que considero bem importante para pessoas de produtos são: ter uma visão clara do produto e onde se deseja chegar, e para esta visão funcionar é preciso saber o que é importante/urgente do que não é. Prioridade é a palavra-chave.

Mas se não há prioridade e as necessidades estratégicas não são bem estabelecidas, podemos desviar do que importa, então teremos uma pessoa PM que diz o COMO FAZER e não POR QUE FAZER!

Como dito por Marty Cagan : "não importa o quão boa é a sua equipe de engenharia se não for dado a eles algo que valha a pena desenvolver". Saber programar irá te ajudar a criar produtos que as pessoas amam e precisam? Ou vai te colocar como quem escolhe como algo tem que ser feito?

Foco em decidir O QUE fazer e não COMO fazer

A PO/PM que buscam estabelecer sua visão de como fazer, e tentam impor ao time como deve ser feito e entregue cada funcionalidade, gerenciando no detalhe cada mudança de código podem facilmente perder a visão dos motivadores e problemas que emergiram, podem sugar dinâmica e interação do time reduzindo a possibilidade de diversidade, inovação e foco no valor esperado.

Lembrando que pelo Scrum Guide a responsabilidade da pessoa de produtos (Product Owner) é ser responsável por maximizar o valor do produto que é resultado do trabalho do time de desenvolvimento. Não impedindo que esta pessoa desenvolva código também (inclusive o PO e o SM podem ser ou não contabilizados dentro do time de desenvolvimento), mas tendo como principal dever a entrega do valor real para o usuário através do seu produto.

Então, por muitas vezes um background técnico pode vir como uma complementação, um auxiliador para entender a linguagem das pessoas da engenharia, das necessidades técnicas e estruturantes do produto, fazendo que a visão do produto possa ser mais facilmente atingida e a comunicação com os stakeholder mais fácil e amigável.

Concluindo

A realidade da empresa, a estratégia, as necessidades e o direcionamento devem ser alguns dos fatores a serem observados e avaliados quando as empresas definirem  o papel das pessoas que irão gerir o produto. Podemos não chegar a um consenso, mas precisamos de abertura na mente para dialogar e entender as razões que levam a determinados níveis de exigência, entendendo a realidade da empresa e do mercado, e não por receio do time não entregar ou esperando um produteiro que use o chicote com palavreado técnico.

Acredito que todas as empresas gostariam de extrair o melhor de seus times e colaboradores, se beneficiando da multidisciplinaridade, do capital humano criativo e de boas entregas que atendem e superam suas metas. Mas para tal, creio, que é preciso de espaço para errar e aprender, espaço para confiança e desenvolvimento pessoal, espaço para desenvolvimento de maturidade e percepção do que é importante por todos, afinal, atingir uma meta é uma ação que não envolve um indivíduo isolado, mas é um conjunto de ações coletivas que levam ao alvo traçado.