Mas Afinal o que é um MVP - Minimum Viable Product
Introdução
Este artigo será de leitura curta, mas contém informações sobre o que é um MVP, ilustrado com alguns exemplos paradigmáticos que suportarão a própria conclusão do artigo.
Definição de MVP – Minimum Viable Product
O termo MVP – Minimum Viable Product foi popularizado pelo autor Eric Ries, autor do best-seller “The Lean Startup”. Sua definição diz que um MVP – Minimum Viable Product é uma versão do novo produto que nos permitirá recolher a máxima quantidade de aprendizagem validada sobre os consumidores, com o mínimo de esforço possível. Em suas próprias palavras: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about the customers with the least effort.”
Será que as empresas e as equipas estão definindo e entregando efetivamente um MVP?
Lendo e compreendendo a definição de MVP – Minimum Viable Product, uma questão surge nos dias de hoje:
1 – Será que precisamos desenvolver um produto com um número mínimo de recursos para termos um MVP? A resposta é NÃO.
No entanto, a maioria das empresas e equipes que trabalham nesses assuntos acredita e faz isso repetidamente, sprint após sprint. O objetivo é entregar algo novo em cada sprint/iteração e no prazo proposto, e depois avaliar o que os clientes acham. Isso piora quando não há essa iteração.
O próprio autor do livro, Eric Ries, dá o exemplo de como foi frustrante desenvolver o que ele pensava ser um MVP. Ou seja, um produto com um número mínimo de recursos, colocá-lo online e pedir às pessoas para fazerem o download. Ele dá esse exemplo porque o número de downloads desse suposto “MVP” foi zero. Isso aconteceu apesar de todo o esforço e investimento feito em campanhas Adwords.
Se esse simples exemplo não for suficiente, analisemos os exemplos de empresas reais no próximo ponto.
Os Custos de uma Má Definição de MVP
Os produtos que não funcionam, ou seja, que não proporcionam uma experiência excepcional aos clientes, têm custos associados, refletindo-se em:
- Dívida técnica e dívida de UX.
- Custos de reputação de marca. A primeira impressão é sempre a que fica, e se a impressão for ruim, isso se traduzirá em custos.
- Custos de suporte e treinamento. Se o produto MVP for ruim, será necessário explicar aos clientes como utilizá-lo.
Exemplos de MVP que não envolvem necessariamente o desenvolvimento de software
Os exemplos apresentados são de Empresas que oferecem uma boa experiência de cliente e tudo partiu de um MVP bem pensado. Lançar um MVP não é uma atividade fácil. É preciso saber muito bem o que se pretende com o produto que estamos a desenvolver; perceber as necessidades dos potenciais clientes e a partir dai pensar no que pode mesmo ser o seu MVP e não a versão 1.0 ou versão beta. Vejamos os exemplos abaixo.
Exemplo 1 – DropBox
O exemplo da DropBox é flagrante e paradigmático de que para se desenvolver um MVP não é preciso desenvolver features para um produto. No caso da DropBox o seu MVP foi um video onde se apresentava aquilo que seria o produto e era disponibilizado um endereço de e-mail para as pessoas se inscreverem. A lista de espera beta para o serviço saltou de 5.000 para 75.000 potenciais utilizadores quase da noite para o dia.
Veja o video do MVP da Dropbox
Exemplo 2 – Amazon
Outro exemplo interessante é o da Amazon. O MVP da Amazon baseou-se numa abordagem simples de desenvolvimento de um aplicativo com um back-end manual que os utilizadores não conhecem.
E mais, era o próprio Jeff Bezos a comprar os livros nas livrarias e despachá-los para os clientes pelo correio.
Foi uma abordagem inicial de baixo custo, como se pretende num MVP, mas funcionou. Em dois meses, a Amazon estava a ganhar perto de US$ 20.000 / semana.
Exemplo 3 – Instacart
O exemplo da Instacart é muito semelhante ao exemplo da Amazon.
O seu fundador teve a brilhante ideia de desenvolver um serviço móvel de entregas ao domicílio de supermercado. No entanto, na época, ele não tinha recursos para construir o extenso e complexo back-end do aplicativo.
A solução (MVP) foi o de criar, tal como a Amazon, um back-end manual, ou seja, sempre que uma pessoa encomendava algo do Instacart MVP, os fundadores tinham que comprar esses produtos e entregá-los aos clientes. Tudo manualmente.
MVP vs Versão 1.0 ou Versão beta
As diferenças entre um MVP e uma versão 1.0 ou versão beta de um produto está na sua definição, nomeadamente nos pontos:
- “aprendizagem validada sobre os consumidores”
- “Mínimo esforço possível”
Ou seja, a versão 1.0 ou versão beta de um produto pressupõe um lançamento. E havendo um lançamento, logicamente há ou terá de haver bastante esforço envolvido. Por outro lado, ao lançarmos uma versão 1.0 ou beta, em princípio, estamos cientes já daquilo que iremos lançar e o nosso propósito não é o de recolher findings e insights, ou seja termos uma aprendizagem validada por parte dos consumidores. Não que eles não nos possam dar feedback, mas esse feedback não fará parte do ciclo de iterações que um MVP terá. À partida, uma versão 1.0 de um produto já passou por ser um MVP. Mas um MVP não passa por ser uma versão 1.0 ou beta do produto. A não ser que o que esteja em causa na definição dessa versão 1.0 ou versão beta é a definição correta do MVP.
Mas Como nos focamos em Entregar um MVP na Realidade
O foco das empresas e das equipas em entregar um MVP depende primeiramente na correta compreensão do que é um MVP como visto acima. E tudo isto tem a ver com a cultura. Se a empresa tiver uma forte cultura de research e é madura o suficiente em termos de UX, o foco no que é na realidade um MVP torna-se fácil.
Por outro lado, se a cultura é a do “agile” de sprints a cada 2 semanas, entregar depressa e dentro destes prazos de forma inflexível e sem recorrer a várias iterações em cada ciclo de entrega, então o foco é a entrega de features em detrimento de entrega de outcomes que tem pro base o MVP definido à priori.
Conclusão
Antes de chegarmos a alguma conclusão sobre o que é definitivamente um MVP na prática, convêm perceber porque razão as empresas desenvolvem produtos ou serviços.
Eu diria que existem 2 tipos de razões. Um primeiro tipo de razões são aquelas em que o foco está no Outcome proporcionado. E um segundo tipo de razões são aquelas em que o foco está no output. Vejamos cada uma dessas razões:
Razões para desenvolver produtos/serviços em que as empresas estão focadas no Outcome
- Provocar uma mudança no mundo e/ou nos comportamento do cliente que torne a sua vida melhor, mais fácil e vice-versa.
- Surpreender e/ou Deliciar os clientes (relacionada com a primeira razão)
Razões para desenvolver produtos/serviços em que as empresas estão focadas no Output
- Atrair cada vez mais clientes
- Gerar mais receitas (relacionada com a primeira razão)
Desenvolver um determinado produto com uma série de features (mínimas ou que achamos mínimas), pode não ser o nosso MVP e, consequentemente, podemos não estar a entregar valor aos clientes, e não entregamos valor ao nosso negócio. Mas acima de tudo, não conseguimos iterar com os clientes de forma ideal para que possamos realmente apresentarmos um produto que seja “valioso” para os clientes e nos traga valor para o negócio. Isto porque não temos as iterações suficientes em termos de research.
