A literatura sobre MVP é abundante e razoavelmente boa. Ela explica o que é, compara com protótipo e prova de conceito, dá o passo a passo, lista tipos e até faixas de preço no Brasil. Se o problema fosse falta de instrução para começar, ele já estaria resolvido.
O que praticamente nenhum desses materiais responde é a pergunta que decide o destino do dinheiro: como saber que acabou. Não "como saber se deu certo" — isso todo mundo tenta responder com métricas genéricas. A pergunta é mais dura: em que ponto, com que número na tela, a empresa para de investir naquela hipótese.
O que é um produto mínimo viável?
MVP é a menor versão funcional de um produto capaz de colocar uma hipótese de negócio diante de usuários reais e produzir aprendizado confiável. As três palavras da sigla puxam em direções opostas de propósito: mínimo restringe o escopo, viável exige que funcione de verdade, produto exige que alguém consiga usar sem manual.
O que ele não é: uma primeira fase do projeto. Essa confusão é a origem de metade dos problemas. Um MVP não é o capítulo um de uma obra que continua — é um experimento que pode terminar em desistência, e essa possibilidade precisa ser aceitável para quem paga antes de começar.
Qual a diferença entre MVP, protótipo e prova de conceito?
Os três respondem perguntas diferentes, com custos diferentes. Trocar um pelo outro é caro nos dois sentidos: construir MVP quando um protótipo bastava desperdiça meses; fazer protótipo quando era preciso MVP produz aplauso em reunião e nenhum aprendizado sobre comportamento real.
| O que é | Que pergunta responde |
|---|---|
| Prova de conceito (PoC) | É tecnicamente possível fazer isso? |
| Protótipo | As pessoas entendem e conseguem usar? |
| MVP | Alguém usa de verdade, repetidamente, e há sinal de que pagaria? |
| Primeira versão comercial | Isso se sustenta como operação e como negócio? |
Por que os projetos morrem sem resposta?
Existe um levantamento recorrente sobre por que startups fecham, e ele ajuda a enxergar o que está de fato em jogo quando se discute escopo de MVP.
Repare na relação entre os dois primeiros números. Ficar sem capital é o desfecho, não a causa — é o que se escreve na certidão. A causa que mais aparece logo atrás é não ter encontrado encaixe entre produto e mercado, e é exatamente essa a pergunta que um MVP existe para responder cedo, enquanto ainda há dinheiro para mudar de ideia.
Quando não há critério de parada, o MVP consome o caixa que deveria financiar a próxima tentativa. A empresa não descobre que errou: ela descobre que acabou.
O que é o critério de parada de um MVP?
É um acordo escrito antes de começar, com quatro campos, assinado por quem decide — não pelo time técnico sozinho.
1. A hipótese, em uma frase
Uma frase, com sujeito e verbo, que possa ser falsa. "Vamos validar o mercado" não é hipótese. "Gestores de clínicas com 3 a 10 profissionais vão trocar a agenda em papel por esta agenda digital se ela importar os dados do sistema atual" é. A diferença é que a segunda pode dar errado de um jeito reconhecível.
2. A métrica, com piso numérico
Não basta escolher a métrica; é preciso escrever o número que separa confirmação de refutação. "Vamos medir retenção" não decide nada. "Se menos de 30% dos que usarem na primeira semana voltarem na quarta, a hipótese não se sustenta" decide. O piso precisa ser fixado antes de existir dado — depois, todo número parece justificar continuar.
3. O prazo, com data
Um MVP sem data não termina, apenas desacelera até parar de ser mencionado nas reuniões. A data não é a de entrega do software: é a data em que a empresa vai olhar a métrica e tomar a decisão, com o que houver.
4. As três saídas, combinadas antes
Continuar, pivotar ou encerrar. As três precisam estar sobre a mesa desde o início, e encerrar precisa ser socialmente aceitável — se a saída "encerrar" significar que alguém falhou publicamente, ninguém vai escolhê-la, e o projeto vira zumbi orçamentário.
O que entra na primeira versão?
A regra é curta: entra o que é necessário para a hipótese poder ser falsa. Tudo o mais espera. Na prática, três perguntas resolvem quase todas as discussões de escopo.
- Sem esta funcionalidade, o usuário consegue completar o fluxo que estamos testando? Se consegue, ela fica fora.
- Ela existe para o teste ou para a operação futura? Painel administrativo, relatório e configuração quase sempre são da segunda categoria.
- Dá para fazer isso manualmente nos primeiros usuários? Muito do que se automatiza na primeira versão poderia ser feito à mão por semanas, e o trabalho manual ensina mais sobre o problema do que o código.
- Se der certo, isso vai ser reescrito de qualquer forma? Se sim, escolha o caminho mais rápido agora e assuma a dívida com data.
- Alguém pediu isso ou nós imaginamos que pediriam? A diferença entre as duas respostas costuma ser um mês de trabalho.
Vale insistir no terceiro item. Conversar com usuários antes e durante o desenvolvimento é a parte mais barata e mais negligenciada do processo — a biblioteca pública da Y Combinator tem um guia direto sobre como conversar com usuários sem induzir a resposta, e ele economiza mais orçamento que qualquer decisão de arquitetura.
Um MVP sem critério de parada não é um teste. É uma obra com nome de experimento.
Quem assina o critério de parada?
Essa é a parte que costuma ser tratada como detalhe e é onde o acordo se sustenta ou desmonta. Se o critério é escrito pelo time de produto e apenas comunicado à diretoria, ele não vale nada no dia em que o número vier baixo: quem paga não se sente obrigado por um compromisso do qual não participou, e quem executa não tem autoridade para encerrar.
O critério precisa da assinatura de três papéis. Quem financia, porque é quem decide continuar ou não. Quem responde pelo negócio afetado — a área que vai operar o produto —, porque é quem sabe se o piso escolhido significa alguma coisa no mundo real. E quem constrói, porque é quem pode dizer, antes, se o escopo proposto é suficiente para que a hipótese possa de fato falhar.
Uma reunião de trinta minutos com os três, antes do primeiro sprint, resolve o que meses de relatório não resolvem depois. E ela tem um efeito colateral útil: com frequência, é nessa conversa que alguém percebe que a hipótese ainda não está clara o bastante para virar produto.
Como saber se o MVP deu certo?
Pelo número que você escreveu antes — e por mais nada. O maior risco desta etapa não é o resultado ruim: é a reinterpretação do resultado. Toda equipe encontra, depois do fato, uma razão pela qual o número baixo não conta.
| Sinal | O que costuma significar |
|---|---|
| Uso repetido sem incentivo | O sinal mais forte de encaixe: alguém volta porque precisa |
| Cadastro alto e uso baixo | A promessa funciona, o produto não — problema de escopo, não de marketing |
| Uso alto e nenhuma disposição a pagar | Resolve um incômodo, não um custo. Reveja quem é o cliente |
| Poucos usuários muito intensos | Pode ser nicho viável: reduza o público-alvo antes de descartar a hipótese |
| Elogio sem uso | Educação. Não é dado |
Quando desistir de uma ideia de produto?
Quando o prazo chegou, a métrica ficou abaixo do piso e nenhuma explicação nova apareceu — só explicações que já existiam antes do teste. Desistir nesse ponto não é fracasso; é a única forma de preservar caixa para a hipótese seguinte, que é o que os 70% da pesquisa não conseguiram fazer.
Há um caso em que vale estender: quando o teste revelou um problema de execução tão evidente que a hipótese nunca chegou a ser testada — o produto não funcionava, o público errado foi convidado, a integração prometida não ficou pronta. Aí a extensão é legítima, desde que venha com novo prazo e novo piso escritos. Uma vez.
O que muda por tipo de projeto?
| Contexto | Como calibrar o critério |
|---|---|
| Startup buscando investimento | O piso precisa ser aquele que convence um investidor, não o time |
| Empresa consolidada lançando produto novo | O risco é o oposto: escopo infla porque a marca 'não pode entregar algo simples' |
| Software interno para reduzir custo | A métrica é hora economizada, medida antes e depois — não adoção |
| Marketplace ou rede | Valide um lado de cada vez; medir os dois juntos esconde qual falhou |
Em qualquer um deles, a tentação é a mesma: fazer o MVP no menor custo possível com ferramenta pronta e descobrir depois o preço da escolha. A conta real desse caminho está em a conta que chega depois que o app no-code funciona.
Por onde começar hoje
- Escreva a hipótese em uma frase que possa ser falsa e mostre para alguém de fora do projeto.
- Escolha uma métrica e fixe o piso numérico — antes de existir qualquer dado.
- Marque a data da decisão no calendário de quem paga, não no do time técnico.
- Combine por escrito as três saídas e diga em voz alta que encerrar é uma delas.
- Só então defina o escopo, cortando tudo o que não é necessário para a hipótese poder falhar.
Se quiser entender onde a sua operação está antes de investir em produto, o diagnóstico gratuito de marketing avalia tecnologia e maturidade digital junto com as demais dimensões. E o trabalho de escopo, construção e validação está descrito na página de desenvolvimento de MVP.