Você sabe o que é um MVP?

Em outro post mais antigo aqui do blog eu falei sobre como criar um MVP na prática, assumindo à época que o conceito de MVP era algo já “batido” e dominado por todos. No entanto, no final do ano passado finalmente entendi que embora todos saibam o que é a sigla, pouquíssimas pessoas realmente entendem a filosofia por trás deste conceito e o que de fato Eric Ries pretendia quando tornou-o famoso (embora ele não tenha criado o mesmo) em 2011.

A situação que me deparei foi a seguinte:

Ao que parecia, MVP era uma sigla que gestores que pouco entendem do assunto passaram a usar para convencer os times de desenvolvimento e a diretoria que sabiam o que estavam fazendo. Não havia nada de “mínimo” no escopo proposto, nada de “viável” no prazo estabelecido e nada de “produto” uma vez que era apenas um copycat. Resumindo, era uma sandice chamar este projeto de um MVP.

Chegou-se a usar inclusive a piada interna de que MVP significava “Maximum Viable Product” para aquele projeto.

Sendo assim, neste artigo (antes tarde do que nunca), eu tentarei dar uma luz à este tema, falar das origens, das armadilhas e muito mais.

A origem

O termo MVP passou a ficar famoso após a obra Lean Startup de Eric Ries, lançada em 2011, que já escrevi resenha aqui no blog. O conceito não foi ele quem inventou, ele é de 2009, e principalmente as ideias do Lean Startup também não eram 100% originais uma vez que Ries foi aluno de Steve Blank, autor do famoso livro The Four Steps to the Epiphany, onde descreve a metodologia Customer Development, além de ser investidor de muitas startups de sucesso e professor de empreendedorismo em universidades americanas.

Mas voltando à obra do Eric, neste fantástico livro ele nos traz conceitos como Contabilidade para Inovação (resumindo seu CAC deve ser menor que seu LTV), Métricas de Vaidades vs Métricas Acionáveis (ou sua métrica faz parte de um funil similar a um AARRR ou esqueça), Product Market-Fit (ajuste seu produto para atender uma necessidade de mercado), Pivotar (mude o produto conforme a necessidade, mas não a visão), Early Adopters (encontre primeiro quem pagaria para testar seu produto) e o famoso MVP (o mínimo para oferecer aos Early Adopters).

Claro que fui bem raso nas considerações sobre cada conceito e realmente lhe encorajo a ler este livro por completo.

Build-Measure-Learn

A metodologia foca muito forte em um ciclo chamado Build-Measure-Learn ou Construir-Medir-Aprender, conforme mostrado no diagrama abaixo. Esse ciclo foca em ajudar empreendedores a criar produtos inovadores, afinal, se você está apenas copiando um produto, não há porque ficar “experimentando”, apenas copie a receita do concorrente e pronto.

Você constrói uma parte do seu produto, mede o resultado alcançado e aprende com essas medições para que possa construir a próxima parte do seu produto. O ciclo ele é bem tranquilo quando estamos acertando, mas e quando estamos errando? Aí entra uma variação desse diagrama que é a minha favorita:

Nesta versão, que não é oficial do livro, quando o aprendizado nos traz que falhamos na ideia que construímos, é hora de pivotar (mudar de direção); ou seja, partimos para o campo das ideias e/ ao invés de ir para a próxima parte do produto, pode ser necessário trocar de funcionalidade (mais comum) ou até de produto (casos mais extremos).

Note também que esta versão enfatiza o uso de métricas acionáveis na medição para que de fato tenhamos aprendizado. Lembra quando falamos em Scrum sobre a Definição de Pronto? Não pode haver ambiguidade no que “DONE” significa e a analogia que faço aqui é que não pode haver ambiguidade sobre o que uma métrica significa para o sucesso do produto.

Você deve medir Métricas Acionáveis para poder aprender algo real com o que construiu. Métricas Acionáveis são aquelas que impactam diretamente no sucesso do seu produto, enquanto que as Métricas de Vaidade são aquelas que não contribuem tanto assim. Em minha antiga startup, uma métrica de vaidade era o número de visitantes no site. Uma métrica acionável era a receita gerada pelos anunciantes. Embora elas estivessem ligadas de alguma forma, a que realmente importava era a segunda.

Mas o que eu realmente queria mostrar nesta imagem era que a etapa Build do ciclo serve para construir um MVP. O ciclo Build-Measure-Learn e o MVP estão intimamente ligados uma vez que…anote isso…

Um MVP é criado para que possamos rodar uma vez o ciclo completo de Build-Measure-Learn. O seu tamanho deve ser pequeno o bastante para que seja barato falhar (considerando que estamos trabalhando com inovação, falhar faz parte do processo) e grande o bastante para que permita rodar o ciclo completo uma vez.

Ou seja, um MVP não serve para lançar um produto mais rapidamente no mercado, não na sua primeira iteração ao menos. Ele serve para validar uma hipótese, para se certificar que seus Early Adopters compram a ideia dele. Para lhe ajudar a entender se o que você está pensando tem futuro, se faz sentido.

Pra rodar uma vez o ciclo de Construir-Medir-Aprender, usando Métricas Acionáveis.

Apenas isso.

O Mindset MVP

