Como validar uma ideia antes de abrir o editor

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 teste capaz de contrariá-la. 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 precisa ter espaço para contrariar você. Caso contrário, não é evidência; é torcida.

7. Tome a decisão honesta

A decisão não precisa caber em “sim” ou “não”: continuar, quando a direção parece boa mas um risco importante ainda pede teste; fortalecer as evidências, quando a evidência está genuinamente dividida; reformular, quando o problema é real mas a sua solução não é a resposta; partir para o build, quando a hipótese mais arriscada sobreviveu a um teste de verdade; e parar, quando a evidência diz não. Registre o veredito e o porquê — você do futuro vai querer saber, e ideia parada 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 especificação que dá origem a primeira versão.

Onde o Motriz entra

É esse o trabalho que o Motriz organiza com você — as perguntas de fundador, da aposta que você está realmente fazendo até uma decisão honesta de construir e, depois, a tração real no mercado, com um cofundador de IA fazendo o trabalho pesado e cada evidência registrada na própria trajetória. Quando o veredito é construir, o escopo sustentado pela evidência segue direto para agentes de código no seu repositório de verdade. Leia o passo a passo completo em como o Motriz funciona, ou comece por por que a gente constrói a coisa errada.