O que veio depois do MVP? As abordagens que expandiram o legado de Eric Ries

systems development

Poucos conceitos tiveram tanto impacto no universo de startups e inovação quanto o MVP (Minimum Viable Product, ou Produto Mínimo Viável), popularizado por Eric Ries. A proposta era simples e poderosa: construir a menor versão possível de um produto que permitisse gerar aprendizado validado junto aos clientes reais.

O problema é que, ao longo do tempo, muitas equipes passaram a interpretar o conceito de forma equivocada. Em vez de criar o mínimo necessário para aprender, passaram a lançar produtos incompletos, mal acabados e com pouco valor para os usuários.

Sobre esse ponto, Jason Fried, fundador da 37signals, é um dos críticos do conceito de MVP. Para ele, a preocupação não deveria estar em construir uma versão mínima, mas a melhor primeira versão possível dentro das restrições existentes, desde que seja simples, enxuta e genuinamente útil para os clientes. Em vez de buscar o mínimo viável, ele defende entregar o melhor produto possível com os recursos disponíveis.

Ao mesmo tempo, outra reflexão começou a ganhar força. Algumas equipes perceberam que, em muitos casos, era possível aprender algo relevante antes mesmo de construir um produto. Em vez de investir tempo e recursos desenvolvendo um MVP, passaram a validar hipóteses por meio de experimentos mais simples e baratos.

Essa mudança de perspectiva levou muitas empresas a questionarem não apenas o que deveria ser construído, mas também se era necessário construir alguma coisa para aprender.

Um dos exemplos mais conhecidos é o do Dropbox, que inicialmente utilizou um vídeo demonstrando como a solução funcionaria antes de ter o produto pronto. O objetivo era descobrir se as pessoas compreendiam o valor da proposta e tinham interesse em utilizá-la. O forte interesse gerado pelo vídeo validou a demanda e forneceu evidências suficientes para justificar o desenvolvimento da plataforma.

Esse tipo de aprendizado levou muitas empresas a perceberem que, frequentemente, a primeira pergunta não é como construir?, mas sim vale a pena construir?.

MLP: quando aprender não basta, é preciso encantar

Foi nesse contexto que surgiram abordagens que complementam, refinam ou até questionam alguns aspectos do MVP. Uma das evoluções mais conhecidas é o MLP, ou Minimum Lovable Product (Produto Mínimo Adorável).

Enquanto o MVP procura responder à pergunta “qual é o mínimo que preciso construir para aprender?”, o MLP busca responder “qual é o mínimo que preciso construir para encantar?”. A diferença pode parecer sutil, mas representa uma mudança importante de foco.

O MVP privilegia a validação de hipóteses. O MLP, por sua vez, procura equilibrar aprendizado com experiência do usuário. A premissa é que, em determinados contextos, oferecer apenas o mínimo funcional pode não ser suficiente para conquistar clientes ou gerar engajamento.

Imagine o caso do Airbnb. Um MVP poderia simplesmente permitir que pessoas anunciassem quartos disponíveis. Um MLP, por outro lado, incluiria elementos essenciais para gerar confiança e satisfação desde o primeiro contato, como boas fotografias, comunicação clara e uma experiência agradável de uso.

A filosofia do MLP parte da ideia de que não basta que o produto funcione. É preciso que ele gere uma impressão positiva logo no início. Afinal, aprender continua sendo importante, mas criar uma experiência que as pessoas gostem de usar também faz parte da validação de uma proposta de valor.

Customer Development: entender o cliente antes de construir

Muito antes de o Lean Startup ganhar notoriedade, Steve Blank já defendia uma ideia que influenciaria diretamente o trabalho de Eric Ries: a necessidade de descobrir e compreender os clientes antes de investir pesado em desenvolvimento.

O princípio fundamental do Customer Development ficou conhecido por uma frase memorável: “Saia do prédio e converse com clientes.” Segundo essa abordagem, uma série de entrevistas bem conduzidas pode gerar mais aprendizado do que semanas ou meses construindo funcionalidades.

O foco deixa de ser o produto e passa a ser a compreensão profunda dos problemas, necessidades e comportamentos das pessoas que se pretende atender. Por exemplo, uma equipe que deseja criar um aplicativo para restaurantes pode descobrir, após entrevistar dezenas de proprietários, que o maior problema não é a gestão de pedidos, como imaginava inicialmente, mas o controle de estoque e desperdício de alimentos.

