Um founder me procurou depois de gastar R$80 mil num projeto que chamava de MVP. Seis meses de desenvolvimento, design bonito, onboarding com animações. Quando lançou, tinha 23 usuários. A maioria, amigos e ex-colegas. Nenhum pagou. Nenhum voltou.

O problema não era o produto. Era o que veio antes: ele construiu a solução antes de entender se alguém tinha o problema.

Essa história se repete com uma regularidade que não seria cômica se não custasse tanto. Segundo o CB Insights, 42% das startups falham porque não existia demanda real de mercado para o produto que construíram. Não foi a tecnologia. Não foi a equipe. Foi ter ignorado a pergunta mais importante — alguém realmente precisa disso? — e só perceber isso depois de gastar o dinheiro.

MVP (Produto Mínimo Viável, do inglês Minimum Viable Product) é um dos termos mais usados e menos compreendidos do ecossistema de produto. Este post destrói o mito e apresenta o caminho real: como validar uma ideia de produto digital antes de codar, com as 3 perguntas certas e o framework que usamos com founders aqui na Northern.

O que MVP significa de verdade (e o que virou no mercado)?

Eric Ries, no livro A Startup Enxuta (lean startup é o movimento que popularizou o conceito), definiu MVP como a versão de um produto que permite coletar a maior quantidade de aprendizado validado sobre clientes com o menor esforço possível. Repare: a palavra central é aprendizado, não produto.

O que aconteceu nos 15 anos seguintes foi uma distorção gradual. MVP virou sinônimo de “produto ruim feito rápido”. Agências venderam “construção de MVP” como serviço. Founders pediram “um MVP barato” como se fosse pedir um produto completo com desconto. O conceito foi esvaziado.

Na prática, o MVP original não precisa ser software. Brian Chesky e Joe Gebbia não construíram a Airbnb para validar se pessoas pagariam para dormir na casa de estranhos. Eles colocaram colchões de ar no apartamento deles durante uma conferência de design em São Francisco, tiraram fotos, criaram um site básico e cobraram US$80 por noite. Três hóspedes pagaram. Era validação suficiente.

O Buffer, hoje avaliado em centenas de milhões de dólares, começou com uma landing page e dois botões. O botão “Planos e preços” apontava para uma página de “ainda estamos construindo”. Joel Gascoigne queria saber se alguém clicaria. Clicaram. Era o sinal que precisava para começar a construir.

Nenhum dos dois exemplos envolveu código sofisticado. Os dois envolveram aprender a coisa certa, rápido. Para entender mais sobre como o conceito evoluiu, veja nosso post sobre o que é MVP produto digital.

As 3 perguntas que você precisa responder antes de escrever uma linha de código

Antes de qualquer ferramenta, qualquer framework e qualquer linha de código, existem três perguntas que separaram os produtos que funcionam dos que ficam na gaveta. Elas parecem simples. A maioria dos founders não consegue respondê-las com precisão antes de começar.

1. Quem exatamente tem esse problema?

Não “pequenas empresas”. Não “pessoas que querem ser mais produtivas”. Quem especificamente? Qual o cargo, o setor, a situação atual? Você consegue nomear agora três pessoas reais que têm esse problema e explicar por que elas pagariam para resolvê-lo? Se não, você não está pronto para construir nada.

2. Por que elas não resolvem isso com o que já existe?

Sempre existe uma alternativa. Planilha, WhatsApp, outro software, processo manual, simplesmente não fazer. Por que essa alternativa não é suficiente? Se você não sabe a resposta em detalhe — incluindo o que já tentaram e por que frustrou — você não conversou com pessoas suficientes.

3. Qual o menor sinal que provaria que você está certo?

Essa é a mais difícil. Precisa ser mensurável e alcançável em semanas, não meses. “50 pessoas dizendo que usariam” não é um sinal: intenção declarada não prediz comportamento real. Pagar, mesmo que simbólico, é sinal. Usar um protótipo por três horas sem desistir é sinal. Indicar para alguém sem ser perguntado é sinal.

Se você não definiu o menor sinal de validação antes de começar, não vai saber quando parar de testar e quando começar a construir.

O Protocolo de Validação Norte: 3 semanas para saber se sua ideia é real

Depois de acompanhar dezenas de jornadas de produto, desenvolvemos um protocolo de validação que estrutura as três semanas que antecedem qualquer decisão de construir. Chamamos de Protocolo de Validação Norte — três fases, cada uma com objetivo claro e entregável definido.

Protocolo de Validação Norte: 3 fases em 3 semanas para validar ideia de produto digital
O Protocolo de Validação Norte organiza a validação de uma ideia de produto em 3 semanas, com decisão clara ao final

