Todo mundo fala que você precisa de um portfólio para conseguir a primeira vaga de PM. Poucos explicam o que vai nesse portfólio quando você nunca foi PM antes.

Esse artigo explica. Sem atalho falso e sem "você já tem mais do que imagina" sem explicar o que fazer com isso.

O que um portfólio de PM não é

Não é um currículo em outro formato. Não é uma lista de projetos que você participou com uma descrição do que você fez. Não é uma apresentação bonita com screenshots de produtos que você usa e acha que poderia melhorar.

O que diferencia um portfólio de PM de um portfólio de outras áreas

Um portfólio de design mostra o trabalho visual. Um portfólio de engenharia mostra código. Um portfólio de product manager mostra raciocínio. Isso é tudo. Se você ainda não tem clareza sobre o que um PM faz no dia a dia, vale ler antes o artigo sobre o que faz um product manager na prática.

Especificamente: você consegue raciocinar sobre problemas com estrutura? Você prioriza com critério explícito? Você entende o usuário o suficiente para definir o problema certo? Você comunica decisões com clareza?

Isso significa que você não precisa de vagas de PM no histórico para ter um portfólio relevante. Você precisa de casos que mostrem esse raciocínio — seja de onde vier.

De onde tirar os casos

São quatro fontes que funcionam na prática.

Experiências do trabalho atual

Mesmo que você seja analista de dados, designer ou desenvolvedor, provavelmente há momentos em que você tomou decisões ou participou de discussões que tocaram em produto. Um processo de priorização que você influenciou. Uma funcionalidade que você questionou antes de ser construída. Uma métrica que você propôs acompanhar depois de perceber um padrão nos dados.

Esses momentos contam. O que você precisa fazer é documentá-los com a estrutura de produto: qual era o problema, como você chegou nessa definição, quais alternativas foram consideradas, o que foi decidido e por quê.

Projetos paralelos

Você pode criar um produto do zero, mesmo que simples, e documentar o processo. Não precisa ser um negócio com usuários reais. Um app simples, uma ferramenta interna, uma landing page para testar uma hipótese de mercado. O que importa é o processo de decisão documentado — não a qualidade do produto final.

Um projeto paralelo bem documentado mostra que você consegue definir um problema, explorar soluções, tomar decisões com critério e articular por que fez as escolhas que fez. Isso é o portfólio.

Cases hipotéticos

Escolha um produto que você usa e conhece bem e resolva um problema real dele. "Se eu fosse PM do Nubank, como abordaria a baixa adoção da função de investimentos entre usuários com renda acima de R$5 mil?" É uma pergunta que você pode responder com pesquisa real, análise de dados públicos e raciocínio estruturado.

Cases hipotéticos têm má reputação injusta. Um case hipotético bem feito — com problema bem definido, alternativas exploradas honestamente e uma decisão justificada — é mais valioso do que um relato vago de uma experiência real onde você participou mas não tomou decisões.

Contribuições voluntárias

ONGs com produto digital, projetos open source que precisam de visão de produto, hackathons, empresas júnior. Qualquer contexto onde você possa assumir um papel de produto com responsabilidade real, mesmo que temporária, gera material para o portfólio.

Como estruturar um case de produto

O case precisa responder quatro perguntas: Qual é o problema? Como você chegou nessa definição do problema? Quais foram as opções consideradas? Por que essa solução e não outra?

O erro mais comum nos portfólios fracos

A maioria dos portfólios fracos pula direto para a solução. Os fortes dedicam mais espaço à definição do problema do que à solução em si. É na definição do problema que o raciocínio de PM aparece — e é onde os recrutadores passam mais tempo lendo.

Um case que abre com "o problema era que os usuários abandonavam o checkout" já está no modo solução. Um case que abre com "os dados mostravam abandono de 67% no checkout, mas quando conversei com cinco usuários percebi que o problema real era falta de confiança na plataforma, não complexidade do processo" está mostrando raciocínio de produto.

A estrutura que funciona

Contexto: qual produto, qual momento, qual métrica ou problema estava em jogo. Uma a dois parágrafos.

Problema definido: qual era o problema real, como você descobriu que era esse o problema, o que os dados ou as conversas com usuários mostraram. Essa é a seção mais importante.

Alternativas consideradas: quais soluções foram pensadas e por que algumas foram descartadas. Não precisa ser exaustivo — duas ou três alternativas com raciocínio claro são suficientes.

Decisão e critério: o que foi escolhido e com base em qual raciocínio. Seja explícito sobre as trocas: o que você abriu mão ao fazer essa escolha?

Resultado ou hipótese de resultado: se foi implementado, o que aconteceu. Se foi hipotético, qual resultado você esperaria e como mediria.

Quantos cases você precisa

Um case bem feito é melhor do que cinco fracos. Para começar, dois cases sólidos já são suficientes para uma candidatura séria.

Qual tipo de case ter

Idealmente, os dois cases mostram ângulos diferentes do raciocínio de produto. Um que mostra como você define e entende problemas (discovery). Outro que mostra como você prioriza quando os recursos são limitados (priorização com critério explícito).

Se você tem tempo para um terceiro, escolha um que mostre capacidade de trabalhar com dados. Não precisa ser análise avançada. "Olhei para esta métrica, percebi essa anomalia, hipotetizei essa causa, e propus esse experimento para verificar" já é suficiente para demonstrar que você lê dados com raciocínio de produto.

O formato do portfólio

Notion funciona. Google Slides funciona. Um site simples funciona. O que não funciona é um PDF de 40 páginas que nenhum recrutador vai ler do começo ao fim.

Cada case deve caber em cinco a oito minutos de leitura. Se for mais longo do que isso, revise. A objetividade é parte do que está sendo avaliado — PM que não consegue ser direto num portfólio provavelmente não vai conseguir ser direto num PRD.

A página de apresentação

Inclua uma página de apresentação com contexto sobre quem você é e o que você quer. Não é lugar para objetivos vagos ("busco uma oportunidade de crescer na área de produto"). Seja direto: "Analista de dados com quatro anos em fintechs, buscando primeiro papel como PM. Tenho dois cases aqui que mostram como penso sobre problemas de produto com base em dados."

Objetivo. Verificável. Mostra que você conhece sua própria proposta de valor.

Antes de começar a candidar, vale conhecer também os erros mais comuns que PMs iniciantes cometem logo no começo da carreira — muitos deles aparecem ainda na fase de portfólio e nas primeiras entrevistas. O artigo sobre erros comuns de PMs iniciantes ajuda a identificá-los antes de cometê-los.

Para entender como apresentar seu background de forma que faça sentido para recrutadores de produto, o minicurso Transição para Produto tem um módulo inteiro sobre como reescrever sua história — independente de onde você vem.