Blog · Validação de ideias

Como validar uma ideia antes de escrever a primeira linha de código

Validar não é passar um semestre fazendo pesquisa de mercado. Feito com honestidade, são alguns dias focados fazendo as perguntas certas na ordem certa — e com coragem para ouvir as respostas. A ordem é esta.

O objetivo da validação não é provar que a sua ideia é boa. É descobrir se ela está errada gastando o mínimo possível. Essa inversão muda tudo: se você sair atrás de confirmação, vai encontrar — você está empolgado, sabe argumentar e seus amigos são educados. Procure o tiro fatal. Se a ideia sobreviver, você constrói com confiança de verdade. Se não sobreviver, acabou de economizar semanas.

1. Descreva a ideia em uma frase

Uma frase: para quem é e o que resolve. Sem arquitetura, sem lista de funcionalidades. Se a frase precisa de um "e" para ficar de pé, você tem duas ideias — escolha uma. Depois complete com mais duas frases: o que essas pessoas fazem hoje diante do problema e por que isso não basta. Se você não sabe responder o "hoje", essa é a sua primeira tarefa de pesquisa, não um detalhe para depois.

2. Nomeie a pessoa, não o mercado

"Desenvolvedores" não é cliente. "Dev backend que toca um SaaS sozinho e sofre todo mês na hora de emitir nota" é. O teste: você consegue listar cinco pessoas ou comunidades reais que batem com essa descrição? Se não consegue apontar para elas, não consegue conversar com elas — e sem conversar, tudo o que vem depois é ficção.

3. Mapeie o que já existe

Concorrente é sinal de que existe mercado — campo vazio costuma ser alerta, não oportunidade. Liste o que a sua pessoa usa hoje, incluindo o que não tem glamour nenhum: a planilha, o grupo de WhatsApp, o "a gente vai levando". A sua brecha está onde as soluções atuais falham de verdade, e o custo de troca existe: a pergunta honesta nunca é "o meu é melhor?", e sim "o meu é melhor o suficiente para uma pessoa ocupada largar o que já usa?"

4. Encontre a hipótese mais arriscada

Toda ideia se apoia numa pilha de hipóteses: o problema incomoda, incomoda com frequência suficiente para importar, as pessoas vão mudar de hábito, vão pagar, você consegue chegar até elas. Ordene por "se isso for falso, desmorona tudo". A do topo é a sua hipótese mais arriscada — e quase nunca é "será que eu consigo construir?". Você sabe programar; claro que consegue. Justamente por isso a tentação é testar a hipótese errada primeiro.

5. Desenhe o teste mais barato capaz de derrubá-la

Agora desenhe o menor experimento capaz de provar que essa hipótese está errada. Cinco conversas com pessoas que vivem o problema — perguntando o que elas fazem hoje, sem fazer pitch. Uma landing page descrevendo o produto com um pouco de tráfego pago. Uma versão concierge, em que você mesmo faz o trabalho na mão por trás dos panos. Defina o critério antes de rodar: "se menos de três em cinco descreverem essa dor sem eu sugerir, eu paro." Teste que não pode falhar não é teste — é ritual.

6. Encare a evidência

Anote o que você aprendeu ao lado do que tinha previsto, e guarde num lugar que dure — não no histórico do chat. Cuidado com as duas fugas clássicas: contar gentileza como demanda ("que legal, eu usaria" não vale nada; "posso usar hoje?" vale muito) e mudar o critério depois que o resultado chega. A evidência tem licença para discordar de você. Foi para isso que você a chamou.

7. Tome a decisão honesta

Existem quatro vereditos, não dois: construir, quando a hipótese mais arriscada sobreviveu a um teste de verdade; validar mais, quando a evidência está genuinamente dividida; pivotar, quando o problema é real mas a sua solução não é a resposta; e encerrar, quando a evidência diz não. Registre o veredito e o porquê — você do futuro vai querer saber, e ideia enterrada tem mania de voltar com contexto novo. Se o veredito for construir, o trabalho que você acabou de fazer não é burocracia: o problema, o cliente, a evidência e o escopo são a spec de onde nasce a primeira versão.

Onde a Motriz entra

É exatamente essa a jornada que a Motriz percorre com você — nove perguntas de fundador, do primeiro contexto até um veredito honesto de construir ou parar, com um cofundador de IA fazendo o trabalho pesado e cada evidência registrada na própria jornada. Quando o veredito é construir, a spec comprovada segue direto para agentes de código no seu repositório de verdade. Leia o passo a passo completo em como a Motriz funciona, ou comece por por que a gente constrói a coisa errada.

Tem uma ideia esperando o primeiro teste honesto?

Baixar Motriz para macOS

Grátis durante o early access · Sem conta · Próximo: matar ideias cedo