Exemplos de produto mínimo viável (e por que funcionaram)

A maioria dos fundadores lê sobre MVPs e ainda assim constrói demais. O motivo é que 'produto mínimo viável' foi esticado até passar a significar 'versão pequena do produto final', o que nunca foi seu verdadeiro sentido. Um MVP de verdade é a menor coisa, muitas vezes até constrangedora, que permite testar a hipótese mais arriscada do seu negócio — e muitas empresas famosas começaram com algo que mal podia ser chamado de produto.

O que segue são exemplos concretos de MVPs que funcionaram, o que cada um testou e o que você pode aproveitar sem copiar. O padrão em todos eles é o mesmo: escolha a hipótese que mataria o negócio se estivesse errada e teste-a com a coisa mais barata que produza evidências honestas.

Airbnb: um site de três páginas e um colchão inflável

A primeira versão do Airbnb foi um site feito em um fim de semana que oferecia três colchões infláveis no chão do apartamento dos fundadores durante uma conferência de design em San Francisco. Não havia sistema de reservas, nem pagamentos, nem avaliações, nem inventário além do que os fundadores possuíam pessoalmente. Três pessoas pagaram oitenta dólares cada.

O que eles testaram foi a hipótese mais arriscada: estranhos pagariam para dormir na casa de outra pessoa? Todo o resto — pagamentos, escala, oferta, confiança — poderia ser resolvido depois, se e somente se a resposta fosse sim. Essa disciplina é o que a maioria dos MVPs não consegue captar; eles constroem as partes fáceis e pulam o teste da parte difícil.

Dropbox: um vídeo de três minutos

O primeiro MVP do Dropbox não era software algum. Era um vídeo de três minutos gravado da tela mostrando como seria a sincronização de arquivos de forma fluida, narrado pelo fundador e cheio de referências que o público-alvo (usuários iniciais do Digg e do Hacker News) reconheceria. A lista de espera saltou de cinco mil para setenta e cinco mil da noite para o dia.

A hipótese testada era se pessoas suficientes queriam a experiência para justificar construir a engenharia difícil por trás dela. O vídeo custou um fim de semana; a engenharia teria custado um ano. Inverter essa ordem teria sido um desastre se a demanda não existisse.

Zappos: sapatos da loja do outro lado da rua

Antes de construir estoque, depósito ou logística, o fundador da Zappos foi a lojas locais de calçados, fotografou sapatos e os anunciou em um site básico. Quando alguém fazia um pedido, ele voltava à loja, comprava os sapatos pelo preço de varejo e os enviava. Ele perdeu um pouco de dinheiro em cada venda e aprendeu uma quantidade enorme sobre demanda.

O MVP testou se as pessoas comprariam sapatos online de forma alguma — numa época em que a sabedoria convencional dizia que não. A infraestrutura que acabaria definindo a empresa foi deixada para depois até que a demanda fosse comprovada. O fato de ser barato testar era o ponto, não uma limitação.

Buffer: um experimento de landing page em duas páginas

O MVP do Buffer foi um teste em duas páginas. A primeira página descrevia o produto e três faixas de preço; o call-to-action levava a uma segunda página que dizia que o produto ainda não estava pronto e pedia ao visitante para deixar um e-mail. O experimento media duas coisas: se alguém clicava até a página de preços e qual faixa de preço escolhia.

Só depois que a página de preços gerou cadastros relevantes o fundador escreveu a primeira linha de código. Essa sequência — validar a disposição de pagar antes de construir — é o padrão mais subutilizado no trabalho de produto em estágio inicial.

Stripe: instalar em sete linhas

O MVP mais antigo da Stripe não era um painel sofisticado nem um site de marketing. Era um trecho voltado para desenvolvedores que prometia pagamentos em sete linhas de código, instalado manualmente pelos fundadores para os primeiros usuários. Eles literalmente se sentavam ao lado dos desenvolvedores e integravam a API para eles — um serviço disfarçado de produto.

A hipótese testada era que a experiência de pagamentos existente era tão dolorosa que os desenvolvedores adotariam qualquer coisa dramaticamente mais fácil. Instalar manualmente para os primeiros doze usuários deu aos fundadores uma compreensão incomparável de cada atrito de integração. Essa percepção moldou o produto mais do que qualquer roadmap poderia ter moldado.

Padrões comuns que você pode aproveitar

Em todos esses exemplos — e em dezenas de outros semelhantes — alguns padrões se repetem. Observe que nenhum deles é uma 'versão pequena do produto final'. São testes da crença mais arriscada sobre o cliente, entregues na forma mais barata possível.

• Identifique a única hipótese que mataria o negócio se fosse falsa; teste apenas essa.
• Prefira um serviço manual a software quando a questão for demanda, não tecnologia.
• Cobre dinheiro de verdade, ou meça um compromisso real, no primeiro teste — não depois do polimento.
• Use vídeos, mockups ou landing pages quando o custo de construir superar o custo de estar errado.
• Aceite o constrangimento da versão inicial — o polimento esconde o sinal que você precisa ver.

Projetando seu próprio MVP

Escreva em uma frase a crença mais arriscada do seu negócio. Depois pergunte: qual é a coisa mais barata, mais rápida e mais constrangedora que me diria se essa crença é verdadeira ou falsa? Essa coisa — seja o que for — é o seu MVP. Se você conseguir entregar o resultado manualmente, faça isso. Se um vídeo bastar, produza o vídeo. Se uma landing page for suficiente, publique a landing page.

O MVP tem sucesso quando você aprende algo que muda seu plano, não quando lança algo bonito. Trate o produto inicial como um instrumento para coletar evidências, não como um rascunho da versão final, e você gastará uma fração do que a maioria dos fundadores desperdiça antes de alcançar o product-market fit.