Fase 1 — Mapear (Semana 1)

Objetivo: entender quem tem o problema e o que fazem hoje para resolvê-lo. O método: conduzir de 10 a 15 conversas de 30 minutos com potenciais usuários. A pergunta central não é “você usaria meu produto?” — essa pergunta só coleta educação e não evidência. A pergunta certa é: “como você resolve isso hoje?”

Ao final da semana, você deve saber: com que frequência o problema ocorre, quanto custa hoje (em tempo, dinheiro ou frustração), quais alternativas já foram tentadas e por que não funcionaram. Se você não encontrou 10 pessoas com o problema em uma semana, o mercado-alvo pode ser menor do que você imagina.

Fase 2 — Testar (Semana 2)

Objetivo: observar a reação a uma hipótese de solução sem construir nada. O método: criar algo que simula o produto. Pode ser um protótipo navegável no Figma, uma landing page de captura com proposta de valor clara, um processo manual conduzido por você — o que Eric Ries chamou de “Mágico de Oz”, onde um humano faz o que o software faria.

Apresentar para 5 a 7 pessoas do grupo identificado na Fase 1. Observar comportamento, não coletar opinião. Sinal positivo real: a pessoa pede para continuar, pergunta quando estará disponível ou, melhor ainda, oferece pagar. Opinião positiva sem ação não é validação.

Fase 3 — Decidir (Semana 3)

Cruzar as evidências. Três perguntas decisivas: o problema é real e frequente o suficiente? Existe disposição clara para pagar? A solução prototipada resolveu o problema da forma certa? Se as três respostas forem sim, construir. Se uma for não, pivotar: qual hipótese estava errada? Se duas ou três forem não, pausar: o produto certo pode existir, mas a hipótese atual não é ela.

Três semanas. Sem código. Com uma decisão fundamentada em evidências, não em otimismo.

Quando o MVP faz sentido e quando você está desperdiçando dinheiro

O Protocolo de Validação Norte funciona quando a hipótese é clara e testável. Não funciona quando o founder ainda está tentando definir qual problema quer resolver.

MVP faz sentido quando você tem uma hipótese específica sobre quem tem o problema e por que a solução existente não serve. Nesses casos, o protocolo ajuda a confirmar ou refutar a hipótese rapidamente, com custo baixo.

Mas existe uma armadilha comum: o “MVP caro”. Acontece quando alguém diz “meu MVP já está pronto, só preciso de usuários”. Isso não é MVP. É produto sem validação prévia. A sequência foi invertida: a construção antecedeu o aprendizado. O R$80 mil do founder que mencionei na abertura foi gasto exatamente assim.

Outro sinal de alerta: quando você precisa construir algo para conseguir explicar a ideia. Se a solução é tão complexa que não dá para descrever em palavras e testar com protótipo, o problema ainda não foi entendido com clareza suficiente. Construir nesse estado é apostar num problema que você não sabe se existe.

O que diferencia um produto que vira negócio de um que fica na gaveta

Não é a tecnologia. Não é o design. Não é o tamanho do time ou o quanto foi investido.

É uma coisa: a pessoa certa tem o problema grave o suficiente para pagar para resolver. Tudo o mais é consequência disso. Um produto tecnicamente imperfeito, lento e feio que resolve um problema real e urgente vai encontrar usuários. Um produto lindo e bem construído que resolve um problema que ninguém tem ficará na gaveta com muito mais estilo do que o necessário.

Os founders que constroem produtos que viram negócio têm um padrão em comum: eles passaram mais tempo falando com clientes do que com desenvolvedores no início. Não porque seguiram uma metodologia, mas porque tinham curiosidade genuína sobre o problema que estavam tentando resolver. O lean startup como filosofia parte exatamente dessa premissa — para entender o conceito mais a fundo, vale ler nosso post sobre startup enxuta.

A pergunta que todo founder deveria fazer antes de pedir um orçamento de desenvolvimento: “Se eu mostrar isso para 10 potenciais clientes amanhã, algum deles vai querer usar de novo?” Se a resposta for “não sei” ou “acho que sim”, o Protocolo de Validação Norte começa antes, não depois, da primeira linha de código.

Tem uma ideia de produto? Vamos entender juntos se ela está pronta para ser construída.

A Northern trabalha com founders na fase de validação: conduzimos o Protocolo de Validação Norte com você, estruturamos as entrevistas, analisamos os sinais e ajudamos a decidir se faz sentido construir, pivotar ou pausar. Antes de qualquer linha de código.

Falar com a Northern

Perguntas frequentes sobre MVP e validação de produto digital

