Forward Deployed Product Designer: o que é e como estou me preparando

O nome que eu sempre esquecia

A Palantir criou, ainda em meados dos anos 2000, um cargo chamado Forward Deployed Engineer, o FDE. É o engenheiro que não fica no escritório esperando briefing: senta com o cliente, observa o fluxo real, constrói a solução com dado de verdade e fica até ela rodar. Vinte anos depois a OpenAI, a Anthropic e boa parte das startups de IA copiaram o modelo.

Eu demorei para guardar o nome, mas o trabalho eu já faço há tempo. O meu processo é esse: conversa, protótipo na mão, IA na construção, teste com gente de verdade, ajuste. Odeio briefing frio e cascata. O case do sistema de trabalho com IA mostra isso em detalhe.

O que falta não é mudar de jeito. É fechar algumas lacunas para fazer esse trabalho com produto de IA, que é onde o mercado está indo. Este texto é o mapa. Ele vai sendo atualizado conforme eu estudo, com data no topo e um diário no fim.

O que a função exige

Dividi em seis competências. Fui honesto sobre onde estou em cada uma.

Descoberta em campo. Observar, mapear o fluxo, achar o problema real. É o meu ponto forte. São mais de 15 anos fazendo isso em design, UX e acessibilidade.

Protótipo funcionando. Next.js, Swift, Claude Code, deploy. Também tenho. O cliente vê o site navegando antes de ele existir, não uma imagem parada.

IA como material de design. Saber avaliar a saída do modelo com método, desenhar para incerteza, decidir onde o humano entra. Estou começando. Tenho a prática, falta o vocabulário e o rigor.

Dados e backend. Ler o dado do cliente, banco, agente com ferramentas. É a minha lacuna maior. Sei fazer site estático e app; não sei ainda conectar um agente ao banco de alguém.

Produção e medição. Colocar no ar eu faço. Medir o que está no ar, com amostra e ciclo de correção, eu não faço. Essa é a lacuna que mais se confunde com a anterior.

Posicionamento e venda. Case, preço por resultado, publicar. É o passo que eu mais travo. Por isso este texto existe.

Tem uma sétima coisa que atravessa todas: acessibilidade. Quase ninguém que trabalha com produto de IA sabe testar com leitor de tela ou medir contraste. Eu sei, e sou daltônico, então não confio no que vejo. Isso vira diferencial, não detalhe.

O roadmap

Uma etapa por vez. Cada uma fecha com uma prova concreta. Sem prova, a etapa não fecha. Quando fechar, o diário no fim do texto registra.

Etapa 0, até 15 de novembro de 2026: base. Ler as 18 primeiras perguntas do FAQ de evals de Hamel Husain e Shreya Shankar. Instalar o plugin de evals no Claude Code. Rodar uma análise de erros num fluxo real meu. Prova: uma planilha com 30 saídas anotadas em passa ou não passa, e a lista de tipos de erro que apareceu. Situação: em andamento.

Etapa 1, novembro e dezembro de 2026: IA como material de design. Desenhar para incerteza: quando o sistema deve dizer "não sei", como mostrar a fonte e o passo intermediário, onde a pessoa revisa. Tratar o prompt como especificação, com versão e teste. Construir um primeiro agente que fecha um ciclo de verdade, com ferramentas, guardas, memória e trilha de auditoria visível. Prova: uma interface de anotação funcionando para um fluxo de cliente, e um texto aqui contando o que a análise revelou. Situação: não começou.

Etapa 2, janeiro e fevereiro de 2027: dados e backend. SQL básico e um banco de verdade. Construir um agente com ferramentas que lê dado real de um cliente. A turma de evals começa em 30 de janeiro; entro se a etapa 0 tiver deixado gosto. Prova: uma ferramenta interna para um cliente fixo que consulta o dado dele e responde. Situação: não começou.

Etapa 3, março e abril de 2027: produção e medição. Registro de cada passo do sistema no ar. Amostra de produção a cada duas a quatro semanas, análise de erros, ajuste, repete. Prova: um fluxo de cliente rodando com esse ciclo por pelo menos duas rodadas. Situação: não começou.

