Transição para a carreira de produto.

Algumas dicas de quem já esteve lá.

A medida em que a posição de product manager (gerente de produto, product owner…) vem ganhando popularidade no Brasil, naturalmente tenho visto aumentar o interesse por esse tópico. "Como fazer a transição para a carreira de produto?" é uma pergunta frequente do público nos meetups da área, o que faz total sentido: não há (ainda) curso superior para PM, portanto os caminhos e backgrounds para chegar lá são inúmeros e nem sempre óbvios.

Aproveito que dei uma talk sobre esse tema no TDC SP no ano passado para passar para cá o conteúdo da mesma. Primeiro passo um panorama geral de como é trabalhar com produto, depois conto como tudo aconteceu pra mim, e mais pro fim dou dicas bem diretas que podem ajudar no processo.

Como vários profissionais têm me procurado no LinkedIn para perguntar sobre isso, espero que possa ser útil para bastante gente que está nessa etapa da sua jornada profissional.

Abaixo os slides da palestra intercalados com o que falei por lá:

Antes de entrar nas dicas em si para transicionar para uma carreira em produto, acho legal falar um pouco sobre como é trabalhar nessa área, o que os produteiros fazem o dia todo, e boas skills buscadas em pessoas de produto, até para cada um ver se realmente se identifica com a área.

A posição de PM não é para quem gosta de "sentar a bunda na cadeira" e ficar no seu canto fazendo coisas parecidas o dia todo, de preferência sem interação com muita gente. A "matéria" de produto é bastante multidisciplinar, demandando envolvimento com diferentes tarefas de forma intercalada, ou até ao mesmo tempo. Por isso, também é uma boa área para quem gosta de estudar e desenvolver habilidades novas: dificilmente a pessoa já tem em seu background todos os conhecimentos necessários para ser uma boa PM.

Além de precisar permear diferentes disciplinas (por exemplo, é importantíssimo que consigamos extrair alguns dados do banco de dados para fazer uma análise, ao mesmo tempo que é importantíssimo que saibamos conduzir uma boa entrevista com um cliente), o PM é a pessoa que veste muitos chapéus. Precisamos entender a ótica e os interesses da empresa, do cliente, do nosso time de design e desenvolvimento, do mercado… enfim, de muita gente, e juntar todos esses olhares em um produto/feature que faça sentido.

E o que fazemos o dia todo? A melhor forma que julgo para resumir a essência do trabalho da PM está na frase acima. Obviamente, estamos lá para construir um produto do zero ou evoluir um produto já existente. E vamos fazer isso garantindo que as pessoas para quem construímos o produto querem aquilo que estamos propondo (resolve o problema que elas têm), querem pagar por isso de forma que sustente um negócio lucrativo, e que dominemos a tecnologia necessária para tornar tudo isso possível. Um elemento sem o outro não adianta, e é nosso trabalho achar esse equilíbrio.

Ok, isso é o macro, mas e o dia a dia em si? O que preenche os dias? Conforme citei anteriormente, uma porção de tarefas (prepare-se para ter mil braços). Lembrando que, dependendo do contexto de cada empresa onde vamos trabalhar, isso vai variar consideravelmente.

Por exemplo, em empresas que contam com um time de product marketing (como é o caso da Resultados Digitais onde estou hoje como PM), a pessoa de produto terá muito mais apoio dessa equipe para o go to market de um produto ou feature — materiais de comunicação, apoio a dúvidas dos clientes, divulgação, treinamentos — e também contará com esse time para ajudar a casar a evolução do produto com o posicionamento da marca e com os movimentos de mercado e concorrentes. Onde não há um time assim, todas essas tarefas costumam ficar com o PM.

Outro exemplo são os testes/homologação de uma nova feature: muitas vezes contamos com alguém de QA (quality assurance/garantia de qualidade) para isso, ou é uma demanda que faz parte do escopo do próprio time de desenvolvimento. Mas existem diversos contextos onde é responsabilidade da própria PM garantir que todas as regras de negócio de uma feature foram cumpridas, além do funcionamento da mesma estar OK, antes de algo "ir pra rua".

