Em abril, escrevi sobre o que fez a Prova parecer real: o motor de sprints, a cobrança, as avaliações, o trabalho operacional chato que separa uma demo de um produto.
Aquele post era verdadeiro quando o publiquei. A arquitetura sprint-first que descrevi — sprints autorados, revisões por rubrica, roteamento adaptativo, os caminhos Operator e Builder — estava genuinamente funcionando. Era o motor certo.
O que eu ainda não sabia era que o currículo sobreposto por cima ainda estava errado.
Não errado de um jeito que você perceberia numa demo. Errado do jeito que só aparece depois que você já escreveu cada rubrica, traçou cada caminho de usuário, e fez a pergunta que ninguém me forçou a fazer até meados de maio: o que exatamente torna isso difícil para um chatbot gratuito replicar?
Entre meados de maio e o final de junho, o currículo foi reconstruído duas vezes. Em cada vez, substituí algo de que eu estava previamente convencido. Aqui está o que cada reescrita realmente significou.
A arquitetura de 3 trilhas (26 de maio – 1º de junho)
No final de maio, o produto tinha um problema. Tinha 33 sprints, e três públicos muito diferentes — operadores redesenhando fluxos de trabalho, builders tentando entregar uma primeira fatia útil, e líderes tentando transformar equipes — compartilhando 7 de 9 sprints e chamando os dois restantes de "trilha". Isso era um cardápio, não uma espinha dorsal.
Amplitude não é fosso.
Então construí o que parecia a resposta rigorosa: uma arquitetura em camadas com uma fundação comum Layer 0, depois três trilhas por público (Operator, Builder, Leader) com seus próprios sprints dedicados, todos originados dos 16 templates do curso e do corpus publicado. 38 unidades em 5 tipos de unidade. Conceito, exercício, sprint, projeto, checkpoint — cada um com semânticas de conclusão diferentes.
No papel, parecia um currículo de verdade.
O que quebrou não foi nenhum sprint individual. Foi a premissa estrutural subjacente a tudo aquilo: que mais trilhas e mais sprints tornavam o produto mais defensável.
Não tornam.
O framework 7 Powers de Hamilton Helmer nomeia isso explicitamente. Poder vem de barreiras — vantagens estruturais que concorrentes não podem replicar apenas decidindo fazê-lo. Adicionar sprints a um caminho não é uma barreira. É superfície operacional. Um chatbot genérico iguala a amplitude instantaneamente, sem atrito.
O modelo de 3 trilhas adicionou cobertura. Não adicionou profundidade. Eu tinha construído a coisa errada, e não vi isso até a arquitetura estar implantada e cada sprint estar escrito.
Eu tinha escrito 24 novos sprints para o modelo de 3 trilhas, originados dos templates do curso e do corpus publicado. A arquitetura parecia rigorosa no papel. Eu estava orgulhoso dela.
O sistema de trilhas foi desativado na mesma semana em que foi lançado.
A única regra (2 de junho – 22 de junho)
A segunda reescrita não começou com sprints. Começou com uma pergunta de estratégia.
Sentei e perguntei: se a única vantagem defensável da Prova é algo que uma ferramenta de IA horizontal não pode adotar estruturalmente, qual seria essa vantagem?
A resposta aterrissou em três camadas que se reforçam mutuamente:
Profundidade vertical (a cunha). Um marketer que entrega um fluxo de trabalho de campanha documentado por brief, com medição real e um portão de decisão, segundo um padrão de nível publicitário. Isso não é algo que um chatbot pode produzir a partir de um prompt.
Andaime (a ativação). A maioria dos marketers não sabe o que perguntar. O produto precisa encontrá-los no "acho que IA poderia ajudar com isso, mas não sei por onde começar" e fazer o trabalho de escopo, sequenciamento e definição de padrões.
Trabalho verificado, entregue segundo um padrão (a prova). Cada sprint termina com uma submissão revisada contra uma rubrica real. Não "está com boa aparência". Não "está gramaticalmente limpo". Mas: este artefato se sustentaria diante do que um operador de agência ou comprador de mídia realmente usaria?
A partir dessas três camadas, a arquitetura simplificou dramaticamente.
A estrutura de 3 trilhas foi substituída por uma única gramática em loop: checagem de realidade → brief → plano → executar/construir → portão de decisão → capstone.
Mesma gramática para os três caminhos. Artefatos diferentes por caminho. O operador executa um piloto de fluxo de trabalho de campanha. O builder entrega uma fatia de produto funcional. O líder constrói um business case para stakeholders e um blueprint de modelo operacional.
Profundidade foi adicionada apenas após o capstone: extensões de agência, extensões de profundidade de produto, extensões de mudança organizacional. Se um usuário quisesse mais, ele ganhava isso passando primeiro pela espinha dorsal.
Amplitude não desapareceu. Foi rebaixada a módulos de desvio acionados por evidência — sprints curtos e designados que só aparecem quando um revisor detecta uma lacuna que a espinha dorsal já escrita não consegue cobrir atualmente. A auditoria de infraestrutura de dados. As decisões de stack de fornecedor. O diagnóstico de apostas de mesa. Eles ainda existem. Só não são a rota que você toma, a menos que o produto tenha evidência de que você precisa deles.
O commit único que formalizou isso foi feat!: replace dual curriculum routing with unified path sequences em 11 de junho. O ! denota uma mudança quebradora. primary_path (operator, builder, leader) substituiu learning_track como o único eixo de roteamento. Havia uma feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — que isolou a transição até o gate de QA ser aprovado. Sete sprints legados foram aposentados do sequenciamento, mas mantidos visíveis como histórico.
O capstone tornou-se estrutural, não uma funcionalidade. É o mecanismo de custo de troca. Uma ferramenta horizontal pode gerar um pacote de sprint decente. Não pode gerar um portfólio de artefatos verificados, entregues, revisados contra padrões de nível publicitário com um histórico persistente de revisor.
Antes de escrever qualquer novo sprint ou caminho, pergunte: qual dos 7 Powers isso fortalece, e qual é a sua barreira? Se a resposta honesta for "adiciona cobertura" sem barreira, é superfície operacional que um chatbot já cobre — não construa.
— 5 de junho de 2026, documento de estratégia do currículo da Prova
Essa regra matou a arquitetura de 3 trilhas. Matou sprints que eram bem escritos mas estruturalmente redundantes. Transformou o capstone de uma funcionalidade que eu estava adiando em um requisito estrutural. E é a pergunta que eu deveria estar fazendo desde março.
A diferença entre abril e junho
O produto que lancei em abril estava certo no motor. O produto que fechei em junho estava certo na espinha dorsal.
O motor — sprints autorados, revisões por rubrica, roteamento adaptativo, ciclo de vida de sprint composto — era necessário. Uma arquitetura de currículo sem um motor de sprint funcionando é apenas uma ementa.
Mas um motor de sprint sem uma espinha dorsal defensável é apenas uma lista de funcionalidades que ferramentas gratuitas já estão igualando.
A diferença entre os dois produtos não foi mais código. Foi uma pergunta melhor. "Qual Power isso fortalece?" me forçou a matar coisas de que eu estava orgulhoso, e a elevar coisas que eu estava tratando como opcionais.
Não estou afirmando que a arquitetura de junho está pronta. Produtos raramente estão. Mas se você está construindo um produto de aprendizado agora, vale a pena fazer a pergunta antes de escrever seu próximo sprint. Porque amplitude é a coisa mais fácil de adicionar, e a primeira que uma IA genérica vai comoditizar.
Contexto adicional: Prova é meu produto de coaching para marketers e profissionais de publicidade, com um caminho Operator para redesign de fluxos de trabalho e um caminho Builder para entregar uma primeira fatia útil. Está em prova.chandlernguyen.com. O framework 7 Powers vem do livro 7 Powers: The Foundations of Business Strategy de Hamilton Helmer — este post referencia o framework mas não o ensina; o livro é a fonte.
Se você está construindo um produto estruturado sobre uma camada de IA que se move rápido, estou genuinamente curioso: o que na sua arquitetura uma ferramenta gratuita não consegue replicar apenas adicionando prompts?
É isso de mim por enquanto.
Um abraço, Chandler