Discovery ou MVP: por onde começar quando tempo e budget são curtos

Resposta direta: Não é escolha entre um ou outro. O Discovery reduz o risco de construir o MVP errado; o MVP valida no mercado o que o Discovery apontou. Com budget curto, a sequência certa é um Discovery enxuto, de escopo fechado, antes do código. Pular essa etapa costuma custar o dobro: você paga o MVP e paga o retrabalho.

A pergunta está errada

"Discovery ou MVP" soa como uma decisão de alocação: onde eu coloco o dinheiro que tenho. Mas os dois não competem pelo mesmo orçamento porque não respondem à mesma pergunta.

• O Discovery responde: o que vale a pena construir, para quem, e qual é o risco de estarmos errados.
• O MVP responde: o mercado usa e paga por isso quando está no ar.

Um é redução de risco antes do investimento pesado. O outro é validação com dinheiro real, usuário real, churn real. Tratar isso como dicotomia é como perguntar se você prefere o mapa ou o carro. O carro sem mapa anda, só que provavelmente na direção errada, queimando combustível que você não tem sobrando.

A discussão honesta não é "qual dos dois", é quanto de cada um, em que ordem, com o caixa que existe.

O que acontece quando você pula o Discovery

A CB Insights, ao analisar os post-mortems de mais de 100 startups que fecharam, encontrou falta de necessidade de mercado em 42% dos casos, uma das principais causas de morte. Traduzindo: gente competente construiu, com qualidade, algo que ninguém precisava. O problema não foi execução. Foi direção.

Quando o MVP nasce sem nenhuma investigação antes, três contas começam a correr contra você:

• Custos Invisíveis. Cada funcionalidade construída sobre uma hipótese não verificada é dinheiro que não aparece como perda no relatório, mas que já foi. O usuário não reclama do que está errado. Ele some: 88% dos usuários não voltam depois de uma experiência ruim.
• Dívida Técnica desde o dia 1. Decidir arquitetura, modelo de dados e fluxo principal no escuro significa que a primeira versão já nasce comprometida. E dívida técnica não é abstração contábil: ela consome até 40% do orçamento de TI.
• Retrabalho com o pior timing possível. A necessidade de refazer aparece exatamente quando o caixa acabou e o investidor quer ver tração.

Já detalhamos aqui no blog como uma decisão de produto tomada sem diagnóstico virou um prejuízo de sete dígitos. O padrão se repete em escalas menores todos os dias. Só muda o número de zeros.

A conta que ninguém faz antes de abrir o Figma

Faça a conta com números redondos. Uma startup tem R$ 400 mil para tirar o produto do papel.

Caminho A: todo o budget no MVP, direto. Seis meses de desenvolvimento consomem os R$ 400 mil. O produto entra no ar com 14 funcionalidades. A ativação não vem: os usuários entram, não chegam ao valor, não voltam. O diagnóstico feito depois do lançamento mostra que o fluxo central precisa ser redesenhado e parte do backend, refeita. Mais R$ 150 mil e três meses. Total: R$ 550 mil e nove meses para chegar a um produto que funciona, se o caixa aguentar até lá.

Caminho B: Discovery enxuto antes, MVP menor depois. Quatro semanas de Discovery custam R$ 48 mil, cerca de 12% do budget. O trabalho com usuários e dados mostra que, das 14 funcionalidades planejadas, 5 sustentam a proposta de valor e o resto é aposta. O MVP encolhe: R$ 280 mil e quatro meses de desenvolvimento, focado no fluxo que importa. Total até o ar: R$ 328 mil e cinco meses, com R$ 72 mil em caixa para iterar sobre dados reais de uso.

Mesma empresa, mesma ideia, mesmos R$ 400 mil. A diferença entre os caminhos é de R$ 222 mil e quatro meses. E o caminho B ainda termina com reserva para reagir ao que o mercado disser. Isso é Eficiência de Capital na prática, e é por isso que o ROI de UX chega a 100:1: o retorno não vem de tela bonita, vem de dinheiro que deixou de ser queimado na direção errada.

Quando faz sentido enxugar o Discovery e ir mais rápido pro MVP

Aqui está a parte que os defensores do "Discovery sempre, completo, inegociável" não gostam de admitir: nem todo contexto precisa de oito semanas de imersão. Discovery é redução de risco. Se o risco já está reduzido por outra via, insistir no processo completo é burocracia, não estratégia.

Sinais de que um Discovery enxuto basta

• Você já opera nesse mercado. O produto novo atende uma dor que os seus clientes atuais verbalizam há meses, com dados de suporte e vendas para provar.
• O comportamento do usuário já existe. Você não está criando um hábito novo, está removendo fricção de um fluxo que as pessoas já executam de outro jeito.
• A hipótese é barata de testar no ar. Se errar custa pouco e corrigir é rápido, o próprio MVP vira instrumento de pesquisa. É a lógica que sustenta estratégias de Product-Led Growth, onde o produto é o motor de aquisição e aprendizado.
• Existe dado proprietário acumulado. Analytics, gravações de sessão, histórico de churn. Boa parte das respostas que um Discovery buscaria já está na sua base, esperando análise.

