O que é o Desafio de Certificação
A prova definitiva de que você é um GTM Engineer
O Desafio Final de Certificação é o projeto que encerra o Cohort 3 da Certificação em Engenharia de GTM. Ele não é um teste teórico. É a prova prática de que você aprendeu a pensar, diagnosticar, arquitetar e construir uma operação de Go-to-Market moderna, com IA no centro de cada decisão. O desafio é desenvolvido em paralelo às 8 semanas de aulas ao vivo da certificação e entregue até 30 de outubro de 2026.
Você vai escolher uma empresa real ou um caso fictício gerado por IA, conduzir um diagnóstico GTM completo, desenhar a arquitetura de receita, e construir pelo menos um componente de IA funcional que resolva um problema real da operação de GTM dessa empresa. O resultado precisa ser algo que você possa demonstrar, publicar e usar como portfólio profissional.
O que separa uma nota 7 de uma nota 10
Uma nota 7 entrega o básico funcionando: discovery feito, arquitetura razoável, componente de IA rodando. Uma nota 10 entrega clareza de problema, rigor metodológico, sofisticação técnica e evidência de impacto. A diferença está na profundidade do diagnóstico, na fidelidade à metodologia SCIENT e na qualidade da execução técnica. não no número de ferramentas usadas.
O desafio acompanha as 8 semanas de aulas da certificação (13/07 a 06/09), com mais ~8 semanas adicionais para finalizar a entrega (até 30/10). Cada passo tem entregáveis específicos, critérios de avaliação claros e um peso na nota final. Você precisará de no mínimo 7,0 pontos para obter o Certificado de GTM Engineer emitido pela SCIENT.
O projeto precisa alavancar sua carreira. interna ou externamente
O entregável final não é apenas um projeto de certificação. É o seu cartão de visita como GTM Engineer. Ele deve ser algo que você possa usar para crescer profissionalmente. seja internamente, apresentando a lideranças da sua empresa como evidência de competência técnica e estratégica; seja externamente, publicando no LinkedIn como case de portfólio, produzindo conteúdo, ou usando como referência em processos seletivos e propostas de consultoria. Pense no seu projeto como o primeiro grande case da sua carreira em GTM Engineering.
Os Três Pilares que o Projeto Deve Cobrir
Cada pilar precisa de uma métrica de impacto clara. Não basta entregar o componente funcionando. Você precisa mostrar qual métrica operacional ele melhora e em quanto. Ex: "redução de 40% no tempo de qualificação", "aumento de 25% na taxa de conversão MQL→SQL", "economia de 6h/semana por SDR". Sem métrica, o projeto não demonstra valor real.
RevOps
Arquitetura de dados unificada, modelo de funil com estágios e critérios de avanço, métricas GTM-5 (#Volume, %Conversão, ΔTempo), ICP documentado, CRM parametrizado e observabilidade da operação de receita. É a fundação: sem dados estruturados, não há IA.
Dados + Processos + ObservabilidadeBizDev (Receita)
Ciclo de aquisição ou retenção mapeado end-to-end com metodologia unificada (SPICED, Challenger, MEDDPICC). Playbook de pelo menos um passo da jornada do cliente com gates de saída, perguntas consultivas e artefatos. Blueprint AS-IS → TO-BE mostrando o que será automatizado vs. humano.
Aquisição ou Retenção + MetodologiaEngenharia
Pelo menos um componente de IA funcional: agente autônomo, copiloto, workflow automatizado ou produto navegável com IA integrada. O componente deve resolver um gargalo real identificado no discovery e ter uma hipótese de impacto mensurável em produtividade ou receita.
Build + IA + ImpactoReal ou Fictícia. Você Decide
O que importa é a profundidade do diagnóstico, não a origem do caso
O projeto pode ser desenvolvido com base em uma empresa real ou em um caso fictício gerado por IA. Ambas as opções têm o mesmo peso na avaliação: o que diferencia a nota é a qualidade do trabalho, não a origem da empresa.
Empresa Real. Você tem acesso
A sua própria empresa, o negócio onde você trabalha ou um cliente que autorizou. Você tem acesso a dados reais e pode implementar e medir resultados concretos.
Autonomia de AcessoEmpresa Real. POC ou simulação
Empresa real, mas sem autorização formal para implementar. Você constrói a POC em ambiente controlado com dados reais ou simulados, como se fosse uma proposta de consultoria.
Consultoria SimuladaCaso Fictício Gerado por IA
Você usa Claude, ChatGPT ou outra IA para gerar um perfil completo de empresa com desafios de GTM reais. Depois, trata esse caso como se fosse real em todo o desenvolvimento.
AI-Generated CaseComo gerar um bom caso fictício com IA
Se optar pelo caso fictício, use um prompt rico e específico. Peça à IA para gerar: nome da empresa, segmento, modelo de negócio (B2B/B2C/PLG), ACV médio, tamanho do time comercial, MRR atual, principais métricas GTM-5 (CAC, GRR, Pipeline Coverage, ROI Rate, Margem Bruta), e os três principais gargalos na operação de receita. Inclua o prompt completo e o output da IA no seu documento de discovery. isso conta como evidência de uso de IA e demonstra seu nível de engenharia de prompt.
Atenção: independentemente da opção escolhida, o rigor metodológico é o mesmo. Não há "desconto" por usar um caso fictício: pelo contrário, um caso fictício mal construído (empresa sem contexto suficiente, métricas vagas, problemas genéricos) resulta em um discovery superficial e notas mais baixas. Use a IA para construir um caso rico, detalhado e realista.
IA em Tudo. Sem Exceção
Um GTM Engineer moderno usa IA como ferramenta principal de trabalho, não como auxiliar
O uso de IA precisa ser documentado em todos os passos
Este desafio exige que você use IA no máximo possível em cada etapa. Isso não significa usar qualquer ferramenta superficialmente, significa usar IA de forma deliberada, mostrando os prompts, os outputs, e o raciocínio por trás de cada uso. A evidência de uso de IA tem peso específico na rubrica de avaliação.
Em cada entregável, você deve incluir uma seção chamada "Log de IA" com: a ferramenta usada, o objetivo do uso, o prompt principal (ou uma descrição do contexto passado), e o output relevante gerado. Não precisa ser exaustivo. foque nos usos mais significativos de cada passo.
Como usar IA em cada passo do desafio
Passo 1. Discovery com IA
Log obrigatórioUse IA para acelerar e aprofundar o diagnóstico. Exemplos concretos do que fazer:
- Geração do caso fictício: Prompt para Claude/ChatGPT para criar o perfil completo da empresa, com métricas, desafios e contexto GTM.
- Pesquisa de mercado e benchmarks: Pergunte à IA quais são os benchmarks GTM-5 para o segmento da empresa escolhida. Compare com os dados da empresa.
- Estruturação do JTBD: Use IA para rascunhar o Job to be Done e depois refine com seu conhecimento do contexto real.
- Mapeamento AS-IS → TO-BE: Peça à IA para identificar gargalos típicos de empresas no mesmo estágio e compare com o diagnóstico que você fez.
- Construção de hipóteses: Use IA para estruturar e criticar suas hipóteses de impacto antes de finalizar o documento.
Passo 2. Arquitetura GTM com IA
Log obrigatório- ICP e Clusters: Use IA para estruturar os critérios MUST / SHOULD / COULD do ICP e identificar clusters de contas prioritárias.
- Modelo de dados: Use Claude/Cursor para gerar o schema de campos do CRM, automações de estágio e regras de qualificação.
- Playbook de Vendas ou CS: Use IA para redigir pelo menos um passo do playbook com fases, gates, artefatos e perguntas consultivas.
- Forecast básico: Use IA para estruturar o modelo de Forecast com base nos GTM-5 e nas metas da empresa.
- Revisão crítica: Peça à IA para criticar a arquitetura que você projetou. identificar gaps, inconsistências ou riscos não endereçados.
Passo 3. Build com IA
Log obrigatórioNeste passo, a IA é o motor principal de construção. Use IA para:
- Código e configuração: Use Cursor, Claude Code ou ChatGPT para escrever automações, configurar fluxos N8N, criar scripts de integração e estruturar o banco de dados.
- Prompt Engineering: Desenvolva o Prompt Master do agente com IA. itere sobre a identidade, regras de decisão, estrutura de output e uso de RAG.
- RAG e base de conhecimento: Use IA para estruturar e organizar a base de conhecimento, criar embeddings e testar a qualidade da recuperação de informação.
- Debugging e otimização: Use IA para identificar e corrigir problemas no fluxo, otimizar o desempenho e melhorar a consistência das respostas.
- Teste de qualidade: Peça à IA para gerar cenários de teste e simular interações que exponham fraquezas do agente.
Passo 4. Documentação e Submissão
Log obrigatório- Documento consolidado: Use IA para redigir, estruturar e revisar o documento final do projeto. Mostre o processo de iteração.
- Script do vídeo: Use IA para escrever o roteiro do vídeo de funcionamento, garantindo cobertura de todos os critérios avaliados.
- Post para LinkedIn: Use IA para criar o rascunho do post de compartilhamento do projeto. e mostre que você editou e adaptou com sua voz.
- Revisão final: Use IA para revisar o documento final e identificar o que ainda está vago, inconsistente ou não documentado.
| Ferramenta | Uso Recomendado | Passo Mais Relevante |
|---|---|---|
| Claude / ChatGPT / Gemini | Análise, escrita, revisão, geração de casos, estruturação de frameworks, prompt engineering | Todas |
| Claude Code / Codex / Cursor | Código de automações, scripts de integração, configuração de agentes, debugging, desenvolvimento assistido por IA | Passo 3 |
| N8N / Make | Construção dos fluxos de automação, trigger, ações, integração com CRM e APIs | Passo 3 |
| Perplexity / Deep Research | Pesquisa de benchmarks, análise de mercado, validação de dados da empresa | Passo 1 |
| Claude / Cowork / Notion | Estruturação de documentos, playbooks, síntese de informações, co-criação de conteúdo | Todos os passos |
Antes de Construir, Entender
O Discovery é a fase mais importante do projeto. sem clareza aqui, tudo que vem depois é ruído
O Playbook de Product Discovery da SCIENT é o guia obrigatório para este passo. O Discovery não é uma lista de templates a preencher. é um processo de investigação que deve resultar em clareza absoluta sobre o problema, o usuário, o impacto esperado e o que será construído. Use os frameworks como ferramentas de pensamento, não como formulários.
Entregável de Discovery: Um documento único e coeso, não uma coleção de templates
O documento de Discovery precisa contar uma história: aqui está a empresa, aqui está o problema de receita que ela enfrenta, aqui está quem sofre com ele, aqui está o que vamos construir para resolver, e aqui está como vamos medir se funcionou. Cada seção deve conectar com a anterior. Se o documento parecer um conjunto de seções soltas sem conexão, ele não passou no Discovery.
O que o Documento de Discovery deve conter
1. Perfil da Empresa e Contexto GTM
Nome, segmento, modelo de negócio (B2B Enterprise / Mid-Market / SMB / PLG), ACV médio, tamanho do time comercial, MRR/ARR atual ou estimado, e stage da empresa (seed, crescimento, escala). Se for caso fictício, inclua o prompt usado para gerar o perfil.
2. Diagnóstico GTM-5 e Mapa do Funil
Mapeie o funil de receita completo da empresa (Contas → Interessadas → Diagnósticas → Propostas → Clientes → Ativos → Retidos → Expandidos). Para cada estágio, documente: volume estimado, taxa de conversão, ciclo médio, e o principal gargalo. Compare com benchmarks do segmento e identifique os três maiores problemas que impactam as métricas GTM-5 (CAC:LTV, GRR, ROI Rate, Pipeline Creation Rate, Margem Bruta).
3. Mapeamento de Stakeholders
Identifique os principais stakeholders: Usuário (quem usa o que será construído), Champion (quem defende internamente), Decisor (quem aprova), Comprador Executivo (quem assina). Para cada um: cargo, principais dores, valor que receberão com a solução, e a mensagem certa para conectar dor ao valor.
4. Job to be Done (JTBD) Principal
Um parágrafo único que descreve: quem é o usuário principal, em que momento a necessidade surge, o que ele está tentando realizar (objetivo funcional e emocional), o que atrapalha hoje, e como seria uma experiência bem-sucedida. Siga a estrutura do Playbook SCIENT de Discovery. Não é uma lista. é um parágrafo coeso e específico.
5. User Persona do Usuário Principal
Perfil detalhado de quem vai usar o componente de IA que você vai construir: nome fictício, cargo, contexto profissional, objetivos, frustrações, comportamentos típicos e necessidades de suporte. Evite personas genéricas. a persona precisa ser específica o suficiente para informar decisões de design do agente/produto.
6. Hipótese de Impacto + Métrica-Chave
Hipótese principal no formato: "Acredito que, ao implementar [o componente], vamos [impacto esperado] porque [razão baseada no problema diagnosticado]." Métrica de sucesso: a métrica objetiva que provará se a hipótese está correta (ex: redução de X horas semanais, aumento de Y% na conversão, N reuniões agendadas). Método de medição: como você vai medir isso na POC.
7. Blueprint AS-IS → TO-BE
Mapeamento visual ou textual do processo atual (AS-IS): etapas, gargalos, retrabalhos, perdas de informação, dores do usuário. E do processo futuro (TO-BE): o que será automatizado, o que continuará humano, o que será AI-Native, o que será AI-Embedded. Pode ser um diagrama simples (Miro, tldraw, Lucidchart) ou uma tabela comparativa clara.
8. Definição do Componente de IA que Será Construído
Qual tipo de componente você vai desenvolver (Agent Workflow, Agente Conversacional ou Produto Agêntico Navegável), em que parte do GTM ele opera (aquisição, qualificação, ativação, retenção, expansão), quem é o usuário final, qual problema específico ele resolve, e qual é o fluxo de alto nível (trigger → processamento → output → ação).
9. Log de IA do Discovery
Seção documentando como a IA foi usada neste passo: ferramenta, objetivo, prompt principal (ou contexto passado), output relevante. Mínimo de 3 usos documentados de IA neste passo.
Formato do entregável de Discovery
Documento único (Google Docs, Notion, Docs, etc.) com no máximo 5 páginas de conteúdo (não contando o Log de IA). Pode incluir diagramas, tabelas ou imagens. A clareza e a coesão contam mais do que o volume. Um discovery de 3 páginas denso e preciso é melhor que um de 8 páginas superficial.
O que Você Precisa Entregar
Todos os entregáveis devem ser submetidos no formulário oficial até 30 de outubro de 2026 às 23h59
Tipos de Entregas Agênticas
No Passo 3, você constrói um componente de IA que resolve o problema identificado no Discovery. Existem três categorias de entregável técnico. escolha a que melhor se encaixa com o problema diagnosticado e com seu nível técnico:
| Categoria | O que é | Exemplos concretos | Complexidade |
|---|---|---|---|
| Agent Workflow | Automação de processo em backend. Roda sozinho, sem interface visual. Executa um processo GTM de ponta a ponta. | BDR AI que prospecta e envia mensagens personalizadas, Pipeline Hygiene Agent que atualiza CRM automaticamente, Lead Scoring Agent que qualifica e distribui leads. | Médio. Requer N8N/Make + integrações + prompt engineering |
| Agente Conversacional | Chatbot interno ou externo que interage via texto ou voz. Pode ser assistido por humano (copiloto) ou totalmente autônomo (agente). | SDR AI por WhatsApp que qualifica leads, CS Copilot que prepara revisões trimestrais, Assistente de discovery interno que prepara AEs para reuniões. | Médio-alto. Requer RAG + prompt + integração de canal + CRM |
| Produto Agêntico Navegável | Aplicação web onde o usuário entra, interage e recebe um output estruturado. Tem interface visual e experiência de usuário definida. | Ferramenta de diagnóstico GTM, Dashboard de saúde de conta, Gerador de GTM Blueprint, Calculadora de ROI com IA integrada. | Alto. Requer desenvolvimento web + IA integrada + UX/UI |
Sugestões por pilar GTM
Aquisição: BDR AI (Outbound), SDR AI (Inbound), Lead Scoring Agent, Sequência de nutrição automatizada.. Vendas: Prep de reunião com IA, Copiloto de proposta comercial, Deal Risk Agent, Follow-up automatizado.. CS e Retenção: Health Score Copilot, QBR Copilot, Churn Prediction Agent, ROI Verification Agent.. RevOps: Pipeline Hygiene Agent, CRM Data Quality Agent, Forecast Agent, GTM Blueprint Generator.
O desafio é 100% assíncrono. Você não vai apresentar nada para uma banca. Tudo é enviado via formulário: documentos, vídeo gravado mostrando o componente funcionando, JSON do fluxo (se N8N) e evidências de uso. Os avaliadores vão revisar o material no próprio tempo deles. Foque em entregar material claro e completo, não em fazer uma performance ao vivo.
Entregável 1. Documento de Discovery GTM
Documento único e coeso com os 9 elementos descritos na seção de Discovery. Máximo de 5 páginas de conteúdo, sem contar o Log de IA. Pode ser Google Docs, Notion, PDF ou equivalente. O documento deve mostrar clareza do problema, rigor do diagnóstico e uma definição precisa do que será construído.
- Perfil da empresa com dados suficientes para contextualizar o projeto
- Diagnóstico GTM-5 com gargalos identificados e comparação com benchmarks
- Mapa de stakeholders com dores e valor por papel
- JTBD em um parágrafo coeso e específico
- User Persona do usuário do componente de IA
- Hipótese de impacto + métrica de sucesso + método de medição
- Blueprint AS-IS → TO-BE (visual ou tabela comparativa)
- Definição do componente de IA com tipo, escopo e fluxo de alto nível
- Log de IA com mínimo 3 usos documentados neste passo
Entregável 2. GTM Blueprint e Arquitetura
Documento ou conjunto de documentos que detalha a arquitetura da operação de receita projetada para a empresa. Pode ser integrado ao documento de Discovery como Parte 2, ou ser um documento separado.
- ICP e Clusters: Critérios MUST / SHOULD / COULD, score de ICP, e clusters de contas priorizados por potencial de receita
- Modelo de dados: Estágios do funil com definições e critérios de avanço, campos principais do CRM por objeto, e automações de estágio recomendadas
- Playbook de pelo menos um passo: Etapas, gates de saída, artefatos, perguntas consultivas e KPIs para Marketing, Vendas ou CS. conforme o problema diagnosticado
- Stack proposta: Ferramentas recomendadas para cada camada (CRM, Marketing Engagement, Sales Engagement, CS Platform, Data Enhancers, Automação, Observability)
- Targets GTM-5: Metas definidas para as 5 métricas fundamentais (CAC:LTV, GRR, ROI Rate, Pipeline Creation Rate, Margem Bruta) no horizonte de 6-12 meses
- Log de IA da passo 2 com mínimo 3 usos documentados
Entregável 3. Componente de IA Funcional (POC)
A POC funcional do componente de IA escolhido, demonstrando operação de ponta a ponta. Este é o entregável com maior peso na avaliação. Deve incluir:
- Fluxo funcionando: Screenshots ou vídeo do componente executando o processo completo. do trigger ao output final
- Prompt Master documentado: O prompt principal do agente com identidade, objetivo operacional, regras de comunicação, regras de decisão e estrutura de output
- Base de conhecimento / RAG: Evidência da base de conhecimento construída e de como ela é acionada. Deve mostrar um exemplo de consulta e retrieval (print do top-K chunks ou equivalente)
- Integração com stack: Evidência de integração com pelo menos uma ferramenta real (CRM, canal de comunicação, planilha, banco de dados ou similar)
- Output real: Exemplo de output gerado pelo componente em uma situação concreta. mensagem enviada, documento gerado, score calculado, etc.
- Log de IA da passo 3 com mínimo 5 usos documentados (esta é a fase mais técnica)
Entregável 4. Pacote Final de Submissão
O pacote final que consolida todo o projeto e o torna compartilhável. Composto por:
- Vídeo de funcionamento: Vídeo de 5 a 10 minutos demonstrando o componente de IA em funcionamento. Deve cobrir: contexto do problema, fluxo do componente de ponta a ponta, output gerado, e o impacto esperado ou medido. Não precisa ser produção profissional. clareza e completude contam mais do que edição.
- Documento consolidado do projeto: Versão final e integrada de todos os documentos anteriores (Discovery + Arquitetura + POC), organizada como se fosse uma proposta de consultoria ou case study. Este é o documento que ficará no seu portfólio.
- Artefato de alavancagem de carreira: O projeto precisa produzir algo concreto que alavanque sua carreira. interna ou externamente. Escolha pelo menos um dos formatos: (a) rascunho de post para LinkedIn descrevendo o projeto, o problema resolvido e o impacto gerado. pronto para publicar; (b) apresentação executiva de 5 slides para apresentar à liderança da sua empresa como proposta interna; (c) one-pager em formato de case study para usar em processos seletivos ou propostas de consultoria. O objetivo é que ao final do desafio você tenha um artefato real que amplie sua credibilidade profissional como GTM Engineer. seja para crescer internamente, mudar de cargo, entrar em consultoria ou produzir conteúdo no mercado.
- Log de IA do passo 4 com mínimo 3 usos documentados
- Autoavaliação: Parágrafo breve avaliando seu próprio projeto contra a rubrica: o que funcionou, o que você faria diferente, o que aprendeu.
Sobre o formulário de entrega: Todos os entregáveis são submetidos em um único formulário ao final do projeto. Você pode. e deve. submeter entregáveis intermediários conforme as datas de prazo de cada passo, para receber feedback antes da entrega final. O formulário está disponível em desafio-gtme-cohort-3.vercel.app/entrega.html
Como Seu Projeto Será Avaliado
5 dimensões com pesos distintos, cada uma com critérios específicos por faixa de nota
O projeto é avaliado em 5 dimensões independentes. Cada dimensão tem um peso específico na nota final e critérios detalhados para cada faixa de pontuação. A nota final é calculada como a média ponderada das 5 dimensões, com possibilidade de pontos bônus adicionais.
A quinta dimensão. Documentação e Apresentação. representa 15% do peso total. Os bônus podem adicionar até 1,0 ponto à nota final.
Dimensão 1. Discovery GTM
Peso: 20%Dimensão 2. Arquitetura GTM e Foundational RevOps
Peso: 20%Dimensão 3. Componente de IA Funcional
Peso: 30%Dimensão 4. Uso de IA no Processo de Desenvolvimento
Peso: 15%Dimensão 5. Documentação e Entrega
Peso: 15%Bônus. Impacto Real Documentado
Os bônus são adicionados à nota final após o cálculo ponderado. Não substituem uma nota baixa em qualquer dimensão. são complementos para projetos que vão além do básico.
| Bônus | Critério | Pontos |
|---|---|---|
| Impacto Real Medido | Projeto implementado em empresa real com métricas antes/depois documentadas (ex: X horas economizadas, Y% de aumento em conversão, Z reuniões agendadas automaticamente por semana) | +1,0 ponto |
| Feedback de Usuários Reais | Pelo menos 2 usuários reais testaram o componente e forneceram feedback documentado (pode ser screenshot de conversa, formulário de feedback, NPS ou depoimento) | +0,5 ponto |
| Publicação Pública | Post no LinkedIn publicado apresentando o projeto (pode ser em qualquer formato: case study, carrossel, artigo), ou apresentação interna para liderança com registro (print, ata, email de aprovação). O projeto saiu do campo privado e foi usado profissionalmente. Compartilhe o link ou evidência no formulário. | +0,5 ponto |
Como Funciona a Nota Final
Nota mínima de 7,0 para obter o Certificado de GTM Engineer emitido pela SCIENT
| Dimensão | Peso | Nota Máxima | Contribuição Máxima |
|---|---|---|---|
| D1. Discovery GTM | 20% | 10,0 | 2,0 pts |
| D2. Arquitetura GTM e RevOps | 20% | 10,0 | 2,0 pts |
| D3. Componente de IA Funcional | 30% | 10,0 | 3,0 pts |
| D4. Uso de IA no Processo | 15% | 10,0 | 1,5 pts |
| D5. Documentação e Entrega | 15% | 10,0 | 1,5 pts |
| Subtotal | 100% | - | 10,0 pts |
| Bônus (acumulável) | - | - | +2,0 pts (máximo) |
| NOTA MÍNIMA PARA CERTIFICAÇÃO | 7,0 / 10,0 | CERTIFICADO GTM ENGINEER | |
Exemplo de cálculo: D1 = 8,0 | D2 = 7,5 | D3 = 9,0 | D4 = 8,0 | D5 = 7,0 → Nota = (8,0 × 0,20) + (7,5 × 0,20) + (9,0 × 0,30) + (8,0 × 0,15) + (7,0 × 0,15) = 1,60 + 1,50 + 2,70 + 1,20 + 1,05 = 8,05. Com bônus de impacto real (+1,0): nota final = 9,05.
Atenção: o componente de IA tem o maior peso
A Dimensão 3. Componente de IA Funcional. representa 30% da nota total. Isso significa que um componente de IA que não funciona ou que é apenas conceitual limita drasticamente sua nota final, mesmo que todas as outras dimensões sejam excelentes. Invista a maior parte do seu tempo de desenvolvimento no Passo 3, garantindo que o componente realmente funcione de ponta a ponta.
Feedback individual
Todos os projetos avaliados receberão feedback escrito por dimensão. Quem não atingir nota mínima terá uma semana adicional para submeter uma versão revisada, mas apenas para entregáveis que tiverem sido submetidos antes do prazo. Projetos entregues no prazo com nota abaixo de 7,0 terão chance de recuperação; projetos entregues fora do prazo não terão.
Trilha da Certificação e Cronograma do Desafio
8 semanas de aulas ao vivo + tempo de construção até 30 de outubro de 2026
A certificação é dividida em duas fases: 8 semanas de aulas ao vivo (masterclasses às segundas, office hours às quartas, sempre às 18h30) e um período de construção livre para finalizar o desafio. O projeto de certificação deve ser desenvolvido em paralelo às aulas, aplicando o conteúdo aprendido a cada semana.
Como a trilha alimenta o desafio
Cada semana da certificação cobre um pilar que você vai precisar no seu projeto. As semanas 1-3 constroem a fundação (dados, metodologia, stack). As semanas 4-6 ensinam gestão (MBR, forecast, teoria das restrições). As semanas 7-8 focam em construção (discovery de produto, deploy do agente). Use cada aula para avançar no seu projeto.
Sprint 01: Fundação (Semanas 1-3)
Tese Central: O que é Engenharia de GTM
Abertura da certificação. Os 3 pilares, como GTM Engineering se diferencia de RevOps, e a trilha completa das 8 semanas.
Masterclass Seg 13/07Arquitetura de Dados: O centro da máquina
Do naming padronizado no CRM até as 4 camadas da arquitetura de dados de receita. Sem dados estruturados, IA não funciona.
Convidado AnthropicMetodologia Unificada e POPs
Escolher uma metodologia de qualificação e transformá-la em processo documentado. Como POPs e handbooks viram a memória da operação.
Hands-on HandbooksSprint 01: Gestão (Semanas 4-6)
MBR e Cultura de PDCA
Como estruturar Monthly Business Reviews que não viram teatro. Estudos de caso reais de operações que usam MBR como motor de melhoria.
Convidados Vercel + NektBP, Forecast e Capacity Planning
Modelagem matemática do BP, forecast científico multi-motion e capacity planning por função. A meta em fórmulas, não em achismo.
Hands-on OpenClawTeoria das Restrições: Onde atacar primeiro
Os 5 passos de focalização aplicados ao funil de receita. Como transformar dados observáveis em identificação de gargalo e plano de ação.
Cheque de RealidadeSprint 02: Construção (Semanas 7-8)
Mentalidade de Produto: Discovery & Delivery
Sair da mentalidade de operações e entrar na mentalidade de produto. Como conduzir uma Discovery real com usuários da própria operação antes de sair construindo.
Primeira DiscoveryRoadmap Final e Deploy do Agente
Semana de fechamento. O aluno consolida o roadmap dos 5 pilares e faz o deploy do agente. As entregas do desafio acontecem em paralelo, via formulário, e não dependem do hackathon.
Consolidação · DeployDinâmica semanal
Segundas 18h30: Masterclass ao vivo com conteúdo técnico do pilar da semana. Quartas 18h30: Office Hours ao vivo para dúvidas, hands-on e sessões com convidados (Anthropic, Vercel, Nekt, OpenClaw). Aulas gravadas: RevOps, BizDev e Product Engineering, 5-8 aulas por tema de 10-20 minutos, disponíveis a qualquer momento. Comunidade: Discussões peer-to-peer e project-based no Circle.
Período de Construção e Entrega do Desafio
Lançamento do Desafio + Início das Aulas
O desafio é lançado junto com a certificação. Comece o discovery e a escolha da empresa desde a primeira semana. Use cada aula para avançar no projeto.
Office Hours para Dúvidas do Desafio
Sessão semanal para tirar dúvidas sobre qualquer etapa do projeto. Preencha o formulário de perguntas até terça à noite.
Hackathon Final da Certificação
Evento opcional para alunos que querem receber feedback ao vivo e apresentar seus projetos para o painel SCIENT + convidados. A entrega do desafio é independente: você submete o .zip pelo formulário a qualquer momento até o prazo final.
Período de Construção Livre
Após o término das aulas, você tem mais ~8 semanas para finalizar, polir e documentar seu projeto de certificação com calma.
Prazo Final de Entrega
Submissão completa do projeto no formulário oficial. Todos os entregáveis devem ser enviados em um único .zip até esta data.
Atenção ao prazo. O prazo final é 30 de outubro de 2026, 23h59. Entregas após essa data não serão aceitas para avaliação neste cohort.
Instruções de Entrega
Siga estas instruções para garantir que sua entrega seja avaliada corretamente
Toda a entrega é feita em um único formulário. Organize todos os arquivos em uma pasta, compacte em .zip e anexe no formulário junto com os links complementares (vídeo, acesso ao sistema, etc.).
Como organizar sua pasta de entrega
Crie uma pasta com seu nome (ex: joao-silva-gtme-cohort2), coloque todos os arquivos dentro, compacte em .zip e envie pelo formulário.
PDFs, Google Docs exportados, apresentações. até 50 MB por arquivo. Inclui: documento de Discovery, GTM Blueprint, documento consolidado, autoavaliação e artefato compartilhável.
Grave o componente funcionando de ponta a ponta. até 100 MB, ou envie o link do YouTube/Loom no formulário. Obrigatório para agentes conversacionais e componentes interativos.
Exporte o fluxo em JSON (Menu → Download) e inclua na pasta. Inclua também screenshots do fluxo rodando com outputs reais. Se usar Make ou outro, exporte no formato nativo da plataforma.
Crie um usuário de demonstração com login e senha e inclua as credenciais no formulário (campo específico). Para agentes conversacionais (OpenClaw, WhatsApp, Claude), grave o vídeo e/ou compartilhe o link de acesso.
Prazo final: 30 de outubro de 2026, 23h59. Organize todos os entregáveis em uma pasta .zip e envie pelo formulário oficial até essa data.
Perguntas Frequentes
Dúvidas que costumam aparecer. leia antes de perguntar
Posso trabalhar em grupo?
Não. O desafio é individual. Você pode trocar ideias com colegas e usar a comunidade para discutir abordagens, mas cada projeto precisa ser desenvolvido e entregue por um único aluno. Projetos idênticos ou com grande sobreposição de conteúdo serão desqualificados.
Preciso usar N8N obrigatoriamente?
Não. N8N é a ferramenta preferencial para automações, mas você pode usar Make, Zapier, HubSpot Workflows, Dify, LangChain, código próprio ou qualquer outra solução técnica que construa o componente funcional. O que importa é o resultado. o componente funcionando, não a ferramenta.
E se eu não tiver acesso a um CRM?
Você pode usar qualquer ferramenta que simule as funções de CRM: HubSpot gratuito, Attio, Pipedrive trial, Notion, Airtable, ou mesmo uma planilha bem estruturada. O que precisa estar presente é a lógica de dados. estágios do funil, critérios de avanço, registro de interações. A ferramenta é secundária.
Posso mudar a empresa ou o tipo de componente depois do Discovery?
Sim, mas apenas até a entrega do Discovery (19 de abril). Depois disso, a empresa e o componente ficam definidos. Se você precisar fazer uma mudança significativa após esta data, avise no grupo da turma com justificativa. mudanças de escopo pós-discovery sem justificativa serão penalizadas na avaliação.
O vídeo precisa ter produção profissional?
Não. Clareza e completude contam mais do que edição. Uma gravação de tela simples com narração clara mostrando o componente funcionando de ponta a ponta é suficiente. e preferível a um vídeo bem editado que omite etapas críticas. Use Loom, OBS ou qualquer gravador de tela. Lembre-se: não há apresentação ao vivo. o vídeo gravado é a sua demonstração.
Como entrego o componente de IA para avaliação?
Depende do tipo de componente que você construiu. Se for um fluxo de automação no N8N, exporte o JSON e inclua na pasta de entrega. Se for uma plataforma web, crie um usuário de demonstração para acesso dos avaliadores. Se for um agente conversacional (WhatsApp, Claude, OpenClaw, etc.), grave um vídeo demonstrando o fluxo completo de ponta a ponta. O objetivo é que os avaliadores consigam verificar o funcionamento real do componente, não apenas ler sobre ele.
Onde peço ajuda durante o desenvolvimento?
Primeiro: no grupo da turma: alguém provavelmente já passou pelo mesmo problema. Segundo: publique na comunidade do Circle com contexto completo (o que você tentou, o erro, o que pesquisou). Terceiro: envie sua dúvida no formulário semanal de perguntas para ser respondida durante a Office Hours de quarta-feira.