Minimum lovable product: onde investir o amor

Um minimum lovable product não é um MVP mais polido. É um MVP com o amor concentrado em um só lugar. Como um founder não-técnico decide onde esse amor vai, e quando “lovable” vira uma desculpa cara para superdimensionar o produto.

Um founder com quem trabalhamos no ano passado chegou ao kickoff de um build com uma lista de 41 coisas que a primeira versão “tinha que parecer ótima”. Animações suaves em cada tela. Um tour de onboarding sob medida. Modo claro e escuro. Ele tinha lido três artigos sobre como construir um minimum lovable product no fim de semana e chegou convencido de que “lovable” significava “polido em tudo”. Esse instinto, mais do que qualquer erro técnico, é o que explode primeiros builds.

Um minimum lovable product (MLP) é a menor versão de um produto que as pessoas realmente gostam de usar, não apenas toleram. Ele faz uma coisa tão bem que o usuário perdoa tudo que ainda está tosco ao redor. A palavra que confunde o founder é “lovable”. Ele a lê como um botão de polimento para girar até o máximo. Não é. Amor é um orçamento, e a habilidade toda está em decidir onde gastá-lo.

Então construímos algo diferente da lista dele. Uma tela, o fluxo de agendamento que os clientes tocariam todos os dias, ficou genuinamente boa: rápida, óbvia, difícil de errar. As outras quarenta coisas ficaram honestas e simples. Ele lançou em sete semanas em vez de cinco meses. Seus dez primeiros clientes nunca mencionaram o modo escuro. Mencionaram o fluxo de agendamento, sem ser perguntados, em três das cinco primeiras calls de venda.

O que é, de fato, um minimum lovable product

O termo vem de Laurence McCahill, da The Happy Startup School, que em 2014 o propôs como resposta a um problema real: o minimum viable product original tinha azedado e virado licença para entregar algo meio quebrado e chamar de enxuto. A correção dele foi mudar a pergunta. Em vez de “qual o mínimo que dá para construir e ainda lançar”, pergunte “qual o mínimo que dá para construir e alguém vai amar”.

É uma boa correção. Mas em algum momento entre 2014 e agora, “lovable” foi achatado para “mais features, design mais bonito, experiência mais completa”. Essa leitura é como um founder não-técnico acaba com uma lista de 41 itens “tem que parecer ótimo” e um build de cinco meses para um produto que ninguém pagou ainda.

A leitura correta é mais estreita e mais útil. Um minimum lovable product concentra sua qualidade. Ele escolhe o único momento em que o usuário decide se a coisa vale o tempo dele e faz esse único momento ser inconfundivelmente bom. Em todo o resto, fica deliberada e visivelmente mínimo. O produto não é polido por igual. É torto de propósito.

Minimum viable product vs minimum lovable product

O debate MVP vs MLP é enquadrado como polido versus não polido, e esse enquadramento está errado. Os dois são mínimos. A diferença é onde o mínimo mora.

Um minimum viable product pergunta o quão pequeno o escopo pode ser e ainda te ensinar algo verdadeiro sobre demanda. O risco dele é ser tão fino que não valida nada. Já escrevemos sobre por que a maioria dos MVPs é pequena demais para validar qualquer coisa real; aquele artigo é sobre o tamanho da coisa.

Um minimum lovable product toma o escopo como mais ou menos dado e faz outra pergunta: das coisas que vamos construir, qual carrega o veredito? O risco dele corre na direção oposta. Onde um MVP falha por ser fino demais, um MLP falha por espalhar a qualidade tão por igual que nada se destaca e o orçamento acaba antes do lançamento. Um é uma decisão de escopo. O outro é uma decisão de concentração. Você toma a decisão de MVP primeiro, depois a de MLP dentro dela.

Em bom português: a pergunta do MVP é quanto a gente constrói. A pergunta do MLP é onde a qualidade vai. Tratar as duas como a mesma conversa é como founders acabam ou lançando lixo ou lançando tarde.

Quando “lovable” vira desculpa para superdimensionar

