Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
30 de março de 2021

Quão técnico deve ser um Product Manager?

Este artigo é uma tradução livre deste post original do Medium da Maia Metz. Por ser um conteúdo de altíssimo valor, achamos por bem traduzi-lo e assim ajudar a comunidade brasileira de Produto a evoluir. Boa leitura!

Acho que já ouvi essa pergunta mais de 200 vezes: “Não tenho background técnico, posso ser um Product Manager?”. Esse artigo vai tentar responder a esta questão. Spoiler: a resposta é sim! Vou dar meu ponto de vista e também a perspectiva de Lucas Certan, Lead Product Manager de uma empresa muito técnica: Algolia.

Um PM deve saber codar?

Na maioria dos casos, não (com exceção de algumas empresas). O trabalho de PM é explicar o ‘porque’, não o ‘como’. Quando eu quis me tornar Product Manager, fiz alguns cursos online de Ruby. E vou logo avisando: não usei nada do que aprendi no meu papel de PM. Obviamente, há exceções! Se você deseja ser Product Manager de um produto muito técnico, ou na parte técnica de um produto (como APIs), aí, é claro que saber codar é um bom diferencial. Porém, na maioria das empresas que eu conheço, os times de produto são divididos entre PMs que têm ou não um background técnico.

Dito isso, é importante que você tenha um mínimo entendimento de conceitos técnicos para ser uma boa Product Manager.

E antes de listar quais conceitos, vou explicar por que eles serão úteis. Vejo seis grandes questões:

  • Conseguir fazer trocas baseadas em escolhas técnicas. Ter um entendimento básico sobre arquitetura de dados dos seus produtos pode ser a chave para fazer boas escolhas quando falamos de priorização técnica. Por exemplo: digamos que vocÊ esteja trabalhando em uma funcionalidade de Analytics. A análise deve ser feita em tempo real? Qual é o atraso aceitável na atualização automática? Essas questões têm alto impacto técnico, e para priorizar de forma certa, é importante saber como isso funciona. 
  • Aplicabilidade técnica. Como Product Manager, você vai encontrar milhares de oportunidades, e terá que priorizá-las. Obviamente, para fazer isso, você precisa entender a carga técnica em questão. Alguns dirão que essa é uma missão exclusivamente do seu time de desenvolvimento… Eu acredito que, como PM, você deve conseguir algumas hipóteses levando em conta essa carga técnica, evitando acessar seus devs toda hora. A ideia não é estimar o tempo de trabalho, e sim eliminar as soluções que são um verdadeiro tiro na lua em termos de viabilidade técnica.
  • Débito técnico. Um erro comum é dizer aos times de engenheiros que há margem de 10% para débito técnico, então que eles entreguem como preferirem, respeitando isso. Como PM, deve-se priorizar o débito técnico da mesma forma que qualquer outra coisa, observando o impacto no produto. E é claro que fica muito mais difícil priorizar algo completamente fora do seu domínio de conhecimento!
  • Remoção de bugs. Essa não é a parte mais legal do trabalho, não. Ter um entendimento básico de como seu produto funciona, tecnicamente, ajuda muito aqui.  Não precisa encontrar as causas dos erros, mas é essencial conseguir dizer: “não sei como arrumar isso, mas sei que A acontece, e ela deve ser causada por B ou C”. Oferecer estes caminhos vai poupar tempo de todos os envolvidos. 
  • Dados. Como Product Manager, seu papel é entender problemas. Analisar um produto usando dados é essencial para isso. Se, como acontece muito, você não tiver um analista de dados disponível 24h, é muito útil que você consiga encontrar insights observando os dados de forma independente. T er um conhecimento básico de SQL é uma ótima maneira de ser mais autônomo. 
  • Delivery. Dureante essa fase, os desenvolvedores estão trabalhando na produção do seu produto! E como Product Manager, é importantíssimo se familiarizar com os ambientes de códigos (staging – ou pré-produção, ambiente de teste, homologação, produção…), e também alguns conceitos como branches e pull requests, por exemplo.