O mindset MVP é como chamo o raciocínio de construir produtos usando a técnica de MVP do Lean Startup como guia. Provavelmente eu não inventei este termo, mas é assim que chamo.

Uma das imagens mais populares para o raciocínio de MVP é a abaixo:

Aqui temos a abordagem linear de construção de produtos no topo, e a abordagem usando MVPs.

A visão de ambos empreendedores é a mesma e pode ser definida como “fornecer uma solução de entrega”, onde o que eles adorariam ter seria um caminhão para fazer as entregas com o melhor custo-benefício entre velocidade de entrega, custo e capacidade de carga. No entanto, eles não possuem dinheiro para construir o caminhão em apenas uma iteração, deverão fazer aos poucos.

Enquanto que na abordagem linear, o “construir aos poucos” se resume a construir pedaços do caminhão, na abordagem MVP vamos iterando através de soluções de entrega alternativas e mais baratas ao caminhão, permitindo que desde a primeira iteração já tenhamos nosso produto gerando receita na rua. Ok, as primeiras versões (bicicleta e vespa) talvez não agradem o bastante nossos consumidores (a primeira é lenta e a segunda carrega pouca carga), mas a partir da terceira iteração já passamos a colher bons frutos.

Este diagrama possui muitas variações e serve para ilustrar um pouco o mindset MVP, mas não mostra todos os benefícios da técnica, principalmente considerando o cenário hipotético de que por exemplo, o mercado poderia estar precisando de entregas mais rápidas e menos poluidoras. Neste caso, qualdos dois empreendedores você acredita que poderia pivotar sua estratégia de entrega com o menor custo?

O mindset MVP é iterativo-incremental assim como os métodos ágeis, ao contrário do raciocínio waterfall das abordagens lineares de construção de produtos, onde um gerente de produto acredita ter todas as respostas sobre um mercado na sua cabeça. Repito: se não estiver trabalhando com inovação, mas apenas cópias, talvez dê certo sem uma abordagem MVP.

O Mindset MVP II

Quando entramos mais a fundo no estudo do mindset correto de criação de produtos inovadores entendemos que apenas uma abordagem simplista como a anterior não é o suficiente, embora seja um bom ponto de partida.

Uma falha comum na criação de MVPs é esquecer que ele deve ser um produto. E um produto deve ter algumas características mínimas que proporcionem ao Early Adopter uma experiência que o motive a pagar. O que quero dizer com isso é que um MVP não é “o que eu consigo construir do produto no tempo que eu tenho”, longe disso.

Para ilustrar melhor, considere esta abordagem linear de construção de um produto “bolo de casamento”:

Primeiro a massa de pão de ló, depois o recheio e depois a cobertura. Poderíamos chamar a massa de pão de ló de MVP de um bolo de casamento? Noivas comprariam uma massa de pão de ló para ter uma ideia de como seu produto final será? Estamos proporcionando a experiência correta com esta sequência de desenvolvimento do produto para que possamos gerar aprendizado a partir dele? Claro que não, este é o modo waterfall de desenvolver produtos.

Observe a abordagem abaixo para construção de um produto “bolo de casamento”:

Neste exemplo, nosso MVP (o produto mínimo viável pelo qual noivas pagariam para experimentar) é um cupcake. Um cupcake fornece toda a experiência de um produto “bolo de casamento” e pode ser feito com apenas uma fração do tempo e custo de preparo de um bolo inteiro.

Note que um cupcake não é apenas “o bolo mais rápido que conseguimos fazer”, pois o pão de ló é mais rápido de fazer do que um cupcake. Ele é sim “a experiência de bolo mais completa que conseguimos fazer de maneira rápida”. Jamais chame o “pão de ló” de MVP, ou uma “fatia de bolo” de MVP. Um MVP é um cupcake.

Mas como saber que temos um cupcake, digo, um MVP em mãos?

Quando nosso candidato a produto mínimo viável possui as seguinte proporção de características de um produto inovador:

Esse diagrama mostra as características desejáveis em um produto inovador, da base para o topo:

• factível: conseguimos construir com os recursos que temos;
• valioso: clientes pagariam por isso;
• usável: clientes conseguiriam usar ele;
• encantador: clientes se admiram e recomendam ele aos outros;

Os erros mais comuns de quem acha que sabe o que é um MVP são dois: achar que um MVP deve conter todas estas características na sua plenitude (lembra da imagem inicial deste post?) e o outro é achar que um MVP deve ser apenas “o que conseguimos fazer no tempo e dinheiro que temos”.

Para que seu MVP atraia os clientes certos (no caso de um MVP eles são os Early Adopters), ele deve proporcionar uma experiência de produto adequada. Se fizer algo de qualquer jeito, a sua ideia até pode ser boa, mas não vai vender e você vai ter um falso negativo sobre a sua hipótese de inovação. E se tentar fazer tudo perfeito, um produto completo, poderá demorar muito tempo e perder o time-to-market, ou até mesmo descobrir só mais tarde que construiu algo que ninguém quer.

Espero que eu tenha ajudado a esclarecer e desmitificar esta importante técnica!

E agora que você sabe o que é, leia este artigo para ter algumas ideias de como criar um na prática ou este aqui que fala das armadilhas do conceito.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!