Armadilhas e o que não é um MVP

Em meu último artigo de empreendedorismo e agilidade eu tentei ao máximo desmitificar e esclarecer de maneira clara e didática o que é um MVP. No entanto, mesmo este mindset tão poderoso pode nos fazer cair em algumas armadilhas bem comuns quando estamos construindo nossos produtos.

Duas delas eu discuti no próprio artigo anterior:

Armadilha #1: MVP é aquilo que dá pra fazer no tempo que temos;

Armadilha #2: MVP é a primeira versão do produto que tem tudo que os clientes precisam;

Ambas armadilhas podem ser solucionadas se olharmos o diagrama abaixo que mostra quais características (e qual a proporção) que nossos MVPs devem possuir:

Estrutura de um MVP
Estrutura de um MVP

Um MVP que seja apenas factível (somente feasible, armadilha #1) provavelmente não será inovador o bastante para atrair os Early Adopters (sem o fator delightful, também chamado de “fator uau”).

Um MVP que tenha 100% de todas características não é um MVP é um produto completo.

Além de falar das demais armadilhas do conceito, quero reforçar algumas coisas que não são MVPs, mas que às vezes acabam sendo confundidas erroneamente. Agora, se você não faz muita ideia do que estou falando, sugiro ler o livro Lean Startup.

Armadilha #3: Roadmap de MVPs

Um roadmap de MVPs é algo parecido com o diagrama abaixo, onde temos a evolução de um produto para cortar grama.

Roadmap de MVPs
Roadmap de MVPs

Note que o raciocínio aqui está impecável: primeira versão temos uma tesoura, pra entender se de fato os Early Adopters cortariam suas próprias gramas, segunda versão temos um cortador mais prático para as costas, até chegar no MVP 8 onde poderíamos cortar a grama de um campo de futebol facilmente.

Qual a armadilha então?

Seguir esse roadmap à risca!

O Lean Startup não possui o Lean no nome ao acaso, ele veio dessa linha de pensamento japonesa de melhoria contínua, aprendizado e redução de desperdício, assim como os Métodos Ágeis de desenvolvimento de software. Estes últimos tem como base o Manifesto Ágil, em cujo quarto item nos diz que “responder a mudanças é mais importante que seguir um plano”.

E se a grama de nossos clientes cresce tão pouco que não faz sentido comprar um equipamento de corte? E se a quantidade de grama deles é tão pequena que eles jamais precisarão de um carrinho? E se a grama deles for sintética?

Você continuaria seguindo o roadmap nestes casos?

Lembre-se que o ciclo Construir-Medir-Aprender pode nos levar ao pivot e, com isso, nosso roadmap deve ser revisto. Ou seja, a armadilha aqui é focar em seguir o roadmap desenhado ao invés de aprender com as medições.

Armadilha #4: oferecer o seu MVP pra todo mundo

Vou começar sendo bem direto: o seu MVP não é um produto para lançar para todo mundo. Isso pode soar estranho para alguns, mas é exatamente isso. E não estou falando de segmentos de mercado, mas sim de segmentar os seus potenciais clientes do MVP dentro do seu segmento de mercado, ou seja, os seus Early Adopters.

Vamos pensar rapidamente em um MVP de ponte:

MVP de Ponte
MVP de Ponte

Há quem diga que isto não é um MVP de Ponte, uma vez que não atende aos critérios do diagrama inicial deste post (temos algum “fator uau” aí?), mas se considerarmos que estas pessoas tentavam pular este rio antes da ponte ou andavam kilômetros a mais para contornar o rio, ele pode ser considerado um bem para os ribeirinhos, certo?

Qual é o mercado de uma ponte? Todo mundo que precisa atravessar um rio? Mas especificamente de um MVP de ponte construído com tábuas, será que é o mesmo mercado? Quem são os Early Adopters deste MVP de ponte?

É muito importante oferecer o MVP e em alguns casos até restringir o acesso a somente os Early Adopters que você entender que de fato vão perceber as características de seu produto como valiosas e que a falta de algumas não os impeça de pagar pelo seu uso (ok, na ponte não há cobrança, mas você entendeu a analogia).

O que acontece se eu não restringir o acesso ao meu MVP a somente os Early Adopters? Várias coisas:

  • em uma análise quantitativa, o número de clientes que não gostaram do produto pode ofuscar o número de early adopters que de fato gostaram e que lhe dariam um feedback valioso (aprendizado); quem você quer agradar com a ponte de tábua, os ribeirinhos desesperados por uma solução rápida ou os turistas da cidade buscando uma experiência inesquecível?
  • pode queimar sua imagem no mercado com um “produto ruim” (nem todo cliente tem o mesmo mindset de um Early Adopter), uma vez que sua empresa já possua uma marca a zelar; imagine uma construtora inaugurando aquele MVP e ponte…
  • pode lhe trazer sérios problemas legais e de segurança caso clientes tenham experiências péssimas com um produto que pagaram para usar; imagine seu MVP de ponte sendo usado por um carro…

Armadilha #5: não definir seus Early Adopters

A quinta armadilha está bem interligada com a quarta, mas vou ser redundante mesmo assim: o seu MVP é para os seus Early Adopters. Se você não sabe quem são os seus Early Adopters, você nem deveria começar seu MVP.

O gráfico abaixo mostra a adoção de novas tecnologias pela população:

Adoção de novas tecnologias
Adoção de novas tecnologias

Dentro dos segmentos de mercado temos sempre aquelas pessoas que são mais propensas a adotar novas tecnologias e aquelas que só vão fazê-lo em último caso. Tipo meu sogro que ainda usava telefones de flip (estilo clamshell, de “abrir”) até pouco tempo e só trocou por um touch pois o dele estragou e não vendem mais o outro modelo.

Os Early Adopters são uma fatia do seu mercado, algo menor que 25%, que gostam de ser os primeiros a testar um novo produto, a usar uma nova funcionalidade, sentem-se valorizados quando as marcas pedem seu feedback e são críticos de maneira construtiva, colaborando com a evolução de produtos. Eles gostam de entrar em filas de espera de devices, de testar demos de jogos, se orgulham de usar softwares antes dos outros, mesmo que isso tudo incorra em estar sujeito a falhas ocasionais, falta de funcionalidades, etc.

Você sabia que o primeiro iPhone tinha a pior qualidade de ligação do mercado? E que ele não permitia copiar e colar texto entre apps? E que a Apple poderia ter lançado ele melhor do que lançou, mas que queria justamente testar o mercado? Isso não o impediu de ser um sucesso de vendas entre os early adopters da empresa.

Não definir antecipadamente quem são os seus Earl Adopters, e restringir o acesso ao seu MVP para eles pode gerar problemas enormes, principalmente se seu produto for um MVP de ponte…

MVP de Ponte - fail
MVP de Ponte – fail

O que não é um MVP?

Muitas vezes quando queremos que as pessoas entendam um conceito, precisamos mostrar a elas o que não é aquele conceito.

Um MVP não é um protótipo ou prova de conceito, não ao menos no sentido literal que estas palavras possuem dentro do ramo científico. Um MVP é um produto comercializável, enquanto que uma prova de conceito pode ser algo bem longe de ser comercializável. Cada um tem a sua utilidade, apenas não são a mesma coisa.

Um MVP não é o beta de um produto. Entende-se que um beta é um produto quase finalizado que abrimos para um grupo fechado de pessoas usarem e nos darem seu feedback, bem como descobrirmos erros ocultos que só os usuários conseguem detectar. Um MVP, principalmente nas iterações iniciais, é algo bem longe de um produto completo.

Um MVP não é a versão 1 de um produto. Ele está mais para uma v0.1. Se você chama suas v1.0 de MVP ou você está criando MVPs grandes demais, ou sua v1.0 é muito pequena. De qualquer maneira você está errado.

Um MVP não é um produto de mercado. Ele é um produto de nicho, para seus Early Adopters.

E finalmente, um MVP é um Minimum Viable Product e não um Maximum Viable Product.

Espero ter sido claro! 🙂

Quer ter ideias de como criar um MVP na prática? Dê uma olhada neste artigo aqui.

Querendo aprender a metodologia correta de desenvolvimento de software iterativo-incremental para não correr o risco de cair no modelo Waterfall de desenvolvimento de produtos? Conheça meu livro Scrum e Métodos Ágeis!

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:

Queremos um MVP
Queremos um MVP

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.

Eric Ries e Steve Blank
Eric Ries e Steve Blank

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.

Build-Measure-Learn
Build-Measure-Learn

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:

Build-Measure-Learn-v2
Build-Measure-Learn-v2

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:

Mindset MVP
Mindset MVP

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”:

Bolo linear
Bolo linear

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”:

Bolo com MVP
Bolo com MVP

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:

Estrutura de um MVP
Estrutura de um MVP

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.

Querendo aprender a metodologia correta de desenvolvimento de software iterativo-incremental para não correr o risco de cair no modelo Waterfall de desenvolvimento de produtos? Conheça meu livro Scrum e Métodos Ágeis!

Leituras recomendadas para Product Owners

Desde a criação do Agile Manifesto em 2001 e a consequente popularização dos métodos ágeis no início deste século que eu tenho como o maior ganho promovido pelo modelo a aproximação da área de negócio das empresas com  área de TI das mesmas. Essa aproximação se dá em grande parte à obrigatoriedade do papel do Product Owner dentro dos Times Scrum, sendo esse o framework ágil mais difundido no mundo.

No entanto, para que essa conexão produza bons frutos é necessário que o papel do Product Owner seja respeitado e que o mesmo possua as skills necessárias para tanto. Mas que skills seriam essas?

Um Product Owner geralmente é um especialista na sua área de negócio, mas não necessariamente um especialista em métodos ágeis. No entanto, diferente de um Scrum Master ou de um Agile Coach que devem respirar métodos ágeis no seu dia-a-dia, um Product Owner deve respirar concepção e desenvolvimento de produtos de maneira ágil, tema central das leituras que recomendarei neste artigo.

Clique nos títulos ou nas capas para ver o livro na Amazon.

A Startup Enxuta

Obra máxima de Eric Ries, A Startup Enxuta (Lean Startup no original) já foi motivo de resenha aqui no blog e dispensa apresentações. Conceitos como MVP (Minium Viable Product), Contabilidade para Inovação e o ciclo Build-Measure-Learn são obrigatórios no repertório de qualquer Product Owner.

Business Model Generation

Este fantástico livro de Alex Osterwalder (até a edição é excelente, já fiz resenha aqui no blog) introduz o famoso Business Model Canvas, estrutura o raciocínio sobre a ideação de modelos de negócio inovadores e nos traz diversos cases de modelo disruptivos que empresas famosas descobriram para se reinventar.

Value Proposition Design

Outra obra-prima de Alex Osterwalder, desta vez ele nos introduz ao Value Proposition Canvas, uma poderosa ferramenta que auxilia os Product Owners a fazer a conexão certa entre o que os clientes desejam e o que o seu produto realmente deve ser.

Sprint

Ao contrário do que o nome sugere, este não é um livro de Scrum, mas sim um livro sobre o método usado no Google para testar e aplicar novas ideias em apenas cinco dias. É muito interessante de ler e aplicar, tendo sido escrito por Jake Knapp em parceria com membros do Google Ventures.

Reinvente sua Empresa

ReWork no original de Jason Fried, este livro é a versão parruda e mais moderna do recomendadíssimo Caindo na Real, escrito pelos fundadores do Basecamp. Não apenas promove uma mudança cultural na cabeça de quem lê, ele dá aos Product Owners um passo-a-passo de como orientar a criação de aplicações ágeis e que realmente atendem as necessidades dos clientes com menos pessoas e menos software.

Direto ao Ponto

Paulo Caroli é um engenheiro de software e autor brasileiro que ficou famoso no mundo inteiro com a sua Lean Inception, um método de concepção de novos produtos muito alinhado aos conceitos do Lean Startup, permitindo que através dos métodos descritos em seu livro, empresas consigam definir os escopos de seus novos produtos em até uma semana de trabalho.

Scrum

O mais famoso livro sobre Scrum do mercado (ele aparece na minha lista de 6 livros recomendados para aprender agilidade), o “livro amarelo do Scrum” foi escrito por Jeff Sutherland, um dos criadores do Scrum e uma das figuras mais famosas em agilidade no mundo inteiro. Não é exatamente um livro que te ensina como dominar o framework, mas que te dá a base histórica e teórica do framework, seus princípios e como eles são aplicados em diversos contextos através de todo tipo de case. Essencialmente um livro sobre cultura ágil.

Running Lean

Infelizmente para quem não domina o idioma Inglês, nem todas as grandes obras possuem edição nacional e essa é uma delas. O excelente Running Lean do Ash Mauriya traz conceitos de outros livros como o Business Model Generation e o Lean Startup para outro nível, mais focado em produtos digitais e na realidade que os permeiam. Se eu pudesse resumir esse livro em uma frase seria: saia do escritório e vá falar com seus clientes.

The Four Steps to the Epiphany

Outra excelente obra sem tradução, esse livro de Steve Blank (um dos maiores investidores e mentores do Vale do Silício) é o avô do movimento Lean Startup, tendo sido Blank o professor do Eric Ries (autor do Lean Startup). Neste livro ele introduz conceitos como Customer Discovery e Customer Development, trazendo à tona questões como a busca pelo Product-Market Fit e tantos outros conceitos importantíssimos para todos profissionais responsáveis pela criação de produtos no século atual.

Esqueci algum livro que você gostaria de adicionar na lista? Me mande nos comentários!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.