BT

MVP = aprendizado inteligente

por Danny Ackerman , traduzido por Anselmo Martelini em 18 Set 2013 |

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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT