Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

Episódio 6: Lean Inception – Quando fazer? Quando não fazer?

19 jan 2022

>> Ouça este episódio

Eu sou o Paulo Caroli e este é o Podcast Mínimo Viável, onde compartilho conhecimento sobre as novas relações de trabalho e, assim, contribuo para a transformação de um mundo melhor.

Lean Inception: Quando fazer? Quando não fazer? Primeiro, Lean Inception é um workshop colaborativo para alinhar um grupo de pessoas a construir o produto certo, a solução ideal para o seu problema.

Por que que as pessoas fazem Lean Inception? Primeiro, um grupo de pessoas usa Lean StartUp, está seguindo lá o ciclo que o Eric Lies ensinou para a gente de build-measure-learn e depois faz uma Lean Inception. Por que isso? Está tendo muito aprendizado, muitos experimentos, muito experimentação seguindo esse ciclo construir-medir-aprender.

Têm pedidos da área de negócio? Se tem pedidos, vamos validar, vamos passas por ciclos de construir-medir-aprender, fazer experimentos para aprender rápido. Pesquisa com usuário, validação muito rápida, opa, agora que parece que validou, parece que é um bom product market fit aqui, vamos fazer uma Lean Inception para aí sim decidir qual é o mínimo viável para a gente construir de produto. Esse é o primeiro exemplo.

O segundo: a gente está seguindo o estilo Dual Track Development. A gente está fazendo descoberta contínua e entrega contínua. A Lean Inception vem nesse meio: como trazer da descoberta para entrega. Tem uma equipe ou algumas pessoas fazendo descoberta contínua, mas tem, geralmente é uma outra equipe, se for todo mundo junto ótimo, se for a mesma equipe não precisa fazer Lean Inception já está todo mundo alinhado.

Mas, como é muito comum nas organizações, um grupo está fazendo descoberta um outro grupo fazendo entrega ou delivery, e, de tempo e tempo, junta-se e faz um workshop de Lean Inception para decidir: e aí, para onde a gente vai? Qual o caminho? Qual é o primeiro passo? Qual é o MVP que a gente deve construir?

Um outro exemplo: projeto muito inovador e com muito impacto para o negócio. Vou trazer aqui um gráfico: impacto e negócio, alto ou baixo, inovador alto ou baixo. Então, se é muito inovador e de muito impacto para o negócio, vai fazer uma Lean Inception que vale a pena. Agora, se ele tem muito impacto para o negócio e é pouco inovador, é a tua “vaca leiteira”, não faz Lean Inception, calma. Não estresse a vaca, está dizendo não muda muito que a vaca está indo muito bem, não tente inovar o que já está te dando um bom resultado.

Se é pouco inovador e tem pouco impacto no negócio, esquece, não vai fazer uma Lean Inception e, se ele é muito inovador e tem pouco impacto no negócio, ótimo. Vai pesquisar, vai buscar mais informação e, quando tiver muita informação e mostrar que tem impacto no negócio, aí sim você deve fazer uma Lean Inception.

Outro exemplo são os 3 horizontes da McKinsey. O horizonte um é tua “vaca leiteira”, é o que está dando receita para empresa hoje. Geralmente, esses não têm Lean Inception, porque é um produto já estava dando receita para a empresa. Agora, o horizonte 2, aquelas que são as bezerras, são iniciativas que talvez virem as nossas “vacas leiteiras” daqui a seis meses, um ano. Essas vale a pena fazer uma Lean Inception para entender e aí, por onde a gente vai? Como é que a gente mostra resultado para fazer crescer esse produto, essa solução?

O horizonte três está buscando aprendizado e isso não é Lean Inception. Vai fazer muita pesquisa, muito aprendizado, muita experimentação para gerar conhecimento para lá na frente quiçá fazer uma Lean Inception.

Um outro exemplo: o segundo D do Diamante Duplo, que a gente tem a descoberta, o define e o delivery. O segundo, primeiro você descobre e abre as opções, quando você vai definir uma proposta de solução, neste momento vale a pena fazer uma Lean Inception. Depois, a gente está falando de entrega.

Um outro exemplo: depois de sessões de ideação e experimentação. A tua empresa super inovadora faz sessões de ideação, sessões de experimentação né. Ela roda, por exemplo, Experimentation Sprints, depois de rodar várias Experimentation Sprints, depois de ter muita ideação e falar: opa, parece que um conjunto de ideias aqui, de todo esse aprendizado vai gerar um bom resultado, uma boa solução, faz uma Lean Inception, alinha com outras pessoas e diz: oh, a gente quer seguir esse caminho, qual é o MVP? Qual é o mínimo viável que a gente deve construir para verificar esse product market fit?