Mas e aí, como Product Manager, o que eu devo saber sobre tecnologia?

Abaixo está uma lista de conceitos que devem estar ao seu alcance técnico – incompleta, porém com o básico:

  • Conceitos de front-end e back-end
  • Diferenças principais entre mobile e web, em termos de arquitetura e desenvolvimento de produto. 
  • iOS vs Android: impactos em design, possibilidades de implementação, regras para divulgação nas respectivas lojas etc.
  • Entendimento básico sobre arquitetura técnica de produto — explore a curiosidade! Sempre que puder, pergunte ao seu time como funciona alguma parte do processo. 
  • O que é uma API? O que é um webhook? Sauba ler e entender uma documentação de API.
  • DevOps: conhecimento básico sobre ambientes de código e conceitos de desenvolvimento de software.

Como recrutadores medem o conhecimento técnico?

Existem várias maneiras de as empresas avaliarem seu conhecimento técnico, Cito algumas abaixo:

  • Ter um debate em formato de brainstorming sobre um determinado recurso com o Tech Lead de sua futura equipe, durante uma entrevista, durante a etapa de “estudo de caso” do produto.
  • Perguntando “como você explicaria o que é uma API para uma criança de cinco anos?”. Sua resposta também serve para mostrar sua capacidade de explicar coisas complexas de forma simples, algo fundamental em seu trabalho de PM.
  • Podem sondar sua curiosidade sobre questões técnicas. Por exemplo, verificar se você deu uma olhada na documentação da API do produto do estudo, se houver.

E as empresas com produtos técnicos?

Lucas Cerdan, Lead Product Manager da Algolia, deu uma perspectiva sobre como ele vê isso na empresa. Veja o que ele diz!

Algolia é um produto “search as a service”. É uma API e, portanto, é feito para desenvolvedores – e é bem técnico, de fato.

Em nosso time, temos nove PMs, e há espaço para tudo. Um deles já foi desenvolvedor, outros quatro têm um background em engenharia (e não necessariamente ciência da computação), além de outros três sem background técnico.

E aqui vão alguns conselhos para quem está se tornando Product Manager:

  • Ao se candidatar à esta posição, não observe apenas “quão técnico o produto é”, e sim “quão técnica é a audiência dele”. 
  • Se você quer se tornar Product Manager, precisa ter curiosidade sobre tecnologias. É fundamental para Product Managers saberem sobre muita coisa, como usuários, concorrência, tecnologia. E neste último quesito, saber ler documentações e tutoriais podem ser uma boa forma de começar!
  • Teste o produto da empresa para a qual está se candidatando. Sem isso, o candidato já é um “não” para mim.

E por último, a parte mais importante: Não tente marcar todas as caixinhas da job description! Alexandra é uma das Product Managers da Algolia. Dois anos atrás, falei com ela para trazê-la ao time. Ela me disse que nunca tinha se candidatado porque parecia técnico demais para ela. Bem, ela já está conosco há dois anos! Arrisque e compre o desafio de aprender sempre.

Quer uma ajuda nos processos seletivos de Produto? Confira este e-book gratuito!

Reunimos 20 líderes de Produto para nos contar suas perguntas prediletas nas entrevistas, as respostas ideais e quais são as características que eles mais valorizam nos candidatos a Product Managers!

Baixe o material completo gratuitamente clicando no banner abaixo.

Temos certeza que com ele você vai chegar mais bem preparado em sua próxima entrevista para Product Manager.

Mais conteúdos para te ajudar a ser um(a) PM melhor:

Autoria de:

PM3 Lives 25

Newsletter Mensal

E-book Entrevistas PM

Você também pode gostar de ler

No-code para times de Produto

Sem tempo? Os principais pontos: – No-code é menos sobre codar ou não, mas sobre build (feature) vs buy (SaaS). – Categorizar hacks em: front