No entanto, existem algumas tasks que são bem da pessoa de produto mesmo, e muito provavelmente serão suas na grande maioria das empresas. Alguns exemplos: (1) a priorização do que será desenvolvido e a organização/comunicação disso em um roadmap de produto, (2) a escolha de métricas que darão insights de produto e o acompanhamento das mesmas (por vezes contamos com outros times para ajudar aqui, mas considero primordial que pelo menos a escolha do que será medido venha da PM, porque são esses números que direcionam o trabalho de produto), (3) a diretriz de regras de negócio do que será construído (muitas vezes com grande apoio da designer, visto que são algumas das pessoas que mais dominam os problemas e necessidades do usuário), (4) a manutenção de um backlog (ideia de melhoria vem de todo o lugar, mas alguém precisa filtrar e centralizar todas as possibilidades que temos para atingir nossos objetivos com o produto e como empresa, e esse alguém é o PM), (5) ouvir usuários (isso é importante pra praticamente tudo que o PM faz), (6) e por fim talvez a tarefa mais importante, o product discovery: esse processo contínuo amarra tudo isso que fazemos, e é o motor para uma evolução saudável do produto.

Ufa, agora que falei bastante da minha visão sobre as nossas atribuições, vou comentar rapidamente sobre o meu processo de transição para produto.

Lá nos primeiros passos da minha carreira, me formei em Comunicação Social — Publicidade e Propaganda, em 2010.

Cheguei a trabalhar alguns meses em agência de publicidade, mas logo vi que não era pra mim (e as razões para isso dariam todo um novo post). No entanto, trabalhei praticamente 10 anos com marketing (desde o tradicionalzão mesmo, da era Kotler, planejamento estratégico, estudo de viabilidade de mercado e tudo mais) até marketing digital, que foi com o que trabalhei mais tempo. E por muitos anos fui muito feliz.

No entanto, em determinado ponto comecei internamente com alguns questionamentos sobre a minha atuação. Quando uma campanha patinava um pouco e não engrenava, além de otimizações da mesma, começava a avaliar que aspectos do produto/solução poderiam estar pesando para o insucesso das vendas, como aquela solução (dado o seu contexto de mercado) poderia ser melhor para alavancar a performance das campanhas e vendas. Enfim, por mais difícil que seja esse processo de questionamentos, comecei a me dar conta de que, mesmo estando feliz, talvez quisesse passar a fazer algo diferente da vida.

E foi bem nessa época que surgiu a oportunidade de morar por 12 meses em Boulder (Colorado, EUA), uma cidade universitária que respira inovação e é berço para muitos novos negócios. Dediquei esse tempo para estudar novas áreas, e Boulder/Denver é um excelente lugar para esse tipo de exploração, pois sempre surgem mil eventos e meetups gratuitos sobre os mais diversos assuntos. Foi numa dessas que fui parar em uma palestra de Product Management (101), termo que nunca tinha escutado antes. Quando terminou, tudo fazia sentido: aquilo que eu queria fazer tinha um nome formal e era uma profissão. Decidi passar um tempo em São Francisco fazendo um curso mais completo sobre produto, e então voltei para o Brasil.

Perfeito, comecei a me candidatar para vagas na área. Muitas vagas. Por várias e várias semanas. Só que estava bem difícil de ser considerada para elas, o que é compreensível: eu não tinha experiência de fato com produto, só trazia um curso na mala.

Se eu tivesse insistido por mais alguns meses, talvez tivesse conseguido entrar direto em uma posição de produto, mas queria muito voltar a produzir o quanto antes.

E então comecei a considerar outras áreas. Entrei na InfoPrice para a área comercial, o que acidentalmente e felizmente foi me colocando para o caminho que eu queria trilhar. Vendas é um dos times que mais escuta do cliente sobre o que ele quer em um produto para considerar comprar (coisas que o produto tem e também as que o produto não tem).

Escutava muito dos prospects sobre um problema X que eles precisavam resolver, e o produto da empresa não resolvia ainda. Trouxe internamente essa questão, acabei me envolvendo na idealização desse novo produto, e assim fui oficialmente para a área de produto.

O slide está desatualizado pois é da época da palestra, mas trabalhei como PO lá por 1 ano e 4 meses, e em setembro de 2019 entrei para o time de produto da RD.

Ou seja, aqui vai um spoiler das dicas para transição: uma movimentação interna dentro da empresa onde você está pode ser muito mais fácil e boa para todos os lados.

Mesmo curtindo muito tudo o que eu escutava sobre a área, por um tempo eu me perguntei se eu tinha o que era necessário. Para aqueles que se perguntam a mesma coisa, trago um panorama sobre algumas das principais skills buscadas em uma PM:

