BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias MVP = aprendizado inteligente

MVP = aprendizado inteligente

Favoritos

Criar um produto mínimo viável (MVP) não se trata de criar uma versão menor ou mais barata do produto, mas sim de conseguir dar início ao processo de aprendizado e testes do modelo de negócio. Em um recente artigo de Steve Blank, é dado um exemplo de uma pequena startup de Stanford que confundiu o objetivo do MVP com a necessidade de se construir um protótipo caro.

O plano era se tornar um provedor de dados em um mercado emergente, a agricultura de precisão. Fazendas seriam visitadas semanalmente com robôs voadores que coletariam e processariam os dados, os quais depois seriam entregues aos fazendeiros em um formato de fácil compreensão.

A equipe realizou pesquisas e, com base no feedback obtido, confirmou que os fazendeiros viam, teoricamente, valor nas informações que o projeto poderia oferecer. A equipe então partiu para o próximo passo: levantar dinheiro para criar um MVP. Steve Blank explica:

A ideia da equipe era que o MVP precisaria:
1) Demonstrar um robô capaz de voar;
2) Garantir que o software poderia processar corretamente todas as imagens do campo;
3) Apresentar os dados para o fazendeiro de uma forma útil.

A equipe concluiu que a maneira de fazer isso seria comprando um robô, uma câmera hiperespectral, e um software de processamento de imagens, além de gastar meses da equipe de engenharia integrando a câmera, a plataforma e o software. O orçamento era extremamente limitado para fazer tudo isso. Era lógico - mas errado.

A equipe confundiu o objetivo do MVP (a descoberta do cliente), com o processo de construir um protótipo. Blank propôs uma alternativa mais barata para a equipe, que iria cumprir melhor o objetivo do MVP: encontrar usuários iniciais dispostos a pagar pelos dados.

Não seria mais barato alugar uma câmera e um avião ou helicóptero, voar sobre as plantações das fazendas, processar manualmente os dados e verificar se os fazendeiros pagariam por esses dados? Não seria possível fazer isso em um dia ou dois, por uma fração do custo planejado?

A sugestão de Blank fez a equipe rever sua abordagem e a repensar o que o MVP precisaria testar. Foi mudado o foco inicial. Em vez de construir um protótipo do produto, o objetivo seria entender o que era possível aprender com o MVP. Como se posicionavam como companhia provedora de dados, precisavam de um MVP que provasse que as informações oferecidas tinham valor real antes de gastar tempo e dinheiro:

Isso significava que todo o trabalho de comprar um robô voador, câmera, software e o tempo gasto integrando tudo era desperdício naquele momento. Não era necessário testar nada daquilo agora. Haviam definido o MVP errado.

Ao mostrar um exemplo de equipe fazendo o que a maioria das pessoas pressupõem ser um MVP, Blank demonstra um equívoco que tem se tornado sinônimo desse conceito: a necessidade de construir uma versão barata do produto e entregá-la para potenciais consumidores. Por exemplo, John Burgstone afirma num artigo:

Os princípios do Lean Startup encorajam empreendedores a introduzir seus produtos no mercado rapidamente e aprender com o feedback dos clientes. Aprender com os clientes é de importância imensa, mas ir para o mercado com um produto medíocre pode ser uma loucura.

No entanto, como Eric Ries especificamente aponta nos princípios do Lean Startup, "O primeiro passo é descobrir o problema que precisa ser resolvido e depois desenvolver um produto mínimo viável para começar o processo de aprendizado o mais rápido possível".

É um conceito em que muitas equipes erram, já que focam em construir rapidamente um produto para receber feedback, o oposto de criar um MVP para começar a aprender. Nos primeiros estágios de aprendizado, pode nem mesmo ser necessário escrever uma única linha de código, como explica Ries no seu artigo na TechCrunch sobre como o DropBox usou um MVP para aprender:

O desafio era a impossibilidade de se demonstrar o software funcionando na forma de um protótipo. O produto exigia que uma grande dificuldade técnica fosse superada. Também possuía um componente online que demandava alta disponibilidade e confiabilidade. Para evitar o risco de, após anos de desenvolvimento, aparecer com um produto que ninguém queria, Drew fez uma coisa surpreendentemente simples: um vídeo.

O artigo de Blank conclui seu exemplo com a equipe repensando seu MVP com o objetivo de aprender se havia a possibilidade de se obter um produto viável rapidamente e sem despender dinheiro desnecessariamente. Blank apresenta as principais lições aprendidas com a equipe:

  • O mínimo produto viável nem sempre é uma versão menor ou mais barata do seu produto final;
  • Considere soluções de baixo custo para testar o objetivo;
  • Grandes empreendedores não perdem o foco no resultado final.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT