Eu valido tudo em no-code antes de codar uma linha

A maioria dos PMs que conheço tem uma única forma de testar uma ideia. Escrevem um PRD, agendam refinamento com o time de engenharia, esperam estimativas, esperam o sprint começar, esperam o code review, esperam QA. Três meses depois descobrem que a ideia não funciona.

Eu parei de fazer isso há dois anos.

O que eu faço hoje é simples: valido tudo em no-code antes de codar uma única linha. Telegram, WhatsApp, n8n, planilhas que fingem ser banco de dados. Quando o comportamento estabiliza e usuários reais começam a tirar valor, aí sim vou pra produção.

Não é uma técnica nova. É só rara entre PMs porque exige saber construir a coisa, não só especificar.

Esse post é sobre como isso me salvou em dois produtos seguidos, e o framework que eu uso quando começo qualquer coisa.

A vez que o problema não estava no modelo

Em 2024 entrei como founding Head of Product na CreatorBid, uma plataforma de IA para criadores produzirem conteúdo no tom da própria marca. A primeira versão tinha sido construída em dois meses por quatro pessoas, e a gente tinha uma decisão técnica forte: a janela de contexto da IA era fechada, limitada a documentos curados pelo criador. O motivo era óbvio. A gente queria evitar alucinação no nicho técnico onde a CreatorBid nasceu.

Funcionou pra precisão. Falhou em qualidade.

O conteúdo gerado ficava raso. Repetitivo. Curto demais. Os criadores começavam, davam dois posts, e abandonavam. A primeira instinto do time foi clássico: vamos refinar o modelo. Mais fine-tuning, mais prompts, mais exemplos no contexto. Eu olhei pras conversas que estávamos tendo com early adopters e pensei outra coisa.

O problema não era o modelo. Era o fluxo.

A gente tinha colocado toda a inteligência dentro de uma caixa fechada e exigido que ela resolvesse tudo sozinha. Mas conteúdo bom não nasce de uma caixa fechada. Nasce de iteração, de contexto que vai e vem, de quem está escrevendo poder dizer "não, faz de novo, mas mais assim". A solução era reabrir o contexto e mover a complexidade pro fluxo de uso, não pro modelo.

Era uma decisão arriscada. Mexer no core do produto sem ter certeza que ia funcionar podia atrasar o V1 em meses.

Foi aí que o no-code salvou todo mundo.

Vinte criadores no Telegram

A gente prototipou o redesign inteiro num bot de Telegram. Não é metáfora. Era literalmente um bot conectado direto à API do modelo, com um fluxo de conversa que imitava como a versão final ia funcionar dentro do produto. Quem construiu? Eu, em alguns dias, sem time de engenharia.

Trouxemos vinte criadores reais pra dentro. Pessoas que já usavam a plataforma e estavam frustradas. Disse pra eles: "isso aqui é um teste, é feio, é Telegram. Mas é o que a gente está pensando em construir. Usem por uma semana e me digam se funciona."

A primeira semana foi caótica. A segunda também. Mas alguma coisa interessante começou a aparecer: os criadores estavam ficando no bot. Voltavam todo dia. Mandavam print do que tinham gerado. Diziam "isso aqui ficou mais parecido comigo do que qualquer coisa que eu tinha tirado antes da plataforma". Isso era o sinal que eu precisava.

Quando o comportamento estabilizou, levamos pra V1. Iterações semanais sobre prompts, feedback dos vinte virando roadmap, e a feature central nasceu daí: deixar o usuário escolher qual modelo de IA usar pra texto e qual pra imagem. A gente parou de impor uma escolha técnica e devolveu o controle pro criador.

Resultado: 300 mil usuários no primeiro trimestre. Conteúdo publicado escalou cinco vezes. 1.5 milhão de dólares foi pago direto a criadores.

Nada disso teria acontecido se a gente tivesse feito o que era ortodoxo. O ortodoxo era investir mais no modelo. O certo era validar o fluxo no Telegram, com gente real, antes de tocar uma linha de código de produção.

Mesma história, outro produto

Um ano depois construí sozinha uma plataforma de mentora digital com agentes de IA pra uma fundadora do mercado de educação. Cada módulo do curso (marketing, vendas, e outros) tinha um agente especializado, com tom próprio, conhecimento próprio, e uma memória que funciona como um híbrido de ChatGPT com Notion. O agente lembra onde a aluna travou, o que tentou, o que aprendeu.

