PM Forge · jornada hands-on para Staff/Principal PM
Voltar para Áreas
TPMFormação · Technical PM · Technical PM Formação · Technical PM ≈ 5 minpasso 1/5

Technical PM: quando o cliente é o desenvolvedor

Produto técnico: APIs, plataforma e trade-offs de arquitetura.

🎯 Seu palpite antes da lição

Errar aqui não custa nada — e ajuda a fixar o conteúdo. +5 XP por registrar.

✍️ Escreva seu próprio TL;DR

Em 1 frase, o que você acha que essa lição vai te ensinar? Tentar gera memória mais forte do que ler. +3 XP.

Não tem certo nem errado — escreva seu palpite.

🎬 A cena

Carol assumiu a plataforma da Aurora achando que precisaria codar tudo. Em uma semana entendeu: seu trabalho era entender os trade-offs técnicos o suficiente para decidir — e traduzir entre negócio e engenharia sem nenhum dos dois se perder.

Produto onde o usuário escreve código

O Technical cuida de produtos cujo cliente é técnico: APIs, SDKs, plataformas internas, ferramentas de dev. O valor aqui é Developer Experience (DX): o quão fácil é integrar, entender e confiar no seu produto.

O que muda no seu trabalho

  • API é produto. — Versionamento, contratos estáveis, documentação e exemplos importam tanto quanto features.
  • Trade-offs técnicos viram decisões de produto. — Build vs buy, monolito vs serviço, consistência vs latência — você não decide sozinho, mas precisa entender pra mediar.
  • Métricas diferentes. — Adoção de API, tempo até a primeira chamada bem-sucedida, latência, uptime.
Armadilha
Armadilha: achar que precisa ser o melhor engenheiro da sala. Você precisa entender o suficiente para decidir e traduzir — não para escrever o código.

Como falar com engenharia

Traga problema e contexto, não solução pronta. Pergunte o trade-off ('o que ganhamos e perdemos com cada opção?'). Documente a decisão (um RFC/design doc) para que seja inspecionável.

Na prática
Na prática: pegue uma capacidade técnica do seu produto e escreva o trade-off de duas abordagens em uma frase cada. Decidir com trade-off explícito é o trabalho.