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