Posições além de dev: o que mais existe em tech

O que você faz todos os dias: conversa com usuários pra entender o que eles precisam. Olha os dados de uso pra ver o que tá funcionando e o que não tá. Escreve histórias de usuário ou requisitos que viram tarefas pra dev. Prioriza o backlog (o que faz primeiro, o que espera). Quer dizer: decide O QUÊ vai ser feito e POR QUÊ.

Tem uma diferença entre PM e PO que confunde às vezes. PM = estratégia. O que a gente quer conquistar, pra onde a gente vai, qual é o roadmap de 6 meses. PO = execução do backlog. Como essa estratégia vira sprint, como cada requisito fica claro pra dev implementar. Muitas empresas usam os dois interchangeably; outras separa.

Habilidades que você precisa: comunicação (muita), saber trabalhar com dados (nem que seja Excel e SQL básico pra puxar métrica), frameworks de priorização (RICE, ICE ajudam), pensamento crítico. Você precisa entender trade-off: fazer A significa não fazer B.

Como dev consegue virar PM: ex-dev é PM excelente porque entende restrição técnica. Não promete coisa impossível. Respeita o timing. Sabe qual tech faz sentido. Procure por APM (Associate PM) programs em Google, Meta, grandes empresas. Ou simplesmente converse com seu PM atual e diga que tem interesse; muitas vezes tem uma transição interna.

Mercado no Brasil: toda empresa média ou grande tem PM. Startup pequena tem um PM pra cada 2-4 devs. Demanda alta, salário alto, muito mais remoto que antes.

O que você faz: testa software antes de ir pra produção. Procura bugs, anota, documenta. Mas não é só clicar em botão; o QA moderno escreve testes automatizados (Cypress, Playwright, Selenium). Mantém a pipeline de CI/CD checando tudo. Faz teste de carga (k6, Locust, JMeter) pra ver se a aplicação aguenta spike de usuário. Performance testing também cai aqui.

É realmente uma carreira técnica, não é simplezinho. Piramide de teste é conceito fundamental: teste unitário (muitos, rápido), teste de integração (menos, médio), teste end-to-end (poucos, lento). QA entende essa estratégia e sabe onde cada um encaixa.

Habilidades: programação básica (Python ou JavaScript), entender CI/CD pipeline, conhecimento de testes (o que é cobertura, determinismo, flakinness). Poder de criatividade pra quebrar coisas de forma que ninguém esperava.

Como dev consegue virar QA: é uma transição natural pra dev que gosta mais de quebrar do que construir. Muita gente que virou QA descobriu que prefere essa adrenalina de encontrar bug. Pode ser carreira permanente ou stepping stone pra voltar a dev depois. Ambos os caminhos existem.

Mercado: QA é undervalued no Brasil mas a demanda internacional é gigante. Remoto muito mais fácil que dev. Salário bom, carreia estável. Se você gosta de qualidade e rigor, é posição muito interessante.

O que você faz: entender como usuário pensa e se comporta (UX = User Experience). Desenhar interface (UI = User Interface). Prototipar (Figma). Rodar teste de usabilidade pra saber se as pessoas entendem o que você desenhou. Iteração baseada em feedback real.

UX e UI são coisas diferentes que frequentemente se mesclam. UX é pesquisa, fluxo, decisão sobre o que deve aparecer e em qual ordem. UI é visual, cor, tipografia, componentes. Equipes grandes separam; equipes pequenas a mesma pessoa faz os dois.

Habilidades: Figma é obrigatório hoje. Noção de design system (componentes reutilizáveis). Entender pesquisa (como conversar com usuário, que perguntas fazer). Pensamento crítico: por que essa cor, por que esse botão ali e não ali.

Como dev consegue virar designer: frontend dev tem vantagem porque entende limitação técnica. "Bonito demais pra build" não é problema se você entender realidade. A lacuna é em pesquisa de UX e design systems thinking. Se você tem esse interesse, comece a estudar metodologia de UX, faça cursos em design thinking e usability testing.

Mercado: design é escasso no Brasil pra demanda real. Equipes crescem, querem mais qualidade visual. Remoto completamente normal. Salário competitivo.

O que você faz: responde perguntas sobre dados. "Qual foi o faturamento no mês passado?" "Por que as pessoas estão saindo sem comprar?" "Qual feature teve mais uso?" Você escreve SQL (muito SQL), monta dashboard (Power BI, Tableau), executa análise de A/B test, recomenda ação baseada em dado.