Nesses casos, um Discovery de duas a quatro semanas, com escopo fechado nas duas ou três hipóteses de maior risco, resolve. Não é pular a etapa. É dimensionar a etapa pelo tamanho do risco.

Sinais de que pular o Discovery vai sair caro

• O produto depende de mudança de comportamento. Você precisa que o usuário faça algo que ele não faz hoje. Esse é o risco mais caro que existe em produto digital, e nenhuma sprint de dev resolve.
• Visões conflitantes internas. CEO quer uma coisa, produto quer outra, comercial promete uma terceira. Sem alinhamento sobre o problema, o MVP vira uma média de opiniões. Média de opiniões não tem usuário.
• Ticket alto ou ciclo longo de venda. Errar o MVP num produto B2B enterprise não custa uma iteração. Custa a credibilidade com os primeiros clientes, que não voltam para a segunda versão.
• A retenção é o modelo de negócio. Se o produto vive de assinatura, o primeiro contato do usuário com o valor decide tudo. Construir isso no chute é o caminho mais curto para engrossar a estatística de churn. Os erros de onboarding que matam a retenção em SaaS quase sempre nascem de hipóteses que ninguém validou.

Como sequenciar Discovery e MVP com budget curto

A sequência que protege o caixa não é "Discovery completo, depois MVP completo". É um ciclo com três regras:

1. Dimensione o Discovery pelo risco, não pelo processo. Liste as hipóteses que, se estiverem erradas, matam o produto. O Discovery enxuto ataca só essas. O Nielsen Norman Group descreve bem o papel da fase de discovery em projetos de produto: não é pesquisar tudo, é decidir com evidência o que não pode estar errado.
2. Deixe o Discovery cortar escopo, não adicionar. O entregável mais valioso de um bom Discovery com pouco budget é a lista do que não entra no MVP. Cada funcionalidade cortada antes do código é capital preservado para iterar depois do lançamento.
3. Trate o MVP como a continuação da pesquisa. O lançamento não encerra a investigação, ele troca o método: sai a entrevista, entra o dado de uso. A prioridade número um pós-lançamento é medir se o usuário chega ao valor, e quanto tempo leva. É o trabalho de identificar e encurtar o caminho até o aha moment, agora com números reais na mesa.

Nesse desenho, Discovery e MVP param de disputar orçamento e passam a proteger um ao outro. O Discovery impede que o MVP nasça errado. O MVP impede que o Discovery vire relatório de gaveta. O produto que sai desse ciclo não é um experimento descartável: é um Ativo Digital, construído para render, com um caminho claro de Fricção Zero entre o usuário e o valor.

Perguntas frequentes sobre Discovery e MVP

Discovery atrasa o lançamento do MVP?

Atrasa a data de início do código em duas a quatro semanas, num formato enxuto. E costuma antecipar a data em que o produto funciona, porque corta escopo desnecessário e evita o ciclo de refazer. A pergunta certa não é quando o MVP entra no ar, é quando ele começa a gerar resultado.

Quanto do budget devo reservar para o Discovery?

Depende do risco, não de uma regra fixa. No cenário deste artigo, 12% do budget em Discovery evitou um retrabalho que teria consumido 37% a mais que o orçamento original. A referência prática: quanto mais caro for errar (ticket alto, mudança de comportamento, retenção como modelo), maior a fatia que o Discovery merece.

Dá para fazer Discovery com o produto já no ar?

Dá, e muitas vezes é o cenário mais eficiente: já existe dado real de uso para analisar. Discovery não é ritual de início de projeto, é ferramenta de redução de risco. Serve antes do MVP, antes de um redesign, antes de escalar aquisição.

MVP validado substitui o Discovery na hora de escalar?

Não. O MVP valida a hipótese central com os primeiros usuários. Escalar traz riscos novos: outros segmentos, outros canais, carga sobre a arquitetura, dívida técnica acumulada nas decisões rápidas da fase inicial. Escalar sobre uma base não investigada é multiplicar um risco que ninguém mediu.

Conclusão: a decisão prática

Pare de escolher entre Discovery e MVP. Decida a dose:

• Risco de direção alto (comportamento novo, visões conflitantes, retenção como modelo, ticket alto): Discovery enxuto primeiro, com escopo fechado nas hipóteses que matam o produto. Depois, MVP menor e mais barato.
• Risco de direção baixo (mercado conhecido, comportamento existente, dado proprietário disponível): Discovery mínimo sobre os dados que você já tem, MVP no ar rápido, medição rigorosa desde o primeiro dia.
• Em qualquer cenário: o Discovery corta escopo, o MVP continua a pesquisa, e parte do budget fica reservada para iterar sobre dado real.

O que quebra empresas com budget curto não é gastar em pesquisa nem gastar em código. É gastar duas vezes no mesmo produto porque a primeira versão nasceu no escuro.

Se você está diante dessa decisão agora, com caixa contado e prazo apertado, um Discovery estratégico dimensionado para o seu risco costuma ser o investimento com melhor retorno de todo o projeto. Fale com a UX Agency e traga o cenário: a conversa começa pelo seu risco, não pelo nosso escopo.