Como foi meu primeiro ano como product manager?

Muitas pessoas tem curiosidade em saber como é ser um product manager. Existem muitos posts falando conceitualmente sobre o assunto, mas é difícil fazer as pessoas entenderem o que é ser um product manager apenas falando sobre conceitos. Nesse post pretendo contar minha visão pessoal, de como foi meu primeiro ano atuando nessa profissão e algumas particularidades que podem ser interessantes para você, que está curioso sobre o assunto. Vamos lá?

Como aconteceu a transição do meu cargo anterior para product manager?

Antes de entrar para a Resultados Digitais, em 2017, confesso que nunca tinha ouvido falar sobre product manager. O meu background não era de startup (onde product managers são comuns) e chegando aqui me deparei com muitos cargos diferentes na área de produto e engenharia. Em um processo interno, onde eu estava transitando de suporte Nível 1 para suporte Nível 3 (chamamos de suporte de engenharia aqui na Resultados Digitais), eu fui questionado sobre qual seria meu próximo passo, pois naquele momento a idéia era me desenvolver para outro cargo. Entre os cargos que me foram apresentados estavam: software engineer, team lead, quality assurance e product manager.

Depois de muito pensar e fazer alguns testes, optei por product manager,pois em minha trajetória profissional eu fiz muitas coisas que tinham sinergia com a rotina de um product manager, como reuniões com outras áreas, entrevistas com clientes e estudo de soluções. No tópico O que eu aproveitei de conhecimento de experiências passadas? eu dou mais detalhes do que fiz em minha carreira antes de me tornar product manager. Um tempo depois apareceu uma oportunidade, fiz o teste, passei, então toda a história começou!

Qual foi o maior desafio inicial?

Quando me tornei product manager, tive que mudar minha forma de pensar sobre como estudar um produto, muito disso por causa do meu background como engenheiro de software. Constantemente ficava pensando em problemas de engenharia, ou seja, estava pensando no código, que eram pontos que eu não deveria me preocupar e ao invés disso, envolver os próprios engenheiros para tal quando necessário.

Outro ponto foi o envolvimento com os/as designers nas etapas de estudo. Inclusive foi como product manager que eu entendi tudo o que eles fazem e como são importantes para um produto: designers são fundamentais desde o entendimento do problema até a proposta de soluções. Porém, dentre essas situações o maior desafio foi mudar a forma de pensar para “Qual é o problema que precisamos resolver?”. Sim, isso pode parecer muito simples, mas acredite, entender o problema é um dos principais desafios de um product manager. É muito comum as pessoas (clientes, parceiros, CSMs, etc) lhe trazer uma solução pronta para resolver uma dor deles, mas na maioria das vezes pode não fazer sentido o que é proposto. Por isso sempre é necessário “dar alguns passos para trás” e entender qual é o problema que a solução proposta deve resolver para então pensar nas próximas etapas.

O que eu aproveitei de conhecimento de experiências passadas?

Caso você transicione para o cargo de product manager, será muito difícil não aproveitar algum conhecimento que tenha desenvolvido numa profissão anterior. No meu caso, o background técnico que tive (suporte ao produto, desenvolvedor PL/SQL e analista de business intelligence) foi crucial para meu rampeamento na tribo de plataforma, que fui direcionado (entenda uma tribo como um conjunto de times).

Os produtos que desenvolvemos em plataforma servem como serviço para outros produtos, geralmente utilizados através de uma API e não costumam ser visíveis o usuário final. Dado esse contexto, o conhecimento de engenharia e arquitetura de software que eu já possuía me auxiliou muito para imergir e entender o que os times faziam.

Uma coisa muito comum na vida de um product manager são reuniões. Na tribo de plataforma a maioria dos nossos clientes são engenheiros, isso não me impediu de conduzir a maioria das reuniões sozinho, assim como entender os problemas reportados por eles. Passei por uma situação bem particular num dos times que atuei, onde nós precisávamos construir um dashboard para acompanhar alguns indicadores mensais, esse foi o momento perfeito para utilizar meu conhecimento em SQL adquirido quando fui analista de business intelligence. Em outras palavras, eu conduzi o trabalho de idealização dos dashboards praticamente sozinho, inclusive me tornei referência até mesmo para os engenheiros quando era necessário entender algum dado mais precisamente.

