Este post é uma tradução do original escrito por Ash Maurya, autor do Livro Running Lean, e publicado em inglês em seu blog. Esta publicação foi autorizada pelo autor.

Da última vez, eu passei pelo processo de pensamento por trás do Lean Stack e apresentei uma visão geral das ferramentas utilizadas. Neste post, eu mergulho mais fundo no processo e termino com um estudo de caso concreto.

O MVP do Lean Stack – Uma abordagem diferente

Muitos de vocês indagaram se as novas ferramentas seriam integradas ao LeanCanvas.com. A resposta é sim, eventualmente, mas não começaremos por aí.

Fique por dentro de todas as novidades!

Assine nossa Newsletter e acesse diretamente em seu e-mail nossos principais posts e os últimos acontecimentos do mercado.

Minhas primeiras iterações (camadas do Lean Canvas e Quadro Kanban de Recursos) foram todas feitas por software. Na superfície, um aplicativo web pareceu ser a melhor escolha porque já tínhamos um grande grupo de usuários e o software seria rápido e fácil de se modificar, certo? Não exatamente.  Olhando para aqueles experimentos – eles tomaram muito tempo, custaram muito e criaram muito desperdício desnecessário – sem contar as horas lidando com problemas de UX, navegadores e outros defeitos.

Você quase sempre pode encontrar maneiras não convencionais para acelerar o aprendizado e reduzir desperdícios que não envolvem construir a solução final que você tinha em mente.

O primeiro MVP do Lean Canvas foi um post em um blog. O canvas foi então aprimorado por numerosos workshops (através de slides e exercícios no papel) antes de se tornar um software. Mesmo considerando aplicar a mesma abordagem, realizar experimentos é um passo mais avançado e tardio que não se encaixa naturalmente nos meus workshops de um dia.

Então, eu inventei um novo produto de aprendizado – The Running Lean Bootcamp. A ideia por trás do bootcamp era ir além do livro e do workshop de um dia, que são caracterizados pelo alto índice de ativação, mas pouco acompanhamento. Em outras palavras, as pessoas saíam do workshop muito motivadas, mas falhavam ao colocar esses princípios em prática, porque uma mudança real de comportamento é difícil.

O bootcamp pretende resolver esse problema levando as pessoas a executarem o Lean Startup nos seus produtos no período do bootcamp – com responsabilidade e coaching personalizado embutido no programa. Nós podemos compartilhar (e experimentar) com as nossas últimas práticas e as equipes podem avançar com seus negócios – criando vantagens para ambos os lados. O processo descrito abaixo foi aprimorado através do trabalho com equipes de 20 startups do último bootcamp.

Desta vez eu também decidi experimentar com um MVP físico (usando cartazes). Isso foi contra a minha natureza porque eu costumo pensar de maneira abstrata. Mesmo quando estudei engenharia elétrica, eu era o primeiro a sair do laboratório de simulação, mas o último a sair do laboratório de hardware. Apesar do meu ceticismo inicial, usar um MVP físico foi uma das melhores decisões que tomei.

Em dois dias, tínhamos todos os cartazes desenhados, impressos e presos na parede. Aqui está uma foto de como as versões iniciais eram:

Você notará que não tem o quadro de “Estratégia e Riscos” na imagem de cima. Isso é porque não existia um quando começamos. Este quadro era o elemento de conexão que faltava e foi descoberto acidentalmente enquanto eu trabalhava com uma das startups. A segunda imagem possui um versão feita a mão do quadro que se tornaria um cartaz alguns dias depois e seria estendido para todas as equipes.

Com software, nós teríamos que voltar atrás e escrever o código por mais algumas semanas para que isso funcionasse. Fisicamente, a parede e os post-its forneceram a nós um quadro branco que poderia mudar de propósito para o que quiséssemos. Este é apenas um exemplo da liberdade que os quadros físicos permitiram ao longo do processo. Quem disse que você não consegue iterar rapidamente com um protótipo físico?

Vamos ao fluxo realmente agora.

O Fluxo do Lean Stack

A visão – Lean Canvas

O primeiro passo do processo ainda é capturar a essência da sua visão como um diagrama do modelo de negócio em uma página, usando o Lean Canvas.

Eu já escrevi bastante sobre Lean Canvas, o que não vou repetir aqui de novo. Mas vou compartilhar uma armadilha comum que já vi muitas equipes caírem – a armadilha da paralisia da análise.

O objetivo do Lean Startup é validar as hipóteses mais arriscadas do modelo de negócio através do teste empírico com clientes – não criar razões retóricas em um quadro branco.

Sim, com o tempo seu canvas deve ser corretamente segmentado, focado e resumido – e provavelmente se beneficiará por profundos exercícios exploratórios, como persona e fluxo de criação de clientes. Mas alcançar esses objetivos no primeiro canvas é otimização prematura.

Ao invés disso, foque inicialmente seus esforços em se mover rapidamente através das camadas do Lean Stack e usar o loop de feedback para priorizar áreas que precisam de mais desenvolvimento. Por exemplo, a melhor hora para ir fundo nas personas talvez será no estágio de construção do seu primeiro experimento – o que será, provavelmente, uma Entrevista de Problema.

A estratégia – Quadro de Estratégia e Riscos

Com a sua visão documentada, você então se moverá para o quadro de Estratégias e Riscos. O objetivo aqui é formular um plano de ação apropriado – aquele que priorize o que é mais arriscado acima de tudo.

Priorização de riscos em uma startup pode não ser óbvio. A melhor maneira de começar é identificando os gaps no seu pensamento e falando sobre eles com conselheiros formais e informais.

Outra ótima ferramenta é estudar similares e opostos pré-existentes. Este é um quadro conceitual introduzido por Randy Komisar e John Mullins no livros deles: “Getting to Plan B”.

