Armadilhas e o que não é um MVP

Agile

Armadilhas e o que não é um MVP

Luiz Duarte
Escrito por Luiz Duarte em 13/06/2018
Junte-se a mais de 34 mil devs

Entre para minha lista e receba conteúdos exclusivos e com prioridade

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

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.

Curso Jira

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

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.

Livro para Agile Coaches

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

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

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

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.

* 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!

Curso de Scrum e Métodos Ágeis

TAGS: agile

Olá, tudo bem?

O que você achou deste conteúdo? Conte nos comentários.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

One Reply to “Armadilhas e o que não é um MVP”

Desenvolvimento de software: tendências 2019 – parte 2 | BossaBox

[…] compra. Não seria mais inteligente ter feito uma arquitetura básica, com um código rápido (MVP?) e, depois se fizer sentido para o mercado, ir evoluindo a […]