O mito do produto mínimo viável

Joe Procopio Blocked Unblock Seguir Seguindo 10 de janeiro Sim. Ela está brava com o seu aplicativo.

Vamos esclarecer o que um produto viável mínimo (o que os internos chamam de MVP) deveria e não deveria ser.

Para dar um pouco de contexto, o MVP não se originou no mundo das startups, mas ganhou força na inicialização, permitindo que pequenas empresas com recursos limitados chegassem ao mercado rapidamente e provassem as ideias dos produtos.

O objetivo do MVP é obter uma versão barebone de seu produto no mercado para clientes reais comprarem, usarem e quebrarem. Então você limpa as falhas, conserta os pontos fracos e, o mais importante, descobre onde seus clientes encontram valor e onde eles não.

Não se engane, eu sou um grande crente no conceito de MVP. Na verdade, eu me chamaria de zelote inflexível. Dito isso, eu definitivamente vi o conceito abusado, especialmente nos últimos anos, e estou percebendo que a definição de MVP foi alterada ligeiramente. Está se tornando um meio para o fim. E isso é perigoso.

Um MVP é, de fato, a versão mais rápida do produto que você pode lançar no mercado. Mas quando eu uso a palavra “mais rápida” aqui, essa redução no tempo de comercialização é alcançada por uma redução no conjunto de recursos, não uma redução na qualidade.

Ultimamente, estou vendo o pêndulo balançar longe da qualidade com muita frequência.

Para ilustrar como deve ser um MVP, vamos dar um exemplo semi-ficcional que é fácil de seguir. Se estivéssemos construindo o Uber desde o início, antes que houvesse qualquer tipo de aplicativo de passeio, seria um empreendimento enorme e proibitivamente caro construir a infraestrutura técnica e operacional necessária para dar suporte a um serviço de aplicativo de passeio. Quanto dinheiro? Não sei. Nunca foi feito. Mas muito.

Suponha que precisaremos de dezenas de milhões de dólares para provar que o Uber funcionará como pretendido. Nossa startup não vai chegar nem perto desse tipo de dinheiro de semente a menos que possamos provar o modelo de trabalho e as pessoas acabarão por transformar o Uber em um verbo. É galinha e ovo.

A menos que nos voltemos para um MVP.

Agora, não sei se foi assim que foi feito. Eu não estava lá. Mas, para os propósitos do nosso exemplo, digamos que foi assim:

O MVP pode ser um aplicativo simples com um botão grande para chamar a atenção. A localização do cliente é identificada automaticamente com o seu dispositivo móvel. Então, talvez enviemos um e-mail com todos os detalhes do passeio e do piloto para uma equipe de suporte 24 horas por dia, 7 dias por semana, talvez a equipe fundadora, que ligue ou envie um texto para um grupo de motoristas de teste e organize o passeio. Quando a viagem estiver completa, talvez o pagamento seja efetuado com um cartão manual.

Este não é o serviço sem atrito, a qualquer hora / em qualquer lugar que tornou o Uber perturbador (e também estamos presumindo que as centenas de problemas de pequeno a grande porte que surgem desse caso de uso ainda precisam ser descobertos). O ponto é que seria assim que tiramos o Uber do seu MVP, e isso é feito automatizando-se qualquer parte do processo que não seja necessária para provar a ideia.

Neste exemplo falso da Uber, identificar e agir automaticamente na localização do cliente é provavelmente o caso de teste crítico. Se não temos isso, nossa versão do Uber não merece existir. Podemos contratar manualmente os drivers e fazer o bootstrap de como os encaixamos no processo. Podemos estar errados ao determinar o preço antes de aceitar o passeio e comer a diferença. Podemos pagar demais para aceitar o pagamento no aplicativo.

É por isso que fazemos esse MVP – para testar a viabilidade dos aspectos mais importantes da coisa que fará com que o produto valha a pena o tempo e os recursos necessários para chegar à história de bilhões de dólares. Uma vez que temos dados que dizem: “Isso funciona. As pessoas vão usá-lo. É rentável. Podemos escalar sem cair ”, podemos endurecer esses aspectos importantes, depois levantar o nosso dinheiro e ir à falência. Por assim dizer.