Como soft skill, ressalto bastante a organização. Mil pessoas vão te perguntar mil coisas o tempo todo, e é seu trabalho conseguir responder.

O que está previsto no roadmap até o meio do ano? Quando o usuário fizer ação X sem fazer ação Y, o que deve acontecer? Como funciona feature Z? Você consegue responder esse usuário que não sabe como fazer A? Por que você priorizou B e não C? Tem uma gambiarra pra resolver isso enquanto a feature não sai? Etc…

Além disso, costumo brincar que o PM sempre está no passado, no presente e no futuro ao mesmo tempo: enquanto faz o discovery do que deverá ser construído a seguir, dá suporte pro time no que ele está construindo agora, e tira dúvidas e acompanha o sucesso do que foi entregue anteriormente.

Ou seja, sem organização, não rola.

Comunicação também é essencial: apenas uma das várias consequências negativas que uma comunicação falha de PM pode ter é o time passar semanas trabalhando em algo que sai lá no final diferente do que precisava ser para atender às dores do cliente.

A liderança da pessoa de produto é um desafio à parte, pois ela lidera sem relação de hierarquia. Em outras palavras, a PM não é chefe de ninguém, mas precisa que todo o time esteja comprado em uma ideia e confie nela no processo para entregar determinada feature.

Por fim, para lidar bem com essa mistura de skills e tarefas necessárias, a pessoa precisa ser curiosa. Curiosa para aprender o que não sabe fazer ainda, para entender pessoas que são diferentes dela, para considerar soluções aparentemente não tão óbvias, etc.

Como hard skills, ter facilidade com números ajuda muito nas análises que serão necessárias, ter um embasamento sobre negócios/mercado é importante para entender o macro do cenário que atuamos e sobre a viabilidade das soluções propostas, ter noções de UX (user experience) colabora para a construção de soluções mais consistentes — principalmente em times que não contam com um designer exclusivo, ter conhecimentos básicos sobre programação ajuda em um diálogo mais "na mesma língua" com o time de engenharia, dominar os conceitos básicos das metodologias ágeis mais comuns é importante porque a grande maioria dos squads de produto vão funcionar dentro de alguma delas, e, claro, ter conhecimento sobre as melhores práticas de gestão de produto te deixa mais preparada.

Estou quase chegando nas dicas práticas para buscar a transição para produto, mas primeiro, aqui vão algumas "crises existenciais" pelas quais algumas pessoas passam nesse momento, e razões para contorná-las.

Essa é uma pergunta clássica de quem está cogitando virar PM: "mas precisa ter conhecimento técnico"? A resposta que eu mais gosto é: não precisa, mas ajuda! Se você já vem de um background mais técnico, isso te ajudará bastante a ter diálogos mais ricos com o time de engenharia, além de conseguir pesar a viabilidade de uma solução desde o início da concepção. Às vezes a PM mais técnica pode até colaborar no desenho da solução técnica, mas isso é bastante delicado. Vários profissionais defendem que é mais produtivo tais decisões ficarem na mão do time de engenharia, e eu concordo.

No entanto, ao meu ver, o valor maior do PM está em entender o usuário, entender do mercado e concorrência, entender do negócio da empresa e os objetivos de crescimento da mesma, conseguir comunicar bem tudo isso… enfim, o trabalho essencialmente do PM não está no código em si. Bons squads de produto colaboram e confiam em seus membros, o que significa que você contará com o time de desenvolvimento para compor com você a melhor solução técnica. Com o tempo você poderá ir estudando e se inteirando mais sobre programação, o que é o meu caso agora.

Lembrando que isso também varia muito dependendo da vaga. Existem posições de produto para times que demandam um PM mais técnico mesmo.

Mas você certamente tem experiência em outras coisas. Aqui vai uma dica que não estará nas dicas lá de baixo, mas ajuda bastante: se você está interessado em virar PM, provavelmente alguma coisa você já fez até hoje que te despertou esse interesse. Um exemplo extremo aqui, mas é muito difícil uma dentista acordar um belo dia e decidir que quer ser PM.

Saiba vender as experiências que você já teve até aqui colaborando no contexto de gestão de produtos.

O que pode ser bem desesperador mesmo, mas podemos ver o lado bom. Existem muito mais possibilidades para chegar lá. É questão de achar o seu caminho.