Essa descoberta, obtida antes de qualquer desenvolvimento, pode evitar perda de tempo na construção da solução errada e direcionar os esforços para um problema que os clientes realmente consideram prioritário.

No entanto, a abordagem possui uma limitação importante: clientes costumam opinar com mais precisão sobre problemas atuais do que sobre soluções radicalmente novas. Em mercados inexistentes ou em inovações disruptivas, como ocorreu com smartphones, redes sociais ou plataformas de streaming em seus estágios iniciais, os usuários muitas vezes não conseguem imaginar comportamentos futuros nem expressar uma demanda por algo que nunca experimentaram.

Nesses casos, a observação do comportamento e a experimentação prática tornam-se complementos essenciais às entrevistas. Na prática, entender o que as pessoas fazem costuma ser tão importante quanto ouvir o que elas dizem.

Pretotyping: validar interesse antes de validar a solução

Se o MVP pergunta “qual é o menor produto que preciso construir?”, o Pretotyping, criado por Alberto Savoia, faz uma pergunta ainda mais radical: “antes de verificar se consigo construir isso, já confirmei que alguém realmente quer?” A proposta é testar o interesse do mercado com o menor investimento possível.

Em vez de desenvolver uma aplicação completa, a equipe pode criar uma página de espera, um anúncio experimental, um vídeo demonstrativo ou até mesmo um botão de compra para um produto que ainda não existe. O exemplo do Dropbox citado no início deste texto ilustra bem essa abordagem. O aprendizado acontece antes da construção.

Essa abordagem ganhou força porque ajuda a evitar um dos erros mais comuns da inovação: desenvolver algo tecnicamente sofisticado para resolver um problema que ninguém considera importante.

Continuous Discovery: transformar aprendizado em rotina

Nos últimos anos, uma das ideias mais influentes na gestão de produtos veio de Teresa Torres, por meio da abordagem de Continuous Discovery. Tradicionalmente, muitas empresas seguiam uma sequência linear: pesquisar, construir e lançar. A proposta de Torres é substituir esse fluxo por um processo contínuo de aprendizado.

Em vez de realizar pesquisas esporádicas, os times mantêm conversas frequentes com usuários, testam hipóteses regularmente e tomam decisões apoiadas em evidências coletadas ao longo do tempo. Nessa visão, a descoberta deixa de ser uma etapa do projeto e passa a ser uma prática permanente do trabalho de produto.

Um exemplo conhecido dessa lógica pode ser observado na Netflix, que realiza experimentos constantes com diferentes grupos de usuários para avaliar mudanças em recomendações, interfaces e funcionalidades. Em vez de depender apenas de grandes pesquisas antes de cada lançamento, a empresa coleta feedback e dados de uso continuamente, ajustando seus produtos de forma incremental com base no comportamento real dos clientes.

A principal contribuição do Continuous Discovery é justamente transformar o aprendizado em um hábito organizacional. Em vez de concentrar a descoberta no início dos projetos, as equipes mantêm um diálogo contínuo com o mercado, reduzindo riscos e aumentando a qualidade das decisões ao longo de todo o ciclo de vida do produto.

Lean Experimentation: o experimento acima do produto

Talvez a evolução conceitual mais relevante do próprio pensamento Lean seja o que muitos chamam hoje de Lean Experimentation. Nessa lógica, a pergunta deixa de ser: “Qual MVP devo construir?”. E passa a ser: “Qual experimento reduz minha principal incerteza da forma mais rápida e barata possível?”.

O experimento não precisa ser um produto. Dependendo da hipótese que está sendo investigada, pode ser uma entrevista, um protótipo, uma landing page, uma campanha de marketing ou um teste de concierge (prática na qual o serviço é executado manualmente quando ainda não existe produto).

O importante não é construir algo. O importante é aprender.

Um exemplo clássico é o da Zappos, que, antes de investir na criação de uma complexa operação de e-commerce para venda de calçados, testou se as pessoas realmente comprariam sapatos pela internet. Seu fundador fotografava produtos de lojas locais, publicava as imagens em um site simples e, quando uma compra era realizada, adquiria o item na loja para enviá-lo ao cliente.

O experimento permitiu validar a demanda com baixo investimento e reduziu significativamente a principal incerteza do negócio antes da construção da infraestrutura necessária para escalar a operação.

