Como é mesmo a transição, o que transfere, o que não transfere, e porque construir algo com as próprias mãos é a única prova honesta.
Transição de CarreiraGestão de ProdutoAnálise FinanceiraPessoal
8 min de leitura
Há uma versão deste artigo que lista dez competências transferíveis, te tranquiliza com "os analistas dão ótimos PMs" e termina com um call to action. Não é este artigo.
A transição de Analista Financeiro para Product Manager é real e alcançável, mas não é uma linha reta, e não é automática. Algumas coisas transferem-se bem. Outras não se transferem de todo. E algumas que pareciam vantagens revelaram-se passivos. O que se segue é o meu relato honesto de como essa mudança se sentiu de facto.
O Ponto de Partida
A armadilha confortável
Durante vários anos trabalhei como Analista Financeiro num grupo multiempresa, a construir os dashboards, os frameworks de KPIs e os modelos financeiros que os executivos usavam para decidir. O trabalho era tecnicamente exigente. Power BI, Python, SQL, consolidações entre entidades numa estrutura de grupo. Poucas pessoas na organização o conseguiam fazer, e isso criava um certo tipo de conforto profissional.
Mas havia uma frustração persistente por baixo disto. Eu estava perto das decisões (por vezes a pessoa mais próxima na sala dos dados que as informavam) sem ter qualquer palavra sobre quais essas decisões eram. Conseguia dizer-te o que os números diziam. Não conseguia dizer-te o que fazer com eles. Não era essa a minha função.
Com o tempo, reparei que andava a fazer um conjunto de perguntas diferente das que a minha função exigia. Não "o que mostra esta métrica?", mas "porque é que estamos a acompanhar esta métrica e não aquela?". Não "o que aconteceu à receita no Q3?", mas "que decisão de produto ou operacional causou isto, e podíamos tê-la previsto?". A função de analista recompensava responder a perguntas. Eu estava cada vez mais interessado em escolher que perguntas fazer.
O sinal de que algo precisa de mudar não é a insatisfação com o trabalho. É perceber que andas consistentemente a fazer perguntas que ficam fora da tua descrição de funções.
O Inventário Honesto
O que se transfere de facto
Nem tudo, mas mais do que se pensa, e parte transfere-se melhor do que a maioria dos candidatos a PM consegue oferecer.
Conforto com raciocínio quantitativo
A maioria dos PMs fala sobre métricas. Os analistas vivem nelas. A diferença importa na prática: saber como uma métrica é construída, o que não capta, e quando está a ser manipulada é uma competência diferente de saber que existe. Essa fluência transfere-se diretamente para a instrumentação de produto, o desenho de testes A/B e a análise de retenção.
Perceber como se tomam decisões executivas
Trabalhar dentro de um grupo multiempresa significava construir relatórios que iam à administração. Aprende-se muito depressa como os stakeholders seniores consomem informação, o que lhes importa, o que saltam, e o que precisam de ver antes de decidir. Esse reconhecimento de padrões é diretamente útil quando escreves um business case ou apresentas um roadmap à liderança.
Decomposição estruturada de problemas
A modelação financeira é, no fundo, partir um sistema complexo nos seus drivers e perceber como se relacionam. Essa estrutura (hipótese, variáveis, efeitos de interação, análise de sensibilidade) mapeia quase diretamente para a resolução de problemas de produto. É um vocabulário diferente, mas o padrão cognitivo é o mesmo.
Tradução multifuncional
Numa estrutura de grupo estás constantemente a traduzir entre unidades de negócio, finanças, operações e gestão, cada uma com enquadramentos diferentes, prioridades diferentes e definições diferentes das mesmas palavras. Isso é 80% do que a gestão de stakeholders em produto é de facto.
A Parte Difícil
O que não se transfere (e me surpreendeu)
As coisas que não se transferiram foram mais difíceis de antecipar, não por serem obscuras, mas porque parecia que deviam funcionar e depois não funcionaram.
Ter razão vs. estar alinhado
Na análise, ter razão chega. Os dados ou suportam a conclusão ou não. Em produto, podes estar analiticamente correto e mesmo assim não mover nada, porque o alinhamento, a confiança e o timing importam tanto como a qualidade do argumento. Isto é genuinamente desconfortável quando estás habituado a que a resposta esteja na folha de cálculo.
Influência sem autoridade
Os analistas produzem outputs sobre os quais outros agem. Os PMs precisam de mudar comportamentos sem autoridade formal, em engenharia, design, vendas, suporte e marketing. As alavancas são completamente diferentes: enquadramento, narrativa, relação, timing. Aprende-se, mas não chega automaticamente com o título.
Empatia com o utilizador vs. com os dados
Eu era bom a ler dados. Ler utilizadores é uma competência diferente. Os números dizem-te o que aconteceu. Os utilizadores dizem-te porquê, mas só se souberes ouvir, o que perguntar, e como separar o que dizem do que realmente precisam. Essa lacuna é real e exige prática deliberada, não só instinto analítico.
Sem entregável claro
O trabalho de analista tem um output tangível: um relatório, um dashboard, um modelo. O ciclo de feedback é rápido e concreto. O trabalho de PM é muitas vezes difuso. Estás a moldar direção, a construir contexto, a remover bloqueios. Podem passar semanas sem um artefacto visível. Se o teu sentido de produtividade está ligado a entregáveis, esta ambiguidade é genuinamente desorientadora no início.
A transição não é adquirir novas competências para substituir as antigas. É aprender em que instintos antigos confiar e quais ignorar, e essa distinção só se torna clara fazendo.
A Prova de Conceito
Construir o TryCareerMatch como ponte
A certa altura, a distância entre querer fazer trabalho de PM e conseguir demonstrar experiência de PM torna-se o problema central. Não consegues a função sem a experiência, e não consegues a experiência sem a função. A única saída que encontrei foi criar a experiência eu próprio.
O TryCareerMatch começou como um problema pessoal. Não encontrava uma ferramenta que mapeasse o meu perfil de competências multifuncional face a funções específicas. Seis semanas depois estava live em trycareermatch.com, usado por pessoas reais a tomar decisões reais de carreira. A coisa toda: discovery, desenho do modelo de dados, decisões de UX, construção, deployment. Sem equipa, sem runway, sem produto existente para modificar.
01
Discovery sem equipa de research
Tive de definir o problema, validar o enquadramento e delimitar a solução sem um researcher, um design sprint ou um backlog. Cada decisão de produto exigia que eu fosse explícito sobre o pressuposto que estava a assumir e porquê, o que é, afinal, a disciplina central da função.
02
O modelo de dados como decisão de produto central
A decisão mais crítica não foi a interface. Foi o motor de scoring de mais de 125 competências e 85 funções por baixo dela. Errá-lo teria tornado irrelevante cada decisão de UX correta. Gastar as primeiras semanas inteiramente no modelo de dados antes de escrever código de UI foi a escolha de maior alavancagem que fiz. Essa sequência veio diretamente dos instintos de modelação financeira.
03
Entregar sem permissão
Não há substituto para a experiência de pôr algo à frente de utilizadores que não o pediram e ver o que fazem de facto. O feedback foi imediato e inequívoco de formas que nenhuma revisão interna de stakeholders conseguiria replicar. Esta parte, entregar, é a única competência que só vem de entregar.
O projeto não demonstrou só que eu conseguia fazer trabalho de PM. Respondeu a uma pergunta mais específica: conseguia fazer as partes do trabalho de PM que não vêm de uma base de analista? A resposta, imperfeita mas credível, foi sim.
Estado Atual
Onde estou agora, e o que diria a quem começa isto
Estou no ponto da transição em que a base de analista deixou de parecer um passivo e começou a parecer uma vantagem, mas só em contextos específicos. Em equipas maduras em dados, onde se espera que as decisões de produto sejam instrumentadas e mensuráveis, a combinação de fluência quantitativa profunda com enquadramento de PM é genuinamente diferenciada. Em equipas que ainda estão a construir essa cultura, é um contributo e não um dado adquirido.
Se estás a fazer uma transição semelhante, três coisas saltam à vista em retrospetiva:
Três coisas que diria a mim próprio no dia um
Constrói algo e entrega-o. Não um protótipo, não um documento de conceito, mas algo live que pessoas reais possam usar. Não tem de ser bom. Tem de ser real.
Sai dos dados e fala com utilizadores mais cedo do que é confortável. Os analistas são treinados para esperar até os dados serem conclusivos. Os utilizadores dão-te sinal antes de os dados serem grandes o suficiente para serem conclusivos.
O instinto quantitativo é valioso, por isso não o abandones. A maioria dos conselhos de PM é escrita para quem precisa de ser empurrado para os dados. Tu começas do outro lado: já confias nos números, agora precisas de aprender a confiar no sinal qualitativo com o mesmo rigor.
A transição não é de "analista" para "PM". É de "pessoa que responde a perguntas sobre o sistema" para "pessoa que decide que perguntas sobre o sistema vale a pena fazer". Essa mudança é sobre âmbito, não competência, e o âmbito é uma escolha.