Validar não é só perguntar se as pessoas gostariam da ideia?

Não, e essa é a pergunta que mais engana. As pessoas dizem sim por educação. Validação boa mede comportamento, como deixar um contato, aceitar uma reunião, pagar antecipado ou usar uma versão manual, porque comportamento custa algo a quem realiza.

Quantas pessoas preciso ouvir para ter confiança?

De dez a quinze conversas com pessoas do público certo já mostram padrões claros de problema. O critério não é o número e sim a repetição: quando três entrevistas seguidas não trazem nada novo, você já tem o essencial.

Vale a pena investir em protótipo antes de desenvolver?

Vale quando o risco está no uso e não na demanda. Se você já sabe que existe demanda mas não sabe se as pessoas entendem o fluxo, o protótipo clicável responde isso por uma fração do custo do desenvolvimento.

Como validar uma ideia antes de gastar com desenvolvimento

Antes de investir em desenvolvimento, é possível descobrir por poucos reais se alguém realmente quer o que você pretende construir. A validação útil não pergunta se a pessoa gostaria da ideia, ela mede se a pessoa muda de comportamento por causa dela: deixa um contato, aceita uma reunião, paga antecipado ou usa uma versão feita à mão. Quatro métodos cobrem quase todos os casos.

Primeiro: descubra qual é o seu risco maior

Nem toda ideia precisa do mesmo teste. Identifique onde está a maior dúvida:

Tipo de risco	Pergunta em aberto	Método adequado
Risco de problema	Esse problema dói o suficiente?	Entrevistas de problema
Risco de demanda	Alguém pagaria por isso?	Página de teste com métrica de intenção
Risco de uso	As pessoas entendem e conseguem usar?	Protótipo clicável
Risco de operação	Isso funciona quando executado?	Operação manual nos bastidores

Testar o risco errado desperdiça tempo. Se você já sabe que o problema dói (todo mundo reclama dele), pular direto para o teste de demanda economiza semanas.

Método 1: entrevistas de problema

Converse com dez a quinze pessoas do público que você pretende atender. A regra é falar do passado, não do futuro.

Perguntas que funcionam:

"Me conta a última vez que você precisou fazer isso."
"Como você resolveu?"
"Quanto tempo levou?"
"O que deu errado?"
"Você já tentou resolver de outro jeito? O que aconteceu?"
"Quanto isso te custou, em dinheiro, tempo ou dor de cabeça?"

Perguntas que enganam:

"Você usaria um sistema que faz X?" (todo mundo diz sim)
"Quanto você pagaria por isso?" (número inventado na hora)
"O que você acha da minha ideia?" (educação, não informação)

O sinal de validação forte nas entrevistas é a gambiarra existente. Quando a pessoa já montou uma planilha, um grupo de WhatsApp ou uma rotina manual para resolver aquilo, o problema é real e ela já paga o preço dele. Ideia sem gambiarra existente costuma ser um problema que ninguém sente.

Método 2: página de teste com medida de intenção

Monte uma página simples descrevendo o que a solução faz, para quem, e com um botão de ação. Direcione tráfego pago pequeno ou compartilhe com o público certo.

O que medir, em ordem crescente de valor:

Visitas, mede apenas o anúncio.
E-mail deixado, mede interesse.
Reunião agendada, mede interesse com custo de tempo.
Pré-pagamento ou carta de intenção, mede demanda de verdade.

Os dois primeiros são baratos e fracos; os dois últimos são os que importam. Em negócios entre empresas, cinco reuniões agendadas com decisores dizem mais que quinhentos e-mails coletados.

Cuidado essencial: a página precisa ser honesta. Descreva o que você pretende oferecer e o prazo real. Coletar pagamento por algo que não existe sem deixar isso claro é problema, não validação.

Método 3: protótipo clicável

Um protótipo é um conjunto de telas navegáveis, sem código e sem banco de dados. Serve para responder se as pessoas entendem o fluxo e conseguem completar a tarefa.

Como testar bem:

Dê uma tarefa, não um tour. "Cadastre um pedido com desconto de 15%" em vez de "olha aqui como funciona".
Fique calado enquanto a pessoa tenta. Cada vez que você precisa explicar, é um ponto que o produto real precisará explicar sozinho.
Teste com cinco a oito pessoas. Os mesmos problemas se repetem rápido.
Anote onde a pessoa parou, não o que ela achou.

Um protótipo custa dias e evita reconstruir telas depois de prontas, que é uma das formas mais caras de aprender a mesma coisa.

Método 4: operação manual nos bastidores

O teste mais subestimado. Ofereça o serviço de verdade, cobre por ele, e execute manualmente enquanto ninguém vê. O cliente recebe o resultado; você usa planilha, e-mail e trabalho humano por trás.

O que isso responde de uma vez só:

Alguém paga? Sim ou não, sem interpretação.
Qual é o processo real? Você descobre as exceções antes de codificar.
O que é frequente e o que é raro? O que se repete todo dia é o que vale automatizar primeiro.
Quanto custa entregar? A conta de margem aparece antes do investimento.

O limite é a escala: manual funciona até algumas dezenas de clientes. Mas esse limite é justamente o gatilho, quando o manual não dá mais conta, você tem demanda comprovada e um mapa exato do que automatizar.

Quanto tempo dedicar a cada etapa

Uma sequência realista para uma ideia nova:

Semana 1 e 2, dez a quinze entrevistas de problema.
Semana 3, página de teste no ar, medindo reuniões ou pré-venda.
Semana 4, protótipo clicável testado com cinco a oito pessoas.
Mês 2 e 3, operação manual com os primeiros clientes pagantes.
Depois disso, desenvolvimento do que se repetiu e doeu.

Ao final, você não terá uma opinião sobre a ideia. Terá uma lista de funcionalidades que pessoas reais usaram e pagaram, o que é a melhor especificação de software que existe.

Quando parar de validar e começar a construir

Três sinais indicam que a validação cumpriu o papel:

Você consegue descrever o fluxo principal em passos, porque já o executou manualmente.
Existem clientes pagando ou compromissos formais de compra.
O trabalho manual virou gargalo e está limitando o crescimento.

Se os três estiverem presentes, construir deixa de ser aposta e passa a ser otimização de algo que já funciona. Se nenhum estiver, mais desenvolvimento não vai resolver, o problema está antes do software.