> ## Content Index > Fetch the complete content index at: https://productoversee.com/llms.txt > Use this file to discover other available public pages before exploring further. # PM deve saber programar?? - URL: https://productoversee.com/blog/pm-deve-saber-programar/ - Published: 2021-05-12T10:45:00.000Z - Updated: 2022-04-13T13:31:58.000Z - Description: A dúvida que não quer calar: os profissionais da área de produtos precisam dominar alguma linguagem de programação? - Author: Éricka Padilha - Tags: Opinião, #blog 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.