Como a Figma deu a 60 PMs um repositório de IA com 31 habilidades

O problema antes do PM OS

Quando Ezra Mechaber entrou na Figma↳Figma3 conteúdosFigma Dev Mode funciona mesmo? Testando na práticaDev (Back & Front) · mar 2025Claude Design: nova aposta da Anthropic contra Figma e MicrosoftProduto & UX · abr 2026A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → como growth PM, reparou em algo que destoava do resto da empresa: fora da engenharia, quase ninguém usava IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → para produzir trabalho de verdade. Ele já tinha um setup pessoal de Claude Code rodando tarefas do dia a dia. A ideia de transformar esse uso individual em algo coletivo veio da constatação óbvia de que times de produto estavam reinventando a roda sozinhos, cada um tentando descobrir na marra o que já funcionava para o colega da mesa ao lado.

Junto com outros dois PMs, Ezra pegou esse setup pessoal e virou um repositório compartilhado: o PM OS. A entrevista, concedida ao podcast How I AI, de Claire Vo (Lenny's Newsletter), publicada em 2 de novembro de 2026, detalha como esse repositório passou de experimento de corredor para infraestrutura usada por 60 a 70 PMs dentro da Figma.

Preguiçoso nos lugares certos.

Ezra Mechaber, PM de growth na FigmaLazy in the right places.

A frase resume o objetivo declarado por Ezra: automatizar o trabalho repetitivo e burocrático para sobrar energia para decisão de produto, não para operar ferramenta.

Por que é um repositório, não um produto

O detalhe que mais interessa a quem pensa em escalar práticas de equipe é a escolha deliberada de formato: PM OS é um repositório de código, não um produto interno com interface polida. Ele é composto por "skills" (blocos de prompt e automação reutilizáveis que o Claude Code executa), hooks que disparam ações automaticamente e sub-repos privados para times que precisam de contexto específico sem expor tudo para a empresa inteira.

Segundo o relato de Ezra, as skills passaram por um processo de curadoria dura antes de chegarem às 31 que sobreviveram: foram construídas, "roasted" (criticadas sem dó pelos próprios colegas PMs) e cortadas até sobrar só o que de fato se usava no dia a dia. Esse processo de seleção importa mais do que o número final: um repositório de IA para time só funciona se alguém tiver coragem de matar a skill que parecia boa na teoria e não pegou na prática.

As skills que tomam conta do dia a dia

Na demonstração, Ezra mostra um conjunto de usos concretos que foram do individual para o padrão da equipe:

• Uma skill de "chefe de gabinete" que ele roda seis vezes por dia só para domar o volume de mensagens no Slack;
• Uma rotina de bug bash que usa o Codex para encontrar problemas que ele, segundo o próprio relato, nunca pegaria sozinho revisando manualmente;
• Integrações com o servidor MCP do Figma e com o FigJam para gerar artefatos de build direto a partir de especificações;
• Skills de coaching, pensadas para ajudar PMs menos experientes a estruturar decisão sem depender de um mentor disponível o tempo todo.

Houve também uma transição de interface: o time começou operando tudo via terminal e migrou para um front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → web local, tornando o repositório acessível a PMs que não tinham familiaridade com linha de comando. Esse detalhe é o tipo de decisão de produto que normalmente fica invisível em cases de IA: a tecnologia por trás pode ser a mesma, mas sem uma camada de interface acessível, 31 skills viram ferramenta de uma pessoa só.

AutoXP: o agente que roda experimento com um checkpoint humano

A peça mais ousada do sistema é o AutoXP, descrito como um "growth PM automatizado". A proposta é que o agente conduza um experimento de crescimento de ponta a ponta, com apenas um ponto de checagem humana no meio do processo, em vez de um PM revisando cada etapa manualmente.

O resultado citado no episódio é direto: o primeiro experimento rodado pelo AutoXP já trouxe uma vitória grande para o time. A fonte não detalha a métrica nem o tamanho exato do ganho, então vale tratar esse dado como qualitativo, não como benchmark replicável.

O que interessa mais para quem desenha processo de produto é a arquitetura de controle, não o resultado pontual. Um checkpoint único implica uma aposta: o agente tem autonomia para decidir desenho de teste, segmentação e análise de resultado, mas existe um momento específico em que um humano precisa validar antes de o experimento seguir ou ser publicado. O episódio não detalha exatamente o que esse checkpoint cobre (se é aprovação de hipótese, de amostra ou de decisão final), e essa é uma lacuna real do material: a pergunta que fica para quem for copiar o modelo é onde, exatamente, colocar o próprio checkpoint.

O assistente de escrita que virou parte das reuniões

Paralelamente ao AutoXP, Ezra construiu com o Jev um assistente de escrita em tempo real. Segundo a pauta do episódio, essa ferramenta passou a acompanhar praticamente todas as reuniões de Ezra por duas semanas seguidas, sugerindo texto e estrutura enquanto a conversa acontecia.

O caso ilustra um padrão que aparece em outros episódios do mesmo podcast (como a conversa anterior sobre como usar o Jev na prática, também publicada na Lenny's Newsletter): ferramentas de IA generativa para texto estão migrando de "editor assíncrono" para "copiloto síncrono", presente dentro da própria reunião, não só depois dela.

O que fica em aberto

O modelo da Figma é consistente em um ponto: toda automação relevante guarda um ponto de intervenção humana, seja no bug bash com Codex, seja no checkpoint único do AutoXP. Isso é diferente de simplesmente "dar IA para o time" sem desenho de processo.

Mas o relato também deixa claro que esse sistema nasceu de baixo para cima, de um setup pessoal que virou cultura, e não de uma decisão de liderança de produto imposta de cima. Para quem lidera um time de produto menor, a pergunta que vale levar daqui não é "que ferramenta copiar", e sim: qual seria a única etapa do seu processo de growth em que você não abriria mão de aprovar antes de o experimento ir ao ar?

Fonte: Lenny's Newsletter