Mais um exemplo: uma fase inicial de um projeto. É muito tradicional em empresas grandes que trabalham com projetos, às vezes, você tem um projeto aprovado, um período longo de aprovação. Aprovou aquele projeto tudo bem, o mundo não vai mudar de projeto para produto da noite para o dia. Então, mesmo no escopo de projeto, no início do projeto para entender e aí, como é que a gente vai fazer esse projeto? Agora que você está dentro da vida de um projeto, vamos usar Product thinking dentro da vida de um projeto. Então faz uma Lean Inception, o projeto já foi aprovado, faz e entende aí por onde a gente começa? Qual é o MVP e os incrementos seguintes.

Ou, o passo seguinte do Business Model Canvas. Se você é mais empreendedor, fez o seu Business Model Canvas, ótimo, a estrutura do seu negócio parece estar ótima e agora? Qual é o primeiro passo muito firme para criar um MVP? Faz uma Lean Inception e como resultado você vai ter o Canvas MVP e vai ser muito firme em relação ao que é esse teu produto mínimo viável, qual o primeiro passo na direção dessa estratégia ótima do seu negócio que está demonstrada no seu Business Model Canvas.

Mas, é muito importante falar sobre quando não fazer uma Lean Inception o que, aliás, a gente vai conversar hoje aqui também.

Por exemplo, DiscoveryResearch não é Lean Inception. Você tem que ter muitas atividades para fazer descoberta e research não é Lean Inception.

Outro: decidir um protótipo não é Lean Inception, aliás, faz um Design Sprint que é muito boa para decidir protótipo em uma semana. Lean Inception é para alinhar o MVP, alinhar vários times sobre um programa de trabalho. Até o Borba está aqui com a gente: Borba, essa pergunta é para você: e aí nesse pessoal, essa galera que usa SAFe, você pode usar PI Planning e outros tipos de workshop para alinhar e isso não é Lean Inception.

Priorizar o portfólio de iniciativas: sim vai lá usar Cost of Delay (CoD), Weighted Shortest Job First (WSJF) para decidir desses todos aqui qual é o que a gente prioriza, não é uma Lean Inception que vai priorizar o portfólio.

Mapear detalhes técnicos: vamos fazer um Event Storming para entender ou atividades mais baseadas na arquitetura, vamos sim entrar no nível de detalhe técnico, não é uma Lean Inception, é detalhe mais técnico mesmo e Event Storming é ótimo para isso.

Definir o processo de trabalho, ways of working. Um time que começou a trabalhar precisa definir como será esse processo de trabalho, não é Lean Inception é ways of working.

Planejar o backlog das Sprints em histórias do usuário: faz o PBB do Fábio Aguiar, o Product Backlog Building é exatamente para isso ou mapear a jornada do usuário para as histórias do usuário: User Story Mapping, do Jeff Patton, é exatamente para isso, não é uma Lean Inception.

Qual foi minha conclusão?

Eu vi que a Lean Inception é que nem um sanduíche: geralmente, vem alguma coisa antes, a Lean Inception e alguma coisa depois. Tweet This

Vou te dar alguns exemplos aqui: Alguns já falei. Usar Sprint para avaliar e decidir qual o protótipo seguida de uma Lean Inception para decidir: tá, agora que eu sei o protótipo do produto, por onde eu começo? Cadê o MVP? E, depois, faz um PBB para decidir as histórias que vão para cada Sprint.

Outro exemplo: Business Model Canvas, excelente, estamos super alinhados em relação à estratégia do negócio, da nossa solução como um todo, faz uma Lean Inception para decidir qual o primeiro passo e depois um Kanban para a execução de cada tarefa, de cada atividade para esse primeiro passo.

Esse eu tenho rodado muito ultimamente: a transformação baseada em dados, faz um workshop de aceleração de Data Mesh e depois faz uma Lean Inception. Agora que eu fiz um workshop e decidi opa, vamos fazer um data products, faz uma Lean Inception e depois um Event Storming que entra em muito mais detalhe técnico.

Mais um exemplo: estamos usando SAFe e PI Planning para entender todos os trens que têm que ir e depois uma Lean Inception para cada trem desses e, depois, um Ways of Working e, talvez, uma User Story Mapping se você já tiver jornadas.