Saindo um pouco do contexto técnico, em todas as profissões que passei eu sempre precisei fazer muito alinhamento com demais áreas e reuniões com clientes, isso me ajudou a ter familiaridade em conversar com as pessoas e de como me comportar em reuniões, como por exemplo, levar questionamentos para as pessoas com quem ia conversar para conseguir ter um objetivo claro para a conversa, dessa forma eu já conseguia conduzir reuniões minimamente simples e sair com algum propósito definido.

Como vocês podem ver, o que vai ser aproveitado é muito relativo e irá variar de profissional para profissional, para mim por exemplo, o contexto técnico e o fato de interagir bastante com outras áreas em minhas profissões passadas me ajudaram muito, consegui aproveitar até mesmo meu conhecimento em SQL para fazer dashboards para meu time, ou seja, como product manager você poderá explorar muitos conhecimentos diferentes.

Que erro eu cometi e o que eu aprendi com ele?

O meu background técnico foi uma faca de dois gumes em meu rampeamento. Foi crucial, mas não impediu que eu cometesse alguns deslizes. Independente do perfil de um product manager ser técnico, é importante ele saber que ele não é um engenheiro e saber dos seus limites em reuniões, tomada de decisão, estudos, etc.

Existem diversos posts falando sobre esse assunto e um dos meus preferidos é o do Wyatt Jenkins, onde ele comenta sobre como transicionar para um platform product manager (ou technical product manager, como é chamado em algumas empresas, que basicamente são product managers com um viés mais técnico, como é o meu caso). Como já dito, reuniões com demais times e áreas são corriqueiras no dia-a-dia de um product manager. O erro que cometi por várias vezes e demorei a perceber, era que eu não envolvia todas as pessoas necessárias em minhas reuniões, fazendo com que muitas delas fossem improdutivas.

Por exemplo, numa determinada situação eu precisava alinhar o desenvolvimento de uma feature com um gerente de engenharia de um outro time, foi muito difícil fazer o projeto iniciar pois as discussões acabavam saindo do escopo estratégico e iam para questões de engenharia, como consequência, eu sempre tinha uma série de pontos que precisava validar com os engenheiros do meu time. Se, ao invés disso, eu tivesse levado algum engenheiro do meu time para participar, tudo teria sido resolvido antes.

O que eu aprendi com isso? Envolva as pessoas necessárias para dar o suporte em suas reuniões. Dependendo do projeto, quando é algo muito técnico, que envolve muitas regras comerciais ou leis, sempre tenha com você alguém para lhe dar o apoio necessário e fazer a reunião fluir de forma objetiva. Você não precisa se preocupar em saber todas as respostas nesse tipo de situação, pois o papel do product manager é muito mais importante em fazer o produto acontecer, mantendo alinhamento e objetividade do que saber de todos os detalhes técnicos minuciosos.

Como está o momento atual?

Apesar de um ano completado, sinto que foi só a ponta do iceberg. Recentemente passei por uma troca de time e muitas coisas mudaram, pois são frentes bem diferentes e as responsabilidades são igualmente diferentes, já vejo vários novos desafios e uma rotina completamente nova do que a que eu tinha até então. Meu primeiro ano foi muito reativo, tive muita sorte de trabalhar em conjunto com pessoas incríveis que me ajudaram muito, daqui para frente sigo essa jornada e espero ter muitas outras experiências para compartilhar.

Enfim, tudo isso tem me empolgado muito. Ser product manager para mim tem sido muito desafiador, pois como é uma profissão que não tem uma receita de bolo a ser seguida, exige muito do bom senso de quem está desempenhando esse papel. Dar um norte para o time, mantê-los focados no que é o certo, no que faz sentido para a companhia não é uma tarefa fácil. Se por um acaso você está pensando em se aventurar por esse caminho espero que esse post tenha lhe dado um pouco de clareza sobre possíveis desafios que você pode ter, até a próxima! =)