Tratei meu portfólio como produto: PRD, North Star e LGPD

Um portfólio de Product Owner tem um problema curioso: ele precisa provar que eu sei conduzir produtos, mas costuma ser feito como um currículo bonito, sem nenhuma das práticas que eu defendo.

Então decidi fazer o contrário: tratar este site como um produto, com problema definido, público, métricas, roadmap e registro de decisões. Este texto conta como foi.

Começando pelo problema, não pela tela

Currículo e LinkedIn mostram cargos, empresas e ferramentas. Mas quem avalia um PO quer saber outra coisa: ele entende o problema antes de propor solução? Como decide quando há trade-off? Mede resultado?

Como minha experiência formal em produto começou em 2024, depois de anos em compras, esse problema é ainda maior para mim. A qualidade do raciocínio precisa estar visível. Por isso o centro do site são os estudos de caso, e não a lista de experiências.

Para quem é

Defini quatro públicos: recrutadores, líderes de produto, clientes em potencial e a comunidade de produto. A persona principal é o líder de produto que vai me contratar, porque é quem mais pesa na decisão e quem os cases foram desenhados para convencer.

Isso guiou escolhas concretas. Os estudos de caso seguem um template fixo (contexto, papel, restrições, discovery, decisões, entrega, resultados e aprendizados) e têm um bloco próprio para decisões, com alternativas, critérios, escolha e trade-off. É a parte que um líder de produto mais quer ver, e a que os portfólios costumam esconder.

A North Star

Pageview mede alcance, não valor. O site existe para gerar conversas de trabalho, então a métrica principal é contatos qualificados por mês: pessoas que leram ao menos um estudo de caso e depois clicaram para o meu LinkedIn ou GitHub.

Ainda não instrumentei esses eventos de conversão. Está no roadmap, e assumir isso faz parte de tratar o site como produto: a métrica foi definida antes da medição existir.

Decisões e trade-offs

Algumas decisões que registrei:

Decisão

Onde guardar o conteúdo?

Alternativas consideradas

• Um CMS headless, como o Directus que uso no trabalho.
• Notion como fonte de conteúdo.
• Arquivos MDX no próprio repositório.

Critérios

Um único autor, publicação esporádica, custo zero e controle total do formato, incluindo componentes como este bloco de decisão.

Escolha

MDX no repositório, lido no build. Todo conteúdo nasce como rascunho e só vai ao ar quando eu mudo o status para publicado.

Trade-off

Publicar exige Git e um deploy. Em troca, tenho histórico de versões, revisão antes de publicar e nenhuma dependência externa.

Decisão

Como medir sem desrespeitar a privacidade?

Alternativas consideradas

• Manter o Google Analytics rodando para todos, sem aviso.
• Carregar o Google Analytics só depois que o visitante aceitar os cookies.

Critérios

Adequação à LGPD e coerência com o princípio de transparência do site.

Escolha

O Google Analytics só carrega depois do "Aceitar". "Aceitar" e "Rejeitar" têm o mesmo peso no aviso, e a escolha pode ser mudada a qualquer momento. A política de privacidade explica o que é coletado e por quê.

Trade-off

Perco os dados de quem rejeita ou ignora o aviso. Meus números ficam menores, mas confiáveis no que importa: tendências e proporções.

Também decidi ter o site em português e inglês, com o português como padrão, e indicar quando um cliente é confidencial em vez de inventar números que não posso divulgar.

Construído com agentes de IA

Boa parte do código e da documentação foi feita com agentes de IA, que eu orientei e revisei. Isso permitiu algo que eu não faria sozinho no mesmo tempo: em paralelo, um agente cuidava dos testes automatizados e do CI enquanto eu trabalhava no aviso de cookies.

O papel de PO não diminuiu, mudou de lugar. Em vez de escrever cada linha, passei a definir o problema, escolher entre alternativas e revisar o resultado. Por isso toda página tem uma nota dizendo que o site foi feito com apoio de IA e que o conteúdo é revisado por mim.

O que vem a seguir

O roadmap público deste site tem, entre outros itens:

• instrumentar os eventos de conversão para medir a North Star de verdade;
• um terceiro estudo de caso, sobre modernização de sistemas e ferramentas para desenvolvedores;
• um contato direto no fim de cada case, que é o momento de maior convencimento.