Dia a dia: SQL todo dia, exploração de banco de dados, criação de visualização, comunicação de achado (essa parte é importante, nem todo analista consegue). Você é tradutor entre negócio e dados.

Diferente de Data Scientist: analista responde "o que aconteceu e por quê". Scientist constrói modelo preditivo ("o que vai acontecer"). Tem overlap, mas são carreiras diferentes.

Habilidades: SQL (inegociável), Excel/Google Sheets, ferramenta de visualização (Power BI, Tableau, Looker), Python ou R pra coisas mais pesadas. Pensamento estatístico básico (o que é amostra válida, o que é correlação vs causalidade).

Como dev consegue virar analyst: aptidão técnica já tem. O que falta é SQL proficiency e business context reading. Comece a estudar SQL sério (não just queries simples), leia relatório de empresa (earnings call), entenda métricas de produto (DAU, retention, churn).

Mercado no Brasil: um dos crescimentos mais rápidos. Fintech, e-commerce, marketplace, todos querem analista. Oferta é menor que demanda. Muito remoto, salário em alta.

O que você faz: comunica sua empresa pra comunidade de dev. Escreve documentação (muito). Dá palestra em conferência. Constrói sample apps e tutoriais pra mostrar como usar o produto. Mantém comunidade no Discord ou similar. Coleta feedback de dev pra trazer pro produto team.

É mais sobre empatia e comunicação que sobre código, mas você precisa ter sido dev pra ter credibilidade. Você é evangelista do produto.

Situação realista: DevRel existe principalmente em empresa cuja produto É uma ferramenta pra dev (API, SDK, cloud platform, lib open source). SaaS B2B comum, e-commerce, marketplace, não tem DevRel. Se a sua empresa tem 50 devs mas nenhum dev externo usando seu produto, devrel não faz falta.

Habilidades: excelente comunicação escrita, public speaking, empatia pra com dev (você foi um), criatividade pra criar conteúdo interessante.

Mercado: maioria dos DevRel no Brasil trabalha pra empresa internacional com sede aqui. Stripe, Twilio, cloud providers. Mas tá crescendo. Muito remoto, salário internacional.

O que você faz: cuida de pessoas. 1 a 1 com cada pessoa no seu time (conversa individual, feedback, carreira). Tira bloqueador pra time conseguir entregar. Contrata. Escalona conflito. Planeja headcount e orçamento. Quase não escreve código.

Nota importante: EM não é tech lead. Tech lead ainda programa muito e é referência técnica. EM é manager, trabalha com gente.

Como dev chega aqui: normalmente depois de 5 a 8 anos de experiência. Você sente que problemas de gente te interessam mais que problemas técnicos. Ou informalmente você já tá fazendo isso (ajudando juniors, facilitando alinhamento). Às vezes você vira informal tech lead e depois faz a transição.

Ponto real: muita gente tenta EM, descobre que gosta mais de código, e volta pra IC (Individual Contributor). Não é fracasso. Muitos ciclos de carreira acontecem assim. Mesmo conhecer gestão é útil depois.

Mercado: toda empresa com mais de 20 devs tem EM. Salário alto, responsabilidade alta. O desafio não é técnico, é humano.

Não tem checklist pra isso. Mas você pode escutar a si mesmo: qual tipo de problema você gosta mais de resolver? Qual tipo de dia saiu do trabalho pensando "puxa, que dia bom"?

Se você fica interessado em por que fazer algo em vez de como fazer, pode ser PM. Se você fica frustrado que ninguém testou direito, talvez QA. Se você quer desenhar antes de implementar, pode ser design. Se você quer conversar com usuário em vez de escrever código, pode ser PM ou DevRel ou UX.

Muitos de nós vivemos isso: você tá programando e pensa "opa, isso não deveria ser assim". Depois você tá em meeting e pensa "opa, ninguém entendeu essa métrica direito". Depois você tá na interface e pensa "opa, isso tá feio demais e confuso". Essas intuições importam.

Nenhuma dessas escolhas é fracasso. Desenvolvimento de carreira é descoberta. Muita gente faz híbrido: PM que prototipa em código, QA que código automação test full-time, dev que virou EM e ainda mentora tech.

O truque é conhecer você mesmo e ter coragem de explorar.