Quando decidi aplicar para vagas de marketing e comercial, pensei em fazer isso durante um tempo enquanto me especializava mais para daí entrar em produto, mas acabou que justamente esse caminho meu levou para lá mais rápido. Exercite a criatividade!

E, finalmente, as dicas propriamente ditas para fazer essa movimentação para a área de gestão de produto.

Como comentei mais acima, fazer uma migração interna para a área de produto da empresa em que você já está pode facilitar bastante as coisas. Primeiro porque as pessoas da empresa já conhecem o seu trabalho, confiam em você e sabem do seu valor. E segundo porque, como também já comentei, saber do modelo de negócio da empresa e entender do mercado em que ela atua já é grande caminho andado pra PM performar bem.

Se a sua empresa conta com uma área de produto, mostre interesse: marque papos com os PMs, aproxime-se das lideranças da área e procure se inteirar dos processos e dia a dia deles.

O que me ajudou muito na minha transição foi a oportunidade de, mesmo estando em outra área, poder puxar um projeto de desenvolvimento de um novo produto.

Procure entender os maiores desafios de produto da sua empresa, aprofunde-se no seu usuário e na dor dele, foque no objetivo macro que a sua companhia está buscando e proponha um novo produto/feature para alcançar esses objetivos resolvendo problemas reais dos clientes. Quanto mais completo for esse projeto, mais confiança você passará de que estaria pronto para o desafio.

Se nada disso parece fazer sentido no seu contexto, e você quer mesmo buscar uma posição de produto em uma nova empresa, o que pode ser legal é exercitar o processo de discovery e desenvolvimento de produto com uma empresa X que você curte. Quando fiz o curso de PM, por exemplo, precisei desenvolver um projeto final simulando ser a PM do Airbnb. Você pode ver um pouco sobre como ele ficou aqui.

Como dificilmente você reunirá de cara todas as skills necessárias, mapeie aquilo em que você mais precisa evoluir e vá preenchendo essas lacunas uma a uma.

Quando cheguei dos EUA, eu já me sentia mais à vontade com toda a parte de estudo de mercado, concorrência e noções de negócio que eu tinha. Entrevistar usuários também era tranquilo para mim. No entanto, percebia outros gaps para preencher. Desde então, fiz um curso de UX Design, outro de análise de dados e agora estou começando a estudar noções e conceitos básicos de programação.

Os cursos de product management sozinhos talvez não garantam a transição em 100% dos casos (tipo o meu), mas certamente ajudam a dar uma base, e são úteis principalmente por causa das pessoas que você vai conhecer e trocas que fará com os professores e outros participantes. No Brasil, os que mais ouço falar são os da Tera e PM3, e nos EUA o Product School é bem famoso. Por causa de agendas, acabei fazendo o da General Assembly, e gostei bastante!

O que também vale bastante a pena é pesquisar os eventos de produto que rolam na sua cidade ou próximos a você e sempre estar presente, tanto pelo conteúdo quanto pelo networking.

A internet está cheia de tudo o que se pode imaginar, e com conteúdos de produto não é diferente. Blogs, portais, podcasts, livros… enfim, tem muita coisa. Adquira o hábito de consumir esses conteúdos com frequência, para estar sempre atualizada e se aprofundar cada vez mais nesse novo mundo que você pretende permear. Fiz esse post que agrega várias fontes de conteúdo, e também alguns meetups e eventos em São Paulo, o que pode ajudar.

Além disso, começar a escrever sobre produto te ajuda a ganhar relevância na área. Quando escrevi esse post eu nunca tinha trabalhado com produto na vida, mas já vinha estudando o tema. Claro que não é o post mais brilhante sobre técnica de gestão de produtos, mas comece com o que você tem.

E, por fim, expanda a sua rede e procure pessoas que possam te ajudar. Faça uma pesquisa em seu LinkedIn filtrando os contatos por posições de produto, contate essas pessoas demonstrando seu interesse em migrar para a área e peça dicas/ajuda.

Se você tem mais proximidade com alguma PM da sua empresa ou fora dela, peça para fazer algumas mentorias para começar a entender melhor do universo de produtos digitais. Alguém vai te ajudar!

***

Cada vez mais o mercado vai precisar de novos PMs, e eu acredito que a diversidade (de perfis e de backgrounds) só enriquece nossa área. Boas vindas a todas que estão interessadas em gestão de produtos, e boa sorte em suas transições de carreira!

No que eu puder ajudar, contem comigo no LinkedIn ou no hello@martinascherrer.com