Etapa 4, maio e junho de 2027: posicionamento. Case no portfólio com o nome na porta, em português e inglês. Pelo menos uma proposta precificada por resultado, não por hora. Prova: um cliente novo, ou a renovação de um fixo, fechado nesse modelo. Situação: não começou.

As regras que valem o tempo todo

• Encontro mensal com amigos que também trabalham com IA. Cada um leva um experimento rodando e mostra na tela. Sem demo não conta. A conversa já existia; a regra é nova.
• Um texto público por mês. Curto. O experimento do mês vira post. É o passo que eu pulo, então deixa de ser vontade e vira regra.
• Formato curto e grátis entre as etapas. Os cursos da Anthropic e os cursos curtos da DeepLearning.AI, de uma a duas horas. Nada que vire dívida.
• O que eu cortei da lista: MBA, pós-graduação em UX, mestrado e bootcamp genérico de "IA para designers". Dois anos e uma dissertação não cabem em quem vai fundo, não largo.

Por que evals é a porta de entrada

De tudo que li, o que mais pareceu com o meu trabalho foi a análise de erros que os autores do FAQ descrevem. Pega 20 a 50 saídas reais, lê uma por uma, anota o que deu errado em texto livre, agrupa em categorias, repete até parar de aparecer categoria nova.

Isso é o mapa de afinidades da pesquisa de UX, aplicado ao que a máquina devolve. Nota é passa ou não passa, nunca de 1 a 5. E só se escreve teste para erro que já apareceu, não para erro imaginado.

Tem uma pergunta no FAQ que é problema de design puro: como tornar a saída de IA mais fácil de avaliar por uma pessoa. A resposta deles é expor o passo intermediário e a fonte, e cuidar da interface de quem revisa. É exatamente onde um designer entra num time de IA, e quase ninguém está cobrindo.

O que o pessoal que inventou o modelo diz

Bob McGrew foi executivo da Palantir e depois diretor de pesquisa da OpenAI. Num episódio do podcast Lightcone, da Y Combinator, ele conta como o modelo nasceu e por que as startups de IA estão todas adotando. Anotei o que serve para quem é um só, sem time.

Nasceu de uma demo ruim. A Palantir queria fazer software para espiões, e não conhecia nenhum. Levaram uma demo, ouviram "isso não tem nada a ver com o que fazemos", perguntaram "e como você queria?", e anotaram tudo. O produto saiu dessa anotação. É o oposto de briefing frio.

Dois papéis. A Palantir separava o time em dois. O "Echo" é quem conhece o domínio por dentro e é rebelde o bastante para achar que o jeito atual não serve. O "Delta" é quem prototipa rápido e aguenta a dor, não o artesão que quer a abstração perfeita. Como freelancer, eu sou os dois na mesma pessoa: escuto o cliente e construo. A vantagem é que não há passagem de bastão. O risco é não ter quem puxe o freio.

Estrada de cascalho e rodovia. O FDE abre uma estrada de cascalho até onde o produto precisa chegar, para um cliente. O time de produto olha aquilo e pavimenta a versão que serve aos próximos dez. No meu caso, a estrada de cascalho é cada projeto de cliente. A rodovia é o que eu empacoto depois: o kit de papel, o design system, o script de recorte de retratos. Quem não pavimenta vira consultoria e recomeça do zero toda vez.

Vende-se resultado, não instalação. A frase dele: você não está vendendo software, está vendendo que resolveu um problema. O contrato começa pequeno e cresce conforme o resultado aparece. No começo o próprio FDE assume o risco, porque o cliente não acredita que vai funcionar. É a base da etapa 4 do roadmap, preço por resultado.

Tem que ser um dos cinco problemas do dono. Se o que você resolve não está entre as cinco prioridades de quem manda, ninguém vai ter energia para atravessar a mudança. E o erro mais fácil é construir o que o cliente pede, que costuma ser o problema cômodo, em vez do que de fato muda o negócio dele.