A grande mudança de mentalidade

Ao observar a evolução dessas abordagens, fica claro que nenhuma delas eliminou a relevância do MVP. O que ocorreu foi uma ampliação da forma como encaramos validação e aprendizado.

Durante muitos anos, a conversa girou em torno da pergunta: “Qual é o menor produto que posso construir?”. Hoje, equipes mais maduras costumam perguntar: “Qual é a forma mais rápida de testar uma hipótese?”.

Essa mudança de perspectiva representa uma evolução natural das ideias defendidas por Eric Ries. O objetivo continua sendo o aprendizado validado. A diferença é que o foco se deslocou do produto para o experimento.

No fim das contas, o valor não está no MVP em si, mas naquilo que ele nos permite descobrir. À medida que as práticas de produto evoluem, fica cada vez mais claro que aprender rápido é tão ou mais importante do que construir rápido.

E, muitas vezes, a melhor forma de aprender não é desenvolver uma nova funcionalidade, mas encontrar maneiras simples e inteligentes de testar uma ideia antes de investir nela.

Há ainda um fator recente que reforça essa mudança de mentalidade: a popularização da inteligência artificial. Durante muito tempo, desenvolver software era um dos principais gargalos da inovação. Construir um protótipo, testar uma ideia ou criar uma primeira versão exigia semanas ou meses de trabalho. Hoje, ferramentas de IA permitem gerar protótipos, interfaces e até aplicações funcionais em questão de horas. Nesse contexto, o desafio deixa de ser a capacidade de construir e passa a ser a capacidade de validar. Quando criar ficou mais fácil e barato, o verdadeiro diferencial passou a ser identificar quais problemas valem a pena resolver e quais soluções realmente geram valor para os usuários.

A primeira tabela abaixo compara os objetivos e as características de cada abordagem. Já a segunda mostra como a pergunta central da inovação evoluiu ao longo do tempo, deslocando o foco da construção do produto para a redução de incertezas e o aprendizado contínuo.

Abordagem Pergunta principal Foco Método predominante Quando usar Exemplo
MVP (Minimum Viable Product) Qual é o menor produto que posso construir para aprender? Validar hipóteses por meio de um produto funcional mínimo Construção de uma versão simplificada do produto Quando é necessário observar o uso real da solução Primeiras versões de startups digitais
MLP (Minimum Lovable Product) Qual é o mínimo que preciso construir para encantar o usuário? Aprendizado combinado com experiência do usuário Produto mínimo, mas com atenção especial à percepção de valor Mercados com alta concorrência ou forte impacto da experiência Airbnb investindo em confiança, boas fotos e experiência de uso
Customer Development Estou resolvendo um problema importante para as pessoas certas? Compreensão profunda do cliente Entrevistas, observação e validação de problemas Antes de começar a desenvolver uma solução Entrevistas com donos de restaurantes para entender suas dores reais
Pretotyping Existe interesse suficiente para justificar a construção? Validar demanda antes de desenvolver Landing pages, anúncios, vídeos, listas de espera e testes de interesse Quando a principal incerteza é a existência da demanda Vídeo inicial do Dropbox validando interesse antes da construção
Continuous Discovery O que estamos aprendendo continuamente sobre clientes e oportunidades? Descoberta contínua e tomada de decisão baseada em evidências Conversas frequentes com usuários, experimentos e análise de comportamento Durante todo o ciclo de vida do produto Netflix realizando testes constantes com usuários
Lean Experimentation Qual experimento reduz minha principal incerteza da forma mais rápida e barata? Aprendizado acima da construção Qualquer experimento capaz de gerar evidências: entrevistas, protótipos, concierge, campanhas etc. Em qualquer fase, especialmente diante de grandes incertezas Zappos validando a compra de sapatos online antes de criar a operação completa

A segunda tabela com a evolução das perguntas sobre o que fazer:

Abordagem Pergunta dominante
Customer Development Qual problema vale a pena resolver?
Pretotyping As pessoas realmente demonstram interesse?
MVP Qual é o menor produto que me permite aprender?
MLP Como aprender sem comprometer a experiência?
Continuous Discovery Como transformar aprendizado em rotina?
Lean Experimentation Qual é o experimento mais eficiente para reduzir incertezas?

Gostou da resenha? Garanta já o seu exemplar aqui: A startup enxuta