A parte técnica era complexa. A parte produto era mais ainda: a solução não podia ser um chatbot que entrega resposta pronta. O objetivo pedagógico era guiar a aluna até a resposta. A diferença é tudo.

Sabe o que eu fiz primeiro? Telegram. De novo.

Botei os agentes no Telegram via n8n, conectei à OpenAI, e coloquei algumas alunas reais pra testar. A interface era feia. O comportamento era instável. Mas em três semanas eu sabia o que estava funcionando e o que não estava. A memória híbrida nasceu de uma conversa com uma aluna que disse "queria que ele lembrasse daquela coisa que eu disse semana passada". A regra de "guiar até a resposta" nasceu de outra conversa, onde uma aluna ficou frustrada porque o agente estava cuspindo respostas prontas e ela queria entender.

Quando o comportamento ficou estável, a gente codou a interface web final como produto.

Hoje sessenta alunas usam ativamente. Sistema entregue ponta a ponta. E eu não escrevi uma linha de produção até ter certeza do comportamento.

O método em quatro passos

Depois desses dois projetos virou um padrão. Quando começo qualquer coisa nova, o fluxo é:

1. Construir a versão mais feia possível em no-code. Telegram bot, planilha, n8n, Lovable, tanto faz. Tem que rodar, tem que aceitar input de usuário real, tem que produzir output. Visual zero. Polish zero.

2. Trazer entre cinco e vinte usuários reais. Não é teste de usabilidade com pessoas que não entendem o problema. São pessoas que sentem a dor agora e estariam dispostas a pagar pela solução se ela existisse. A barra é alta de propósito.

3. Iterar até o comportamento estabilizar. Isso é o passo difícil. Não é semanas de polish, é semanas de mudança radical. Se o fluxo tá errado, descarta. Se a feature não engaja, corta. Se ninguém volta, recomeça. O objetivo é ter clareza absoluta do que tem que existir, antes de pagar o custo de construir bonito.

4. Codar com confiança. Quando você sabe exatamente o que está construindo, codar fica fácil. As decisões já foram tomadas. O risco de descobrir três meses depois que a ideia não funcionava virou zero. O time de engenharia (quando tem time) constrói uma coisa que já tem usuário esperando.

Quando isso não funciona

Não vou te vender que esse método serve pra tudo, porque não serve.

Não funciona quando o produto é puramente sobre experiência visual (um design tool, um editor, um jogo). Telegram não consegue prototipar isso.

Não funciona quando o produto depende de escala desde o dia um (infraestrutura, latência, performance). Você não valida latência no n8n.

Não funciona quando o usuário precisa de confiança institucional pra usar (banco, saúde, legal). Pessoa não vai testar coisa séria num bot do Telegram.

Pra todo o resto (que é a maior parte dos produtos de IA hoje), funciona muito bem.

Por que mais PMs não fazem isso

Acho que tem três razões.

A primeira é que a maioria dos PMs nunca aprendeu a construir nada além de PRD. Não é culpa deles. É como a profissão foi formada nos últimos quinze anos. PM virou ponte entre stakeholders e engenharia, e a habilidade de construir foi terceirizada.

A segunda é que parece amador. Telegram, planilha, fluxo feio. A primeira reação de stakeholder sênior é "isso não parece sério". Demora um pouco pra mostrar que o protótipo feio é justamente o ponto. Ele tira o stakeholder da discussão de cor de botão e força a discussão de comportamento.

A terceira é que dá medo. Validar com gente real significa que a ideia pode estar errada, e ninguém gosta de descobrir que a ideia estava errada. Mas é melhor descobrir em duas semanas no Telegram do que em três meses depois do deploy.

---

Se você é PM e quer começar a fazer isso, o atalho é simples: escolhe o próximo problema que você tem na fila, e em vez de escrever um PRD, abre o n8n e tenta resolver ele lá. Vai dar trabalho. Vai parecer que você está perdendo tempo. Mas em duas semanas você vai saber mais sobre o problema do que em seis meses de discovery tradicional.

E quando você for pra produção, você vai com confiança que a maioria dos PMs nunca tem.

Sou Sabrina Lima Bettanin. Cofundo duas empresas de IA e construo produtos sob demanda pra outras. Se você quer conversar sobre construir um produto de IA, me chama.