Uma ideia de software costuma chegar disfarçada de solução: uma lista de telas, integrações, automações e recursos que parecem inevitáveis. O problema é que essa lista descreve o que alguém deseja construir, não o que outra pessoa precisa usar.
Validar uma ideia é reduzir essa distância. O objetivo não é provar que você estava certo. É descobrir, com o menor custo possível, se existe um problema relevante, para quem ele é relevante e qual mudança faria alguém adotar uma solução.
Validação não é pedir aprovação
Perguntar “você usaria este aplicativo?” quase sempre produz respostas otimistas. A pessoa quer colaborar, imagina um futuro ideal e não precisa pagar, migrar dados ou mudar a rotina naquele momento.
Uma conversa útil investiga comportamento passado e fricção presente. Em vez de apresentar a solução cedo demais, procure entender:
- quando o problema aconteceu pela última vez;
- como ele é resolvido hoje;
- quanto tempo, dinheiro ou energia essa solução improvisada consome;
- quem sente a dor e quem decide pela compra;
- o que já foi tentado e por que não permaneceu.
Opinião é um sinal. Comportamento é evidência mais forte. Uma pessoa que improvisa uma planilha há meses, paga por uma ferramenta incompleta ou repete uma tarefa manualmente está mostrando que o problema ocupa espaço real.
1. Transforme a ideia em uma hipótese
Antes de escrever código, formule uma frase que possa estar errada. Um formato simples é:
Acreditamos que [tipo de pessoa] enfrenta [problema observável] com frequência suficiente para adotar [mudança proposta]. Saberemos que isso é verdade quando [comportamento mensurável] acontecer.
“Criar um ERP completo para escolas” é uma intenção ampla. “Coordenadores de escolas pequenas perdem horas conciliando matrícula, contrato e cobrança em ferramentas separadas” é uma hipótese investigável.
Essa mudança de linguagem importa porque obriga a equipe a nomear o público, o problema e a evidência esperada. Também revela quantas suposições estavam escondidas dentro da ideia original.
2. Encontre as pessoas certas
Cinco conversas com pessoas que vivem o problema podem ensinar mais do que cinquenta respostas genéricas. O recorte precisa ser específico o bastante para que os relatos sejam comparáveis.
Comece pelo contexto em que a dor acontece: tamanho da operação, frequência da tarefa, ferramenta atual e responsabilidade da pessoa. Uma recepcionista, um gestor e o dono de uma academia podem enxergar o mesmo processo de maneiras completamente diferentes.
Registre frases literais, exemplos e exceções. Não transforme toda resposta em confirmação. Se ninguém consegue lembrar da última vez em que o problema ocorreu, talvez ele não tenha a urgência imaginada. Se cada pessoa descreve uma dor diferente, o segmento ainda está amplo demais.
3. Construa o menor teste que produz aprendizado
MVP não significa necessariamente uma versão pequena do produto final. Significa o menor mecanismo capaz de testar a incerteza mais perigosa.
Se a dúvida é compreensão, uma tela navegável pode bastar. Se é disposição para mudar o processo, um serviço manual por trás de uma interface simples pode ser mais honesto. Se é viabilidade técnica, um protótipo isolado deve atacar a integração ou o desempenho antes de qualquer acabamento.
Alguns testes possíveis:
- uma página que explica a proposta e mede pedidos de acesso;
- um protótipo clicável usado durante uma tarefa real;
- uma operação assistida manualmente para observar o fluxo completo;
- uma importação de dados de exemplo para medir complexidade e erros;
- uma pré-venda ou carta de intenção, quando houver confiança e contexto para isso.
O teste deve parecer real o suficiente para exigir uma decisão, mas pequeno o suficiente para ser descartado sem apego.
4. Defina o sinal antes de executar
Sem um critério prévio, qualquer resultado pode virar uma história conveniente. Defina o que será observado, por quanto tempo e qual resultado muda a próxima decisão.
Evite métricas de vaidade desconectadas da hipótese. Visitas e curtidas podem ajudar a entender alcance, mas não demonstram que alguém completou uma tarefa, voltou ao produto ou pagou por valor.
Para um teste inicial, sinais mais úteis podem incluir:
- pessoas que chegam ao fim do fluxo sem ajuda;
- tempo necessário para concluir a tarefa principal;
- retorno espontâneo depois da primeira experiência;
- dados reais que alguém aceita importar;
- convite de outro membro da equipe;
- compromisso concreto de piloto, pagamento ou agenda.
Um protocolo de quatro etapas
Na TestaAí, o processo editorial cabe em quatro verbos:
- Idear: registrar a hipótese e a incerteza central.
- Construir: criar somente o necessário para tornar o teste possível.
- Testar: colocar o mecanismo diante do contexto real e observar comportamento.
- Evoluir: continuar, alterar ou encerrar com base no que apareceu.
O valor desse protocolo está na repetição. Ele impede que meses de execução escondam uma pergunta que poderia ter sido respondida em dias.
Quando continuar, mudar ou parar
Continuar faz sentido quando o mesmo problema aparece repetidamente, o teste provoca comportamento compatível com a hipótese e o próximo investimento reduz uma incerteza relevante.
Mudar faz sentido quando há dor, mas o público, o momento ou a solução proposta não encaixam. Parar também é resultado válido: às vezes o problema é raro, a mudança de hábito custa demais ou a operação necessária contradiz o tipo de negócio que se deseja construir.
O aprendizado precisa terminar em uma decisão explícita. “Vamos pensar mais” costuma apenas adiar a conversa.
O próximo teste
Se você tem uma ideia hoje, não comece pela arquitetura completa. Escreva a hipótese em uma frase, escolha três pessoas que viveram o problema recentemente e defina a evidência que faria você investir mais uma semana.
Depois, construa somente o teste. É assim que uma ideia deixa de ser uma promessa e começa a virar produto.
Veja também o manifesto da TestaAí e acompanhe os experimentos em movimento.
