Construir, Medir, Aprender? Entenda as formas de validar seu negócio Construir, Medir, Aprender? Entenda as formas de validar seu negócio

Construir, Medir, Aprender? Entenda as formas de validar seu negócio

Steve Blank
Steve Blank

Steve Blank é um empreendedor serial que se tornou educador e está mudando a forma como startups são construídas e como empreendedorismo é ensinado. Ele criou a metodologia Customer Development (Desenvolvimento de Cliente), que gerou o movimento Lean Startup, e escreveu sobre o processo em seu primeiro livro, Os Quatro Passos para a Epifania. Seu segundo livro, Startup: Manual do Empreendedor, é um guia passo a passo para montar um negócio de sucesso. Blank já deu aula em Stanford University, U.C. Berkeley, UCSF, NYU, Columbia University, the National Science Foundation e the National Institutes of Health. Ele escreve regularmente sobre empreendedorismo em www.steveblank.com.

Sempre me surpreendo quando os críticos reclamam que a abordagem Construir, Medir, Aprender (Build, Measure, Learn) da Lean Startup não é nada mais que “jogar produtos incompletos para fora do prédio para ver se funcionam”.

Infelizmente, o diagrama do Construir, Medir, Aprender é uma plausível causa para essa confusão. Olhando rápido, parece um processo “preparar, apontar, fogo!”.

build-measure-learn1

Construir, Medir, Aprender soa bem simples. Construa um produto, coloque-o no mundo real, meça as reações e comportamentos dos clientes, aprenda com isso e use o que aprendeu para construir algo melhor. Repita, entendendo se é preferível incrementar, pivotar ou recomeçar do zero, até ter algo que seus clientes amem.

É hora de atualizar o Construir, Medir, Aprender para o que agora sabemos que é a melhor maneira de se formar Lean Startups. Aqui falaremos sobre ela.

waterfall1Waterfall Development

Mesmo parecendo simples, a abordagem Construir, Medir, Aprender em desenvolvimento de produto é uma melhoria radical em comparação ao tradicional Modelo em Cascata (Waterfall) usado durante o século 20 para construir e distribuir produtos. Naquela época, o empreendedor usava um processo de desenvolvimento que processava etapa por etapa com muito pouco ou nenhum feedback de clientes. Fundadores presumiam que entendiam os problemas e necessidades de seus clientes, escreviam documentos de requerimento de melhoras na engenharia, desenhavam o produto, implementavam/construíam o hardware/software, verificavam o que funcionava por meio de testes e só então introduziam o produto aos clientes, em um lançamento formal.

O desenvolvimento em cascata consistia na execução do documento de requerimentos. Versões precoces do produto eram compartilhadas com clientes em testes Alfa e Beta e o objetivo era descobrir bugs, em vez de recolher feedbacks sobre funcionalidades ou usabilidade. Só depois de lançar e tentar vender o produto uma startup escutaria qualquer retorno substancial de clientes. Acontece que depois de meses ou mesmo anos de desenvolvimento, era comum empreendedores aprenderem da pior forma que o produto não era comprado porque clientes não queriam ou precisavam da maioria das funções oferecidas.

As melhores práticas de desenvolvimento de software só começaram a ingressar no caminho da agilidade no início dos anos 2000. A metodologia de Agile Development superou o modelo de cascata por sugerir o desenvolvimento de software de forma iterativa e que envolvesse o cliente. Mas faltava nela uma estrutura para testar hipóteses de comercialização “fora do escritório”. Com a Agile, você poderia acabar atendendo a todos os pedidos de funcionalidade de um cliente e, mesmo assim, ir à falência.

Até que surgiu o foco Construir, Medir,Aprender da Lean Startup.

Build-Measure-Learn

O objetivo do Construir-Medir-Aprender não é lançar de cara produto final, nem mesmo construir um protótipo, mas maximizar os aprendizados desse processo por meio de uma engenharia incremental e iterativa.

Quando falo em aprender, pode ser sobre funções do produto, necessidades do cliente, precificação, canais de distribuição, entre outros. A etapa Construir se refere a fazer um mínimo produto viável (MVP) a cada etapa. Aqui, é essencial entender que um MVP não é um produto com menos funções, mas a mais simples versão de um produto que você possa mostrar a seus clientes para absorver o máximo de aprendizado possível. Na fase inicial da startup, o MVP pode ser simplesmente um slide de powerpoint, uma estrutura básica, um modelo de argila, a amostra de um conjunto de dados, etc. Cada vez que você monta um MVP, você também define o que está buscando testar ou medir. Mais tarde, conforme se vai aprendendo, o MVP vai ficando mas fiel ao produto, mas o objetivo continua sendo maximizar o aprendizado, não construir um beta.

Bem superior ao modelo de cascata, o Construir-Medir-Aprender permite que startups sejam rápidas, ágeis e eficientes.

O diagrama de 3 círculos do Construir-Medir-Aprender representa o processo de forma bem aproximada, mas infelizmente, a palavra “construir” ainda causa certa confusão. O diagrama parece mesmo implicitar “construa coisas e jogue para o mercado”, porém uma versão mais detalhada dele ajuda a esclarecer o significado do método ao adicionar três novos elementos: Ideias-Construir-Codificar-Medir-Dados-Aprender.

ideas-build-code-measure

Essa versão nos ajuda a perceber que a real intenção por trás da parte de construção é testar ideias – não construir cegamente, sem um objetivo. O círculo Codificar também poderia ser “produzir hardware” ou “construir genoma artificial”. O círculo Dados indica que, depois de medir nossos experimentos, vamos usar os números para refinar nosso aprendizado. E esse aprendizado influencia as novas Ideias que entram no ciclo.

Esse foco em experimentação contesta a preocupação de que Construir-Medir-Aprender significa só “jogar coisas contra a parede para ver se funcionam”, e sim confirmar ou descartar uma ideia inicial, o que vai gerar novas ideias. Mas ainda não está bom o suficiente. Nós podemos fazer melhor.

Comece com hipóteses

O que o Construir-Medir-Aprender perde de vista é que novos empreendimentos, tanto startups quanto novas ideias dentro de empresas já existentes, não começam com ideias, mas com hipóteses (uma palavra chique para “chutes”). E as palavras “ideia” e “hipótese” são completamente diferentes. Para a maioria dos inovadores, “ideia” evoca uma visão que imediatamente requer um plano para se frutificar. Em contraste, “hipótese” indica um palpite com precedentes, que requer experimentação e dados para ser validado ou invalidado.

As hipóteses abrangem desde quem pode ser o cliente até preço e canais do seu negócio. A Lean Startup começa já reconhecendo que sua ideia é simplesmente uma série de hipóteses não testadas.

hypotheses-experimentO que você constrói deve estar alinhado com a hipótese que você quer testar. O MVP que você precisa para encontrar o cliente certo é diferente do MVP que você precisa para testar se o preço é adequado, que é diferente do MVP que você precisa para testar funções específicas do produto. E todas essas hipóteses (e MVPs) mudam com o tempo, conforme você aprende. Então em vez do Construir-Medir-Aprender, o diagrama para fazer MVPs em uma Lean Startup se parece mais com Hipóteses-Experimentos-Testes-Percepções.

Gerando Hipóteses

Usando esse novo diagrama, a questão então passa a ser “quais hipóteses devo testar”. Por sorte, o business model canvas apresenta uma visão geral sobre os nove componentes de um negócio em uma só página. São eles:

E isso nos traz à definição de uma startup: uma organização temporária desenhada para buscar um modelo de negócios replicável e escalável.

Testando Hipóteses

Uma vez que essas hipóteses completam o canvas, como um empreendedor as testa? Se você for um cientista, a resposta vem fácil: com experimentos. O mesmo acontece na Lean Startup.

Uma opção é o processo de Customer Development, uma simples metodologia para levar novas hipóteses de um empreendimento para “fora do escritório”. Enquanto isso, o Customer Discovery captura a visão do fundador e a transforma em uma série de hipóteses do modelo de negócios, para então desenvolver uma série de experimentos para testar reações de clientes a essas hipóteses e torná-las fatos. Os experimentos podem ser apenas algumas perguntas a potenciais clientes, mas mais frequentemente elas são acompanhadas de um MVP que os ajude a entender a solução que seu produto pode oferecer.

Finalmente, o objetivo desses experimentos e MVPs não é só conseguir dados. Os dados não são a linha de chegada. Qualquer um pode coletar dados. Grupos focais podem coletar dados. Isto não é um grupo focal. O objetivo é conseguir percepções (insights). Toda a ideia de sair do escritório é informar a visão do fundador mundo afora. O insight pode vir de uma análise das respostas dos clientes, mas também pode vir de ignorar os dados ou perceber que o que você está descrevendo é um mercado novo e disruptivo e que você precisa mudar seus experimentos – em vez de medir especificações, inventar o futuro.

Lições aprendidas

Artigo originalmente publicado no Blog do Steve Blank