GitHub

A maioria dos aplicativos corporativos não fracassa por causa de código ruim. Fracassa porque ninguém validou, antes de assinar o contrato, se o produto resolvia um problema que alguém estava disposto a pagar para resolver.

Tenho visto esse roteiro se repetir em empresas de portes muito diferentes. Um diretor traz uma ideia convincente, o time monta um escopo, a área de tecnologia estima prazo e custo, o orçamento é aprovado. Seis meses depois, existe um app funcional, bonito, dentro do prazo, e quase ninguém usa. O projeto foi um sucesso de execução e um fracasso de produto.

Este texto é para quem decide. Se você aprova orçamento, cobra resultado ou responde pela conta no fim do trimestre, a validação de ideia não é uma formalidade técnica que o time de produto resolve sozinho. É uma decisão de alocação de capital, e merece o mesmo rigor que você aplicaria a qualquer outro investimento relevante.

Por que validar é uma decisão financeira, não um detalhe de produto

Construir software é caro, mas o custo de construção raramente é o maior risco. O maior risco é o custo de oportunidade: cada time alocado em um app que ninguém quer é um time que não está resolvendo outro problema real da empresa.

Quando uma organização decide investir em um aplicativo sem validar a ideia, ela está fazendo uma aposta. Apostas fazem parte de qualquer negócio. O problema é apostar alto sem nenhuma evidência, quando seria possível apostar baixo primeiro, comprar informação barata e só então decidir se vale a pena apostar alto.

Validação, vista por esse ângulo, é gestão de risco. Você gasta pouco para descobrir se o problema existe, se o público se importa e se o modelo fecha, antes de comprometer o orçamento cheio. É a diferença entre testar a temperatura da água e mergulhar de cabeça.

A tese: a empresa deve comprar evidência antes de comprar produto

Minha posição é direta. Antes de aprovar a construção de um aplicativo, a empresa deveria exigir evidência de três coisas: que o problema é real e relevante, que existe um público disposto a mudar de comportamento, e que há um caminho plausível de retorno.

Nenhuma dessas três respostas exige construir o app inteiro. Todas podem ser respondidas com investimento pequeno e prazo curto. Quem inverte essa ordem, constrói primeiro, descobre depois, está terceirizando para o mercado uma pergunta que poderia ter respondido no escritório, por uma fração do custo.

Isso não significa engessar a inovação com burocracia. Significa que o entusiasmo do patrocinador da ideia precisa ser confrontado com evidência antes de virar uma linha de orçamento.

O que a empresa precisa validar antes de aprovar o investimento

O problema é real e vale dinheiro

A primeira pergunta não é "o app é uma boa ideia?", mas "que problema, de quem, com que frequência e que custo?". Um problema que incomoda raramente justifica um produto. Um problema que custa caro, acontece com frequência e não tem solução boa é onde mora o retorno.

Em uma empresa, isso significa conversar com as pessoas que vivem o problema, clientes, operadores, áreas internas, antes de qualquer mockup. Se a dor não aparece de forma consistente nessas conversas, o app não vai criá-la.

O erro comum aqui é validar a solução em vez do problema. Pergunte "você usaria um app que faz X?" e quase todo mundo diz que sim, por educação. Pergunte "como você resolve isso hoje e quanto isso te custa?" e a verdade aparece.

Existe público e ele está disposto a mudar de comportamento

Todo aplicativo pede uma mudança de hábito de quem vai usá-lo. Mudar hábito é difícil, mesmo quando a solução é melhor. Validar significa entender se a dor é grande o suficiente para vencer a inércia.

Um teste honesto é observar se as pessoas já tentam resolver o problema por conta própria, com planilhas, grupos de mensagem, processos manuais improvisados. Esse esforço espontâneo é o sinal mais confiável de demanda real. Onde existe gambiarra, costuma existir mercado.

Há um caminho de retorno que fecha a conta

Aqui é onde a decisão corporativa se diferencia do entusiasmo. Um app pode resolver um problema real e ainda assim não fazer sentido financeiro. A validação precisa estimar, mesmo que de forma grosseira, como o investimento volta: receita nova, redução de custo, retenção de cliente, eficiência interna.

Se ninguém na mesa consegue explicar como o app paga a própria conta em um horizonte razoável, isso não é um detalhe a resolver depois. É um motivo para não aprovar ainda.

Como validar com pouco dinheiro e prazo curto

Validar é barato comparado a construir. Entrevistas com clientes reais, uma página de captura para medir interesse, um protótipo navegável sem código por trás, um piloto manual em que a equipe executa nos bastidores o que o app faria, todas essas táticas geram evidência por um custo marginal.

O objetivo não é provar que a ideia é boa. É tentar derrubá-la com o menor gasto possível. Uma ideia que sobrevive a tentativas honestas de invalidação é uma ideia em que vale a pena investir. Times que validam para confirmar o que já queriam ouvir não estão validando, estão coletando aplausos.

Um piloto pequeno, com um grupo limitado de usuários reais, costuma ensinar mais do que meses de discussão interna. É também onde a empresa descobre os custos escondidos: integração com sistemas legados, suporte, treinamento, manutenção, itens que raramente aparecem na estimativa inicial e que pesam no orçamento real.

Os riscos que a validação não elimina, mas torna visíveis

Validar reduz risco, não o zera. Vale ser honesto sobre os limites.

O primeiro risco é validar o problema errado de forma convincente. Um patrocinador influente pode conduzir a conversa para a resposta que deseja. Por isso a validação precisa de independência: quem coleta a evidência não pode ser quem mais quer ouvir o "sim".

O segundo é a falsa precisão. Pesquisas com números bonitos dão sensação de certeza, mas decisão de produto se apoia em sinais qualitativos consistentes mais do que em métricas ininfladas no início. Cuidado com slides cheios de percentuais que não resistem a uma pergunta.

O terceiro é cultural. Em organizações onde questionar a ideia do chefe é arriscado, a validação vira teatro. O time finge testar, todos fingem acreditar, e o aprendizado real só chega quando o produto já está no mercado e o dinheiro, gasto. Validação só funciona quando a empresa aceita ouvir "não" cedo, inclusive de quem propôs a ideia.

Há ainda a questão de dados e conformidade. Se o app vai coletar informações de clientes ou cidadãos, a LGPD entra na conta desde a validação, não como um carimbo no fim. Descobrir tarde que o modelo de dados é inviável legalmente é caro e evitável.

Validar é proteger foco, não atrasar inovação

A objeção mais comum à validação é que ela atrasa. Na prática, o que atrasa a inovação de verdade é construir a coisa errada e ter que recomeçar. Validação bem feita é o caminho mais rápido para o investimento certo, porque elimina cedo as apostas que iam custar caro e entregar pouco.

A pergunta que um líder deveria fazer antes de aprovar o orçamento de um app não é "quanto custa construir?". É "o que precisamos saber para ter confiança de que vale a pena construir, e qual é a forma mais barata de descobrir isso?". Quem aprende a fazer essa pergunta para de financiar produtos órfãos e passa a financiar apostas com evidência.

Se a sua empresa está prestes a investir em um aplicativo e a conversa começou pelo escopo técnico em vez do problema de negócio, talvez valha a pena pausar e validar primeiro. Tenho outros textos no blog sobre roteiros de validação e construção de produto, e fico à disposição para trocar ideias com quem está nesse ponto de decisão.

Validação de ideia de aplicativo: o que uma empresa deve decidir antes de investir