MVP: o que é, o que entra na primeira versão e como validar a ideia

Quase nenhum produto dá errado por ter sido mal programado. Dá errado porque resolve um problema que as pessoas não sentem tanto quanto o fundador achava, ou porque elas já resolvem de outro jeito que funciona bem o bastante.

O problema é a ordem em que se descobre isso. Na maioria dos projetos, a descoberta vem depois do produto inteiro pronto — quando todo o investimento já foi feito e mudar de rumo custa o mesmo que começar de novo. O MVP existe para inverter essa ordem.

O que é MVP, e o que ele não é

MVP é a sigla em inglês para produto mínimo viável: a menor versão de um produto que pessoas reais conseguem usar para resolver o problema principal. O termo ficou conhecido com A Startup Enxuta, de Eric Ries, e a ideia central é simples — construir o mínimo necessário para aprender se vale construir o resto.

A palavra que mais se perde nessa definição é "viável". Mínimo sem viável vira um esboço que ninguém usa de verdade, e aí o teste não prova nada. É útil separar três coisas que costumam ser chamadas pelo mesmo nome:

Protótipo. Telas clicáveis, sem sistema por trás. Responde se a pessoa entende a interface e acha o caminho. Não responde se ela usaria.

MVP. Software funcionando, com um fluxo só, usado por pessoas reais com dados reais. Responde se o produto resolve o problema bem o bastante para a pessoa voltar.

Produto. Tudo o que vem depois: os casos de exceção, os perfis de acesso, os relatórios, as integrações. É o que se constrói quando a resposta do MVP foi sim.

O MVP não é a versão barata do produto final. É uma ferramenta para responder uma pergunta — e a pergunta vem antes do código.

Antes de construir: a hipótese em uma frase

Todo MVP que dá resultado começa com uma frase escrita, não com uma lista de funcionalidades. Um formato que funciona: quem tem o problema, qual é o problema, o que a pessoa vai fazer de diferente e como você vai saber.

Por exemplo: "Os vendedores externos perdem pedidos porque anotam no WhatsApp e esquecem de passar para o escritório. Se tiverem um formulário no celular que já cai no sistema, vão registrar ali a maioria dos pedidos da semana." Essa frase diz quem testar, o que construir e o que medir.

A parte que quase todo mundo pula é a última: decidir antes qual resultado confirma a ideia e qual derruba. Sem esse número combinado, qualquer resultado vira "promissor" depois, e o projeto segue por inércia.

O que entra na primeira versão

Menos do que parece. Três coisas, e só elas:

O fluxo principal de ponta a ponta. A tarefa que justifica o produto existir, completa. No exemplo do vendedor, é abrir, registrar o pedido e ver que chegou — não é o cadastro de clientes, nem o histórico, nem o relatório de vendas.

O mínimo para ser real. Dado salvo de verdade, acesso de quem precisa usar, funcionamento no aparelho que a pessoa já tem. Se o teste depende de alguém imaginar como seria, ele não é um teste.

A medição. Quem usou, quantas vezes, onde parou. É a parte que justifica todo o resto, e a que mais vezes fica para depois — e depois ninguém sabe dizer o que aconteceu.

O que fica de fora (e como fazer sem)

A lista do que fica de fora é sempre maior, e é ela que mantém o MVP mínimo. Os candidatos mais comuns:

Painel administrativo. Nas primeiras semanas, quem administra é a equipe do projeto, direto no banco ou numa planilha.

Integrações com outros sistemas. Exportar e importar à mão uma vez por dia resolve enquanto o volume é pequeno — e mostra qual integração realmente importa.

Perfis e permissões detalhadas. Um tipo de usuário, com acesso ao que precisa. As exceções aparecem com o uso, não no planejamento.

Relatórios. Uma consulta feita pela equipe responde a mesma pergunta sem tela nenhuma.

Os casos raros. Se acontece uma vez por mês, uma pessoa resolve à mão.

Fazer à mão o que não escala parece amadorismo e é o contrário: é a forma mais barata de descobrir qual parte do processo merece virar sistema. Muita funcionalidade planejada com cuidado perde o sentido na segunda semana de uso real.