A demo cria desejo. A Palantir tinha uma demo só, e toda função nova precisava caber nela e fazer sentido do ponto de vista de quem usa. Uma demo boa é aquela em que o cliente quer pegar e levar para a vida dele. É isso que o protótipo navegável faz, e o motivo de eu não entregar imagem parada.

Por que agora. Agente de IA não tem produto estabelecido para substituir. Ninguém sabe ainda o que esse mercado é, então a descoberta só acontece de dentro da empresa. Na definição dele, o modelo é "fazer coisas que não escalam, em escala". E a oportunidade dos próximos anos está na distância entre o que os modelos já conseguem e o que as pessoas conseguem adotar. Esse vão é trabalho de design.

O caminho prático: auditoria, eval, implantação

Num segundo vídeo, o Greg Isenberg recebe Vas, da Varick Agents, que faz exatamente esse trabalho em grandes empresas, e o modelo aparece em forma de manual. A premissa dele: toda empresa hoje compra a mesma inteligência, então a vantagem mudou para a implantação. Onde, como e por que usar.

O slide que eu guardei diz que a função exige dois tipos de julgamento que raramente moram na mesma pessoa. Do lado comercial: fluxo de trabalho, custo, incentivos, risco, adoção, valor para o negócio. Do lado técnico: modelos, sistemas, APIs, dados, código, confiabilidade. O FDE transforma entendimento do negócio em software funcionando. Não é a média dos dois lados; é o melhor dos dois. Na minha tabela lá em cima, o lado comercial é onde eu já estou e o lado técnico é onde o roadmap mira.

Ele resume o trabalho em três partes, nessa ordem: auditoria, que acha o problema certo e mapeia a realidade; evals, que provam que o sistema se comporta; implantação, que faz funcionar dentro do negócio. Cada etapa conquista o direito à seguinte. Não se constrói antes de auditar, não se implanta antes de medir.

Três coisas mais ficaram comigo.

O trabalho de verdade nunca é o documentado. "Chega um e-mail" parece um gatilho limpo. Na prática chegam e-mails de quarenta remetentes, cada um num formato, metade é exceção, e a regra de como tratar está na cabeça de uma pessoa só. Quem não senta ao lado dessa pessoa constrói para um processo que não existe. É por isso que a maior parte do tempo do FDE vai em observar, não em programar.

Decidir onde a inteligência entra, e onde não entra. Num fluxo de dez passos, talvez só três precisem de julgamento. O resto é regra, chamada de API, planilha. O desenho bom é maioria determinística, modelo só nos pontos de julgamento, e uma pessoa aprovando antes de qualquer coisa irreversível. A era de "joga IA em tudo" é a que produziu os 95% de pilotos que falham.

O fluxo que ele desenha tem quatro caixas em linha. Software determinístico faz entrada, validação e roteamento. O agente age: reúne, decide, rascunha. Uma pessoa aprova, com uma decisão clara só. O registro é atualizado no sistema que o cliente já usa, sem redigitar. Acima do agente, uma caixa tracejada: exceção escala para uma pessoa. Embaixo de tudo, uma linha: cada passo registrado como evidência. A frase de fechamento resume a função: o FDE entende o fluxo atual, desenha o fluxo nativo de IA e constrói o sistema que liga os dois. As duas primeiras partes são trabalho de designer.

Auditoria é a porta de entrada, e dá para chamar de sprint. A empresa dele não começa nenhum projeto sem uma auditoria paga: mapear os fluxos de um setor, as exceções, o que vale automatizar e o que não vale, e a matriz de retorno. Os clientes dizem que só a auditoria valeu dez vezes o que pagaram. O Greg conta que a agência dele vendia a mesma coisa e a palavra "auditoria" assustava, então rebatizaram de sprint. Para mim isso fecha um círculo: o design sprint que eu já sei conduzir é a auditoria de IA com outro nome. É o produto de entrada do Forward Deployed Product Designer.

O slide da auditoria dele tem três passos. Coletar contexto: entrevistas, e-mails, planilhas, procedimentos escritos, sistemas, aprovações, caminhos de exceção. Rastrear os achados: gargalos, trabalho repetitivo, pontos de julgamento, sistemas obrigatórios, modos de falha, automação que vale a pena. E produzir a entrega, que é um mapa operacional só, com cinco partes:

• Fluxo atual: como o trabalho acontece hoje, de verdade.
• Fluxo futuro: o mesmo trabalho, reconstruído em volta da IA.
• Caso escolhido: um fluxo, escolhido pelo valor.
• Limites: o que o sistema pode e o que não pode fazer.
• Valor esperado: horas, custo e erros, em número.

Esse mapa é um entregável de design. Eu já faço quatro dessas cinco partes em todo projeto; a quinta, o valor em número, é a que eu passo a fazer.

Evals transformam o imprevisível em evidência. Cada caso de teste é julgado em quatro perguntas: pegou o dado certo, cumpriu os passos obrigatórios, bate com o que um especialista faria, é seguro agir. O caso normal passa nas quatro. O caso de borda pode pegar o dado certo e ainda assim errar no julgamento. Informação incompleta, pedido ambíguo e ação de alto risco não tentam passar: vão para uma pessoa, por regra. O relatório que sai disso é curto: quantas execuções passaram de quantas, as categorias de falha com contagem (dado faltando, registro errado), e três regras de operação. Confiança abaixo de um limiar escala para humano. Ação de alto risco sempre chega a uma pessoa. E o estado de prontidão do sistema, que começa como piloto com revisão humana em toda ação. Isso é o que eu quero apresentar para cliente no lugar de "ficou bom".

Mais três notas rápidas dele que entram no roadmap:

• Só três medidas importam para o dono do negócio: receita que subiu, risco que caiu, custo que caiu. Todo experimento meu tem que responder a uma das três.
• Construir em cima do que o cliente já usa, nunca forçar migração. Quem gastou dois anos trocando de sistema não vai trocar de novo por sua causa. O diagrama de implantação dele é simples: o sistema em produção recebe o dado que já existe, as APIs internas e as permissões de quem usa, e devolve revisão humana, registros, alertas e um botão de voltar atrás. Primeiro roda numa caixa de areia dentro da infraestrutura do cliente. Depois ganha autonomia aos poucos, começando pela menor ação útil, e só recebe mais autoridade quando prova que é confiável. A frase dele: implantação é quando o software passa a carregar responsabilidade operacional.
• Se o cliente não consegue ver o que o agente fez, não confia. Trilha de auditoria é problema de interface, não só de log. De novo: design.

Ele fecha com um plano de 30 dias para quem quer fazer o trabalho antes de ter o título. A regra do plano é que cada semana acrescenta capacidade ao mesmo sistema, nunca começa outro. Guardei os slides e traduzi dia a dia, porque é a espinha das etapas 1 e 2 do meu roadmap.

O plano de 30 dias, dia a dia

Semana 1: um agente que fecha um ciclo de verdade. No dia 7, o agente completa um fluxo útil e mostra cada passo que deu.

1. Laço do agente. Prompt, modelo, resposta, próximo passo, até a tarefa terminar ou bater o limite de passos.
2. Uso de ferramenta. Uma chamada de API e uma busca na web. O agente decide quando chamar.
3. Guardas. Validação de entrada, limite de passos, filtro de saída.
4. Contexto e memória. Janela de contexto por padrão; memória externa só quando o estado precisa sobreviver à execução.
5. Trilha de auditoria. Registrar cada prompt, resposta, chamada de ferramenta, resultado, erro e horário.
6. Fluxo real. Rodar num processo que era manual, ligado a um projeto do portfólio.
7. Marco. Um agente funcionando com ferramentas, guardas, memória deliberada e trilha completa.

Semana 2: a demo vira um sistema que se recupera. No dia 14, o agente produz saída previsível e retoma depois de falhar.