Então esse é um MVP. Aqui é onde a definição está ficando incompleta.

Muitas vezes hoje vemos um MVP lançado no mercado que tenta fazer muito de uma vez e faz tudo mal. Isso faz muitas bagunças, incluindo, mas não se limitando a:

  1. Lançamos o lixo no mercado e imediatamente criamos uma péssima experiência do cliente. Os clientes podem viver com um produto que não faz exatamente o que eles querem. Eles não aceitarão um produto que faça a coisa mais importante mal ou de maneira alguma. Se não tivermos o caso de uso crítico correto e robusto, não devemos liberar o MVP.
  2. Nós sacrificamos coisas importantes como segurança, privacidade e até segurança física, pensando que não precisamos disso ainda. Além das implicações morais e éticas, é algo que mata o produto e talvez a empresa se a exposição for muito grande. Você nunca pode colocar seus clientes em risco, não importa quão pequeno esse risco possa parecer. É o equivalente a nunca começar uma empresa sem um advogado, porque se você está fazendo o startup certo, você não tem idéia do tipo de problema que está por vir até você estar no fundo do poço.
  3. Nós derrotamos o propósito de liberar o MVP em primeiro lugar. No máximo, nossa versão deve ser A / B testando alguns recursos, um que sabemos que os clientes querem e alguns que achamos que os clientes querem. Se nossos clientes estão ignorando algum recurso, precisamos saber por quê. E se por que “não funcionou”, então o teste se torna discutível. Também se torna caro à medida que apressamos as correções no mercado para testar novamente nossa hipótese.

Em nosso exemplo do Uber, todas as coisas que não foram automatizadas precisaram funcionar corretamente todas as vezes. Precisamos ter certeza de que não importa o que a tripa pareça para fazer o passeio acontecer, o cliente chega onde precisa ir com rapidez, segurança e baixo custo, com pouca dor de cabeça para eles, o que significa muita dor de cabeça para nós.

Agora, você pode questionar se o Uber cresceu ou não, especialmente nas áreas de segurança de pilotos e pilotos, economia de motoristas e folga do setor e do governo. Eu não vou defender o método do Uber, mas deixe-me adicionar algumas nuances. Embora não possamos divulgar a porcaria no mercado e esperar aprender alguma coisa, também não podemos ser 100% à prova de balas. Nosso MVP deve quebrar, especialmente nos limites de desempenho ou casos de borda. Quanto mais tempo gastamos fazendo ajustes e testes de qualidade, além de testes e camadas e lobby, menos tempo temos para aprender e repetir.

E, para ser sincero, quanto mais tempo dermos a Lyft.

Eu não estou dizendo que é certo. Estou dizendo que é assim.

Felizmente, é aí que entram os dados e as melhores práticas. Nunca devemos estar completamente à vontade para lançar um produto ou uma versão no mercado. Nunca devemos nos surpreender quando algo dá errado, e nunca devemos estar a mais do que alguns cliques de encontrar a fonte e parar o sangramento.

Ser capaz de mudar e mexer na hora é a marca registrada de uma ótima inicialização antecipada. Os clientes podem até nos dizer que estamos fazendo 90% errado e 10% certo, mas se conseguirmos capitalizar esses 10%, poderemos ter um vencedor. Nosso MVP deve ter os ganchos e o modelo para podermos fazer essas mudanças com rapidez e facilidade.

Isso significa que um MVP nunca deve perder um loop de feedback, uma arquitetura facilmente modificável e um switch kill.

Então vamos juntar tudo. Um MVP precisa de um pequeno conjunto de recursos, alta qualidade, baixa automação e máxima flexibilidade. Uma vez que essas coisas se juntam, a única coisa que nos impede de partir é o próprio medo.

E na inicialização, o medo é bom.

Texto original em inglês.