MVP (Minimum Viable Product — Produto Mínimo Viável) é a versão de um produto que permite coletar o máximo de aprendizado validado sobre clientes com o mínimo de esforço. A definição é de Eric Ries, em “The Lean Startup” (2011), e contém três elementos críticos: mínimo (não é o produto completo), viável (funciona o suficiente para gerar aprendizado real), e produto (existe algo concreto para testar, não apenas uma ideia). MVP não é sinônimo de produto ruim, versão bugada ou protótipo incompleto lançado prematuramente — é um experimento deliberadamente dimensionado para responder a uma pergunta específica sobre o cliente ou sobre a tecnologia.
Por que a maioria dos MVPs falha — e o que fazer diferente
O erro mais comum é confundir MVP com “produto com menos funcionalidades”. Isso gera um produto que ninguém quer usar porque está incompleto, sem que se aprenda nada útil sobre a hipótese central. Jeff Gothelf e Josh Seiden, em “Lean UX” (2016), argumentam que o MVP deve ser dimensionado pela hipótese que se quer testar, não pela capacidade de entrega da equipe.
A pergunta correta antes de construir qualquer MVP é: qual é a hipótese mais arriscada do meu negócio? O MVP deve testar essa hipótese — e apenas ela. Se a hipótese mais arriscada é “clientes pagarão por isso”, o MVP precisa permitir uma transação real, não apenas medir interesse. Se a hipótese mais arriscada é “a tecnologia funciona nestas condições”, o MVP é um experimento técnico, não um produto de mercado.
Os 5 tipos de MVP — quando usar cada um
1. MVP de Landing Page — Uma página que descreve o produto que ainda não existe e oferece um mecanismo de pré-cadastro ou pré-compra. Testa se há demanda suficiente para justificar construir o produto. Mede intenção, não uso real.
2. MVP Concierge — Você entrega manualmente o que o produto automatizaria. O cliente recebe o resultado sem saber (ou sabendo) que o processo é manual. Testa se o cliente usa e valoriza o resultado, independente de como foi produzido. Exemplo: uma plataforma de curadoria de conteúdo onde, inicialmente, a equipe seleciona manualmente o que o algoritmo selecionaria.
3. MVP Wizard of Oz — O produto parece automatizado para o cliente, mas é operado manualmente por trás. Testa se o cliente adota e usa o produto quando acredita que ele funciona automaticamente.
4. MVP de Vídeo Explicativo — Um vídeo que demonstra o produto funcionando (mesmo que ainda não exista) e convida para pré-cadastro. Testa se a explicação do produto gera interesse qualificado.
5. MVP de Protótipo Funcional — Uma versão funcional com escopo reduzido, suficiente para uso real por um grupo limitado de clientes. Testa se o produto gera valor em uso real, não apenas em teoria. Usado quando as hipóteses sobre demanda já foram validadas.
MVP para deep tech — quando o MVP exige pesquisa
Startups de base tecnológica enfrentam uma restrição que os frameworks tradicionais de MVP não endereçam: quando a hipótese mais arriscada é técnica, não de mercado, o MVP precisa ser um experimento científico, não um produto de mercado. Não existe landing page que valide se um sensor funciona em condições de campo. Não existe MVP Wizard of Oz para testar se um algoritmo de deep learning atinge a acurácia necessária.
É precisamente aqui que o PIPE FAPESP se posiciona: o programa financia o MVP técnico — o conjunto de experimentos de pesquisa que valida a viabilidade da tecnologia antes que a empresa precise investir recursos próprios em escala. A relação entre MVP técnico e TRL é direta: o MVP técnico de uma Fase 1 tipicamente leva a tecnologia do TRL 1-2 para TRL 3-4.
A relação MVP × TRL
| TRL | Tipo de MVP correspondente | O que valida |
|---|---|---|
| TRL 1-2 | Revisão bibliográfica + simulação teórica | Princípio é plausível com base no conhecimento existente |
| TRL 3 | Experimento de bancada (prova de conceito) | Princípio funciona em condições controladas de laboratório |
| TRL 4 | Componentes integrados e testados em lab | Componentes individuais funcionam juntos no ambiente de laboratório |
| TRL 5 | Protótipo testado em ambiente relevante | Sistema funciona em condições que simulam o uso real |
| TRL 6-7 | Piloto com usuários reais | Produto funciona no ambiente operacional e gera valor para o usuário |
→ Seu MVP é pesquisa ou produto? Descubra no Assessment PIPE FAPESP
Erros mais comuns na definição de MVP
MVP como versão 1.0 reduzida: construir o produto completo com menos funcionalidades, sem definir qual hipótese está sendo testada.
Não definir critérios de sucesso antes de lançar: sem saber o que constitui sucesso, qualquer resultado pode ser interpretado como positivo ou negativo conforme a conveniência.
Testar com o público errado: amigos, familiares e colegas que respondem por gentileza. O MVP deve ser testado com o segmento-alvo real.
Ignorar dados negativos: o aprendizado mais valioso frequentemente vem dos MVPs que “falharam” — porque revelam hipóteses inválidas antes que o custo de desenvolvê-las se torne proibitivo.
MVP técnico sem validação de mercado paralela: construir o experimento técnico sem verificar se, caso a tecnologia funcione, há mercado para ela. Essas duas linhas de validação devem correr em paralelo.
Perguntas Frequentes
MVP e protótipo são a mesma coisa? Não necessariamente. Um protótipo é uma representação do produto, usada para testar usabilidade ou aparência. Um MVP é um experimento para testar uma hipótese de negócio ou técnica. Um protótipo pode ser um tipo de MVP, mas nem todo MVP é um protótipo — e nem todo protótipo é um MVP.
Para o PIPE, o MVP precisa estar pronto antes de submeter? Não. O PIPE financia a construção do MVP técnico. O que se espera é que o proponente tenha clareza sobre quais hipóteses técnicas serão testadas, com quais experimentos, e com que critérios de sucesso — não que já tenha as respostas.
Qual o tamanho certo de um MVP? O tamanho é determinado pela hipótese mais arriscada. O MVP deve ser o mínimo necessário para testá-la com dados confiáveis. Mais do que isso é desperdício de tempo e recursos antes da validação.
Fontes: RIES, E. The Lean Startup. Crown Business, 2011. | MAURYA, A. Running Lean. O’Reilly, 2012. | BLANK, S. The Four Steps to the Epiphany. K&S Ranch, 2005. | GOTHELF, J.; SEIDEN, J. Lean UX: Designing Great Products with Agile Teams. 2. ed. O’Reilly, 2016.
→ Seu MVP é pesquisa ou produto? Descubra no Assessment PIPE FAPESP
