Seguindo a série de notas sobre a SLLConf iniciada com a mensagem de abertura do Eric Ries, nesse post vou cobrir as observações sobre a palestra do Kent Beck, que abriu o bloco Build do evento. Também estão no final o vídeo e os slides da palestra.

Para quem é da área de software, Kent Beck não necessita de apresentação. Entre diversas outras coisas memoráveis, ele foi um dos signatários originais do Manifesto Ágil e criador da metodologia Extreme Programming e dos conceitos de Desenvolvimento Orientado a Testes.

Ele iniciou sua palestra comentando o fato de que os conceitos de Lean Startup e a comunidade de prática que se formou em torno do tema foram responsáveis por trazer uma nova “energia” para que ele continue criando negócios através da sua capacidade de desenvolver software. Na sequência, ele fez uma série de análises que geraram muita discussão e comentários na blogosfera. Abaixo faço o resumo dos principais conceitos:

Encontrando o “ponto da coceira”

Essa foi uma analogia bem-humorada entre as Startups e uma experiência que ele teve com uma das cabras de sua criação. A estória é a de que um dia ele estava brincando com uma das cabras, fazendo um movimento de cócegas com os dedos ao longo do corpo da cabra, que por sua vez não reagia àquele movimento. Em um determinado momento, Kent achou um ponto (itchy spot) onde, com o mesmo movimento nos dedos, a cabra teve uma reação desproporcional às cócegas.

Com as Startups, a coisa é parecida. Você tenta uma, duas, três, várias vezes, e recebe quase nada de resposta do mercado. De repente, nesse processo iterativo, a Startup encontra algo que tem uma demanda e uma alavancagem desproporcional ao resto. Achar esse “ponto da coceira” requer timing, sorte, mas principalmente, muitas “cócegas”.

É aí que entra uma das ideias principais das Lean Startups: aumentar a velocidade de iteração para garantir que se ache esse “itchy spot” o quanto antes, maximizando as chances de sucesso do empreendimento.

O princípio de “Pull”

Nas suas apresentações, Eric Ries sempre mostra o Loop Fundamental da Lean Startup, que é composto pelo ciclo Build->Measure->Learn (clique aqui para ver a imagem).

Kent Beck analisou esse loop e percebeu que, se quisermos extrair o máximo de valor de cada iteração, a sequência está na verdade invertida. Ele então propôs que adotássemos algo mais próximo do conceito de “Pull” do Lean Manufacturing, ou seja, começar com uma necessidade concreta (de aprendizado ou demanda dos clientes). Desta forma, o Loop deveria estar na sequência: Learn->Measure->Build.

Loop Learn Measure Build

Kent também escreveu um post explicando melhor sobre essa ideia do Learn->Measure->Build, dando alguns exemplos práticos de como isso altera a maneira de agir.

Essa ideia também se alinha com a forma que os princípios Ágeis são praticados hoje. Segundo ele, as metodologias ágeis por si só trazem bastante micro-eficiências ao processo de desenvolvimento de software, porém se não alinhadas a esse processo maior de aprendizado e Customer Development, perdem macro-eficiências por permitir que se construa coisas que as pessoas não querem ou precisam.

Revisando o Manifesto Ágil

Aproveitando o insight acima, Kent Beck fez uma revisão do Manifesto Ágil aplicado ao contexto das Startups:

Valorizar:

Visão da Equipe e Disciplina mais do que Indivíduos e Interações (e mais do que Processos e Ferramentas);

Aprendizado Validado mais do que Software em Funcionamento (e mais do que Documentação Abrangente);

Descoberta do Cliente mais do que Colaboração com o Cliente (e mais do que Negociação de Contratos);

Iniciar as Mudanças mais do que Responder às Mudanças (e mais do que Seguir um Plano);

Esse post traz mais detalhes sobre esses pontos.

O princípio de “Flow”

Para fechar a palestra, Kent falou sobre o quanto o princípio de “Flow” está alinhado ao de “Pull” para as Startups. A ideia central é que devemos buscar minimizar o tempo total gasto no Loop para cada iteração.

Para o processo de aprendizado, ter “meia-entrega” em menos tempo é mais valioso do que uma entrega completa em mais tempo. Devemos então sempre nos perguntar: Como podemos diminuir o tempo nesse próximo ciclo Build->Measure->Learn para o que queremos aprender? Qual o atalho que podemos tomar ou a redução que podemos fazer no Build?