Aqui está o modo de falha que ninguém nos primeiros resultados de busca te avisa, porque eles são escritos majoritariamente para product managers de empresas com capital, não para um founder gastando o próprio runway.

“Lovable” é a palavra mais cara de uma reunião de kickoff. Ela não tem bordas. Qualquer feature pode ser argumentada para dentro do balde “lovable”, porque toda feature poderia, em princípio, ser mais encantadora. Um dev que quer construir a coisa sofisticada e um founder que quer um produto premium vão concordar um com o outro até estourar o orçamento. Já vimos primeiros builds dobrarem de custo não porque o escopo cresceu, mas porque a palavra “lovable” foi aplicada por igual e ninguém freou.

O sinal é quando os pedidos de polimento se grudam em telas que o usuário quase não vê. Transições animadas na tela de configurações do admin. Um estado vazio lindamente desenhado para um relatório que os primeiros clientes não vão rodar por meses. Isso é craft apontado para o alvo errado. Bom design é bom negócio, mas design gasto onde ninguém está olhando é só custo de roupa nova.

A disciplina de um MLP de verdade é dizer “não, essa parte fica simples” em voz alta, de propósito, e conseguir explicar por quê. Se o seu estúdio nunca te diz que uma parte do produto está tosca intencionalmente, você não está construindo um MLP. Está construindo um produto adorável máximo com orçamento mínimo, e a conta não fecha.

O framework do orçamento de amor: decidindo onde o amor vai

Trate a lovability como um orçamento fixo que você está alocando, não como um nível de qualidade que você está ajustando. Antes de o build começar, passe as telas e fluxos candidatos por quatro perguntas. As que pontuam mais alto ganham o amor. Todo o resto pode ser honesto e simples.

1. O usuário toca nisso no dia um, ou todos os dias? O fluxo que o cliente acessa na primeira sessão, e o que ele repete diariamente, são onde os veredictos se formam. Uma tela de agendamento usada vinte vezes por semana merece amor. Uma exportação em massa usada uma vez por trimestre, não.

2. É o momento em que ele decide que a gente vale a pena? Todo produto tem um lugar onde o usuário te avalia em silêncio. Numa fintech, a primeira transação compensando. Num marketplace, o primeiro match que parece certo. Ache esse momento e gaste demais nele, mesmo que seja uma única tela.

3. A tosquice aqui é lida como quebrado, ou só como básico? Algumas arestas toscas são lidas como “no começo e focado”. Outras são lidas como “essa gente não sabe fazer software”. Uma tela de configurações simples está ok. Um checkout que parece capenga é fatal, porque dinheiro deixa as pessoas nervosas e capengagem é lida como risco. Gaste amor onde a tosquice seria lida errado, como incompetência.

4. É onde a gente é diferente, ou onde a gente é igual a todo mundo? Despeje amor na parte que é a sua razão real de existir. As partes que são básicas, login, um dashboard simples, podem parecer iguais às de todo mundo sem te custar nada.

A maioria dos produtos tem um, talvez dois fluxos que vencem nas quatro perguntas. Esse é o seu orçamento de amor. Concentre ali. O trabalho real do framework é te dar, founder não-técnico, a linguagem para defender o “deixa simples” contra uma sala cheia de gente que sinceramente quer deixar tudo mais bonito.

Como isso fica num build de verdade

O MLP do founder de agendamento tinha exatamente uma superfície adorável: o fluxo de agendamento. Gastamos tempo real de design e engenharia nele. Resposta abaixo de um segundo, sem becos sem saída, uma confirmação que passava solidez. Tudo atrás dele, as configurações de conta, os relatórios, as telas de gestão de time, foi construído para funcionar e nada além. Cinza onde cinza era suficiente.

Os concorrentes dele tinham produtos mais completos. Mais configurações, mais polimento espalhado por mais telas. Eles também demoravam mais para lançar qualquer coisa e pareciam, para um usuário novo, um monte de “ok” em vez de uma coisa que era ótima. Seis meses depois do lançamento, ele tinha orçamento e feedback de cliente para deixar as telas de relatório adoráveis também, dessa vez sabendo exatamente quais relatórios as pessoas de fato rodavam. Essa é a ordem certa: conquiste a próxima superfície, não a pré-construa.

