Produto mínimo viável: como testar, validar, transformar e lançar um produto ou serviço?
Veja porque grandes empresas estão adotando o MVP (Minimum Viable Product – ou Produto Mínimo Viável) e lançando produtos de sucesso cada vez mais.
Robério Gonçalves
Designer
Termo criado por Frank Robinson, em 2001, e popularizado por Eric Ries por meio de seu livro Lean Startup (aqui no Brasil foi traduzido para A startup enxuta), o MVP trata-se da versão de um novo produto que permite uma equipe coletar o máximo de aprendizado, com o mínimo de esforço, e validá-lo. Não significa criar um produto com a menor funcionalidade e não é também lançar o "produto mínimo viável" para o público final. O MVP é um mecanismo de aprendizado validado, que é usado para testar hipóteses e descobrir o que atenderá às necessidades dos clientes.
Porém, note-se que o termo "produto mínimo viável" não deve ser necessariamente seguido ao pé da letra. Há empresas que o alteram para "produto mínimo adorável". Já Henrik Kniberg, cujo trabalho é mais conhecido por sua participação na cultura de engenharia do Spotify, prefere descrevê-lo como Produto Antes Testável/Usável/Adorado.
Veja, na imagem abaixo, a ideia que define esse conceito de Henrik Kniberg (o desenho foi feito por ele mesmo). E é a partir dessa ideia que estruturamos nossa postagem sobre esse tema.
Desenho de Henrik Kniberg
Essa imagem de Henrik, muitas vezes mal interpretada, é uma metáfora. No exemplo dele, não se trata do desenvolvimento real do carro, mas do desenvolvimento do produto em geral, usando o carro como metáfora.
A linha superior apresentada no desenho ilustra um equívoco comum sobre o desenvolvimento de produto interativo e incremental (também conhecido como Agile).
Segundo Henrik, muitos projetos não vão adiante porque os desenvolvedores do produto o entregam por completo de uma única vez, isto é, o constroem até ficar 100% pronto e o entregam no final. Por outro lado, quando o produto é apresentado sob a perspectiva do Agile (interativo e incremental), como era de se esperar, as pessoas hesitam em entregar um produto inacabado – ninguém quer a metade ou partes de um carro, não é?
Imagine o seguinte:
— Senhor, aqui está nossa primeira iteração do produto, um pneu dianteiro. O que você acha?
Continuando com a ideia do Agile, o cliente receberia o carro em partes e, ao final, ele teria o carro completo, que era o seu objetivo. E aí está o equívoco, porque muito tempo decorreu até que o carro ficasse pronto, sem que em nenhuma das etapas tivesse tido teste real do usuário (não é possível testar rodas e chassi somente, não é?), de modo que o produto pode estar repleto de falhas de design, talvez baseadas em suposições incorretas sobre o que o usuário final precisava.
Nesse primeiro exemplo, o cliente recebeu o produto esperado, mas como ele foi desenvolvido pelo método Agile, de modo incremental, a ausência de um feedback constante torna-o muito arriscado — e definitivamente não ágil.
Agora, com base na segunda linha do desenho de Henrik Kniberg, há uma abordagem um pouco diferente. Embora o cliente tenha comprado o carro, a criação do produto não começou de forma incremental, mas na ideia subjacente: "Preciso ir do ponto A ao ponto B mais rapidamente", de modo que o carro seria apenas uma solução possível para isso. Lembre-se que o exemplo do carro é somente uma metáfora, então você deve pensar em qualquer tipo de situação de desenvolvimento de produto de acordo com o seu caso.
Nessa situação, a equipe pode oferecer, por exemplo, a menor coisa que torna possível o cliente testar e dar o feedback. Obviamente, o cliente pode ainda não estar satisfeito, claro. Mas esta não é fase em que o cliente deve ficar feliz ainda, pois esta etapa é somente para aprender. Então é importante que a equipe explique isso para o cliente com antecedência, para que ele não fique muito desapontado.
Mas note que, diferentemente do exemplo anterior, o skate hipotético é um produto testável/utilizável, que faz o cliente conseguir sair do ponto A e chegar ao ponto B. Portanto, dizemos ao cliente: “não se preocupe, o projeto não foi concluído, pois esta foi apenas a primeira de muitas iterações. Ainda estamos com o objetivo de construir um carro, mas, enquanto isso, tente usá-lo e nos dê um feedback”. A ideia é pensar grande, mas entregar em pequenos incrementos viáveis.
Podemos aprender algumas coisas realmente surpreendentes com isso. Suponha o seguinte diálogo com o cliente:
— Odiei o skate.
— Por quê? — perguntamos ao cliente.
— Não gostei da cor.
— Uh…. a cor? Isso é tudo? – indagamos novamente.
— Sim, você pode fazê-lo azul? Fora isso, está tudo certo! — responde o cliente.
Nesse exemplo, você acabou economizando dinheiro, pois não foi preciso construir o carro! Provavelmente não, mas quem sabe?
A questão principal é: “Qual é a maneira mais econômica e rápida de começar a aprender? “Podemos entregar algo antes de entregar o skate? Que tal uma passagem de ônibus?
Você não precisa testar o produto com todos os usuários nem construir um produto para testar algo. Testar um protótipo, até mesmo com um único usuário, vai lhe ensinar mais do que nada.
Continuando a metáfora, podemos chegar à constatação de que o cliente, depois de usar o skate alguns dias no escritório, diz:
— O skate é bastante divertido e consigo chegar mais rapidamente à máquina de café, mas é instável, e caio muito!
Assim, a próxima etapa consistiria em fazer que o cliente pudesse se locomover sem cair (skate 2).
Desse modo, depois de muitos feedbacks do cliente, o produto poderia ser transformado gradativamente, tornando-se a hipotética bicicleta, a moto e até mesmo o carro. Mas antes de se transformar verdadeiramente em um carro, talvez o produto que o satisfaça seja a bicicleta.
Por meio de uma análise inicial, talvez seja possível prever o contexto das necessidades do cliente e desenvolver o produto esperado imediatamente, sem as fases de feedbacks, mas na maioria dos cenários de desenvolvimento dos produtos da vida real, a despeito de todas as análises iniciais, acontecem inúmeras surpresas quando o usuário real coloca as mãos no primeiro lançamento.
Portanto, sim, você deve fazer uma análise inicial e descobrir o máximo que puder antes de iniciar o desenvolvimento. Mas não gaste muito tempo nisso e não confie muito na análise – em vez disso, comece a prototipar e lançar. É aí que o verdadeiro aprendizado acontece.
Podemos de fato acabar com o mesmo hipotético carro que imaginamos originalmente. No entanto, é muito mais provável que ganhemos insights vitais ao longo do caminho.
O conselho de Henrik Kniberg é que "você pode aprender e fazer alterações, em vez de apenas seguir o plano e esperar pelo melhor. Começar pequeno não significa que você não pode pensar grande."
Se você quiser acompanhar essa metáfora de Henrik Kniberg na íntegra e ler sobre a experiência dele no Spotify (desde a época do “Spotify skate” deles até o “Spotify carro” de hoje), veja esta matéria (em inglês).
Aqui, na Witix, com base no conceito MVP, já construímos muitos skates que hoje já se tornaram os carrões de nossos clientes.
