Pensar grande, mas começar pequeno: o mínimo produto viável (MVP) é construção pensada para o aprendizado validado
Como empreendedor, sua visão é a de um produto refinado, de alta qualidade, com grande impacto sobre seu segmento e usuários, capaz de virar um case de sucesso, certo? Está certíssimo!
Então, por que você começaria com um simples mínimo produto viável – MVP, que não vai atender de maneira alguma todas as necessidades nem mostrar todo o seu valor logo de cara para os usuários?
Porque, embora você saiba que praticamente qualquer produto pode ser desenvolvido com as tecnologias de que dispomos hoje, você ainda não sabe com certeza se deve desenvolver seu produto nem tudo que ele precisa ter. Ou melhor, você tem apenas hipóteses sobre isso – e normalmente pouco organizadas.
Basicamente, você só será capaz de responder a essas perguntas desenvolvendo o produto. De fato, mas será que basta desenvolver o produto, que os clientes virão? Nem sempre.
Então, se você pretende investir muito dinheiro, energia e tempo em um produto perfeito para você e sua equipe de desenvolvedores, esperando espontaneamente uma reação positiva do público, você está arriscando demais – e desnecessariamente.
Partir de um MVP ajuda a evitar uma desgraça e, no fim das contas, a fazer um produto que os usuários queiram.
Como? Neste post, explicaremos isso fazendo um breve overview sobre MVP: o que é, de onde veio, por que fazer, tipos, metodologias para desenvolver e riscos de usá-los.
O que é um MVP?
MVP – Minimum Viable Product ou, em português, Mínimo Produto Viável – é a configuração mais básica e fundamental de um novo produto, aquela que oferece sua solução principal.
Entre o produto final e um protótipo, o MVP está bem mais próximo do protótipo, com o nível mais baixo de complexidade possível, menor esforço possível da equipe e, claro, menor custo de desenvolvimento.
Porém, mesmo que imperfeito, ele não é apenas o que é possível fazer no menor tempo possível. Ele precisa ser capaz de despertar interesse, ser funcional e agregar valor para o que Eric Ries, autor de A startup enxuta, chama de adotantes iniciais.
Seu objetivo, ao começar simples, barato e pequeno, é testar o produto com usuários, a fim de obter feedbacks reais sobre as hipóteses de valor e de crescimento, bem como sobre público-alvo, assumidas pelos desenvolvedores.
Partindo da premissa de que você não precisa fazer um produto completo para conhecer isso, fazer um MVP é eliminar todo o trabalho que não contribua diretamente para esse conhecimento.
De posse desse aprendizado validado, a equipe continuará incrementando o produto, em novos lotes de funcionalidades, que tornarão o MVP um produto completo e, ao mesmo tempo, adequado a seu público.
Leia também: Do MVP ao MLP: o que está em jogo?
O conceito de MVP em A Startup Enxuta
Embora seja usado desde os 2000 e faça parte de diversas abordagens de desenvolvimento de produto, o conceito de MVP está estritamente ligado ao livro The lean startup, de Eric Ries – citado acima.
Nesta obra, baseada em sua própria experiência e nos conceitos do Lean Thinking, Ries desenvolve em detalhe a aplicação do ciclo construir-medir-aprender ao empreendedorismo, ou seja, à transformação de ideias em produtos.
O conceito de MVP, dentro desse contexto, é fundamental para encurtamento, aceleração e escalada, consolidando a gestão sustentável da inovação.
Por que fazer um MVP?
Para Eric Ries, em seu A startup enxuta, “um mínimo produto viável (MVP) ajuda os empreendedores a começar o processo de aprendizagem o mais rápido possível”.
Agilidade no lançamento e rapidez na obtenção de feedback: os dois principais motivos para fazer um MVP.
Para perceber a necessidade disso, basta uma comparação com o desenvolvimento tradicional de produtos em cascata. Neste caso, há um enorme período de incubação e a expectativa de chegar a um produto bem acabado ao final do projeto – o que pode ser dar ao longo de anos!
Tudo funcionava assim até a percepção de que o risco de construir um produto inadequado ou obsoleto antes mesmo de ser lançado cresce quanto maior for a duração do projeto com o escopo fechado. Sem contar os custos da mudança, que ficam maiores quanto mais tarde for identificada a necessidade.
Ou seja, se é para errar, que seja rápido, com um produto menor e ainda barato, quando o impacto de suposições erradas não sacrifica o projeto por completo e, junto com ele, o trabalho de uma equipe e o investimento de stakeholders. Que seja o MVP!
Saiba mais: Empresas de desenvolvimento de software: conheça a Supero
Tipos de MVP: formatos que seu produto inicial pode assumir
Sabemos que um MVP é simples e imperfeito, mas o nível de complexidade que ele precisa ter pode variar bastante.
Isso deu origem a tipos de MVP, que podem ser usados juntos, separados ou até mesclados com testes A/B.
1. Protótipo
Este é o tipo de MVP que todo mundo imagina primeiramente. Ele já tem todas as características de um produto funcional, mas ainda em uma versão básica. Mas atenção: tampouco é o que se chama de versão beta. Esta já está bem mais próxima do produto final do que o MVP.
Por causa de suas características, esse tipo de MVP é também considerado o mais efetivo para validação das hipóteses assumidas. Afinal, os clientes vão lidar com ele diretamente.
2. Fumaça
Nem sempre você conseguirá fazer um protótipo real do produto. Produtos tecnicamente complexos, com uma camada de serviço adicional, por exemplo, dificilmente são demonstráveis na forma de protótipo.
Mas isso não os impede de ser validados através, por exemplo, do MVP fumaça.
Neste caso, você fará um vídeo, landing page ou outro canal de marketing, para fazer uma demonstração do seu produto em funcionamento. Veja que nada precisa ser tecnicamente pronto. Você venderá a ideia para ver que feedback obtém.
3. Concierge
Neste modelo de MVP, a validação das hipóteses e a aprendizagem sobre o produto se dão por meio da interação com uma pessoa diretamente, não com o produto em si, que age gerando o mesmo valor que o produto oferecerá.
Evidentemente, nada disso é escalável. Além disso, seu objetivo é criar um produto. Mas a validação do MVP concierge enseja a expansão do produto validado, não o contrário, o que diminui o desperdício e a chance de erro.
4. Mágico de Oz
O Mágico de Oz é uma variação do MVP concierge em que o usuário interage com uma camada superficial de produto, geralmente apenas uma interface, por trás da qual existem pessoas reais fazendo o trabalho.
A ideia deste tipo de MVP é a mesma: automatizar apenas quando o comportamento estiver instaurado e validado pela prática dos usuários.
Como fazer um MVP: metodologias de desenvolvimento de roadmap
E como fazer um MVP, seja ele um MVP protótipo, fumaça ou concierge?
Já falamos que um MVP retira da equipe todo o esforço e do produto todas as funcionalidades que não contribuam diretamente para a validação das hipóteses de negócio assumidas em sua concepção. Saber disso, no entanto, não torna a tarefa de fazer um produto mínimo mais fácil.
Não há fórmula para determinar quantos recursos ele precisa nem o nível de complexidade.
Além disso, a maioria das pessoas envolvidas em um roadmap de MVP superestima a quantidade de funcionalidades necessárias para sua versão inicial. Outro ponto é o público, que geralmente começa muito amplo, mas que para o escopo de um MVP precisa ser bastante nichado, restrito aos adotantes iniciais.
Eric Ries diz que “cada recurso deve ser pensado como uma forma de desperdício”. Mas, ao mesmo tempo, o livro A startup enxuta não nos ensina, passo a passo, a criar um MVP – embora dê vários exemplos.
Há algumas metodologias que auxiliam a desenvolver o roadmap de MVP enxuto. E já falamos sobre duas que mais usamos em nossos projetos aqui no blog:
Design Sprint
Criada por Jake Knapp dentro do Google e exposta no livro Sprint: o método usado no Google para testar e aplicar novas ideias em apenas cinco dias, a design sprint é uma maneira de validar ideias por meio de protótipos construídos por uma equipe reduzida.
Segundo o próprio Knapp, ela está aquém de um MVP (embora o autor opte por uma definição bem mais restrita que a nossa de MVP). Justamente por isso, é ideal começar por ela.
Veja sobre esta metodologia de desenvolvimento de MVPs em Design Sprint: o método do Google passo a passo
Lean Inception
Criada por Paulo Caroli, consultor da ThoughtWorks, e conceituada no livro Lean Inception: como alinhar pessoas e construir o produto certo, essa metodologia alia a Inception – um método de desenvolvimento de produtos – aos conceitos da startup enxuta de Ries.
O resultado é um workshop colaborativo de até cinco dias com profissionais de produto e stakeholders, cujo resultado é um MVP Canvas.
Confira sobre esta metodologia de desenvolvimento no post O que é Lean Inception?
Riscos de lançar um MVP
Uma das perguntas mais incômodas ao se propor um tipo de MVP concerne a seus riscos.
Como provar hipóteses de negócio se um produto mínimo viável não está no seu ápice de desenvolvimento e qualidade? Essa avaliação não será parcial? E no limite, ela não poderá queimar uma marca que ainda sequer nasceu?
São boas essas perguntas. Vamos responder a cada uma delas separadamente.
Testes com um produto incompleto têm validade?
A melhor resposta vem de Eric Ries. De acordo com o autor de A Startup Enxuta, você só define qualidade e completude quando conhece os clientes e o que eles valorizam no produto. No começo você só tem suposições.
Ries vai além, questionando inclusive o valor de focus groups e pesquisas de mercado, materiais normalmente usados para a definição de clientes e de escopo de produto.
Segundo ele, ambos os métodos supõem que as pessoas já saibam o que desejam, o que nem sempre é o caso – sobretudo quando se trata de inovação e de tecnologia.
Então, Ries conclui, de maneira categórica, assim:
Se não sabemos quem é o cliente, não sabemos o que é qualidade.
O primeiro MVP pode parecer limitado, mas na verdade é específico. Estamos falando do primeiro passo de uma jornada bem maior de aprendizagem. Mesmo quando um MVP falha e é percebido como ruim, cria oportunidades de entendimento positivo sobre as necessidades reais do cliente.
É esse aprendizado validado pelo usuário, e não as hipóteses dos empreendedores, que interessa para o desenvolvimento dos próximos lotes de funcionalidades. Incrementos esses que, por sua vez, também serão submetidos ao crivo da experiência, num avanço até as versões mais acabadas do produto.
Um MVP mal-sucedido pode queimar a marca?
Um MVP sempre envolve um risco. Mas não tanto para a marca – que consegue, muitas vezes, controlar o alcance do produto –, e sim para as suas suposições. Aliás, é normal que a negação das suposições aconteça na experiência com o MVP e ceda lugar a novas hipóteses, isto é, ao que Ries chama de pivotar.
Comparado ao risco envolvido em projetos tradicionais em cascata, o risco de um MVP queimar a marca é muito menor do que o de lançar um produto completo que não atraia os usuários.
MVP: pense grande, mas comece pequeno
Neste post, guiamos você pelo conceito de MVP. Vimos seu conceito, sua origem, sua motivação, seus tipos, metodologias para desenvolver e, ainda, possíveis riscos.
Se pudéssemos resumir em uma frase o que a ideia de MVP encerra, ela é esta: pense grande, mas comece pequeno, validando cada avanço com base em experimentos comprovados. Todo o resto é suposição.
E então? O que você tem a dizer sobre MVP? Fale conosco!