Um teste de sanidade útil antes de começar: as decisões sobre polimento são tomadas quando você aprova os designs, não quando o código sobe. Se você não sabe a diferença entre um wireframe, um mockup e um protótipo, você vai dar feedback cosmético no que é estrutural e feedback estrutural no que é cosmético, e seu orçamento de amor vai vazar no ciclo de revisão antes de uma linha de código ser escrita.

Como fazer o brief de um minimum lovable product para um estúdio

Se você está pagando alguém para construir isso, o brief é onde o orçamento de amor se define ou se perde. Três coisas para colocar por escrito.

Nomeie a única superfície adorável explicitamente. Não “deixa premium”. Escreva: “O fluxo de agendamento é a única experiência que tem que ser genuinamente boa. Gaste aqui.” Um bom parceiro vai questionar ou confirmar a sua escolha. Um fornecedor caixa-preta só vai dizer sim e te cobrar por polimento em tudo. Parceiros de tech não deveriam ser caixas-pretas; o vai e volta sobre onde a qualidade vai é exatamente a conversa que vale a pena ter.

Nomeie o que fica simples. Essa é a parte que founders pulam, e é a parte que protege o orçamento. “Configurações, relatórios e gestão de time devem funcionar corretamente e ter aparência padrão. Não gastem tempo de design deixando isso especial na v1.” Colocar a tosquice por escrito a transforma de acidente em decisão.

Amarre ao dinheiro. O orçamento de amor sai do mesmo bolso que todo o resto, então saiba qual é esse bolso. Nossos textos sobre quanto custa desenvolver um app e sobre a decisão de construir ou comprar que fica acima de tudo isso cobrem os números. A versão curta: cada tela que você torna adorável é uma tela pela qual você paga premium. Uma superfície premium cabe em quase qualquer orçamento. Dez é como um primeiro build vira, silenciosamente, uma segunda rodada.

Perguntas frequentes

Qual a diferença entre minimum viable product e minimum lovable product?
Um MVP é sobre escopo: o menor build que ainda testa demanda real. Um MLP é sobre concentração: pegar esse escopo e tornar uma experiência central genuinamente boa, deixando o resto deliberadamente simples. Você decide o escopo do MVP primeiro, depois decide, dentro dele, onde vai a lovability. São sequenciais, não concorrentes.

O que é um minimum lovable solution?
A mesma ideia, aplicada a ferramentas internas ou operacionais em vez de um produto voltado ao cliente. A superfície “adorável” é onde o seu time passa mais tempo. Um dashboard de operação diária merece cuidado real; uma tela de config usada uma vez por mês, não. Concentre a qualidade onde as horas vão.

O que é um minimum acceptable product?
Um minimum acceptable product é o piso: funciona e não te envergonha, mas nenhuma parte foi feita para ser amada. É um alvo ok para uma ferramenta interna descartável. É um alvo fraco para qualquer coisa que um cliente escolhe usar, porque “aceitável” raramente gera boca a boca. Um MLP custa um pouco mais que um minimum acceptable product e concentra esse custo extra em um lugar.

O que é um minimum lovable product na Amazon?
Costuma se referir à prática de “working backwards” da Amazon, escrever o press release e o FAQ antes de construir. É um método para forçar clareza sobre o que os usuários vão amar antes de começar, compatível com tudo acima. Ferramenta diferente, mesmo instinto: decida o que tem que ser amado antes de gastar.

Onde um founder não-técnico deve investir o amor primeiro?
No único fluxo que os clientes mais tocam e pelo qual te julgam, normalmente a primeira ação real que eles fazem no produto. Torne essa coisa inconfundivelmente boa. Deixe o resto honesto e simples até os clientes te dizerem o que melhorar em seguida.

Um minimum lovable product não é o máximo que você consegue pagar para polir. É a única coisa que você se recusa a entregar tosca, cercada por tudo que você teve coragem de deixar simples. Escolha bem essa coisa, e seus dez primeiros clientes vão te dizer se você escolheu certo.