Promessa é dívida, então aqui estou para escrever a segunda parte do post sobre Lean Startup! Na primeira parte eu falei um pouco sobre o histórico do Lean Startup, seus pilares e princípios. Agora a ideia é entrar no método propriamente dito, descrever o processo, seus principais conceitos e algumas ferramentas de apoio.Vamos lá!
Acredito que a melhor forma de explicar o método Lean Startup seja através de seus conceitos, que visualizados lado a lado fornecem um bom entendimento do todo. Vamos a eles:
Feedback Loop
A proposta de Eric Ries é que cada iteração do negócio deva passar por 3 passos principais: Construir – Medir – Aprender. Os resultados dessas fases são, respecitvamente, Código – Dados – Ideias. O loop é geralmente representado pela imagem abaixo:
O método se inicia considerando que você já identificou um problema a ser resolvido e uma provável solução para este problema (no futuro pretendo fazer um post sobre o Validation Board, que funciona na etapa anterior e te ajuda a identificar o problema certo!). Portanto, a primeira coisa a fazer é começar a Construir seu produto. Idealmente, aqui já entram em cena técnicas como desenvolvimento ágil, prototipação (rápida), testes de usabilidade e o tão comentado MVP – Minimum Viable Product (já falo sobre ele). O objetivo é ter algo que consiga demonstrar seu produto aos seus possíveis clientes, de preferência da forma mais rápida e mais barata possível. O resultado desta primeira parte provavelmente será Código, já que na maioria dos casos estamos falando de startups digitais.
Em seguida, é necessário Medir seu experimento, ou seja, verificar se a solução que você imagina para o problema é viável em termos técnicos, de negócio e de funcionalidade (tríade do Design Thinking). Para extrair osDados necessários para comprovar sua hipótese, você pode usar testes de usabilidade, Search Engine Marketing (aka Google AdWords), Testes A/B, de preferência seguindo a filosofia Genchi Gembutsu (explico daqui a pouco). Para Eric Ries, o ideal nesta etapa é estabelecer e atingir uma meta que seja capaz de validar (ou invalidar) a sua hipótese. Por exemplo, você pode definir que “se 5 usuários se registrarem em sua landing-page num prazo de 2 dias”, você irá perseverar com a hipótese.
Depois de conseguir material suficiente na sua etapa de medição, é hora de olhar para ele e identificar o que é possível Aprender. Neste ponto você pode entender, por exemplo, que sua solução não é viável (por qualquer um dos 3 pontos citados), que você não identificou o problema certo ou que você não está focando no público certo. Por outro lado, pode ser que você tenha acertado em cheio e que já esteja no caminho certo. O ponto é que seu próximo passo será baseado em algo que você validou com alguém externo ao projeto e não está simplesmente dando suas hipóteses como verdadeiras. Com isso, muito provavelmente você terá novas Ideiassobre o seu produto, algo que você não tinha pensado e que surgiu desta pesquisa, o que pode te levar a novas hipóteses a serem validadas e vai fazer girar o seu Loop.
Pivot
A cada rodada completa do seu Feedback Loop chega o momento de tomar uma decisão: pivotar ou perseverar. O nome Pivot vem do basquete e remete à ação de fixar um dos pés no chão e girar com o outro, ou seja, procurar opções sem abandonar totalmente seu ponto de apoio. Traduzindo para negócios, isso significa validar apenas uma hipótese a cada loop, evitando gerar uma dúvida sobre qual variável funcionou ou falhou. Em termos práticos, se sua hipótese foi validada, você deve perseverar com ela e testar uma nova; se ela foi invalidada, você precisa pivotar seu produto em termos de problema, solução ou público-alvo. Daí vem a noção de que uma startup sobreviverá enquanto puder pivotar suas hipóteses, pois se chegar ao momento em que não há mais opções disponíveis, o negócio fracassou.
Aprendizado Validado
Como disse na primeira parte do post, o Aprendizado Validado é a principal métrica do empreendedor em uma startup. É ele que vai direcionar a equipe na construção da solução certa, para o problema certo e para as pessoas certas. Devo lembrar que estamos falando de uma “condição de extrema incerteza”, ou seja, o empreendedor realmente não conhece muitos dos obstáculos que ele vai precisar enfrentar, portanto precisa aprender sobre eles. O Lean Startup contesta fortemente a construção de um Plano de Negócios recheado de informações sobre receita e lucro da empresa, com projeções de crescimento e estimativas de ROI; na verdade, no estágio inicial o empreendedor não tem as mínimas condições de fazer tais afirmações, pois está trabalhando apenas no plano das hipóteses. Apresentar o Aprendizado Validado como métrica é muito mais real e transparente, além de ajudar o negócio a trilhar o caminho correto (ou fracassar cedo, minimizando o prejuízo).
MVP – Minimum Viable Product
“Se você não tiver vergonha do seu MVP, você demorou demais para lançar.” Essa frase de Daniel Wildt resume bem o objetivo do MVP: lançar algo o mais rápido e barato possível, que seja o suficiente para validar ou invalidar sua hipótese atual. Um MVP pode ter diversos formatos, entre eles um protótipo simples, um vídeo explicativo, um serviço de concierge (onde o serviço é realizado manualmente pelo empreendedor) ou até mesmo o produto já funcionando. Tudo vai depender do que você precisa validar. O importante é que ele consiga te entregar o Aprendizado Validado estabelecido no início do loop e que você tenha plena consciência de que está construindo o estritamente necessário para isso.
O vídeo abaixo foi o MVP do Dropbox, serviço de armazenamento de arquivos na nuvem, que surgiu quando as pessoas estavam acostumadas a usarem seus browsers para enviar seus arquivos. Drew Houston, CEO da empresa, precisava validar a hipótese de que “as pessoas entenderiam o Dropbox como uma ferramenta muito mais fácil de utilizar do que um browser”. O vídeo é narrado pelo próprio Houston e é totalmente fake (a ferramenta ainda estava começando a ser desenvolvida):
Split Tests (ou Testes A/B)
Testes A/B não são exclusividade nem foram inventados para o Lean Startup, mas funcionam perfeitamente quando você precisa validar hipóteses, principalmente de funcionalidades. Imagine que seu produto já esteja em operação e você precisa validar se uma determinada funcionalidade nova será bem aceita pelos clientes. Tradicionalmente você iria investir todo o tempo necessário para construir a funcionalidade inteira para então começar a receber feedbacks de seus clientes, que podem ou não considerá-la útil. No segundo caso, você desperdiçou tempo e dinheiro, além de deixar de desenvolver algo que pudesse ser realmente um diferencial para seu produto.
Os Testes A/B surgiram para evitar essa situação. Basicamente você vai “oferecer” a nova feature para um grupo selecionado de clientes, de preferência aqueles que possivelmente usariam essa nova feature. Porém, ao tentarem acessar a funcionalidade, os clientes são apenas direcionados para uma página fake, que pode ser um protótipo da funcionalidade em si, ou apenas uma explicação sobre ela, se possível solicitando algum tipo de feedback do cliente. Com isso será possível extrair diversas métricas e afirmar com algum embasamento se aquela feature deveria realmente ser construída ou não.
Você também pode usar os Split Testes como testes de usabilidade, por exemplo: você está em dúvida se o botão “Comprar” deve ser verde ou azul. Direcione metade de seus clientes para ver o botão verde e outra metade para ver o azul. O que tiver mais cliques muito provavelmente tem uma melhor usabilidade (é um exemplo extremamente simplista, só para ilustrar).
5 “Por Quês”
Sabe aquela fase do “Por que”? Ela vai voltar a ser muito útil para você! A técnica foi desenvolvida por Taiichi Ohno, pai do sistema de produção Toyota, e é utilizada para se encontrar a causa raiz de um problema. Ela é tão simples assim: para um dado problema, pergunte 5 vezes “Por que?”. A tendência é que você consiga se aprofundar no problema suficientemente para entender sua real causa, conseguindo assim eliminá-la por completo e evitar que o problema volte a ocorrer. Eric Ries propõe algumas adaptações para o cenário de uma startup, mas não foge do conceito básico proposto por Ohno.
Genchi Gembutsu
Também original da Toyota, este lema significa “vá ver você mesmo“. Por trás disso está todo o conceito de que você não pode confiar nas suposições que são feitas no seu escritório, por mais óbvias que elas possam lhe parecer. Você precisa ir até o cliente e enxergar a realidade com seus próprios olhos. Daí também surgiu o termo “Get Out of the Building” (Saia do Prédio), cunhado por Steve Blank em “Four Steps to Epiphany”, livro onde ele detalha o conceito de Customer Development.
Outras Ferramentas
Em posts futuros pretendo falar de outras ferramentas ligadas ao Lean Startup, como o Business Model Canvase o Validation Board. Não vai caber aqui… rsrsrs
Conclusão
Essa segunda parte do post ficou maior do que eu esperava, mas espero que essa enchurrada de informação faça sentido para você e te ajude a entender um pouco deste tema. Também queria aproveitar para chamar uma discussão: você já conhecia o Lean Startup? O que você achou do tema e do post? Como acha que pode aplicá-lo no seu dia a dia? Vamos transformar este blog na nossa mesa de bar!
Abraços e até a próxima!
Agile Momentum 