Como ler o resultado sem se enganar

A pergunta "você usaria?" tem quase sempre a mesma resposta, e ela não vale nada. As pessoas são gentis com quem pergunta, e imaginar o uso é muito diferente de mudar o hábito. O que vale é comportamento:

Voltou? Uso na segunda e na terceira semana diz mais que qualquer volume de cadastro no primeiro dia.

Concluiu? Quantos começaram a tarefa principal e quantos chegaram ao fim. O ponto onde as pessoas param é a próxima coisa a corrigir.

Pediu mais? Quem reclama que falta algo está usando. O silêncio é o sinal ruim, não a reclamação.

Assumiu um compromisso? Indicar um colega, levar para outra área da empresa, pedir para continuar quando o teste acabar. Compromisso custa alguma coisa para quem dá, por isso é sinal confiável.

Cadastro mede curiosidade. Retorno mede valor. Um MVP com poucos usuários que voltam vale mais que um com muitos que sumiram.

Os erros que mais aparecem

O MVP de oito meses. Cada reunião acrescenta "só mais uma coisa", e quando a primeira versão sai ela já é o produto inteiro, com todo o risco que o MVP devia ter evitado.

Construir para todo mundo. Um produto para "empresas" não tem para quem perguntar. Um produto para o vendedor externo de distribuidora tem nome, endereço e telefone.

Testar com quem gosta de você. Amigos, sócios e o cliente mais fiel vão elogiar. O teste precisa de gente que tem o problema e nenhum motivo para ser educada.

Medir o que é fácil, não o que importa. Visitas e cadastros sobem com qualquer divulgação. Uso repetido só sobe se o produto resolve.

Não decidir nada no fim. O MVP termina com uma escolha — ampliar, mudar ou parar. Sem a escolha, ele só vira um produto mal acabado em produção.

MVP em empresa que já fatura

Quase todo conteúdo sobre MVP fala com startups, mas a empresa estabelecida tem uma vantagem enorme: os usuários já existem. Para um sistema interno, são a equipe. Para um produto novo, são os clientes atuais, que já confiam o bastante para testar e dizem com franqueza quando algo não serve.

Isso muda a natureza do teste. A pergunta deixa de ser "alguém quer isso?" e passa a ser "isso resolve melhor do que o jeito atual?" — e o jeito atual quase sempre é uma planilha, um grupo de WhatsApp ou um processo que depende de uma pessoa lembrar. É uma comparação concreta, que se mede em semanas.

O cuidado é o mesmo: começar por um processo só, o que mais dói, e não pelo sistema que resolveria a empresa inteira. Se a dúvida é se esse processo merece um sistema próprio ou uma ferramenta de mercado, escrevemos sobre essa escolha em Software sob medida ou sistema pronto: como decidir.

Como fazemos a primeira versão na CRIA

O ponto de partida é uma conversa sobre o negócio, não sobre funcionalidades: quem tem o problema hoje, como ele é resolvido agora e o que precisaria acontecer para a ideia ser considerada um acerto. Dessa conversa sai a hipótese em uma frase e a lista do que fica de fora — que costuma ser a parte mais longa.

Com isso, a primeira versão fica pronta em poucos dias, funcionando, para você abrir e clicar no lugar de imaginar. É nela que o seu time ou os seus clientes fazem a tarefa principal de verdade, e é dela que sai o primeiro número.

Para empresas do Rio Grande do Sul que já faturam a partir de R$ 50 mil por mês, a CRIA constrói essa primeira versão sem cobrar pela construção. A conversa começa com o nosso agente, em poucos minutos, em cria.digital/mvp-gratis.

Resumo

MVP é a menor versão funcionando de um produto, feita para responder uma pergunta antes de investir no resto. A pergunta vem escrita antes do código, com o número que a confirma. Entra o fluxo principal, o mínimo para ser real e a medição; o resto se faz à mão até provar que merece virar sistema. E o resultado se lê em comportamento — quem voltou, quem concluiu, quem pediu mais —, porque é isso que diz se a ideia se sustenta.