Pergunta: Temos uma área de UX, pegada de Design Thinking, e, como consequência, aplicamos técnicas como Design Sprint. Além disso, temos muitos times de produto e que temos fomentado fortemente a aplicação da Lean Inception, tal como você trouxe para a comunidade! Eu percebo que ambas as técnicas são válidas, já presenciei resultados positivos com ambas e aos poucos estou conseguindo aprender e perceber alguns critérios que são relevantes para aplicar uma ou outra técnica, mas diria que ainda são hipóteses que estou construindo. Queria saber sua de você, se tu entendes que têm critérios e quais seriam para aplicar uma técnica ou outra?
Resposta:
Eu também gosto das duas: Google Design Sprint e Lean Inception (Inception Enxuta, em Português).
Algumas similaridades: workshop colaborativo, o papel de um facilitador com experiência no workshop, agenda de uma semana, atividades de design thinking, jornadas do usuário, ambas são usadas tanto por pequenas startUps quanto por grandes corporações.
Algumas Diferenças entre Design Sprint e Lean Inception:
- Inception vs Sprint: Lean Inception é para ser um workshop para o alinhamento inicial; por isso o nome inception, usualmente utilizado para o início de algo. Sprint é para fazer uma Sprint, mas, conforme o nome indica, a equipe pode (e deve) fazer algumas sprints.
- Protótipo vs MVP: Um dos resultados da Design Sprint é o feedback de um grupo de stakeholders sobre os protótipos apresentados. Um dos resultados da Lean inception é o showcase para os stakeholders sobre o canvas MVP (artefato que detalha o MVP). O outro resultado é o alinhamento da equipe sobre o artefato gerado. Mas isso ambas as propostas alcançam.
- O que vs como: Geralmente as equipes não detalham o COMO fazer nas Lean Inceptions. Enquanto que geralmente, as equipes detalham o COMO fazer nas Design Sprints. Como o nome diz: design, e isso acaba sendo demonstrado como telas e protótipos. As Lean Inceptions não detalham telas ou protótipos, somente as funcionalidades do MVP; o COMO fazer fica para depois. Algumas equipes gostam disso, pois somente descrevem o QUE do MVP, tendo mais liberdade para decidir o COMO quando forem realmente colocar a mão na massa. Eu já ouvi ambas as frases: “Design é tão importante que fazemos todos os dias.”, e “Primeiro nós definimos o Design, para depois ajudar pontualmente com o Delivery.”
- Design vs Define: Todo modelo é uma simplificação de como atuamos. Mas se for olhar para o modelo do diamante duplo < Discover – Define > < Design – Deliver >; a Lean Inception estaria na parte de Define (convergir sobre o QUE fazer), enquanto o Design Sprint estaria no Design (divergir sobre COMO fazer).
- Ovo e galinha: Dado a explicação acima, eu já vi equipes combinando ambas de formas distintas: primeiro um Lean Inception e depois algumas Design Sprints (para alguns COMOs e telas do MVP em construção). Mas também vi o oposto, onde o teste da ideia do produto (via protótipo) era realizado em uma semana numa Design Sprint, para depois a equipe realizar uma Lean Inception para alinhar sobre o MVP (agora com P de produto, e não de protótipo). E tem equipes que mesclam ambas na mesma semana.
Então, respondendo a sua pergunta… se você está buscando um resultado final com telas, protótipos e definição do COMO, eu faria uma Design Sprint. Mas se você busca como resultado final o entendimento do MVP e uma definição inicial sobre o QUE fazer, eu faria uma Lean Inception.
————————————
Olha só que comparação excelente (direto ao ponto) recebi num comentário no LinkedIn:
“O sprint para o dia a dia quando o foco é prototipar e validar ideias de forma rápida, é ótimo se você não tem a estrutura e o tempo necessário para algo em profundidade como o Design Thinking. O Lean Inception para planejar o escopo de um produto, levantar os requisitos e definir um cronograma de entrega.” — Rodrigo Diego
[content_block id=3005 slug=inception-mvp-e-diretoaoponto]