Outro que é muito comum: o Onboarding do time começou, o time começou a trabalhar, consultoria, projeto aprovado, faz um Onboarding daquele time naquele projeto, faz uma Lean Inception e depois segue na tua Sprint Zero, Um, Dois, Três e aí vai.

Pessoal, essa era a mensagem que eu queria deixar. Aliás, esse conteúdo que eu passei para você muito rápido aqui em nem 10 minutos é o conteúdo da grande novidade que a gente tem na Caroli.org: o Lean Inception Pocket, que a gente está lançando agora é são vários conteúdos gravados para complementar para a nossa comunidade conhecimento sobre Lean Inception.

E aqui o episódio de hoje. Espero que você tenha gostado. Eu te peço para se inscrever e recomendar esse podcast na sua plataforma de podcast preferida, como Spotify e YouTube, e nas redes sociais. Ou, como eu prefiro: recomende aos seus amigos. Assim, você me ajuda com a missão de compartilhar conhecimento sobre as novas relações de trabalho, de forma a contribuir para a transformação de um mundo melhor.

>>> Temos mais uma novidade: se você gostou desse episódio, escreva um review na sua plataforma de podcast preferida e nos envie um e-mail com um print para [email protected]. Os cinco primeiros e-mails vão ganhar um livro a sua escolha.

 

Notas do episódio

MVP: Conheça e saiba como usar o Produto Mínimo Viável

Saiba mais detalhes sobre o Treinamento Lean Inception

 

>> Adicione nosso podcast a sua playlist

Caroli.org

Caroli.org is a hub for agile methodologies, innovation, and digital transformation, founded by Paulo Caroli, author of Lean Inception and Team OKR. We help organizations move from project to product and from strategy to execution, offering training, and consulting in Lean Inception, OKRs, Data Mesh, and agile transformations—empowering teams to align, validate, and deliver real business value.
#116: Quando os OKRs Atrasam: Ajustar o Prazo, Mudar o Plano ou Recomeçar?

#116: Quando os OKRs Atrasam: Ajustar o Prazo, Mudar o Plano ou Recomeçar?

Nem todo OKR é alcançado no prazo previsto. Mas quando isso acontece, qual é a melhor decisão? Estender o prazo, revisar as iniciativas ou abandonar o objetivo e começar de novo?
Neste episódio, Paulo Caroli discute os motivos mais comuns para um OKR atrasar, como diferenciar um problema de execução de uma mudança de contexto e quais critérios ajudam a decidir o próximo passo. Um bate-papo sobre aprendizado, adaptação e como usar os OKRs da forma certa para gerar resultados — sem transformar o framework em uma burocracia.

ler mais
#115: Do OKR Estratégico às Iniciativas: Centralizar ou Desdobrar?

#115: Do OKR Estratégico às Iniciativas: Centralizar ou Desdobrar?

Quando uma organização define seus OKRs estratégicos, qual é o melhor caminho para transformá-los em iniciativas concretas? Neste episódio, exploramos duas abordagens bastante utilizadas:
1️⃣ A liderança define os OKRs estratégicos, escolhe as iniciativas e depois distribui a execução entre os times.
2️⃣ A liderança define os OKRs estratégicos, compartilha a direção com os times, que então criam seus próprios Team OKRs e definem as iniciativas mais adequadas para contribuir com os resultados.
Quais são as vantagens, riscos e contextos ideais para cada modelo? Como equilibrar alinhamento estratégico, autonomia dos times e velocidade de execução? Uma conversa prática para líderes, gestores de produto, agilistas e profissionais que buscam conectar estratégia e entrega de forma mais eficaz.

ler mais
#114: Team OKR + Team Topologies: Estruturas ou Jetskis?

#114: Team OKR + Team Topologies: Estruturas ou Jetskis?

Team OKR + Team Topologies: Estruturas ou Jetskis?

Como aplicar Team OKR e Team Topologies em grandes empresas que ainda operam com estruturas organizacionais baseadas em áreas e funções?
Neste episódio, discutimos o desafio de alinhar estratégia e execução em organizações complexas, explorando o contraste entre equipes estáveis e os “Times de Jetski” — modelo utilizado pelo iFood para acelerar iniciativas estratégicas. Também abordamos a Curva de Tuckman e os impactos da formação e evolução dos times na geração de valor.

ler mais

Pin It on Pinterest