8. Saída estruturada. Um esquema JSON definido, não texto livre.
9. Validação de esquema. Validar toda resposta; tentar de novo ou escalar quando a estrutura vier inválida.
10. Modos de falha. Dado faltando, resposta malformada, API fora, tempo esgotado, duplicata, conclusão parcial.
11. Pontos de salvamento. Guardar o estado a cada poucos passos: tarefa, ações, resultados de ferramenta, pendências, erros.
12. Retomada. Parar o agente de propósito e reiniciar do último ponto salvo.
13. Tratamento de falha. Comportamento explícito para ferramenta que falha, saída ruim, estado incompleto, continuação insegura.
14. Marco. Um agente retomável, com saída estruturada, recuperação de estado e falha explícita.

Semana 3: o sistema fica mensurável e viável economicamente. No dia 21, você sabe como ele falha, quanto custa e se está melhorando.

15. Nova tentativa. Espera exponencial em toda chamada externa: 1, 2, 4, 8 segundos, teto em 16.
16. Categorias de falha. Contexto faltando, ferramenta errada, registro errado, saída inválida, ação insegura, tempo esgotado.
17. Conjunto de referência. 20 consultas reais com a saída ideal marcada à mão: normal, limite, ambígua, de alto risco.
18. Rodar evals. Correção, formato, escolha de ferramenta, passos obrigatórios, comportamento de escalada.
19. Otimizar custo. Modelo mais barato para subtarefa simples, cache, limite de tokens, custo por consulta.
20. Multiagente. Só quando dividir ajuda: um planeja, vários executam, um sintetiza.
21. Marco. Um agente avaliado, com modos de falha conhecidos, custo medido e conjunto de referência.

A cadeia da semana: 20 casos, execuções do agente, evidência de passa ou não passa, categorias de falha, custo por execução.

Semana final: defender o sistema como um FDE. No dia 30, você explica o sistema para um engenheiro e para um executivo sem formação técnica.

22. A dor. Quem faz o trabalho, o que demora, onde erra, quanto custa.
23. Por que IA aqui. Por que não software comum, o que fica humano, onde a autonomia para.
24. Arquitetura. Pilha, ferramentas, modelos, dados, memória, guardas, e por que cada um existe.
25. Iterações. O que a v1 errou, o que falhou, o que mudou, como melhorou.
26. Os evals. Conjunto, taxa de aprovação, categorias de falha, limiares, riscos em aberto.
27. Economia. Tempo economizado, erros reduzidos, risco, receita, custo por consulta.
28. Ensaio para engenheiro. Arquitetura, decisões, falhas, trocas.
29. Ensaio para diretor. Problema, resultado, evidência, risco, em linguagem simples.
30. Marco final. Um case completo de FDE, que serve para engenheiros e executivos.

Os quatro marcos, para ter na parede: dia 7, agente funcionando; dia 14, sistema que se recupera; dia 21, sistema avaliado; dia 30, case completo de FDE. O título do slide final é a frase que resume o roadmap inteiro: faça o trabalho antes de ter o título. No dia 30 você não deve só entender o que é Forward Deployed; deve ter evidência de que sabe fazer.

O que você sai tendo, na lista dele: laço de agente, duas ferramentas, guardas, memória deliberada, trilha de auditoria, saída estruturada, validação de esquema, estado salvo, retomada após falha, caminhos de falha explícitos, novas tentativas com espera, taxonomia de falhas, conjunto de referência, suíte de evals, custo por consulta, auditoria do fluxo, arquitetura do sistema, relatório de avaliação, controles de implantação e caso de negócio. Para mim, isso fecha com a etapa 4 do roadmap: o case do portfólio sai do próprio exercício.

Diário de bordo

Entradas mais recentes no topo. Cada uma com o que mudou e o que aprendi.

29 de outubro de 2026. Publiquei o roadmap. Decidi não fazer MBA, pós nem mestrado. Escolhi evals como primeira porta e marquei a etapa 0 para fechar até 15 de novembro. No mesmo dia ouvi o episódio do Lightcone com Bob McGrew e o do Greg Isenberg sobre o manual do FDE, e anotei acima o que serve para quem trabalha sozinho. A descoberta do dia: a auditoria que abre todo projeto de FDE é o design sprint que eu já faço. Próximo passo: ler as 18 perguntas e escolher qual fluxo meu vai passar pela primeira análise de erros.