MVP não é protótipo: o que realmente precisa existir no primeiro lançamento
A confusão mais cara em produto digital é tratar o MVP como uma versão bonita e vazia. Um MVP existe para testar uma hipótese real — e isso muda tudo o que precisa ser construído primeiro.
MVP significa minimum viable product — produto mínimo viável. A palavra que mais se perde na tradução prática é "viável". Não é "mínimo apresentável". É mínimo que já resolve o problema de verdade, mesmo que de um jeito simples.
O erro mais comum
Construir uma interface completa, com todas as telas desenhadas, sem nenhuma delas realmente funcionando — um protótipo navegável disfarçado de produto. Isso serve para validar design, não para validar se alguém paga pelo que você está construindo.
Outro erro simétrico: construir a versão completa, com todos os recursos que algum dia vão existir, antes de saber se o primeiro recurso resolve o problema de alguém. Isso atrasa a validação em meses — e, com frequência, descobre tarde demais que o problema nem era esse.
O que decide o que entra no MVP
A pergunta certa não é "o que dá pra fazer rápido". É: qual é a menor versão desse produto que já obriga alguém a mudar de comportamento?
Se o produto é um CRM, o mínimo viável não é ter todas as integrações possíveis — é ter um lugar único e confiável para registrar contato e acompanhar status, que já seja melhor do que a planilha que a pessoa usa hoje.
Se o produto é uma ferramenta de diagnóstico, o mínimo viável não é cobrir vinte variáveis — é entregar, nas três ou quatro variáveis que mais importam, uma resposta clara o suficiente para gerar uma decisão.
O que não pode faltar, mesmo num MVP
- Persistência real. Dados salvos de verdade, não mockados — quem usa precisa confiar que o que fez ontem ainda está lá hoje.
- Um fluxo completo, do início ao fim. Não adianta ter cinco telas bonitas se nenhuma jornada inteira funciona sem travar.
- Feedback de erro e de sucesso. Um sistema que falha silenciosamente destrói confiança mais rápido do que um sistema limitado.
O que pode (e deve) ficar de fora
Integrações com terceiros que só um usuário entre cem vai precisar. Customização avançada de interface. Relatórios complexos quando ninguém ainda validou que o dado base é útil. Automações que otimizam um processo que ainda não existe em volume suficiente para precisar de otimização.
Como decidimos isso na prática
No desenvolvimento do Veredito — nosso CRM jurídico em desenvolvimento — a primeira pergunta não foi "quais funcionalidades um CRM jurídico completo tem". Foi: qual é o momento em que um escritório de advocacia perde controle do funil hoje, e o que precisa existir para esse momento específico parar de doer.
Esse é o filtro real de um MVP: não é o que cabe no prazo. É o que já muda a vida de quem usa, mesmo sendo pouco.