Em algum momento dos últimos dez anos, o MVP virou desculpa.
O Minimum Viable Product, criado por Frank Robinson e imortalizado por Eric Ries em The Lean Startup, nasceu com um propósito nobre: validar hipóteses rapidamente, antes de investir meses de desenvolvimento em algo que o mercado não quer. A lógica é impecável. O problema é o que aconteceu na prática.
Equipes passaram a usar “isso é MVP” como justificativa para lançar produtos incompletos, interfaces confusas e experiências frustrantes. O mercado ficou saturado de produtos viáveis que ninguém escolheria se houvesse alternativa. E aí entra a Amazon com um conceito que muda o padrão mínimo aceitável de lançamento: o Minimal Lovable Product.
De onde vem o conceito
O termo foi cunhado em 2013 por Brian de Haaff, cofundador da Aha!, em um artigo provocativo onde argumentava que “viável” era um padrão muito baixo para construir negócios duradouros. Seu diagnóstico: o MVP treina as equipes a tolerar a mediocridade.
Mas foi dentro da Amazon que o conceito ganhou musculatura institucional. A figura central foi Jeff Wilke, então CEO da Worldwide Consumer, o número dois da empresa abaixo de Jeff Bezos. Wilke observou que as equipes estavam usando o framework MVP como escudo para lançar produtos abaixo do padrão da empresa, uma contradição direta com o Princípio de Liderança número 1 da Amazon: Customer Obsession.
Sua intervenção foi simples e precisa: nomear o problema. O padrão mínimo aceitável de lançamento não seria mais “isso funciona?” mas “nos orgulharíamos de levar isso ao mercado?”
MVP vs MLP: a diferença que importa
Não se trata de adicionar mais features. A diferença é filosófica.
Com o MVP, você pergunta: o que posso remover para tornar o produto viável?
Com o MLP, você pergunta: o que preciso adicionar para tornar o produto amável?
O MVP trata o cliente como testador. O MLP trata o cliente como alguém que merece excelência desde o primeiro contato.
| MVP | MLP | |
|---|---|---|
| Objetivo | Testar hipótese | Encantar o cliente |
| Foco | Funcionalidade | Funcionalidade + UX + conexão emocional |
| Pergunta central | Isso funciona? | As pessoas vão amar isso? |
| Resultado esperado | Tolerância | Deleite e lealdade |
O AWS formaliza isso em sua documentação de Product Management:
“AWS breaks releases into minimum lovable products, with each iteration addressing a significant customer need that customers are excited to buy and use.”
Os três pilares do MLP segundo a Amazon
A Amazon estrutura o MLP em três dimensões, e todas precisam estar presentes no lançamento:
1. Funcionalidade O produto resolve o problema real de forma completa, não pela metade. Não é uma prova de conceito. É uma solução que funciona no mundo real, para clientes reais.
2. Usabilidade A interação é intuitiva e sem fricção. O cliente não precisa de manual. Não precisa de suporte para descobrir o valor. Navega naturalmente até o resultado que busca.
3. Deleite A experiência gera emoções positivas. Há algo que surpreende, que parece ter sido pensado especificamente para aquele cliente. Um detalhe que transforma usuário em defensor.
Faltando qualquer um dos três, o produto pode ser funcional, mas não é amável.
Por que a Customer Obsession muda o padrão mínimo
O Princípio de Liderança número 1 da Amazon é categórico:
“Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust.”
Se você parte do cliente e trabalha de trás para frente, viável nunca é suficiente. Viável é o mínimo para o produto não falhar. Amável é o mínimo para o cliente voltar, recomendar e se tornar defensor da marca.
O segundo princípio que sustenta o MLP é o “Insist on the Highest Standards”:
“Leaders have relentlessly high standards. Defects do not get sent down the line.”
Na visão da Amazon, o MVP, como praticado na maioria das empresas, enviava defeitos linha abaixo. Normalizava lançar produtos incompletos em nome da velocidade. O MLP corrige esse erro de calibração: o mínimo aceitável passa a ser o que o cliente amaria.
Os produtos que comprovam a teoria
Kindle (2007)
O Kindle não foi lançado como “um leitor de e-books funcional”. A equipe trabalhou com um objetivo declarado: o dispositivo deveria desaparecer nas mãos do leitor, tão natural quanto segurar um livro de papel. No lançamento, havia mais de 90.000 títulos disponíveis, incluindo 101 dos 112 bestsellers do New York Times. Vendeu todos os estoques em 5,5 horas. Não era apenas viável. Era amável desde o primeiro dia.
Amazon Echo e Alexa (2014)
Desenvolvido em anos de trabalho sigiloso, o Echo foi construído com um objetivo: criar uma experiência de voz tão natural que os usuários sentissem estar conversando com algo genuinamente inteligente. Hoje, com mais de 600 milhões de dispositivos Alexa ativos (incluindo licenciamentos para terceiros), é possivelmente o maior case de hardware com crescimento orientado pelo produto da história.
Amazon Prime
Desenvolvido a partir da pergunta “o que nos faria amar a Amazon como plataforma de compras?”, o Prime foi construído para eliminar toda a fricção do e-commerce. Frete grátis. Rápido. Previsível. Sem pensar. A resposta emocional dos clientes foi amor, não satisfação.
O Working Backwards como operacionalização do MLP
O MLP na Amazon não é um valor abstrato. Tem um mecanismo específico que o torna concreto: o processo Working Backwards.
Antes de escrever uma linha de código, a equipe escreve o press release do produto já lançado. O documento precisa responder:
- Para quem é este produto?
- Qual problema resolve?
- Por que o cliente vai amar?
- Qual detalhe vai fazer este produto se destacar?
Esse exercício força a resposta para a pergunta central do MLP, “o que tornará isso amável?”, antes de qualquer decisão técnica ou alocação de recursos.
Colin Bryar e Bill Carr documentam no livro Working Backwards (2021) que escrever um press release é muito mais barato do que construir um MVP para testar a mesma hipótese, com uma vantagem adicional: testa se a proposta de valor é amável antes de gastar um centavo em desenvolvimento.
MLP além da Amazon: quem mais adota
Spotify
Usa explicitamente o MLP no processo de desenvolvimento. A sequência interna é: MVP (testar hipótese com usuários limitados) → MLP (produto que um segmento específico ama) → produto escalável (pronto para toda a base). A diferenciação por personalização profunda, especialmente os algoritmos de playlist, é a expressão prática dessa filosofia.
Slack
Lançou em 2013 sem nunca usar o termo MLP, mas com a filosofia incorporada: em vez de lançar uma ferramenta de chat funcional, criou uma experiência de comunicação que as equipes de tecnologia amavam usar. Zero marketing tradicional. Zero vendas outbound. Cresceu puramente por defensores apaixonados. Contratou o primeiro vendedor em 2016, depois de já ser unicórnio.
Henrik Kniberg e o Earliest Lovable Product
O coach lean/ágil sueco que trabalhou com Spotify chegou à mesma conclusão de forma independente. Em 2016, propôs o framework Earliest Testable / Earliest Usable / Earliest Lovable Product, com uma metáfora visual que ficou famosa: cada etapa de desenvolvimento precisa ser usável e amável para o segmento que a recebe naquele momento. Não é suficiente ter uma roda se o que o cliente precisa é de transporte.
As limitações reais que ninguém fala
Seria desonesto apresentar o MLP sem as suas tensões. Elas existem e são relevantes.
O custo é real. Construir um MLP custa significativamente mais que um MVP em tempo e recursos. Para startups em estágio pré-validação, polir a experiência antes de confirmar que alguém vai pagar pelo produto é um risco genuíno.
Valide antes de encantar. A crítica mais grave ao MLP: construir um produto amável antes de validar que existe demanda. A lógica lean permanece válida. A sequência correta é: confirme que o problema existe e que as pessoas pagariam pela solução. Depois, construa algo que as pessoas amem.
“Amável” é subjetivo. Diferente do MVP, que tem métricas relativamente claras (taxa de conversão, retenção, receita), o MLP depende de pesquisa qualitativa e leitura cuidadosa de comportamento. O que encanta um segmento pode irritar outro.
O risco do scope creep disfarçado. Equipes podem usar o MLP como justificativa para adicionar features desnecessárias sob o pretexto de “tornar o produto mais amável”, violando o princípio de minimalidade que é central a qualquer framework de lançamento incremental.
O que você pode aplicar agora
O MLP não exige que você seja a Amazon. Exige uma mudança de pergunta.
Antes de qualquer lançamento, substitua a pergunta “isso está pronto para ir?” por “nos orgulharíamos de levar isso ao mercado?”
Se a resposta for não, a pergunta seguinte é: o que falta para que a resposta seja sim?
Escreva o press release antes de construir. Não precisa ser formal. Pode ser um parágrafo. Mas articule o que o cliente vai amar neste produto antes de alocar um único recurso para construí-lo.
Identifique os três pilares no seu produto. Funcionalmente, ele resolve o problema de forma completa? É intuitivo o suficiente para o cliente chegar ao valor sem ajuda? Tem algum detalhe que surpreende positivamente?
Defina “amável” para o seu segmento. Amor não é universal. Para um usuário corporativo que precisa auditar relatórios, amável é confiabilidade e rastreabilidade. Para um estudante que aprende uma nova habilidade, amável é progresso visível e celebrado. Conheça seu cliente profundamente o suficiente para saber o que ele chamaria de amor.
A mudança de padrão que importa
O MLP não é sobre fazer produtos bonitos. É sobre não aceitar um padrão mínimo que o cliente não escolheria voluntariamente.
Em mercados saturados, produtos apenas funcionais não geram mudança de comportamento. O cliente já tem alternativas. Ele vai usar o que já conhece até encontrar algo que o faça sentir que foi pensado especificamente para ele.
Jeff Bezos escreveu na carta aos acionistas de 1997, republicada todos os anos até sua saída da Amazon:
“Our energy at Amazon comes from the desire to impress customers rather than the zeal to best our competitors.”
O padrão de referência é o que impressiona o cliente. Não o que supera o mínimo competitivo.
Isso é o MLP. Não um framework. Uma calibração de padrão.
E a pergunta que fica, para todo produto, toda feature, todo lançamento: isso é algo que as pessoas vão amar?
Antonio Polo é consultor em Kanban e OKR, com mais de 20 anos de experiência ajudando organizações a entregar com mais foco, fluxo e resultados reais.