Similares e opostos, essencialmente, permitem você se apoiar nos outros e aproveitar suas lições aprendidas.

Depois de estudar similares, alguns padrões talvez apareçam, o que ajuda na hora de formular o seu plano de implementação. Por exemplo, depois do sucesso da 37signals com o Basecamp, várias empresas aplicaram a estratégia “construa uma audiência com um blog e então crie um aplicativo web”. Algumas deram certo, outras não.

Mesmo que a estratégia padrão não garanta seu sucesso, ela ajuda no início de sua jornada.

O Produto – Quadro de Validação do Aprendizado

Com suas estratégias e riscos documentados, você está pronto para ir aos experimentos.

Não de forma surpreendente, o trabalho neste quadro gerou a maioria das perguntas. Vamos a elas:

Pergunta: Como se cria um cartão para um produto antes de realizar entrevistas de Problema e Soulução?

O cartão do produto é apenas um espaço reservado para a ideia que você planeja implementar. Tudo que você precisa é uma etiqueta para identificar a ideia ou o conceito (que você pode mudar depois). Isso não pressupõe uma solução definida ou um comprometimento de construir a ideia. A única hora em que poderia se esforçar para encontrar um nome mais adequado para o produto é se estivesse buscando ideias aleatoriamente para implementação. Mesmo assim o produto poderia se chamar “ideia aleatória”.

Mas, na prática, na hora que você chega a este estágio, já se tem uma boa suspeita do problema, do cliente e até de uma solução possível. Ao invés de descrever como nomear o seu produto, eu devia gastar mais palavras convencendo-o a não nomear o seu produto prematuramente – sem gastar ciclos preciosos, realizar buscas de domínios ou criando logos para o seu “produto”.

Pergunta: O que é Minimum Viable Feature (MVF)? Qual sua relação com o MVP? Como sabemos qual deles usar?

O cartão do produto tem a intenção de capturar “uma unidade do produto” que é entregue aos clientes. A primeira “unidade do produto” que você lança é o seu Menor Produto Viável (MVP).

No meu último post, eu estava assumindo um processo de desenvolvimento contínuo, como o que nós usamos, onde depois do MVP, nós entregaríamos “~unidades do produto”TM subsequentes como características individuais adicionadas. Dado que nem todo mundo desenvolve desta maneira, uma etiqueta mais generalista pode ser chamada de Mínimo Lançamento Viável (MVR), onde o MVP é o lançamento 1.0 e o mesmo pode ser uma única característica (MVP) ou uma coleção delas.

Além do MVP e os seus MVR”TMs em seguida, o cartão do produto pode ser usado para representar múltiplos produtos relacionados no mesmo quadro. Na Spark59, nós usamos um único Lean Stack para capturar diferentes “ferramentas, conteúdo e coaching” do produto que construímos.

Pergunta: Você pode expor o ciclo de produto através dos 4 estágios no quadro?

O que eu descobri depois de construir alguns produtos da maneira Lean é que o processo de ir da Ideia para o MVP é/deveria ser o mesmo de ir do MVP para o lançamento 2.0, 3.0, etc. Caso contrário, é muito fácil você parar de escutar os clientes e acabar desencaminhado. Esse processo é o que eu representei na interação padrão mostrada no quadro.

Idealmente, esse processo deveria envolver:

1. Encontrar um problema que vale a pena resolver através da compreensão do problema (e dos clientes).
2. Definir uma solução possível ou um MVP.
3. Testa este MVP em menor escala.
4. Escalar.

Lançamentos subsequentes seguem estágios similares:

1. Encontrar outros problemas que valem a pena resolver que justifiquem o lançamento.
2. Definir soluções possíveis ou características que compensam o lançamento
3. Testar o lançamento em menor escala usando uma distribuição parcial.
4. Verificar o valor através de uma distribuição total.

Pergunta: Onde você captura o produto e experimenta os detalhes?

O cartão Kanban tem a intenção de visualizar e comunicar o fluxo de trabalho. O cartão é pequeno demais para mostrar todos os detalhes que vão com um produto ou experimento. Então, nós colocamos apenas as informações mais importantes em cada cartão.

• Para um produto, isso seria o identificador (nome) e o critério de saída para o estágio específico.
• Para um experimento, isso seria um identificador (normalmente um nome curto baseado numa ação, como “realizar Entrevistas de Problema”) e uma lista de uma ou mais hipóteses testáveis.
• Para um risco ou problema, isso seria um identificador tipicamente mostrado como uma pergunta, como por exemplo “Podemos cobrar R$ 100,00 ou mais nesse produto?”

Se essa fosse uma ferramenta online, abrir um cartão revelaria mais detalhes. Nós implementamos isso usando um relatório em uma folha A3. O Relatório A3 (nomeado assim pelo tamanho internacional da folha em que é feito) é muito usado na Toyota para iniciativas de resolver problemas variados, o que é muito similar aos desafios de uma startup. Na minha tentativa de compartilhar Relatórios A3, eu descobri outro paralelo entre os 4 estágios da iteração padrão descrita acima e os 4 estágios do clico de Deming: Planejar, Fazer, Checar, Agir (PDCA). Mas isso é assunto para um futuro post.

O Lean Stack na prática

Hora de irmos para o estudo de caso.

Agora é a sua vez

No pensamento Lean, um processo não á algo transmitido e escrito em pedra, mas um produto vivo que pertence àqueles que fazem o trabalho.

Assim como o Lean Canvas, o Lean Stack é licenciado como Creative Commons.

O que acontece a partir daqui é com você!

Caso você não tenha lido, veja o Lean Stack em Português – Parte 1!