Ele exemplificou usando um caso próprio de aplicação de um MVP, e brincou: “Not having a customers is a blessing. You can make mistakes all along.”

Deixo também mais dois quotes provocantes que geraram alguns debates interessantes.

“As a developer, you have to realize that the solutions to shortening the cicle might not be the better technicaly.
Sometimes, it´s gonna look like hackery.”

“Good engineering sometimes isn´t good startup engineering. It depends on the Learning you need to create.”

Seguem agora o vídeo e os slides da palestra:

To agility, and beyond…

Para descobrir a combinação Problema/Solução para o seu produto, a Startup deve estabelecer um processo iterativo que permita um aprendizado constante sobre os clientes e outras premissas do negócio. Esse processo é uma combinação de experimentações práticas com investigações qualitativas que buscam extrair dados para comprovar as hipóteses dos empreendedores, bem como as nuances e “porquês” que estão por trás do comportamento dos clientes. No centro dessa experimentação está o conceito do Minimum Viable Product (MVP).

O MVP tem como definição “o mínimo conjunto de funcionalidades que permite uma ação e aprendizado sobre os clientes ou usuários”. Sua origem remete ao mantra release early, release often das metodologias ágeis de desenvolvimento, prática que coloca o feedback real dos usuários como norte da evolução do software. Em termos de estratégia geral para o lançamento de produtos, também são vários os defensores desta abordagem. (alguns exemplos aqui, aqui e aqui)

No entanto, o MVP vai além da prática agile comum em dois pontos principais. Primeiro, a preocupação principal do MVP não é colher sugestões gerais para o produto, mas sim provar a visão inicial do empreendedor. Parafraseando Steve Blank, Customer Development não é um Focus Group. Segundo, além de testar a utilização do produto e suas features, o MVP também serve – e deve ser usado – para testar as demandas do mercado com relação ao produto. Ou seja, para determinadas iterações, o objeto do experimento não será o software em si, mas outros componentes que permitem validar outras hipóteses do negócio.

Por exemplo, o MVP pode tomar forma de uma campanha de anúncios no Google Adwords combinada com a criação de diferentes landing pages para testar a reação dos consumidores sobre diferentes tipos de chamadas para o benefício principal do produto. Ou então, split tests para estudar qual a melhor opção de pacotes de preços/funcionalidades do produto.  Ou então, uma apresentação em ppt para guiar uma série de entrevistas com potenciais clientes. Ou então, uma chamada fake para uma nova funcionalidade  no software só para testar a receptividade dos usuários atuais. E por aí vai… Resumindo, o MVP toma qualquer forma que seja necessária para garantir um aprendizado relevante que ajude a Startup a caminhar em direção ao Product/Market Fit.

Portanto, mais do que a forma específica que o MVP toma para um determinado experimento, o mais importante é a criação da cultura de experimentação que permite o aprendizado de uma forma lean, gastando a menor quantidade de recursos e tempo possível. Deixo duas frases abaixo que reafirmam essa questão do processo:

“Entrepreneurship in a lean startup is really a series of MVP’s.” – Eric Ries

“You can’t identify one thing and then stop talking to your customers and go build.  Because you’re not really building a product – you’re building an environment that supports increasingly educated guesses.” – Cindy Alvarez

Interiorizada a necessidade do processo, resta responder a questão: o que construir e testar primeiro? Essa resposta não é simples, e está muito relacionada ao tipo de negócio da Startup e quais são suas hipóteses mais importantes e questionáveis. Em linhas gerais, para produtos corporativos de alto valor agregado, a recomendação inicialmente é testar a demanda principalmente através de apresentações e entrevistas com potenciais clientes. Para produtos voltados para pequenas/médias empresas ou para o consumidor final, testar a demanda via Web também é essencial (por landing pages, formulários de conversão, etc.), mas dependendo do caso os testes da experiência com o produto também passam a ser importantes. Já para produtos B2C onde o modelo de negócio é venda de publicidade, ou seja, exigem a adoção de larga escala de usuários, os MVPs devem caminhar mais fortemente em direção à construção do próprio produto, algo que Andrew Chen cunhou como Minimum Desirable Product.

Definir o que deve ser o próximo MVP a cada iteração é uma arte, não uma ciência.

Para ilustrar melhor, esse post do Venture Hacks traz alguns exemplos de MVPs bastante interessantes. Deixo abaixo também um vídeo e os slides de uma apresentação do Eric Ries sobre o tema.