MVP (Minimum Viable Product, ou Produto Mínimo Viável) é a versão de um produto que permite coletar o maior aprendizado sobre clientes com o menor esforço. O conceito foi popularizado por Eric Ries no movimento lean startup. Na prática, MVP não é um produto barato ou incompleto: é um experimento desenhado para responder uma hipótese específica sobre quem tem o problema e se vai pagar para resolvê-lo.

Protótipo é uma representação visual ou funcional do produto para testar usabilidade e design. MVP é um experimento para testar uma hipótese de negócio: o problema existe? As pessoas pagam? O protótipo pode ser parte de um MVP, mas MVP pode ser também uma landing page, um processo manual ou uma venda real antes de qualquer desenvolvimento. O objetivo do protótipo é design; o objetivo do MVP é aprendizado de mercado.

Porque 42% das startups falham por falta de demanda real de mercado, segundo o CB Insights (2024). Desenvolver sem validar é apostar meses de trabalho e dezenas de milhares de reais numa hipótese não testada. Validar primeiro permite descobrir se o problema existe, se as pessoas pagam e se a solução resolve da forma certa — com custo muito menor do que desenvolver um produto completo.

Os mais comuns: construir antes de validar (invertendo a ordem correta), colocar funcionalidades demais no MVP por querer impressionar, confundir intenção declarada com validação real, não definir antes o sinal mínimo de sucesso, e tratar o MVP como versão barata do produto completo em vez de experimento. O resultado costuma ser produto com custo de produto e aprendizado zero.

Quatro técnicas comprovadas: entrevistas de problema com 10 a 15 potenciais usuários perguntando como resolvem hoje, landing page de captura medindo conversão, protótipo navegável no Figma apresentado para 5 a 7 pessoas do público-alvo, ou processo manual conduzido por você (chamado de “Wizard of Oz MVP”). Em todos os casos, o sinal real é comportamento — usar, pagar, indicar — não opinião.

A fase de validação pode ser conduzida com custo próximo de zero usando ferramentas gratuitas de entrevista e protótipo. O desenvolvimento de um MVP funcional no Brasil varia de R$30 mil a R$150 mil dependendo da complexidade, equipe e prazo. O custo real de um MVP mal planejado não está no desenvolvimento: está nos meses de trabalho investidos depois de descobrir que não havia demanda real.

Com o Protocolo de Validação Norte, a fase de validação leva 3 semanas: uma semana para mapear o problema com entrevistas, uma para testar a hipótese com protótipo ou processo manual, e uma para cruzar aprendizados e decidir. Esse prazo assume dedicação parcial do founder e pode poupar de 3 a 12 meses de desenvolvimento mal direcionado.

O sinal mais confiável é disposição para pagar, mesmo que simbólica, antes do produto estar pronto. Outros sinais fortes: usuários voltando espontaneamente para usar um protótipo, recomendação para outras pessoas sem ser solicitado, e pedidos explícitos de funcionalidades adicionais. Opiniões positivas em entrevistas não são sinal suficiente: quase todo mundo diz que usaria algo novo se for gentil com o entrevistador.

Quando a construção antecede a validação. Se você já desenvolveu o produto e só agora está tentando encontrar usuários, o MVP já passou: você tem um produto sem mercado confirmado. Também vira desperdício quando não há hipótese clara para testar — se você não sabe o que quer aprender com o MVP, não vai reconhecer o aprendizado quando ele aparecer. MVP sem hipótese é produto ruim com nome acadêmico.

Uma variável: a pessoa certa tem o problema grave o suficiente para pagar para resolver. Um produto tecnicamente imperfeito que resolve um problema real vai encontrar usuários. Um produto bem construído que resolve um problema inexistente vai ficar na gaveta. Os founders que acertam têm em comum ter passado mais tempo falando com potenciais usuários do que com desenvolvedores antes de escrever a primeira linha de código.

Conclusão

MVP não é sobre construir rápido. É sobre aprender rápido a coisa certa. A diferença entre o founder que gastou R$80 mil num produto que ninguém usou e o Brian Chesky que alugou colchões de ar num apartamento não foi orçamento nem tecnologia. Foi a ordem das perguntas.

Chesky perguntou “alguém paga por isso?” antes de construir qualquer coisa. A resposta foi sim. Aí ele construiu.

O Protocolo de Validação Norte não é uma garantia de sucesso. É uma forma de descobrir o erro cedo, quando ele ainda custa pouco. Três semanas de validação podem poupar de seis a doze meses de desenvolvimento mal direcionado. Se você tem uma ideia de produto e a primeira coisa que fez foi pedir um orçamento de desenvolvimento, vale dar um passo atrás.