Validação não responde 'a ideia é boa?' — responde qual suposição derruba o resto se for falsa e qual é o teste mais barato para descobrir. Este artigo traz cinco prompts para as cinco etapas: achar a hipótese mais cara, escrever roteiro de comportamento (nunca de opinião), testar uso com tarefa em vez de demonstração, estruturar beta com critério de saída, e ler o resultado contra um corte definido antes. A regra que atravessa todos é restritiva: o modelo não decide se o produto vale a pena, não inventa dado, e não recebe dado de participante.
- MVP não é uma versão pequena do produto: é o menor teste da hipótese mais cara — que quase nunca é a técnica.
- 'Você usaria isso?' é cortesia, não validação. Só comportamento passado conta: o que já fez, o que já pagou, a gambiarra que já montou.
- Grupo focal mede o grupo, não o mercado: sem regra de moderação, a pessoa mais confiante da sala define a opinião das outras.
- No momento em que você explica durante um teste de usabilidade, o teste acabou — daí em diante você mede a sua explicação.
- Beta sem critério de saída vira beta eterno, que é quase sempre uma desculpa educada para não começar a cobrar.
- Sem número de corte escrito antes, qualquer resultado vira confirmação do que você já queria fazer.
- Dado de participante (nome, e-mail, empresa, gravação) não entra no prompt: é dado pessoal de terceiro, e a responsabilidade é de quem coletou.
Validar não é perguntar se a ideia é boa
Cole a sua ideia num modelo e pergunte se ela tem futuro: ele vai dizer que sim, com a confiança de um relatório. O problema não é o modelo mentir, é a pergunta errada. Validação não responde “a ideia é boa?”, e sim “qual suposição, se for falsa, joga fora o resto — e como descobrir isso mais barato?”.
Daí a regra restritiva dos cinco prompts abaixo: o modelo não decide se o produto vale a pena nem inventa dado que você não coletou. E nenhum dado de participante entra no prompt — nome, e-mail, empresa e gravação são dados pessoais de terceiro; cola-se transcrição anonimizada, com consentimento pedido antes.
1. Descobrir qual suposição é a mais cara
Me ajude a escolher o que testar primeiro no meu produto.
IDEIA EM UMA FRASE: [descreva]
QUEM EU ACHO QUE É O CLIENTE: [descreva]
COMO ELE RESOLVE ISSO HOJE: [até "planilha" ou "não resolve"]
O QUE JÁ ESTÁ PRONTO: [nada também é resposta]
Entregue: (1) as suposições embutidas na ideia, separando as
de DESEJO, de CAPACIDADE DE PAGAR e as técnicas; (2) o
estrago de cada uma se for falsa; (3) qual é a mais cara — a
que derruba as outras; (4) o menor teste que responde essa,
sem escrever código; (5) o que esse teste NÃO prova.
Não avalie se a ideia é boa. Não estime tamanho de mercado.O item 3 corrige o erro mais caro de fundador técnico: MVP não é versão pequena do produto, é o menor teste da hipótese mais cara — e a mais cara quase nunca é técnica. É “alguém muda de rotina” ou “alguém tira dinheiro do bolso”, e nenhuma exige código. Ponto de partida em prompts para desenvolver um produto mínimo viável.
2. Roteiro que pergunta comportamento, não opinião
Escreva o roteiro de uma conversa de 30 minutos com um
possível cliente.
PROBLEMA QUE EU INVESTIGO: [descreva]
COM QUEM EU VOU FALAR: [papel e contexto, sem nome]
O QUE EU PRECISO DESCOBRIR: [liste]
Regras: (1) só perguntas sobre o que a pessoa JÁ fez —
última vez que aconteceu, o que fez, quanto custou; (2)
nenhuma pergunta hipotética e nenhuma menção à minha solução;
(3) marque as perguntas em que eu vou querer interromper para
explicar, com um lembrete de não explicar; (4) se eu ouvir
várias pessoas juntas, a regra para evitar que a mais
confiante da sala defina a opinião das outras.
Depois liste as 3 perguntas que dariam falso positivo.“Você usaria isso?” não é validação, é cortesia. O que não mente é comportamento passado: o que já pagou, a gambiarra que montou para não passar por aquilo — gambiarra em produção é o sinal mais forte que existe, porque custou trabalho a alguém. A regra 4 existe porque grupo focal mede o grupo, não o mercado. Variações em prompts para conduzir grupos focais.
3. Teste de uso, não demonstração
Monte um teste de usabilidade do que eu já tenho no ar.
O QUE EXISTE: [tela, protótipo, formulário, landing]
O QUE O USUÁRIO PRECISA CONSEGUIR FAZER: [liste]
QUEM VAI TESTAR: [papel, familiaridade com o tema]
Entregue: (1) de 3 a 5 TAREFAS escritas do ponto de vista do
usuário, sem citar o nome dos botões; (2) o que conta como
concluída e o que conta como falha; (3) o que registrar
quando a pessoa trava; (4) a frase que eu digo quando ela
perguntar como faz — sem ensinar; (5) quantas pessoas bastam
nesta rodada.
Não escreva roteiro de apresentação do produto.O item 4 é o mais difícil e o mais valioso: no momento em que você explica, o teste acabou — daí em diante você mede a sua explicação. Por isso as tarefas não citam botões: “clique em Publicar” testa se a pessoa sabe ler; “coloque este artigo no ar” testa se a interface conta a própria história. Mesmo cuidado na entrega ao cliente, em prompts para a entrega de um site. Referência em prompts para realização de testes de usabilidade.
4. Beta com data de fim escrita antes do começo
Estruture o beta do meu produto.
O QUE ENTRA NO BETA: [funcionalidades]
O QUE EU QUERO APRENDER: [liste, em ordem]
PRAZO E TAMANHO: [quanto tempo, quantas pessoas]
Entregue: (1) critério de ENTRADA — quem serve e quem
atrapalha; (2) o que eu prometo e o que aviso que não
funciona; (3) por onde se reclama e em quanto tempo eu
respondo; (4) critério de SAÍDA: o que precisa ser verdade
para o beta acabar, e o que faz eu cancelar antes; (5) o que
acontece com os dados e a conta de quem testou.
Marque [DEFINIR] o que eu não informei.O item 4 separa beta de limbo: beta sem critério de saída vira beta eterno — quase sempre desculpa educada para não cobrar. O item 1 economiza meses: amigo animado não é participante, é torcida, e torcida não reclama. O que fazer com o canal do item 3 está em prompts para o suporte parar de repetir resposta. Mais em prompts para realizar testes beta.
5. Ler o resultado sem se enganar
Organize o resultado do teste que eu acabei de rodar.
O QUE EU TESTEI: [descreva]
O QUE DEFINI COMO SUCESSO ANTES DE COMEÇAR: [cole; se não
defini, diga isso]
DADOS BRUTOS: [números e falas ANONIMIZADAS]
Entregue: (1) o que os dados sustentam; (2) o que eu estou
concluindo além disso; (3) o que ficou sem resposta; (4) qual
fatia dos participantes produziu o resultado — e se foi
sempre a mesma; (5) a decisão que cabe agora: seguir,
ajustar e repetir, ou parar.
Se eu não tinha critério de sucesso definido antes, comece
dizendo que este teste não decide nada.A última instrução é a mais importante do artigo. Sem número de corte escrito antes, qualquer resultado vira confirmação: 4 de 10 é “promissor” se você queria seguir e “fraco” se já estava cansado. O item 4 pega o autoengano seguinte: três respostas entusiasmadas da mesma pessoa não são três dados. Detalhamento em prompts para análise de resultados de testes.
O que os cinco têm em comum
Nenhum pede opinião ao modelo sobre o produto, e é isso que mantém a saída utilizável. Alimentado com “o que você acha da minha ideia”, um LLM devolve aprovação — o que ele fabrica mais barato e o único produto que não serve para nada. Teste que não pode dar errado não é teste, é apresentação.
Se o gargalo já é o seu dia e não a ideia, o recorte é outro: prompts para quem toca a startup sozinho. Se já existe time a distância, prompts para time remoto segue a mesma regra restritiva.
Perguntas frequentes
Posso colar as respostas da minha pesquisa de usuários no ChatGPT?
Só anonimizadas, e só se você avisou antes. Nome, e-mail, cargo específico, nome da empresa e gravação de call são dados pessoais de um terceiro: colá-los numa ferramenta pública tira esse dado do controle da sua empresa, e a responsabilidade é de quem coletou, não da ferramenta. O caminho prático é remover identificadores da transcrição antes de colar e pedir consentimento explícito no começo da conversa, dizendo que a transcrição será analisada com apoio de IA. Em pesquisa de produto isso não custa nada: o que interessa no depoimento é o comportamento descrito, não quem descreveu.
A IA pode me dizer se minha ideia de produto vai dar certo?
Não, e pedir isso é o uso que mais estraga a validação. Um modelo de linguagem responde com o que é plausível no texto, e texto sobre ideias de produto é quase todo otimista — o resultado é uma aprovação bem escrita que você vai confundir com evidência. Pior: estimativa de mercado gerada assim sai com número redondo e sem fonte, e número sem fonte em deck de investidor é um problema seu, não do modelo. O que a IA faz bem aqui é desenhar o teste, escrever o roteiro e organizar o que voltou. A resposta sobre o futuro do produto vem de gente usando coisa.
Qual a diferença entre este artigo e o de quem toca a startup sozinho?
São dois momentos diferentes. O artigo do fundador sozinho trata de operar o que já existe com pouca gente: caixa, prioridade, contratação, roadmap. Este trata da etapa anterior, quando ainda não está claro se vale construir — hipótese, entrevista, teste de uso, beta e leitura do resultado. Se você já tem cliente pagando e o gargalo é o seu dia, o outro recorte serve melhor. Se você tem uma ideia e a vontade de começar a codar amanhã, comece por aqui: a etapa que os cinco prompts cobrem é justamente a que costuma ser pulada.
Quantas pessoas eu preciso ouvir para validar?
Depende do que você está testando, e essa é a resposta honesta. Para achar problema grosso de usabilidade, 5 pessoas do perfil certo já mostram a maior parte — e a sexta costuma travar no mesmo lugar que as outras. Para decidir se existe demanda, número pequeno não decide nada: o que decide é comportamento verificável, como alguém pagar, assinar uma carta de intenção ou abandonar a gambiarra atual. Mais importante que a quantidade é a regra do quinto prompt: escreva antes quantos precisam passar para você considerar validado. Definir isso depois é escolher o resultado.
