La siguiente obra está disponible a través de Caroli.

org con el objetivo de

ofrecer contenido para uso en investigaciones y estudios académicos, con el
fin exclusivo de futura compra.
Está completamente prohibida y totalmente repudiable la venta, o
cualquier uso comercial del contenido presente.
Usted encuentra este y otros libros y e-books gratuitos en www.caroli.org

Traducción y colaboración
Patricia Trejo
Traducción
María Fernanda Escudero y Freddy Coronel
Corrección de estilo
Juliana Cury Rodrigues
Proyecto gráfico y diagramación del
cuerpo y tapa
Vanessa Lima Copyright © 2018 by Paulo Caroli
Derechos exclusivos de edición
Revisión © 2019, Editora Caroli.
Nicole Haddad Avenida Itajaí, 310 – Barrio Petrópolis
Desarrollo de eBook Porto Alegre, RS, Brasil – 90470-140
Loope Editora www.caroli.org/editora
www.loope.com.br contato@caroli.org

Catalogación en la Publicación (CIP)

Angélica Ilacqua CRB-8/7057

Caroli, Paulo
 Lean inception: creando conversaciones hacia un producto exitoso / Paulo Caroli;
traducción y colaboración Patricia Trejo; traducción María Fernanda Escudero y
Freddy Coronel. – São Paulo: Editora Caroli, 2019.

Bibliografia
ISBN 978-85-94377-09-8

1. Proyecto de producto 2. Planificación de productos 3. Planificación de

producción 4. Planificación estratégica I. Título II. Trejo, Patricia III. Escudero,
María Fernanda IV. Coronel, Freddy

18-1904 CDD 658.575

Las puntuaciones de catálogo sistemático:

1. Desarrollo de productos: planificación
AGRADEZCO a ThoughtWorks y ThoughtWorkers por inspirarme y utilizar mis
actividades de Lean Inception. Estoy convencido de que este increíble contenido
solo puede surgir cuando formas parte de un contexto muy específico. Mi
agradecimiento especial a ThoughtWorks Brasil, mi país de origen y la cuna de
este trabajo.
Gracias a los que compartieron sus conocimientos sobre los talleres de inception
e hicieron posible este libro. Mi agradecimiento especial a Jeff Patton y Jonathan
Rasmusson, de quienes tengo el placer y el privilegio de aprender.
Gracias a todos los que leyeron, utilizaron y compartieron sus comentarios sobre
Lean Inception. Este contenido evolucionó debido a la gran retroalimentación y las
experiencias compartidas. No fue hasta que me enteré del éxito que tuvieron otros
facilitadores al aplicar este método que me di cuenta de que me encontraba ante
algo especial.
Gracias a Martin Fowler por entrenarme y por solicitar este contenido en inglés.
Realmente aprecio su apoyo e incentivo al compartir prácticas importantes con
nuestra gran comunidad, tales como Lean Inception.
 Gracias a mi familia—Carolina, João, Duda y Fernanda—, por el amor y el apoyo
que me ha dado mientras sigo leyendo y escribiendo, en búsqueda de aprender y
compartir. Mi especial agradecimiento a João Caroli. Todavía recuerdo mi primer
viaje después de que naciste. Siempre me ha gustado facilitar inceptions, pero te
amo más y no podía estar lejos de ti por más de unos pocos días. Tuve que
hacerlas más lean —sencillas— para volver más rápido. ¡Definitivamente me has
inspirado!
Prefacio
Presentación
Lo que encontrarás en este libro
Cómo surgió el libro que tienes en tus manos

CONSTRUYENDO EL PRODUCTO CORRECTO

Desarrollo de un producto que importa

Inception: el comienzo de un proyecto ágil
¿Por qué se llama Lean Inception?
¿Por qué una Lean Inception?
La agenda de Lean Inception
Producto mínimo viable
El origen
Incrementos del MVP
Hipótesis pequeñas, grandes negocios
 Un ejemplo de evolución a través del producto mínimo viable (MVP)
Visión amplia, producto mínimo
Valioso, usable y factible
El factor “guau”
Cuidado con romper
Legado y bloques organizados
Embudo de ventas — AARRR
¡Haz una lean inception!

PREPARANDO EL TALLER

El taller (workshop) de Lean Inception

Colaboración
Diviértete con los “rompehielos”
Colocación
La sala de guerra
Post-its coloridos
El rol del facilitador
Estacionamiento
Las agendas
La agenda burn-up
Agenda de la semana
Checklist para lean inception

EJECTUANDO LEAN INCEPTION

Escribiendo la visión del producto

El producto Es/No es/Hace/No hace
Aclarando el objetivo
Entendiendo los trade-offs
Describiendo a las personas
Cuadrantes para identificar tipos de personas
Creando mapas de empatía
Actualiza el entendimiento sobre las personas
Brainstorming de las funcionalidades (features)
Muéstrame el dinero
Funcionalidades, objetivos y personas
Entendimiento técnico, de negocio y de experiencia de usuario
Verificando el entendimiento con el gráfico del semáforo
Tabla de esfuerzo, experiencia de usuario (UX) y valor de negocio
Mostrando los viajes de usuario
Exhibiendo las funcionalidades en los viajes
Secuenciando las funcionalidades
El secuenciador de funcionalidades
El template del secuenciador
Las reglas para cada onda
Convergiendo reglas y viajes
Identificando los MVP en el secuenciador de funcionalidades
Calculando esfuerzo, tiempo y costo
Detallando las funcionalidades de muestra en tareas
Estimación comparativa
 Entendiendo el costo y el tiempo
Calculando el promedio de una onda
Construyendo el canvas MVP
Completando el canvas MVP
El secuenciador de funcionalidades y el canvas MVP
Foco en la propuesta
Minimiza los riesgos con la segmentación de personas
Mejora la experiencia en los viajes
Reevalúa las funcionalidades del MVP
Desarrollo impulsado por hipótesis
Conversa sobre el costo y el cronograma
La estrategia MVP

ANEXOS

Ejemplo de una Lean Inception

Kick-off
Visión del producto
El producto Es/No es/Hace/No hace
Entendiendo los objetivos
Identificando a las personas
Descubriendo las funcionalidades
Entendimiento técnico, de negocio y de experiencia de usuario
Describiendo los viajes
Exponiendo funcionalidades en los viajes
 Secuenciando las funcionalidades
Construyendo el canvas MVP
Glosario
Actividades rompehielos
Localización geográfica
Teléfono visual
Uno dos ping cuatro pong
Formando triángulos
Zip Zap Zoom
Desenredarse
Piezas complejas
Dibujo colaborativo de caras
Espalda con espalda
Encuentra tu par
Referencias bibliográficas
Sé un facilitador de Lean Inception
Acerca de los traductores
Sobre la Editora Caroli
U
na visión ingenua del desarrollo de software ágil es una donde todos se
sumergen y comienzan a escribir el código sin pasar por un tiempo previo
pensando en qué hacer.
Esta visión, tan errónea como simplista, se basa en un cambio genuino de
pensamiento. Antes del ascenso de Agile, la gente seria de software aconsejaba
períodos largos de recopilación de requerimientos y arquitectura, donde en un
proyecto de cinco años podía pasar un año o dos antes de que se escribiese el
código, y ni pensar el tiempo que se tomaba la producción. El mundo ágil ha
descartado aquellos largos períodos de análisis previo, pero aún reconocemos que
tiene valor establecer un sentido inicial de dirección. El desafío es descubrir cómo
podemos hacer esto de forma rápida y eficiente, recordando, a su vez, que nada
nos enseña lo que queremos para nuestro producto final como un producto
incompleto que se lanza y está en uso. Por lo tanto, debemos compensar el ajuste
de la dirección con el conocimiento de que un pensamiento así de anticipado es
nuestra mejor opción.
En ThoughtWorks, nuestra respuesta ha sido un proceso llamado inception.
Reunimos una buena muestra de las personas que se verán afectadas por el
producto y tenemos una sesión intensiva para establecer una dirección inicial,
utilizando una serie de ejercicios que se centran en la colaboración y la
identificación de objetivos generales. No intentamos realizar una especificación
detallada, ya que es exactamente este tipo de cosa la que pasa a ser obsoleta tan
pronto como el código llega a producción. Pero sí queremos entender qué tipo de
resultados estamos esperando, las funcionalidades que creemos conducirán a
estos resultados y cómo evaluar la efectividad de nuestro producto.
 Con Lean Inception, Paulo ha captado su experiencia en la ejecución de estas
inceptions en la última década. En particular, se centra en su trabajo para pulir la
inception hasta su esencia, concentrando la actividad en una única, pero muy
intensa, semana de trabajo. Paulo comparte cómo lleva a cabo este trabajo a
través de la escritura de una visión de producto, captando personas, entendiendo
los viajes de usuario y desarrollando funcionalidades de alto nivel. El resultado no
es un plan de trabajo detallado, ya que consideramos que este se vuelve
rápidamente irrelevante. Es un conjunto guía de objetivos para llevarnos en la
dirección correcta. No planifica un producto final, con todas las funcionalidades
que nuestros usuarios necesitarán, sino que, en vez, se enfoca en un producto
inicial que podemos lanzar y del cual podemos aprender: el mínimo producto
viable (MVP). Este producto actúa como punto de partida para evolucionar hacia
un producto más rico y capaz, utilizando las lean inceptions para ayudar con cada
paso de esta evolución.
En este libro, encontrarás la experiencia que Paulo ha cosechado después de seis
años de efectuar estas lean inception. Hay un tabla para las actividades de la
semana, detalles de los ejercicios que se realizarán y consejos para ayudar al
equipo a aprender del lanzamiento del mínimo producto viable (MVP). Los
esfuerzos de la semana se resumen en un canvas MVP que actúa como un
producto simple y un resumen del trabajo. Empoderado con la experiencia de
Paulo, puedes practicar esta técnica y modificarla para que se adapte a tus
circunstancias.

MARTIN FOWLER
Chief Scientist da ThoughtWorks.
martinfowler.com
LO QUE ENCONTRARÁS EN ESTE LIBRO
De principio a fin, ¡este es un libro corto y práctico! Como su título lo dice: lean1,
directo al punto. Por ende, hay que leerlo todo, de inicio a fin.
El libro está estructurado en cuatro partes: “Construyendo el producto correcto”,
“Preparando el taller” y “Ejecutando Lean Inception”. Al final, están los anexos.

CONSTRUYENDO EL PRODUCTO CORRECTO

Para comenzar, cuento mi historia con las inceptions y por qué creé el concepto de
Lean Inception. Este libro está basado en el concepto de MVP, producto mínimo
viable (minimum viable product, en inglés). El capítulo que trata este tema presenta
el concepto y su historia, así como mi visión de MVP y de la evolución de los
productos lean.

PREPARANDO EL TALLER
Esta segunda sección explica en detalle el formato de taller colaborativo que te
ayudará a entender, alinear y planificar el producto que será construido. Quizás
sea el comienzo de un proyecto ágil en una gran empresa o el alineamiento sobre
qué construir en una pequeña startup. El estilo colaborativo y dinámico de Lean
Inception es el ingrediente secreto del chef en esta receta.

EJECUTANDO LEAN INCEPTION

Lean Inception es una receta, una secuencia de actividades colaborativas y
dinámicas que construirán el canvas MVP, una representación visual de la
evolución de un producto lean y del plan de creación. Cada paso de esta receta es
detallado siguiendo el orden de los subcapítulos, comenzando con “Escribir la
visión de producto” y finalizando en “Construir el canvas MVP”.

ANEXOS
Los apéndices pueden ser revisados antes, durante o después de la lectura del
libro. El primer apéndice presenta un ejemplo real del entendimiento y la
planificación de un producto lean, a partir del resultado de un taller de Lean
Inception realizado en un entrenamiento de ocho horas. Después hay un glosario
de términos y algunas actividades rompehielos.

CÓMO SURGIÓ EL LIBRO QUE TIENES EN TUS MANOS

“The Lean Startup es la guía para la innovación del siglo XXI. Las ideas ahí
contenidas ayudarán a crear la próxima revolución industrial”, nos dice Steve
Blank2 refiriéndose al libro de Eric Ries The Lean Startup (2011), y concuerdo
plenamente con él. Es más, el desarrollo de productos basado en el concepto de
producto mínimo viable (MVP) es el pilar principal para esta nueva revolución.
Esto porque, como explicita Eric Ries en su libro, el producto mínimo viable es
una pieza clave del ciclo construir-medir-aprender, como se muestra en el
diagrama de abajo, donde el MVP está representado como el artefacto a ser
construido.
 Una vez construido, el producto mínimo viable es puesto a prueba para así tener
datos que posibilitarán medir su uso y, por lo tanto, generar el aprendizaje
deseado. En este sentido, considero el modelo basado en las hipótesis de Jeffrey
Taylor, Jeff Gothelf y Josh Seiden sumamente eficiente para describir lo que
estamos buscando medir y aprender con el MVP. Por ejemplo, hace tiempo que
llevo usando el siguiente modelo:

Hasta ahora todo claro… Sin embargo, ¿cómo saber exactamente qué producto
construir? Y es que, si bien en el movimiento de Lean Startup encontré buenas
respuestas sobre cómo aprender y medir el uso del producto mínimo viable,
sentía que faltaba algo para guiarme sobre “qué construir”. Fue así como surgió
Lean Inception.
Al experimentar con diferentes actividades de inception y buscar apoyo en Design
Thinking, creé una secuencia de actividades para ayudar a un equipo a definir las
funcionalidades o features del MVP. A continuación, compartí esa secuencia de
actividades —como una receta a ser seguida— con algunos colegas, los cuales me
confirmaron su utilidad. Pedí feedback, busqué mejoras, realicé alteraciones, e
incluso hice pequeños ajustes en la nomenclatura.
Después de compartir con cientos de personas y trabajar con la
retroalimentación recibida, surgió —y evolucionó— el taller de Lean Inception:
una secuencia de actividades para la creación de productos de forma lean
fuertemente influenciada por Design Thinking y Lean Startup.
Desde entonces comencé a escribir entradas en un blog (en 2010), dictar talleres,
compartir apuntes, e incluso publiqué un e-book antes de que surgiera la primera
edición del libro impreso en portugués, Direto ao ponto, en 2014. Un año después:
opiniones, mejoras y la segunda edición de Direto ao ponto. Desde 2015 en adelante
comencé a compartir más sobre Lean Inception en inglés y en español (a través de
entradas en blogs y e-books).
En 2016 comencé a escribir el artículo “Lean Inception” en el sitio web de Martin
Fowler3. A partir del feedback del propio Martin y de varios colegas —entre ellos
Jonathan Rasmusson y Jeff Patton, quienes influyeron especialmente en mi
trabajo con inception, y muchos colegas de ThoughtWorks— mejoré la estructura y
el vocabulario del artículo y de Lean Inception. Esto me llevó a publicar el libro
Lean Inception en inglés, con una nueva organización y más contenido.
El conocimiento de los efectos positivos y el entusiasmo de tantos facilitadores
de Lean Inception que compartieron conmigo su impresión, además del excelente
trabajo y alianza que hicimos con Patricia Trejo para traducir el texto al español,
¡resultaron en el libro Lean Inception que ahora tienes en tus manos!
Y ahora… ¿qué más?
Continúo muy involucrado con las lean inception y, al enfocarme en el producto
mínimo viable, acabé tocando algunos asuntos relacionados con él, como
transformación digital, innovación, emprendimiento, estrategia, entrega
continua, DevOps, entre muchos otros.
Como puedes ver, existen muchos contenidos ligados a estos términos, pero he
querido mantener este libro lean. Sin embargo, podrás encontrar información
sobre ellos en mi sitio web, en otros e-books y publicaciones. Revisa las novedades
en www.caroli.org.
¡Feliz lectura y bienvenido al grupo de facilitadores de Lean Inception!
1 La metodología Lean fue desarrollada por Taiichi Ohno y Shigeo Shingo (entre 1950-1980) para el sistema
de producción de Toyota, con el objetivo de obtener una producción ajustada y sin desperdicios. En inglés
significa “magro”, sin grasa.
2 Steve Blank es emprendedor y académico de Emprendimiento en Silicon Valley, California, Estados
Unidos.
3 Disponible en: www.martinfowler.com/articles/lean-inception/. Acceso en agosto de 2018.
DESARROLLO DE UN PRODUCTO QUE IMPORTA
Los proyectos ágiles hacen énfasis en las entregas rápidas y frecuentes de software
de alto valor, de acuerdo con los objetivos del negocio y las necesidades de los
usuarios principales. La creación de un producto lean promueve la liberación
incremental del producto mínimo viable (MVP), una versión más simple de un
producto que puede estar disponible para el negocio. Pero, ¿cómo entender el
MVP y comenzar un proyecto ágil lo más rápido posible? ¿Cómo garantizar que el
equipo comience la creación del producto con un buen alineamiento inicial y un
plan eficaz?
He diseñado Lean Inception para responder a estas preguntas.

INCEPTION: EL COMIENZO DE UN PROYECTO ÁGIL

Un agilismo ingenuo no conlleva trabajo por adelantado, pero en la práctica nos
damos cuenta de que tenemos que hacer algo. Para ThoughtWorks4, inception es
ese “algo”. Desde que me uní a ThoughtWorks en 2006, me di cuenta de que todos
los proyectos ágiles de la compañía comenzaban de manera similar. El equipo del
proyecto se reunía durante algunas semanas, realizando muchas actividades
antes de comenzar el trabajo de entrega: esto era la inception.
La inception de ThoughtWorks fue desarrollada principalmente por Luke Barrett
alrededor de 2004. Jonathan Rasmusson (autor de The Agile Samurai) y Jeff Patton
(autor de User Story Mapping) trabajaron en ThoughtWorks por un tiempo, y
describieron y desarrollaron técnicas de inception en sus libros, de las cuales
aprendí mucho.
Nuestras inception varían de un proyecto a otro, pero generalmente generan un
alineamiento entre el negocio y los trabajadores técnicos, y crean una lista
ordenada de historias de usuarios con estimaciones junto a un plan de
lanzamiento.
 Por mucho tiempo estuve satisfecho de facilitar de esta manera las inception
ágiles… hasta el 2011, año en que nació mi hijo. El problema era que, si bien yo era
el facilitador inicial, la inception en sí tomaría de dos a cuatro semanas y no podía
quedarme fuera de casa por más de una semana. Tuve que hacer inceptions más
lean, para hacerlas calzar en una semana.
Recuerdo que iba en mi primer viaje después de que nació mi hijo, en un largo
vuelo desde São Paulo a San Francisco, cuando leí por primera vez el libro The Lean
Startup de Eric Ries. A partir de ahí encontré la excusa perfecta para reducir la
duración inicial y regresar a casa después de tan solo una semana.

¿POR QUÉ SE LLAMA LEAN INCEPTION?

Este nuevo estilo de inception es definitivamente un cambio desde el inicio de
2006. El equipo ya no escribe ni estima historias de usuarios.
Al experimentar con este nuevo estilo, el nombre de inception dio a todos el
mensaje errado. Necesitaba un nombre diferente.
El nuevo estilo de inception es lean por dos razones:
1.La duración de la inception es más corta, eliminando todo lo que no sea sobre el
producto (como arquitectura, proyecto, etc.), lo que hace que sea lean.
2.El resultado final de la inception es la comprensión del producto mínimo viable
(MVP), un concepto fundamental en el movimiento Lean Startup.
Por lo tanto, el nuevo estilo de inception tenía un nombre claro: Lean Inception.

¿POR QUÉ UNA LEAN INCEPTION?

Una lean inception es útil cuando el equipo necesita desarrollar un producto
mínimo viable (MVP) iterativamente. Aunque el término a menudo es
malentendido, la propiedad central de un MVP es que es algo que construimos
para saber si vale la pena seguir construyendo un producto. Por lo que elegimos
funciones que se basan en probar nuestras suposiciones de lo que es valioso para
nuestros usuarios. Para esto debemos entender quiénes son nuestros usuarios,
qué actividad realizan de tal manera que el producto les dé soporte y cómo medir
si es que les resulta útil el producto.
Después de facilitar más de trescientas lean inception y acompañar diversos
proyectos e iniciativas antes y después del taller, descubrí que es muy valiosa,
principalmente, en dos situaciones:
1.Los proyectos grandes encuentran que una lean inception es valiosa para
comenzar rápidamente y orientarse para trabajar en un estilo lean. Tal inicio
construye iteraciones tempranas diseñadas para descubrir y probar qué
características son realmente valoradas por sus usuarios.
2.Las organizaciones más pequeñas (como las startups) usan Lean Inception para
tomar una idea que ha sido probada por algunos MVP presoftware y
desarrollarla en un producto de software.
Este taller es específicamente sobre la comprensión de un producto mínimo
viable (MVP) y, por tanto, no sustituye las sesiones de ideación, la investigación de
clientes, la revisión de arquitectura o el análisis competitivo. Es una técnica
específica que es parte de la comprensión de lo que se necesita para construir un
producto exitoso. Exactamente cómo calza con estas otras actividades depende
mucho del contexto específico de tu organización y del esfuerzo de desarrollo en
el que estás trabajando.

LA AGENDA DE LEAN INCEPTION

Lean inception consiste en una serie de actividades, generalmente programadas
en el curso de una semana. Explicaré cada actividad en la sección del libro llamada
“Ejecutando Lean Inception”.

LEAN INCEPTION - EJEMPLO DE AGENDA

 Este es un ejemplo de agenda, por lo que no se debe considerar como algo fijo.
Sin embargo, es bueno tenerlo en mente, ya que es un buen ejemplo de cómo
pueden fluir las cosas.

PRODUCTO MÍNIMO VIABLE

Una nueva forma de crear y desarrollar productos, entregando solamente el
mínimo viable, ha sido fundamental para ayudar a miles de emprendedores a
lanzar productos fantásticos. Es cosa de considerar los casos de éxito como
iPhone, Facebook, Spotify, Airbnb, EasyTaxi, entre muchos otros. Sus creadores
trabajaron de esta forma desde el inicio de los tiempos, cuando aquellos
productos aún no eran (mega) famosos. Y es que entregar el mínimo viable te
ayudará a llevar a tu producto al mercado de forma mucho más rápida, a
minimizar sus gastos y a desarrollar el producto basado en la necesidad real de tus
usuarios.
La idea de crear solo el mínimo viable de un producto tiene un nombre y un
sobrenombre: producto mínimo viable (nombre completo) y MVP (sobrenombre,
proveniente de la abreviación en inglés, minimum viable product).
Un MVP es la versión más simple de un producto que puede estar disponible
para validar un pequeño conjunto de hipótesis sobre el negocio. Básicamente,
nadie quiere desperdiciar tiempo, dinero y esfuerzo construyendo un producto
que no va cumplir sus expectativas. Por esta razón se necesita entender y validar la
hipótesis acerca del negocio. Un MVP ayuda a validar y aprender de la manera
más rápida.
A diferencia de los productos creados de la manera tradicional, que usualmente
toman mucho tiempo y esfuerzo en prototipos, análisis y elaboración, el objetivo
del MVP es solamente validar el primer paso, el mínimo producto, el cual es
mucho menos elaborado que la versión final. El MVP se enfoca en el producto
mínimo, pero más viable, para verificar si la dirección es la correcta, como también
en el conjunto inicial de funcionalidades necesarias para la validación de la
hipótesis y para aprender más acerca del negocio.

EL ORIGEN
La idea del producto mínimo viable (MVP) se relaciona, desde sus orígenes, con las
ideas que se volvieron populares gracias al estilo de producción de Toyota. Steve
Blank, un emprendedor de Silicon Valley, creó una metodología basada en el
desarrollo del cliente. Ese fue el inicio del movimiento Lean Startup, que alcanzó
su punto culminante con Eric Ries y su libro que lleva el nombre del movimiento.
Si bien Eric Ries popularizó el concepto de MVP desde la publicación de su libro
The Lean Startup, la expresión ya se utilizaba varios años antes de que el
movimiento apareciera, especialmente entre las startups con sus emprendedores e
inversionistas de Silicon Valley. La expresión producto mínimo viable apareció por
primera vez en el 2000 en un artículo de Willian Junk, que se titulaba “El equilibrio
dinámico entre costo, cronograma, características y calidad en el desarrollo de
software”.

INCREMENTOS DEL MVP

Utilizar el producto mínimo viable (MVP) no implica que el producto no vaya a
evolucionar ni mejorar sus funcionalidades. Por el contrario, la idea detrás del
MVP es la mejora del producto guiado y validado por los resultados iniciales.
La corrección o confirmación del curso es lo que va a guiar los siguientes
incrementos. Estos incrementos son, a su vez, los MVP: nuevos productos
mínimos agregados al producto mínimo ya validado que nos permitirán tomar
decisiones acerca de la evolución del producto final. El producto ahora es
extendido, tal vez con una base de datos con más usuarios, permitiendo la
validación de nuevas hipótesis, incluso más elaboradas.
Es muy importante comprender que el MVP promueve una creación evolutiva.
Por lo tanto, la arquitectura como también las herramientas de construcción del
producto deben permitir esta característica de evolución progresiva y continua.
 En el 2010, Jez Humble y David Farley publicaron el libro Entrega continua. En
este, los autores discuten un proceso de entrega rápido y de bajo costo, que
permite la creación de productos de software de manera incremental. Ellos definen
Entrega continua como una disciplina del desarrollo de software que promueve
entregas más rápidas y frecuentes.
A pesar de que el libro de Entrega continua entra en detalles acerca de productos
de software y el flujo de trabajo para su creación, la idea esencial de la entrega
continua es la misma que Eric Ries recomienda en su libro The Lean Startup: ciclos
rápidos para validar las hipótesis.
Ciclos rápidos y frecuentes permiten períodos muy pequeños de liberación y con
bajos costos de experimentación. Sin embargo, no es fácil implementar este tipo
de enfoque y, por lo demás, los creadores de productos al estilo MVP van a
necesitar diferentes estructuras y prácticas de aquellas utilizadas
tradicionalmente para un producto con un ciclo lento.
Este libro se enfoca en actividades de análisis y planeamiento efectivo basadas
en el producto mínimo viable (MVP). Entrega continua es una especie de Biblia para
entender las herramientas necesarias para la creación y evolución de productos de
software. Pero, tal como las técnicas y aprendizajes compartidos por los autores de
Entrega continua pueden ser aplicados para otras clases de productos, y no solo
para productos de software, lo mismo sucede con el contenido de este libro.

HIPÓTESIS PEQUEÑAS, GRANDES NEGOCIOS

El producto es construido incrementalmente, con los MVP recién creados y siendo
agregados al producto sólido existente. Con los incrementos de MVP, la entrega
continua e incremental proporciona un aumento de valor del producto a través del
tiempo, mientras el proceso de creación de productos tradicionales no
proporcionará un valor sino hasta el final, cuando todo el producto está listo.
 Está figura muestra cómo un producto mínimo viable (MVP) ofrece pequeñas
validaciones a lo largo del tiempo, mientras que un estilo de creación de producto
tradicional solo ofrece una validación de todo el conjunto al final. Ahora bien, no
te dejes obnubilar por este ejemplo, porque los productos reales no son tan
simples como ir de un paso a otro de forma relativamente similar.
Imaginemos otro ejemplo de producto mínimo viable: el MVP para cruzar un río.
Una simple solución para cruzar una pequeña corriente es colocar un tronco de
madera atravesado de borde a borde. Y esta sencillez lo hace un gran MVP, pues
además de permitir cruzar la pequeña corriente del río, es una manera simple de
validar la ubicación para construir el puente. Incluso, se podría colocar más de un
tronco de madera en diferentes ubicaciones, y así validar cuál tiene un mayor uso.
Como se puede ver, el producto mínimo viable promueve una aproximación
incremental en la cual solo una pequeña parte de la hipótesis general es tratada al
mismo tiempo. Cada una de estas hipótesis es diseñada, creada y preparada para
ser añadida al producto, con el objetivo de generar información útil para su propia
toma de decisiones, aprendizaje y validación.
En esencia, una idea (o grandes hipótesis de negocios) es secuenciada en una
serie de hipótesis menores, más simples y, por tanto, más fáciles de entender.
Gracias a ello, las hipótesis simples son elaboradas más rápidamente y consiguen
estar disponibles en el producto para el usuario final. Por ejemplo, si hubiese un
puente en este lugar, ¿cuántos peatones lo usarían en una semana?
En este caso, el usuario final (o quien valide el MVP) proporciona información
para la validación de los incrementos del producto. Esta validación es esencial por
dos razones: (1) las correcciones y cambios pueden ser realizados en una fase
inicial del producto, en vez de aparecer al final de la conceptualización,
reduciendo el riesgo del mismo; (2) la complejidad del análisis de la hipótesis se
reduce.
De esta manera, tanto los creadores del producto como los usuarios finales
tienen un acceso temprano a algo funcional y viable, permitiendo que la decisión
de los siguientes pasos e incrementos del producto sean basados en el producto
mismo, en vez de ser simples hipótesis de otras hipótesis. Este patrón de trabajo,
basado en pequeños incrementos del producto y su hipótesis, permite construir
productos mucho más elaborados en pequeños pasos, pero bien fundamentados.

UN EJEMPLO DE EVOLUCIÓN A TRAVÉS DEL PRODUCTO MÍNIMO VIABLE (MVP)

El producto es construido incrementalmente, con los MVP recientemente creados
siendo agregados al producto consolidado ya existente. La última liberación de
MVP tiene un resultado positivo. Luego el equipo continúa la evolución del plan
del MVP creando el siguiente conjunto de características para la próxima
liberación del MVP.
 Esta figura muestra como un producto mínimo viable proporciona pequeñas
validaciones a lo largo del tiempo, mientras que una creación tradicional del
producto solo valida el producto final, enfocándose en la última versión del
mismo, que en este caso sería una máquina cortacésped con más implementos.
Como vemos, la tijera de cortar pasto es la primera versión del MVP. ¿Hay césped
que cortar? ¿Hay alguien que pueda manipular un simple aparato de cortar
césped? La validación de estas hipótesis conduce a la evolución del producto al
siguiente MVP, que esta vez puede ser algo más conveniente: un aparato cortador
de césped con un cable. Pero, ¿qué tal si le añadimos ruedas? Y así sucesivamente
va evolucionando el producto de un MVP a otro MVP.
El feedback más importante y valioso es aquel que contiene una respuesta
negativa. ¿Hay césped que cortar? No. En este caso, las tijeras no son necesarias.
Ahora bien, un cortacésped eléctrico caro, por bonito y sofisticado que sea,
tampoco es necesario. La hipótesis es falsa, por lo que un producto
completamente desarrollado habría sido una gran pérdida de tiempo y dinero.
Este ejemplo ilustra cómo el producto mínimo viable promueve una
aproximación incremental en la cual solo una pequeña parte de la hipótesis
general es tratada al mismo tiempo. Cada una de estas hipótesis es diseñada,
creada y preparada para ser añadida al producto. En esencia, una idea (o grandes
hipótesis de negocios) es secuenciada en una serie de hipótesis menores, más
simples y, por tanto, más fáciles de entender. Y vale la pena recordar que,
afortunadamente, el software no es como la manufactura. En el mundo del
software, un cortacésped puede ser creado agregando ruedas, volante, motor y
asiento a una simple tijera de cortar pasto.

VISIÓN AMPLIA, PRODUCTO MÍNIMO

Es importante que tengas una visión amplia del producto: completo, abarcador,
con diversas funcionalidades para muchos tipos de usuarios, cubriendo muchos
objetivos del negocio.
Sin embargo, aunque es importante pensar en grande, para ello debes comenzar
pequeño. Da un pequeño paso y aprende a partir del mismo. Ese pequeño paso es
lo que llamamos el producto mínimo viable (MVP).
El MVP sirve para validar hipótesis, para fallar y aprender rápido. En este
contexto, menos es más. ¡No desperdicies tiempo, dinero y esfuerzo creando el
producto equivocado!
En pocas palabras, ¡piensa en grande, comienza pequeño, aprende rápido!
Si bien el producto puede satisfacer más de un objetivo de negocio, ser útil para
varias personas y tener muchas funcionalidades, un MVP debe validar una
hipótesis, comprobar una idea y verificar si se logra lo que era esperado. Es que,
como su nombre lo indica, M es de mínimo, por lo que se trabaja una sola
hipótesis a la vez, un pequeño aspecto del negocio, para un segmento específico
de usuarios, con apenas una o pocas funcionalidades.
En la siguiente imagen puedes ver la representación de un producto elaborado a
través del producto mínimo viable. Cada cajita es un MVP validado por medio del
feedback de uso, del interés del negocio y de las posibilidades técnicas.

Como ves, el producto va creciendo y teniendo más funcionalidades

(representadas en la imagen como cajas apiladas). Esto ocurre de MVP en MVP o,
mejor aún, de MVP validado en MVP validado. En otras palabras, cada incremento
del producto tiene que ser validado. ¡No agregues al producto algo que no haya
sido validado!

VALIOSO, USABLE Y FACTIBLE

El producto mínimo viable (MVP) está en la intersección entre lo valioso, lo usable
y lo factible, representando, respectivamente, por el interés del negocio, la
aceptación (y admiración) de los usuarios del producto y lo que es posible
construir.

Valioso:personas de negocio piensan en el valor comercial de un producto.

Generalmente, esas personas tienen una visión de negocio y piensan en los MVP
como un paso a paso incremental para la creación del producto. En este
contexto, las personas de negocio influyen en el MVP para que, aun siendo
mínimo, alcance el retorno en la inversión esperado (o por lo menos demuestre
que está en la dirección deseada para el negocio).
Usable:toda y cualquier funcionalidad debe ser elaborada según las necesidades,
los deseos y las limitaciones de los usuarios. Algo usable está basado en una
comprensión explícita de las personas, sus tareas y de los ambientes en que
están insertos.
Factible:la solución propuesta para satisfacer el negocio y a los usuarios solo tiene
sentido si es ejecutable, si existe la tecnología y el conocimiento para su
elaboración. No tiene sentido definir un MVP si no se sabe cómo será construido.

EL FACTOR “GUAU”
El factor “guau” es aquello que diferencia tu producto en el mercado, que
conquista a los usuarios y los transforma en ávidos promotores de tu producto.
Aquello que literalmente hace que las personas digan “¡guau!”.
Pensemos en el iPhone cuando recién fue lanzado. Tenía el factor “guau”. Sus
usuarios decían: “¡Guau! Una pantalla touch completa... ¡Mira qué genial!”. O bien,
en las primeras personas que pidieron taxi a través de un sitio: “Guau, fue solo
colocar mi dirección, dar clic en OK y el taxi llegó”.
Si el factor “guau” es importante para un producto exitoso, para un MVP ¡es aún
más importante! Basta ver el ejemplo del iPhone 1, el producto mínimo viable del
iPhone. El iPhone 1 no tenía aplicaciones de terceros (y la plataforma de
aplicaciones tampoco estaba lista). Tampoco tenía integrado el GPS y las llamadas
eran peores que en los teléfonos del momento. Sin embargo, el iPhone 1 tenía el
factor “guau”. Las personas lo usaban y daban feedback. Sus usuarios —los early
adopters— eran los principales promotores del producto.
Gracias a ello, las personas hicieron fila para el lanzamiento del iPhone 2, del
iPhone 3, y así sucesivamente. Todo debido al factor “guau”, que transforma a los
usuarios en promotores, generando expectativa y deseo para el próximo
incremento. Lo mismo debe suceder con los MVP. Cada uno de ellos debe contar
con los factores: factible, valioso, usable y “guau”.
 La ilustración de arriba reitera la importancia de esos cuatro factores —factible,
valioso, usable y “guau”— en cada producto mínimo viable (MVP). El MVP es una
delgada porción del producto, conteniendo cada uno de esos factores. Por tanto,
no se debe pensar el MVP como una capa del producto (la figura de la izquierda),
donde primero se entrega lo que es factible para después elaborar de manera
sucesiva los otros factores, y solo al final buscar el factor “guau”. Muy por el
contrario, hay que construir el MVP como se representa en el lado derecho de la
imagen: una delgada porción de la visión del todo que contempla
simultáneamente los cuatro factores (factible, valioso, usable y “guau”).

Entregar un producto mínimo viable no implica que vaya a ser malo, simplón o
incompetente. No hay que confundir inconcluso con malo, simple con
simplón, incompleto con incompetente. El MVP debe ser factible (de ser
construido), fácilmente utilizable, generar mucho valor y ser increíble (¡guau!).

Otro ejemplo de MVP con factor “guau” es Facebook. Al comienzo era necesario
captar el interés de los usuarios, y para ello utilizaron el primer MVP. En las
imágenes siguientes puedes ver el inicio de Facebook o, mejor dicho, el inicio de
The Facebook.
El inicio de Facebook ilustra la idea de una delgada porción de MVP. Puedes ver
cómo siendo un producto simple, inconcluso e incompleto, aun así, era factible,
usable, tenía valor y era increíble. ¡Guau! Los usuarios querían más.

Reproducciones de pantallas de apertura y perfil de usuario de Facebook, en

2004.
CUIDADO CON ROMPER
Los juicios iniciales sobre algo difícilmente cambian. La primera impresión es muy
importante, y por ello quieres dejar una buena impresión de tu producto, de tu
MVP. En pocas palabras, necesitas el factor “guau”. Y, de alguna forma, también
quieres evitar lo opuesto: una falla que deje marcas.
“Errar es aprender rápido”. Ten mucha cautela al usar esta frase. Después de
todo, existen errores y errores, y nadie quiere un gran error, aquel que no tiene
reparo y deja al cliente con una pésima impresión.
Prefiero la frase “validar y aprender rápido”. Cuando se crea un MVP es para
ayudar a validar algo, no para que el usuario se “quiebre” debido a un error del
producto.
Consideremos nuevamente el ejemplo del puente de madera. El MVP sirvió para
validar si alguien atravesaría el riachuelo mediante una viga de madera. Este MVP
también ayudó a identificar el mejor lugar para colocar esa viga de madera, ese
puente. Pero el producto siguió evolucionando, y gracias a ello logramos validar
cada MVP, cada hipótesis: ¿aquellos transeúntes en bicicleta o motocicleta
también usarían ese puente de madera?, ¿y los vehículos de cuatro ruedas?
Así, el puente fue evolucionando de MVP en MVP... ¡Hasta que se cayó! El puente
de madera soporta el peso de los coches, pero no el de un camión y, por eso, ¡se
cayó! Si hubieses proyectado y construido de forma tradicional, ya considerando
todos los vehículos de la región, tal vez habrías construido desde un inicio un
puente de hormigón y, de esta manera, el puente no se habría caído.
Qué escenario más difícil, ¿no es así? Esta argumentación encubre los beneficios
de trabajar con el Producto Mínimo Viable. Sin embargo, recuerda que el MVP
tiene un V, de viable. El producto es mínimamente viable para algo. Un puente de
madera que no soporta cinco toneladas no puede recibir ningún vehículo con más
de cinco toneladas.
 Sin embargo, colocar una placa que diga “peso máximo: cinco toneladas” no es
suficiente. En su lugar se podría incluir una balanza antes del puente capaz de
identificar un camión mayor a cinco toneladas. O, mejor aún, una balanza y una
barrera que se cierre al identificar un vehículo con un peso mayor al permitido.
Dos funcionalidades que, de haber sido agregadas al MVP, habrían evitado ese
error.
Ahora bien, si pasan dos camiones de tres toneladas al mismo tiempo, el puente
se va a caer de todas maneras. Ante esta complejidad, ¿percibes la dificultad
técnica? Y no solo la dificultad técnica, sino también de usabilidad y lo que supone
el negocio.
No trataré aquí la solución a este desafío. Este ejemplo es una metáfora útil para
que reflexiones sobre tu producto mínimo viable. Es fundamental tener en
consideración que las funcionalidades que previenen que se caiga el puente deben
formar parte del MVP desde sus orígenes. Si no están contempladas estas
funciones mínimas en el MVP, el producto liberado no es viable y, por tanto, sus
usuarios no deberían haber sido expuestos a él. Necesitas validar tu MVP, ¡sin
dejar que se caiga el puente!

LEGADO Y BLOQUES ORGANIZADOS

A veces, el producto es una nueva versión de algún legado, algo ya existente, pero
que requiere mejoras. O bien el producto evolucionó tan rápido que su
arquitectura, su estructura interna requiere ser organizada (y bien elaborada).
Generalmente, productos en esta categoría son representados como bloques y
capas lógicamente apiladas.
El producto mínimo viable, aunque incompleto desde el punto de vista del
producto final, debe respetar los bloques y capas que representan la estructura del
producto.
 Conforme se ilustra en la figura anterior, el producto mínimo viable no debe ser
elaborado bloque a bloque hasta componer todo el producto, sino que debes
elaborar tu MVP como se presenta en la imagen del lado derecho de la figura.
Respeta la arquitectura, pero construye el MVP de extremo a extremo, con una
experiencia completa. Es decir, el producto no es construido bloque a bloque, sino
de MVP a MVP, de forma que los arquitectos de bloques (las personas técnicas que
deciden las partes internas del producto) amplíen la estructura del producto
conforme a la evolución del mismo.

EMBUDO DE VENTAS — AARRR

El embudo de ventas es una representación del flujo y de la cantidad de personas
en tu proceso de venta, desde la adquisición hasta las referencias.
AARRR (o métricas para piratas) es un acrónimo de métricas del embudo creado
por Dave McClure para comprender y satisfacer mejor a los consumidores de tu
producto o servicio.
Las cinco métricas —Adquisición, Activación, Retención, Retorno (ingreso) y
Referencia, que forman el acrónimo AARRR— representan las interacciones del
cliente con tu producto. Según Dave, una startup exitosa es capaz de optimizar
cada una de esas cinco métricas. Él recomienda que estas métricas se coloquen y
analicen de forma separada.
 » Adquisición: número de personas que adquirieron tu producto o servicio
» Activación: número de personas que tuvieron una buena experiencia inicial
» Retención: número de personas que volvieron para saber más
» Retorno (ingreso): Número de personas comprometidas en actividades que
generan ingreso
» Referencia: número de personas que recomendaron tu producto o servicio a
otros usuarios
Un producto mínimo viable debe validar todas las etapas del embudo de ventas
simultáneamente. La imagen de la derecha demuestra este caso, donde el MVP
valida todo el embudo de ventas.

Cuidado con insistir en un negocio que no genera ganancias, un falso positivo.

Un falso positivo es un producto que tiene un buen inicio, pero que nunca se
convierte en un buen negocio con bastante retorno y recomendación.
Este escenario está ilustrado en la imagen de la izquierda, donde un MVP
contempla solamente una etapa del embudo de ventas.

¡HAZ UNA LEAN INCEPTION!

Pero no es nada fácil elaborar un MVP. Como nos dice H. L. Mencken, “Para cada
problema complejo, hay una respuesta clara, simple y errada”.
 Para elaborar un producto mínimo viable se deben tener muchos factores en
cuenta: tener una visión amplia del producto y del negocio, validar una hipótesis,
hacer los incrementos, que sea factible, usable, valioso y “guau”, tener bloques que
encajen adecuadamente, utilizar el embudo de ventas, etc.
Pero no desesperes… este libro comparte años de experiencia ayudando a grupos
de personas a alinear el MVP, de forma colaborativa y con sus diferentes
perspectivas. Eso es lo que sucede en una lean inception.

4 Consultoría global en tecnología de la información (TI) que tiene como foco el desarrollo de software ágil.
EL TALLER (WORKSHOP) DE LEAN INCEPTION
En solo una semana de trabajo colaborativo el equipo logrará entender los
objetivos del producto, los principales usuarios y el alcance funcional a alto nivel,
de tal manera que se pueda estimar la duración del proyecto e identificar una
estrategia de lanzamiento incremental de los MVP.
Durante una lean inception, se realizan actividades y dinámicas para definir
objetivos, estrategias y el alcance del producto, así como para mapear y priorizar
las características deseables a ser entregadas gradualmente, construyendo los
MVP. El objetivo principal del taller es hacer que el equipo descubra y comprenda
colectivamente lo que va a ser desarrollado. Al final, el equipo debería estar más
integrado y con una visión más clara del camino a seguir.
Lean Inception es una técnica para entender y planificar una entrega incremental
de los MVP. Esta técnica organiza las ideas y funcionalidades en un modelo que
busca entender la finalidad principal del producto, considerando los viajes de los
usuarios y la entrega de valor de forma incremental. Como un libro de recetas, con
una secuencia de actividades rápidas y eficaces, la técnica va a permitir que el
equipo:
» Describa la visión del producto
» Priorice los objetivos del producto
» Describa los principales usuarios, sus perfiles y sus necesidades
» Entienda las principales funcionalidades
» Comprenda los niveles de incertidumbre, esfuerzo y valor de negocio por
funcionalidad
» Describa los viajes más importantes de los usuarios
» Cree un plan de entrega incremental del producto, impulsado por el concepto
de MVP
 A continuación, vamos a explorar los conceptos fundamentales de Lean
Inception y, en la próxima sección, se tratará en detalle las actividades que tienen
como objetivo cada uno de los propósitos recién mencionados.

COLABORACIÓN
La colaboración es el acto de trabajar juntos para realizar una tarea y alcanzar
objetivos comunes. El éxito de una inception está directamente relacionado con la
capacidad del grupo de colaborar efectivamente en cada actividad descrita en este
libro.
Una inception propone un proceso colaborativo de descubrimiento y
esclarecimiento en el que las personas involucradas trabajan juntas en una
secuencia de actividades para conocer las opciones y elaborar los MVP. Las
actividades presentadas en los capítulos que siguen representan métodos
estructurados de colaboración, buscando un ambiente creativo, donde se
comparte el conocimiento, hay aprendizaje y construcción de consenso. Las
actividades buscan aumentar el éxito de los equipos, a medida que ellos se
involucran en detallar y resolver cada paso hacia la construcción del MVP.

DIVIÉRTETE CON LOS “ROMPEHIELOS”

Nunca subestimes el poder de la diversión. A través de la diversión y de la risa, los
niveles de estrés disminuyen significativamente y estarás mucho más abierto a
trabajar con otras personas. Cuando se está feliz y relajado, hay una mayor
apertura a intentar cosas nuevas y así aumentar la participación en este taller que
es altamente interactivo: la lean inception.
Las personas altamente involucradas, participativas y que se están divirtiendo,
son más efectivas en las actividades colaborativas. Teniendo esto en mente, se
necesita romper el hielo o elevar el estado de ánimo de los participantes. En este
sentido, los rompehielos ayudan a crear un ambiente amigable y a poner a las
personas más cómodas para participar de las actividades de Lean Inception.
Los rompehielos son actividades rápidas y divertidas que pueden ser ejecutadas
para precalentar al equipo y promover la interacción del grupo. Son excelentes
actividades para comenzar cualquier tipo de reunión de equipo. Son todavía más
valiosas para los estados iniciales de construcción del equipo cuando las personas
se conocen poco, lo que típicamente ocurre en la mayoría de las lean inception.
Debes seleccionar una actividad rompehielos específica para el momento en
cuestión. En los primeros días, recomiendo actividades que se enfoquen en
compartir información, tales como nombres y pasatiempos. Para después del
almuerzo, recomiendo seleccionar rompehielos para despertar a las personas. Y,
finalmente, utiliza los rompehielos con mensajes simples, tales como “los
sistemas complejos son más difíciles de manejar”, “si alineamos las fuerzas resulta
más fácil alcanzar el objetivo” o “documentación escrita no es suficiente”. Además
de ser divertidas y energéticas, las actividades rompehielos ayudan a transmitir
mensajes importantes.
A continuación, un ejemplo de rompehielos que es bueno para compartir
nombres. En el anexo “Actividades rompehielos”, puedes encontrar más
actividades de este tipo y algunas ideas.

Paulo Puntual
Esta es una actividad corta para ayudar a los miembros del equipo a recordar los
nombres de cada uno.
El paso a paso de la actividad:
1.Solicítales a los participantes que piensen en un adjetivo que inicie con la misma
letra de su nombre.
2.Forma un círculo y pide a cada participante que diga su nombre con el adjetivo,
por turnos. Por ejemplo: “Hola, ¡yo soy Paulo Puntual!”.
3.Luego de que todos los participantes hayan hablado, pídeles ir en sentido
horario diciendo el nombre y adjetivo de la persona a su lado.
4.Luego de unos pocos turnos, pide a los participantes repetir el paso tres, pero
ahora en sentido antihorario.
Además de compartir algunas risas y romper el hielo, esta actividad ayudará al
equipo a asociar los nombres de las personas con un adjetivo, haciendo así más
fácil el recordarlos.

COLOCACIÓN
No subestimes el valor de la interacción cara a cara. Tecnologías innovadoras,
como la videoconferencia y los documentos compartidos, facilitan el trabajo
remoto entre las personas. Sin embargo, la interacción cara a cara durante la
inception facilita el arduo trabajo en las actividades, garantizando que todos estén
presentes y participando activamente.
Cuando todos están en la misma sala, el nivel de participación aumenta. No
puedes simplemente sentarte en una esquina y darle la espalda a la reunión para
hacer otra tarea. Las reuniones cara a cara tienden a ser más cortas y eficientes que
las reuniones remotas.
El entendimiento es mejor y los malentendidos se resuelven. Las expresiones
faciales y corporales se suman a la comunicación escrita y verbal. En general, las
reuniones cara a cara ayudan al equipo a llegar al punto, ¡directo al punto!
La secuencia de actividades para alcanzar el producto mínimo viable es extensa.
La colaboración y los resultados obtenidos son positivamente sorprendentes
cuando todos están físicamente en un mismo ambiente. Haz todo lo posible para
tener a todos los involucrados en un mismo ambiente, interactuando cara a cara
durante la inception.

LA SALA DE GUERRA
Mantén una misma sala reservada para el equipo durante el intenso período de
inception. Esta es comúnmente llamada “sala de guerra” o, en inglés, war room. La
sala debe permitir que todo el equipo esté cómodo. Debe tener una mesa y
paredes despejadas, una pizarra, papelógrafos, post-its de colores, papel y
bolígrafos para todos.
Una sala de guerra provee un ambiente para las actividades colaborativas.
También evita cualquier pérdida de tiempo cuando las personas deben
trasladarse de una sala a otra. Toda la información que ha sido creada permanece
en un mismo lugar.
Es importante mantener la información en una misma sala, ya que esto evita
transportarla o generar documentación prematura. Todos pueden y deben hacer
anotaciones a mano (tarjetas, post-its, papelógrafos, pizarra, etc.) y colocarlas en la
pared y la mesa, de forma que estén visibles para todos.

POST-ITS COLORIDOS
Haz las anotaciones en post-its o tarjetas coloridas. Escribe y colócalas en una mesa
o en una pared. Reúne a las personas a su alrededor. Habla sobre las anotaciones.
Escribe un poco más. Agrúpalas. Sepáralas. Rómpelas y escríbelas de nuevo. Haz
uso de colores. Reorganízalas. La colaboración generada a partir de algo tan
simple no puede ser emulada por cualquier alternativa digital.
 No hay sustituto para la acción de escribir, reescribir, agrupar o rasgar post-its de
colores. Esto promueve la interacción de las personas y ayuda en el proceso
creativo de experimentación, donde el camino está siendo construido sin miedo a
intentar, equivocarse o rehacer. En cambio, cuando la información se va al
computador, nunca regresa al papel. Esto reduce la interacción entre las personas,
pues no hay nada sobre la mesa o en las paredes, visible para todos y que pueda
ser fácilmente rasgado, reagrupado o reescrito.
EL ROL DEL FACILITADOR
Los talleres bien orquestados tienen algo en común: (1) alguien pensó en su
estructura y (2) alguien los facilita. El resto del libro trata sobre una adecuada
estructura para llevar a cabo una inception. Mientras que en esta sección comparto
algunas reflexiones acerca del rol del facilitador.
El rol del facilitador durante el taller de inception está enfocado en brindar una
guía “liderando la discusión” de los participantes durante el taller. Para ello, el
facilitador es una persona con mucha familiaridad y experiencia con el formato
del taller, su naturaleza colaborativa y la secuencia de actividades que se llevarán a
cabo.
Pero ojo, el hecho de liderar la discusión no implica que el facilitador sea el
participante principal, sino que más bien sirve como guía para propiciar el flujo de
ideas y conversaciones activas entre todos los involucrados en el taller.
Consecuentemente, el trabajo del facilitador se enfoca principalmente en lograr
que los participantes del taller tomen responsabilidad, liderazgo y colaboración a
lo largo de todas las actividades planificadas.
¿Y cómo lo logra? Aquí se presentan algunas características del trabajo del
facilitador durante el taller:
» El facilitador tendrá un mayor nivel de participación cuando explica el proceso
de inception, introduce las actividades y también cuando responde dudas y
preguntas respecto a lo que se espera durante el taller y sus actividades.
» Durante las diversas discusiones que se llevarán a cabo, el facilitador debe
tomar una posición completamente neutral, sin intervenir en absoluto durante
la toma de decisiones. Por el contrario, el facilitador se centra en ayudar al
grupo a seguir las actividades, identificar sus necesidades, solucionar sus
problemas asociados y tomar decisiones al respecto.
 » Para lograr lo anterior, el facilitador les da estructura a las actividades y a las
interacciones de los participantes, de tal manera que puedan llegar a los
resultados esperados en cada actividad de manera efectiva.
» Durante todo el proceso de inception, utiliza diversas técnicas para dar fluidez a
las conversaciones y cerrarlas alcanzando los resultados esperados (por
ejemplo, un brainstorming5 o utilizar la técnica Pomodoro6).
» Finalmente, el facilitador domina el uso de todo lo necesario en el taller: post-
its, papelógrafos, marcadores y, además, tiene una especial habilidad para
organizar espacios, moviendo las sillas y dejando espacio en las paredes.

En otras palabras, el objetivo del facilitador es brindar apoyo a los participantes

para que ellos puedan desempeñarse de forma excepcional en cada actividad e
interacción planificada para el taller, enfocándose en el proceso y en el contenido,
y asegurándose de que este último sea generado de acuerdo a las expectativas y
metas.
Puedes ver algunas otras técnicas de facilitación para Lean Inception en
www.caroli.org/ tecnicas-de-facilitacion-lean-inception.

ESTACIONAMIENTO
El estacionamiento ayuda a archivar momentáneamente cualquier tema, idea o
pregunta que sea planteada durante una actividad en una inception, para no
discutirlas en ese momento específico. Es una herramienta esencial para el
facilitador, pues proporciona una manera educada de decir “Sí, te escuché y vamos
a revisar esto después”.

“Estacionamiento” (parking lot, en inglés) es un término comúnmente utilizado

para estos fines. Alguna vez utilicé el término en inglés y le pedí a un colega
que escribiera el término en un papelógrafo. Mi colega entendió el concepto y
 lo escribió en portugués: Parque em lote. Desde entonces utilizo el término en
portugués, ahora bautizado como “parque-em-lote”.

El facilitador debe introducir el concepto de estacionamiento al inicio de la lean

inception, o apenas un tema comience a desviar la atención o a desviar al equipo
del objetivo. Para ello debes escribir “estacionamiento” en un papelógrafo y
colocarlo en una pared en la sala de guerra. Si el tema en discusión todavía no ha
sido escrito en un post-it, escríbelo en uno y colócalo en la sección de
estacionamiento. Asegúrate de explicar brevemente el concepto de
estacionamiento y luego regresa a la actividad que estabas ejecutando. Es
importante ser muy asertivo con los participantes de la lean inception sobre este
término: “La conversación estaba desviando el foco, y no es parte del alcance de la
actividad en cuestión, es por ello que aquel tema fue derivado al
estacionamiento”.
Es igualmente importante oír y respetar las opiniones, ideas y pensamientos de
los participantes; por lo tanto, el estacionamiento debe ser utilizado conforme a lo
prometido y ser visitado posteriormente: “Este tema está estacionado por ahora,
pero vamos a retomarlo más tarde”.
De hecho, al final de cada día de inception, se deben dedicar diez minutos a
revisar los temas en el estacionamiento. De esta forma, una de estas dos acciones
es tomada por cada tema: (1) el tema es removido del estacionamiento (o el tema
ya fue abordado y no necesita ser tratado más) o (2) el tema permanece en el
estacionamiento para una próxima revisión.
La última revisión debe ocurrir al final de la inception. En esa última validación es
muy importante aclarar todos los temas remanentes y compartir con todos lo que
va a suceder con ellos.

LAS AGENDAS
LA AGENDA BURN-UP
La agenda burn-up ayuda con la administración del tiempo y el alcance de una lean
inception. Tener una agenda visible para todos refuerza el compromiso y genera
confianza en la gestión del tiempo y en el progreso de la lean inception. Es una
herramienta simple y eficaz para planificar y facilitar el taller.

Las agendas burn-up7 surgieron en intensos talleres de brainstorming (lluvia de

ideas), como inceptions y sesiones de ideación. A pesar de que los talleres
realizan brainstorming de amplia discusión, normalmente tienen un límite de
tiempo y deben cubrir varios temas y actividades para lograr el resultado
deseado.

Lean inception es un taller colaborativo con sesiones de brainstorming y mucha

conversación que generalmente sucede a lo largo de la semana. Por eso es esencial
controlar el tiempo y el progreso del mismo. Las personas facilitadoras de Lean
Inception crean y explican la agenda burn-up en las primeras horas del primer día
del taller.

Aquí está el paso a paso para crear la agenda burn-up de Lean Inception:
 1.Dibuja en una pizarra o en una hoja A3 un gráfico XY conforme se ve en la
ilustración de arriba.
2.Anota en post-its separados las actividades de la lean inception (ejemplo: visión
de producto, Es/No es/Hace/No hace, personas, brainstorming de
funcionalidades, revisión, viajes, secuenciador y canvas MVP).
3.Coloca las actividades de abajo para arriba en el eje Y (la primera es visión de
producto, seguida por Es/No es/Hace/No hace, y así sucesivamente).
4.Anota en post-its separados los bloques de tiempo de tu lean inception (como
generalmente dura una semana, los bloques de tiempo son definidos como:
lunes en la mañana, lunes en la tarde, martes en la mañana, etc.).
5.Coloca los bloques de tiempo en el eje X.
6.Dibuja una flecha (vertical, para arriba) en otro post-it y colócalo al inicio del
tiempo (lunes en la mañana).
7.Explica al grupo como usar la agenda burn-up.
Encuentra el cartel de la agenda burn-up y los demás carteles para Lean Inception
en: www.caroli.org/carteles-lean-inception.

Hay dos movimientos básicos para los post-its, y ambos son movimientos
horizontales: (1) para actualizar el “reloj”: el post-it con la flecha que marca la
hora actual debe ser movido para la derecha, hasta la posición que
efectivamente representa la hora actual. (2) Para indicar el término de una
actividad: el post-it de la actividad correspondiente debe ser movido para la
derecha, hasta colocarlo en el bloque de tiempo en que se llevó a cabo.

El mecanismo de movimiento de los post-its permite identificar, de inmediato,

un desvío en la duración esperada de las actividades de la lean inception, y un
posible atraso del taller. Una vez constatado, el problema debe ser discutido y se
deben tomar acciones correctivas (hacer paralelamente actividades, reducir
conversaciones, hacer más uso del parking lot, etc.) lo antes posible y no cuando
sea muy tarde.

AGENDA DE LA SEMANA
La agenda burn-up provee una buena estructura para secuenciar las sesiones y
actividades abiertas de brainstorming, acompañando el progreso general y el
tiempo.
 Sugiero que se utilice la agenda burn-up. Sin embargo, algunas personas,
especialmente aquellas que no van a estar totalmente dedicadas al taller,
necesitan tener un idea de la semana. Por tal motivo comparto la plantilla de la
agenda para Lean Inception (también disponible en www.caroli.org/plantilla-age
nda-lean-inception).

LEAN INCEPTION - EJEMPLO DE AGENDA

El modelo de la agenda planificada presenta dos tipos de sesiones (presentadas

en colores diferentes en la ilustración anterior), que corresponden a los niveles de
participación: las partes interesadas (stakeholders) y los miembros activos.
» Stakeholder es cualquier persona impactada por el proyecto. Son personas
altamente interesadas en el direccionamiento y en el resultado de la lean
inception, pero que no tienen tiempo para participar de todas las sesiones, por
ejemplo: patrocinadores, usuarios finales, jurídico, ventas y marketing.
» Miembro activo es cualquier persona directamente involucrada en la
compresión e implementación del producto. Son las personas que deben
participar activamente en todas las sesiones del taller, por ejemplo: encargado
de producto (product owners), desarrolladores, jefes de proyecto o experiencia
de usuario.
 Es de notar que en la agenda las actividades de kick-off y showcase del taller están
marcadas en negro, respectivamente al inicio y al final de la semana. En el mundo
ideal, todas las personas estarán presentes en la sala de guerra durante la semana.
Sin embargo, raramente tenemos la disponibilidad de agenda de los stakeholders.
El mínimo necesario es que participen de las sesiones de kick-off y showcase, donde
son presentadas, respectivamente, las expectativas para la semana y el resultado
obtenido por el equipo dedicado al taller. Los demás días se realiza una secuencia
de actividades internas.

✓Checklist para lean inception

La lista a continuación está pensada para ayudar en el proceso de planificación
del taller de inception. Por favor, asegúrate de tener todos los ítems
programados antes de iniciar el taller:
( )Participantes seleccionados e invitados (interesados y miembros activos)
( )Facilitador con experiencia
( )Reserva de sala (mantener la misma sala durante el período de la inception)
( )Papelógrafos, tarjetas, post-its de colores, papel A4 y bolígrafos para todos.
( )Coffee break

5 La lluvia de ideas o brainstorming, en inglés, es una técnica de creatividad de grupo, que consiste en dejar la
mayor libertad a los miembros del grupo para generar el mayor número de ideas en relación al proyecto,
sin restricciones.
6 La técnica Pomodoro es un método de administración del tiempo desarrollada por Francesco Cirillo.
7 Lee más sobre agenda burn-up en www.caroli.org/la-agenda-burnup.
ESCRIBIENDO LA VISIÓN DEL PRODUCTO
Con un buen entendimiento de la visión del producto, se puede establecer cuál es
la primera pieza del rompecabezas del negocio y cómo va a encajar. Se debe
decidir cuáles son las características del producto sobre las que se va a trazar el
camino inicial y cuál va a ser su estrategia.
En algún lugar entre la idea y el lanzamiento, la visión del producto ayuda a
trazar el camino inicial. Aquello define la esencia del valor del negocio y debe
reflejar un mensaje claro y convincente para tus clientes. Esta actividad te ayudará
a definir colaborativamente la visión del producto.

Escribiendo la visión del producto8

Para [cliente final],
quien [el problema que necesita ser resuelto],
el [nombre del producto]
es un [categoría del producto]
que [beneficio clave, razón para comprarlo].
A diferencia de [alternativa de la competencia],
nuestro producto [diferencia clave].

El paso a paso de la actividad

1.Escribe la plantilla de la visión del producto en una pizarra o un papelógrafo de
una manera visible para todo el equipo.
2 Divide el equipo en grupos pequeños y pide a cada grupo que llene uno de los
espacios en blanco de la plantilla (o más de uno, dependiendo del tamaño del
equipo).
3.Reúne los resultados de cada equipo formando una sola frase.
 En esta actividad es muy común que el resultado sea una frase sin sentido. Por
ello, luego de ejecutar el tercer paso, es importante que el equipo trabaje unido
para formar una frase homogénea, usando y alternando los resultados previos si
es necesario.

EL PRODUCTO ES/NO ES/HACE/NO HACE

A veces es más fácil describir algo a través de qué es o qué no es. La actividad
Es/No es/Hace/No hace ayuda a definir el producto de esta forma, preguntando
específicamente cada aspecto positivo y negativo acerca de lo que es o hace el
producto.

El paso a paso de la actividad

1.Divide un papelógrafo en blanco en cuatro áreas (Es/No es/Hace/No hace).
2.Escribe el nombre del producto sobre los cuadrantes.
3.Pide a cada participante que describa el producto en post-its y los coloque en el
área correspondiente.
4.Lee y agrupa las notas similares.

El producto es...
El producto no es...
El producto hace...
El producto no hace...
 Esta actividad ayuda a explicar el producto. Generalmente, luego de dicha
actividad los participantes tendrán una visión más consensuada acerca de lo que
el producto hace, así como lo que el producto no hace. Las decisiones estratégicas
pueden ser clarificadas, como cosas que nunca hará el producto o aquellas otras
que aún no debe hacer.

CONSEJO: una vez, en un taller, me preguntaron la diferencia entre “es” y

“hace”. Una participante del taller — Aurineide Cavalcante — dio una respuesta
simple y eficaz: “si describes el producto con un sustantivo o adjetivo, coloca el
post-it en “es”; pero si utilizas un verbo, indicando una acción, colócalo en
“hace”. Por ejemplo, “seguro” y “aplicación móvil” en el cuadrante “es”, “reserva
cancha” y “conecta jugadores” en el cuadrante “hace”.
 Aprendí esta actividad de Rafael Sabbagh9, cuando la utilizó para definir uno de
los roles del Scrum10 durante uno de sus entrenamientos. Adapté esta actividad
para ayudar a definir el producto, y ha obtenido excelentes resultados.

ACLARANDO EL OBJETIVO
Cada miembro del equipo debe compartir lo que entiende como objetivos del
producto y los varios puntos de vista deben ser discutidos para lograr un consenso
de lo que es realmente importante. Esta actividad ayuda a plantear y aclarar estos
objetivos.

El paso a paso de la actividad

1.Pide a cada miembro del equipo escribir, individualmente, tres respuestas a la
siguiente pregunta: “Si tuvieras que definir este producto con tres objetivos para
sus usuarios, ¿cuáles serían?”.
2.Solicita a los participantes compartir lo que escribieron en un papelógrafo,
agrupando los objetivos similares.
3.Pide al equipo volver a escribir el objetivo, ahora colectivamente. En esta
ocasión, estará claro que algunos de los objetivos listados no representan los
objetivos principales del producto y, por tanto, deben ser descartados. De esta
manera estará claro para el equipo cuál es el foco del producto.

ENTENDIENDO LOS TRADE-OFFS

Trade-off o solución de compromiso es un acuerdo en el cual se deja algo fuera
para priorizar otra cosa que se desea más. Un producto lean refleja decisiones de
un equipo en relación a los trade-offs.
La actividad “Entendiendo los trade-offs” ayuda a construir y documentar un
entendimiento común acerca de los acuerdos de un producto lean. Muchas
decisiones y conversaciones son basadas en visiones individuales y premisas entre
alternativas. Algunos ejemplos: ¿qué es más valioso, la seguridad o la usabilidad?
¿Y qué tal entre desempeño y seguridad? ¿O usabilidad y desempeño? Esta
actividad promueve una conversación abierta y colaborativa sobre los trade-offs.
Los acuerdos claros evitan malos entendidos y ayudan a tomar decisiones
rápidamente.

El paso a paso de la actividad

1.Describe todas las categorías que son relevantes para el producto en post-its (por
ejemplo: seguridad, usabilidad, escalabilidad).
2.Pon las categorías en un papelógrafo en blanco como título de las filas. A
continuación, dibuja una línea horizontal para cada categoría.
3.Dibuja líneas verticales (el mismo número de líneas horizontales).
4.Escribe, encabezando cada columna, números del uno en delante (de izquierda
a derecha), donde el uno indica mayor importancia, el dos menos, y así
sucesivamente.
5.Pide a los participantes marcar sus iniciales en varios post-its y poner uno en cada
línea. La única restricción es que cada columna debe tener un post-it con sus
iniciales (por ejemplo: solo una de las categorías debe ser marcada como la más
importante).
6.Iguala los acuerdos. Con un post-it de diferente color (post-it de color rojo intenso
en la imagen), haz una marca en cada categoría, desde la menos a la más
importante. Esta marca debe ser relativamente fácil dado que se considera los
post-it con los votos de todos.
DESCRIBIENDO A LAS PERSONAS
Para identificar efectivamente las funcionalidades de un producto, es importante
tener en mente los usuarios y sus objetivos. La manera usualmente utilizada para
representar estos usuarios es por medio de personas11.
 Una persona representa a un usuario del sistema, describiendo no solo su papel,
sino también sus necesidades específicas, creando una representación realista de
los usuarios, que ayuda al equipo a describir funcionalidades desde el punto de
vista de quien interactuará con el producto final.

CUADRANTES PARA IDENTIFICAR TIPOS DE PERSONAS

La siguiente actividad es utilizada para describir los tipos de personas. La actividad
es simple, ilustrativa, divertida y rápida.
El paso a paso de la actividad
1.Solicita al equipo que se divida en pares o tríos y entrégales la siguiente plantilla
de personas a cada grupo.

2.Pide a cada grupo que cree una persona, utilizando la plantilla como referencia.
3.Solicite a los participantes que presenten sus personas a todo el equipo.
4.Pide al equipo que cambie los grupos y repita los pasos 1 al 3.

La plantilla presentada fue creada por Natalia Arsand, excelente user experience
designer (UX) y colega de trabajo en ThoughtWorks Brasil.
Al final de la actividad, un conjunto de personas debe haber sido creado y los
diferentes tipos de usuarios del sistema deben estar descritos. Las partes
interesadas (stakeholders), que conocen los objetivos del proyecto, deben
participar activamente en la actividad, auxiliando al equipo en la creación de las
personas y sugiriendo cambios en sus descripciones, según sea necesario.

CREANDO MAPAS DE EMPATÍA

El mapa de empatía es una plantilla visual para identificación y visualización de
una persona. Creado originalmente para análisis de segmentos de consumidores,
el mapa de empatía es una excelente herramienta para clasificar, explorar y
entender los diferentes tipos de personas.
El mapa de empatía fue originalmente descrito por Dave Gray como uno de los
métodos de XPLANE12 para comprender a los usuarios, clientes y otros
involucrados en el negocio. Se hizo aún más conocido desde que fue destacado en
el libro Business Model Generation como una herramienta para descubrir ideas sobre
los clientes13.
El mapa representa cuatro áreas principales, las cuales forman la frase:

¿QUÉ ____________ (VEO / PIENSO / OIGO / HABLO)?

Además de estas cuatro áreas principales, la versión original cuenta con dos
zonas para esa persona: el dolor (pain, en inglés) y la ganancia (gain, en inglés).

Siempre que he utilizado el mapa de empatía para identificación de personas,

utilizo sus cuatro áreas principales: veo, oigo, pienso y hablo. Pero, a veces, utilizo
las áreas de dolor y ganancia, como está descrito originalmente; sin embargo,
algunas veces altero estas otras áreas, como, por ejemplo: lo que yo hago, lo que
yo no hago, mis amigos y mis enemigos, mis hobbies.

El paso a paso de la actividad

1.Elige una persona para ser analizada.
2.Diseña una plantilla del mapa, con la persona representada en el centro de la
plantilla.
3.Describe las áreas para esa persona.
4.Repita los pasos 2 y 3 para las siguientes personas.

ACTUALIZA EL ENTENDIMIENTO SOBRE LAS PERSONAS

Es importante destacar que el resultado de la actividad de definir la persona no
debe ser definitivo, y que una construcción inicial puede ser actualizada conforme
el producto evoluciona.
La actividad es realizada basándose en el conocimiento, en las encuestas y en los
datos previos sobre los usuarios del producto. Generalmente, las empresas
grandes tienen conocimiento y datos sobre sus usuarios. Si no fuese el caso,
existirán hipótesis sobre los usuarios del producto y ellas estarán explicitadas en la
actividad de describir las personas.
Con el feedback del producto obtendremos más compresión sobre las personas.
Incluso, más encuestas pueden ser realizadas para adquirir un mejor
entendimiento de los usuarios. Dado que el conocimiento aumentó, rehaz la
actividad de persona, actualizando la representación de los usuarios.

Samantha Rosa, una amiga UX (user experience designer), compartió un ejemplo

de ello. Durante una lean inception, su equipo siguió los pasos de la actividad
presentada y creó las personas, pero después de liberar el producto para
clientes reales, percibieron que una de las personas descritas no estaba de
acuerdo con la realidad. Entonces realizaron de nuevo la actividad para
actualizarla, y repensaron el producto.

BRAINSTORMING DE LAS FUNCIONALIDADES (FEATURES)

Una funcionalidad es una descripción de una acción o interacción de un usuario
con el producto. Por ejemplo, imprimir una factura, consultar una declaración
detallada, compartir con los amigos de Facebook.
La descripción de una funcionalidad debe ser lo más simple posible. El usuario
está intentando hacer una cosa y el producto debe tener una funcionalidad para
eso. ¿Cuál funcionalidad sería esa?
 Dado que ya tenemos a las personas y a los principales objetivos del producto, la
siguiente pregunta ayuda con el descubrimiento de las funcionalidades:

¿Qué necesita tener el producto para cumplir con las necesidades

de la persona? ¿Qué funcionalidades debemos construir para poder
alcanzar aquel objetivo?

La siguiente actividad es utilizada para el brainstorming de las funcionalidades. Es

importante notar que esta actividad depende de la lista de objetivos y personas,
que deben ser artefactos ya elaborados en actividades anteriores.

El paso a paso de la actividad

1.Solicita al equipo que coloque los objetivos sobre una mesa o en una pared, en
orden de prioridades, de izquierda a derecha, como títulos de columnas.
2.Pide al equipo que coloque las personas en el mismo espacio, en orden de
prioridades, de arriba hacia abajo, como títulos de las filas.
3.Promueve un brainstorming de ideas de funcionalidades. La discusión debe ser
guiada para que se descubra qué funcionalidades son necesarias para atender
los objetivos y las personas. Una pregunta que ayuda en este proceso es: ¿Qué
debe tener el producto para cumplir con las necesidades de la persona? ¿Qué
funcionalidades debemos construir para alcanzar este objetivo?

El equipo debe guiarse a través del artefacto creado repitiendo las preguntas de
arriba para cada combinación de persona y objetivo, comenzando con los de más
alta prioridad. De este modo, las candidatas a funcionalidades con mayor
prioridad surgirán primero.

Este libro describe mi experiencia con Lean Inception para productos digitales.
Por lo que llamé a la actividad como Brainstorming de funcionalidades (del
producto digital o del MVP). Pero en algunas instancias, cambié el nombre de
la actividad, por ejemplo: Brainstorming de actividades o Brainstorming de ideas.
Aquello ocurrió en los casos en que el contexto de Lean Inception no era para la
creación de un producto digital, sino para la alineación de las personas para
construir algo (no necesariamente un producto).

MUÉSTRAME EL DINERO
El control de tiempo es esencial para todas las actividades, pero esta actividad
requiere atención especial. En el caso de que un gran número de objetivos y
personas sean seleccionados en los pasos 1 y 2, un sinnúmero de funcionalidades
podría ser planteado por el equipo. Esto será contraproducente y puede llevar al
equipo a gastar mucho tiempo conversando sobre funcionalidades que no serán
parte de los primeros MVP.
Para evitar este escenario, es altamente recomendable que el número de
objetivos y personas sea limitado (por ejemplo, los tres o cuatro principales
objetivos y personas).

Si tuviésemos un presupuesto muy reducido y pudiésemos trabajar

en apenas un objetivo, ¿cuál sería?
 La pregunta de arriba ayuda al grupo a priorizar objetivos y personas. Repite la
pregunta algunas veces para los objetivos y luego para personas. Más allá de la
priorización, ayudará con el foco en la validación y en la evolución del producto a
través del MVP.
Una forma más lúdica y colaborativa de priorizar objetivos y/o personas es
pensar en dinero. Para ello se realiza la siguiente actividad.

El paso a paso de la actividad

1.Divide a los participantes en grupos pequeños.
2.Distribuye cinco post-its con el signo “$” para cada grupo (usar un color de post-it
por grupo).
.3Instruye al grupo a colocar los signos “$” donde cree que se debe invertir más
dinero (sea para entender mejor la necesidad de la persona o en alcanzar un
objetivo).
4.Conversen sobre el resultado (de la opción de redistribuir los “$”).
5.Prioricen los ítems con más “$”.

FUNCIONALIDADES, OBJETIVOS Y PERSONAS

Aunque el canvas es similar a una matriz, no necesariamente habrá una
funcionalidad para cada intersección. Puede haber múltiples funcionalidades para
que una persona alcance un objetivo específico, así como es posible que haya
personas que no necesitan de una funcionalidad para un determinado objetivo.
En caso que se identifiquen funcionalidades que no atienden las necesidades de
ninguna persona, entonces deben ser descartadas o repensadas, pues su valor no
está claramente asociado a un usuario.

ENTENDIMIENTO TÉCNICO, DE NEGOCIO Y DE EXPERIENCIA DE

USUARIO
La actividad anterior logró alistar muchas funcionalidades, pero necesitamos
invertir más tiempo para entender las funcionalidades en detalle. Para desarrollar
este entendimiento evaluamos las funcionalidades en términos de esfuerzo, valor
de negocio, experiencia de usuario y certeza.
Para el esfuerzo, valor de negocio y experiencia de usuario, anotamos las
funcionalidades utilizando marcas en una escala de uno, dos o tres.

Evaluar la incertidumbre es un poco más complejo. “Sé exactamente lo que

quiero de este ítem de trabajo y sé exactamente cómo hacerlo”. ¡Es increíble
cuando eso ocurre! Sin embargo, no siempre es así. Debido a ello es que se
necesita verificar, para cada funcionalidad, cuál es el nivel de certeza que se puede
tener de ella. El gráfico del semáforo nos ayudará con aquello.
 Clasificamos cada funcionalidad combinando el nivel de certeza técnica (qué tan
bien el equipo de desarrollo entiende cómo construir la funcionalidad), de
confianza en el UX (user experience) y por el entendimiento de negocio (qué tan
bien la gente de negocios concuerda sobre qué entra en la funcionalidad). De esta
manera, cada funcionalidad recibe una posición correlativa al nivel de
certidumbre. Si una funcionalidad queda en la parte inferior izquierda del gráfico
(marcada con una “X”), considera descartarla o invierte más tiempo en aclararla.
Este gráfico recibe el nombre de “gráfico del semáforo”, ya que sus colores son los
mismos que los de un semáforo: verde, puedes seguir tranquilo; amarillo, presta
atención pues tal vez tengas que parar antes de continuar; rojo, para y espera
antes de seguir.
Al terminar la revisión del esfuerzo, valor del negocio, experiencia de usuario y
certeza, todas las funcionalidades estarán evaluadas y analizadas. Por ejemplo, la
funcionalidad “registrar dirección favorita” puede tener un esfuerzo medio, valor
de UX alto, valor de negocio bajo y nivel de certeza alto.
 Cada funcionalidad debe pasar por la revisión técnica, de UX y de negocio. Para
ello, cada funcionalidad debe ser primero mapeada en el gráfico del semáforo y, en
seguida, debe recibir marcas según la tabla que mide el esfuerzo, la experiencia
del usuario (UX) y del valor del negocio.
En el gráfico del semáforo, la funcionalidad recibe un color; en la tabla, recibe
marcas de valor y esfuerzo. Cada color representa un nivel de confianza o certeza
de la funcionalidad; mientras que las marcas de esfuerzo, valor de negocio y valor
de UX en la tabla, varían en una escala de una, dos o tres veces comparativamente,
por ejemplo: $, $$ y $$$. El color y la marca van ayudar al equipo en las actividades
siguientes para priorizar, estimar y planificar.
A continuación, se presenta un ejemplo de funcionalidades después que pasaran
por el gráfico del semáforo y por la tabla de esfuerzo, UX y negocio.
 El proceso de evaluar cada funcionalidad con el gráfico y la tabla genera más
resultados que simplemente los colores y marcas en cada tarjeta. Se llevan a cabo
importantes conversaciones, algunas decisiones son firmadas, se definen
premisas y se describen incertidumbres. En otras palabras, las personas discuten y
hacen anotaciones sobre cada funcionalidad en cuestión.
Es muy importante guardar las anotaciones generadas durante estas
actividades, pues sirven para complementar la descripción de la funcionalidad.
Luego, debes solicitar a los participantes hacer anotaciones en post-its y pegarlos
detrás de la tarjeta. Así, las actividades continúan de manera rápida y dinámica,
pero manteniendo las anotaciones importantes.
VERIFICANDO EL ENTENDIMIENTO CON EL GRÁFICO DEL SEMÁFORO
Esta actividad tiene el objetivo de discutir cómo se siente el equipo en relación a la
compresión técnica, de UX y del negocio para cada funcionalidad. A partir de esta
actividad, nuevas notas serán tomadas, y las discordancias y dudas se harán más
evidentes.

El paso a paso de la actividad

1.Crea un gráfico donde el eje de las X represente la certeza técnica (cómo hacer) y
el eje de las Y represente el conocimiento sobre el entendimiento de UX y del
negocio, sobre lo que se requiere (qué hacer).
2.Solicita a un miembro del equipo que lea una funcionalidad en voz alta y que la
coloque en el gráfico de acuerdo a la comprensión que tiene de ella,
respondiendo a las siguientes preguntas para cada eje.
» Eje X: ¿Qué tan seguro estás de cómo realizar esta funcionalidad?
» Eje Y: ¿Qué tan seguro estás sobre qué es lo que esperan el negocio y/o los
usuarios de esta funcionalidad?
3.Pregunta al equipo si todos comparten esta opinión. Si alguien no está de
acuerdo, el equipo debe discutir los requisitos y la tecnología involucrados de
forma que haya un consenso sobre la funcionalidad. Todo lo que sea
mencionado y que ayude a alcanzar una mejor comprensión debe ser anotado
en la funcionalidad.
4.Anota en la funcionalidad el nivel de comprensión. Por ejemplo, la figura
anterior muestra funcionalidades en post-its con su respectivo nivel de
comprensión: verde ( ), amarillo ( ) o rojo ( ), indicando respectivamente un
nivel alto, medio o bajo de comprensión.
5.Para cada funcionalidad identificada anteriormente, repetir los pasos 2 al 4.

En el eje X, el objetivo es verificar la comprensión del equipo en relación a los

desafíos técnicos, las dependencias y los requisitos de infraestructura. ¿Hiciste
esto antes? ¿Sabes cómo hacerlo? La respuesta “sí” indica alto nivel de confianza
sobre cómo hacerlo. “Más o menos”, “tal vez” o “creo que sí” indican nivel medio;
mientras que “no” indica nivel bajo.
En el eje Y, la idea es verificar la claridad de lo que es la funcionalidad, sea del
punto de vista del negocio o de quien va usarlo. ¿Sabes lo que el negocio y/o
usuario quiere(n) de ese ítem de trabajo? La respuesta “sí” indica alto nivel de
confianza sobre qué hacer. “Más o menos”, “tal vez” o “creo que sí” indican nivel
medio; mientras que “no” indica nivel bajo.
Al final de la actividad, las funcionalidades en tarjetas rojas con una X
representan riesgos altísimos para el proyecto. Normalmente, el equipo las divide
en bloques de trabajo más pequeños o las descarta. Evítalas a toda costa. Intenta
aclararlas antes de comenzar a trabajar. Solamente continúa con funcionalidades
que estén en tarjetas verdes o amarillas.
TABLA DE ESFUERZO, EXPERIENCIA DE USUARIO (UX) Y VALOR DE NEGOCIO
Esta actividad tiene el objetivo de discutir cómo el equipo entiende el esfuerzo
para completar una funcionalidad, así como también el valor de negocio y la
experiencia de usuario asociada a cada funcionalidad. A partir de esta actividad,
nuevas marcas son agregadas a cada funcionalidad.

El paso a paso de la actividad

1.Crea una tabla que muestre una escala de uno a tres para el esfuerzo técnico (o
nivel de trabajo que se necesita efectuar), el valor de experiencia de usuario
(cuánto irán a amarlo los usuarios) y el valor de negocio (cuál es el retorno o
ahorro que va a significar).
2.Pide a un miembro del equipo leer una funcionalidad en voz alta y colocarla en
cada fila de la tabla de acuerdo con su comprensión de ella (esfuerzo, valor para
el negocio y valor de UX), respondiendo la siguiente pregunta para cada fila de la
tabla:
» ¿Cuánto trabajo (esfuerzo) necesitamos para crear esta funcionalidad? Marca
con una E, EE o EEE, para indicar, respectivamente, un esfuerzo bajo, medio o
alto.
» ¿Cuánto valor para el negocio vamos a generar con esta funcionalidad? Marca
con el signo $, $$ o $$$, para indicar un valor alto, muy alto o altísimo,
respectivamente.
» ¿Cuánto amarán los usuarios esta funcionalidad? Marca con uno, dos o tres
corazones, para indicar una baja, media o alta aprobación, respectivamente.
3.Pregunta al equipo si todos comparten esta opinión. Si alguien no está de
acuerdo, el equipo debe discutir los requisitos y la tecnología involucrados de
forma que haya un consenso sobre la funcionalidad. Todo lo que sea
mencionado y que ayude a alcanzar una mejor comprensión debe ser anotado y
anexado a la funcionalidad.
 Anota en la funcionalidad el nivel de esfuerzo, experiencia de usuario y valor de
4.
negocio.
5.Para cada funcionalidad identificada anteriormente, repetir los pasos 2 al 4.

ESCALA DE VALOR DE NEGOCIO

Las marcas $, $$ y $$$ indican, respectivamente, valor de negocio alto, muy alto
y altísimo. Cuando comencé a usar esta gráfica de valor de negocio, estas
marcas eran utilizadas para indicar valor de negocio bajo, medio o alto. Sin
embargo, raramente una persona de negocio respondía que una funcionalidad
tenía un valor de negocio bajo (o medio). El cambio en la escala ayudó para que
el resultado representase el valor de negocio comparativo entre las diferentes
funcionalidades.

MOSTRANDO LOS VIAJES DE USUARIO

El viaje de usuario (o user journey, en inglés) describe el camino recorrido por un
usuario a través de una secuencia de pasos necesarios para alcanzar un objetivo.
Algunos de estos pasos representan diferentes puntos de contacto con el
producto, demostrando cómo el usuario interactúa con él. A medida que
construimos el viaje, el equipo plantea preguntas y opiniones alternativas acerca
de los deseos del usuario y de las capacidades del producto.

El paso a paso de la actividad

1.Selecciona una persona.
2.Identifica el objetivo de esa persona.
3.Escribe la persona y su objetivo en un post-it y colócalo en la parte superior
izquierda de un papelógrafo (para que pueda moverse posteriormente).
4.Decide el punto de inicio (preguntas útiles: ¿cómo comienza la persona su día?,
¿qué gatilló su deseo de alcanzar su objetivo?). Escribe el punto de partida en un
post-it y sitúalo en el papelógrafo.
5.Describe cada paso posterior en un post-it y ponlo a continuación (de manera
sucesiva) en el papelógrafo. Continúa agregando pasos hasta que la persona
alcanza su objetivo.

Preguntas, acuerdos y desacuerdos serán los protagonistas en la discusión sobre

la construcción del viaje. Quizás puede surgir más de una opción de viaje. Por
ejemplo, el viaje optimista, el realista, el pesimista, el principal, el caso
excepcional 1, el caso excepcional 2, etc. Las opciones forzarán la priorización y la
definición clara del objetivo y, con esto, el foco será más claro en algunos viajes.
Los viajes priorizados complementarán y ayudarán en la búsqueda del producto
mínimo viable (MVP).
El nivel de detalle de un viaje no debe ser muy alto, ni muy bajo. Al mismo
tiempo que un viaje proporciona un paso a paso de la interacción del usuario,
debe ser una síntesis, un nivel más elevado y simplificado del flujo, sin
información redundante ni los detalles más profundos.
A continuación, se puede ver un ejemplo de un viaje de usuario. Pon atención al
dibujo de la persona al lado de un coche que se encuentra en la esquina superior
izquierda de la hoja, y su viaje descrito con post-it de izquierda a derecha y de
arriba abajo. En el viaje en cuestión, cada post-it representa un paso en el camino
de la persona para alcanzar su objetivo (descrito en el último post-it). Pequeñas
flechas conectan un paso al siguiente.
 Preguntas simples nos ayudan con el inicio de la descripción de los viajes.
Algunos ejemplos:
 ¿Cuál es el objetivo que la persona quiere alcanzar? ¿Cómo él/ella
comienza su día? ¿Qué hace antes de eso? ¿Qué hace después de
eso?

Una conversación, un post-it y un bolígrafo. Eso es lo que necesitas para describir

los viajes de usuario. Te sugiero escribir y reescribir. Lo importante es que
comiences: no te detengas esperando una revelación que no vendrá. Después de
tener algo descrito puedes cambiarlo. Si hace sentido, combina algunos pasos
muy detallados en uno solo o divide un paso poco detallado en pasos más
pequeños. No hay una fórmula mágica para esto. Lo importante es que los viajes
sean descritos.
Aquí hay un ejemplo de un viaje de usuario.

FANÁTICO DEL FÚTBOL: INVITA AMIGOS A UN PARTIDO

» Se despierta temprano para ir al trabajo.
» Toma un gran desayuno.
» Llega al trabajo a las 9:00 a.m.
» Durante una reunión decide realizar alguna actividad física.
» En el almuerzo convence a un amigo del trabajo para jugar al fútbol después
del trabajo.
» Llama y reserva una cancha
» Abre la aplicación móvil Easy-ball.
» Registra el partido a las 8:00 p.m. de ese mismo día
» Coloca la información de la cancha
» Envía la invitación a los amigos.

EXHIBIENDO LAS FUNCIONALIDADES EN LOS VIAJES

Los viajes aclaran cómo será la interacción con el producto. Si seguiste el orden
sugerido en este libro, los viajes deben estar descritos (como una secuencia de
pasos) y las funcionalidades deben estar disponibles (en tarjetas de colores). Esta
actividad describe cómo juntarlos, revaluando y verificando todo el análisis hasta
este momento.

El paso a paso de la actividad

1.Coloca los viajes principales y las funcionalidades visibles, si es posible, lado a
lado, conforme se muestra en la foto a continuación.
2.Siguiendo el viaje, busca las funcionalidades necesarias para cada paso. La
secuencia de abajo muestra un ejemplo de cómo las funcionalidades son
mapeadas en el viaje.
3.Luego de que una persona lee el paso a paso del viaje, las personas del grupo de
funcionalidades verifican si hay alguna funcionalidad que sirva o mejore el viaje
del usuario.
4.Cuando se identifica una “combinación” (de una funcionalidad en un viaje), pon
un identificador a la funcionalidad, anótalo en un post-it pequeño y colócalo en
el paso del viaje al que corresponda.
5.Repite los pasos anteriores para todas los viajes.

En el momento en que la persona que esté leyendo el viaje sea interrumpida por
su colega diciendo, “¡Tienes una funcionalidad en este paso!”, ambos, el viaje y la
funcionalidad, deben ser marcados indicando ese match.
Si el viaje no tuviese un identificador, entonces asígnale un identificador, como
por ejemplo “V1”. Haz lo mismo para la funcionalidad. Anota el identificador del
viaje en la tarjeta de la funcionalidad, y el identificador de la funcionalidad en el
respectivo paso del viaje. De esta forma todas los viajes y las funcionalidades
tendrán marcas indicando sus asociaciones.
 La siguiente imagen muestra otro ejemplo de mapeo de funcionalidades para un
viaje. En el momento de la foto, una persona estaba leyendo el viaje de usuario,
mientras que otras tres personas estaban buscando funcionalidades necesarias
para ese viaje.

Es importante notar que en la foto el viaje está sobre la mesa y las

funcionalidades en la pared. La foto muestra el momento exacto en que una de las
personas sentadas apunta y dice: “Ahí tienes una funcionalidad para este paso”. En
la secuencia, el identificador de la funcionalidad fue anotado en el paso del viaje y
el identificador del viaje fue anotado en la tarjeta de la funcionalidad.
Al final de esta actividad, dos cosas deberían ocurrir: (1) pueden haber sido
identificadas algunas funcionalidades faltantes, y (2) algunas funcionalidades no
fueron mapeadas en ningún viaje.
En el escenario (1) se debe crear la tarjeta de la funcionalidad faltante con los
colores y las marcas identificando incertidumbre, esfuerzo y valor de negocio. En
el escenario (2) aquellas funcionalidades deben ser aclaradas (y documentadas),
pero el equipo no debe seguir con ellas, manteniendo el foco en los ítems
prioritarios por viaje.

SECUENCIANDO LAS FUNCIONALIDADES

“¿Esta funcionalidad es importante?”. Siempre he obtenido la misma respuesta
cuando hago esta pregunta y, por lo tanto, ya no la hago.
La pregunta más relevante para ayudar a planificar el orden en que deben
crearse las funcionalidades es la siguiente: “¿Cuál de estas dos funcionalidades es
la más prioritaria?”. De esta manera las funcionalidades son priorizadas en
relación unas a otras. Esta pregunta es muy útil y debe ser utilizada, pero necesita
de un punto de partida.
Previamente, identificaste a la persona más importante, así como también el
viaje de usuario más prioritario. Este sí es el mejor punto de partida: la primera
funcionalidad de este viaje.
Tal vez encontremos más de una funcionalidad en el viaje o en los viajes que
pueden crearse de forma simultánea. Ante este escenario se debe preguntar cuál
de las dos funcionalidades en cuestión es la de más alta prioridad.
 Felizmente, en las etapas anteriores algunos parámetros ya fueron agregados a
las funcionalidades, como, por ejemplo, el valor de negocio ($, $$ o $$$), esfuerzo
(E, EE o EEE), experiencia de usuario y la identificación del nivel de certeza (tarjeta
de color verde, amarillo y rojo). Estos parámetros nos van a ayudar con la
planificación de las funcionalidades y sus prioridades.

Entonces, ¿cuál es la combinación mínima de funcionalidades que

deben estar disponibles para validar un pequeño conjunto de
hipótesis sobre el negocio?

Ahora es hora de visualizar y conceptualizar el primer MVP y sus incrementos

subsiguientes.

EL SECUENCIADOR DE FUNCIONALIDADES
El propósito del producto mínimo viable (MVP) es crear algo que pueda ser usado
para validar un conjunto pequeño de supuestos acerca del producto y su rol en el
negocio. Ahora que tienes un mapa de las funcionalidades ya integradas en los
viajes de usuario, estás en posición de trabajar tu primer MVP y sus siguientes
iteraciones. Aquello se logra a través de la definición del “secuenciador de
funcionalidades”.
 Nuestro objetivo con un producto mínimo viable es aprender de
cada iteración a través de la construcción de un MVP que nos
permitirá probar si nuestro caso de negocios es efectivo.

EL TEMPLATE DEL SECUENCIADOR

Se debe planificar una secuencia de ondas para agrupar las funcionalidades de tal
manera que sea útil para organizar el orden de producción, algo fácil de entender.
Una onda después de otra, en secuencia. Dibuja en un papelógrafo o en una
pizarra blanca una plantilla con las ondas: el “secuenciador de funcionalidades”.
SECUENCIADOR

La intención es ejecutar lo más pronto posible, en las primeras ondas, aquello

que es más impactante. Y seguir trabajando en las funcionalidades del
secuenciador de onda en onda.

LAS REGLAS PARA CADA ONDA

Las funcionalidades serán agregadas a cada onda. A continuación, las seis reglas
para añadir funcionalidades en las ondas. Estas reglas fueron definidas después de
aplicar un sinnúmero de veces esta forma de planificación y priorización.

» Regla 1: una onda puede contener un máximo de tres funcionalidades.

» Regla 2: una onda no puede contener más de una funcionalidad roja.
» Regla 3: una onda no puede contener tres funcionalidades amarillas o rojas.
 Regla 4: la suma del esfuerzo de las funcionalidades no puede sobrepasar las
» cinco “E”.
» Regla 5: la suma del valor de las funcionalidades no puede ser menor a cuatro
“$” y cuatro corazones.
» Regla 6: si una funcionalidad depende de otra, esa otra debe estar en una onda
anterior.

La regla 1 limita el número de funcionalidades que están siendo trabajadas al

mismo tiempo. Eso evita la acumulación de funcionalidades parcialmente
completadas, aumentando el enfoque en pocas funcionalidades priorizadas por
onda. Las reglas 2, 3 y 4 evitan un período de trabajo desequilibrado con mucha
incertidumbre o mucho esfuerzo. La regla 5 garantiza el enfoque constante en la
entrega de alto valor para el negocio y para los usuarios. La regla 6 evita problemas
de dependencia entre las funcionalidades.

El paso a paso de la actividad

1.Crea la plantilla del secuenciador (generalmente un papelógrafo con filas
numeradas. El alto de la fila debe ser tal que quepa una tarjeta de funcionalidad,
en el ancho de la fila deben caber tres tarjetas de funcionalidades).
2.Explica las reglas del secuenciador.
3.Recuerda a todos el objetivo de la actividad: definir la secuencia en la cual
entregaremos las funcionalidades del producto.
4.Todos colocan las funcionalidades en el secuenciador, moviéndolas para
explorar las diferentes opciones, hasta que alcancemos un acuerdo.
5.El resultado muestra las funcionalidades para cada iteración del MVP.

CONVERGIENDO REGLAS Y VIAJES

Las reglas simples son agregadas a la plantilla del secuenciador de
funcionalidades. Basta con buscar la primera funcionalidad del primer viaje, luego
se debe buscar la próxima. Respetando las reglas, se decide si tal funcionalidad
entra en la onda “n” o en la “n+1”.
Si tienes dudas entre dos funcionalidades que respetan las reglas, basta
responder a la pregunta: “¿Cuál de estas dos funcionalidades es más prioritaria?”.
Abajo hay una imagen para ejemplificar la forma de colocar la funcionalidad en
el secuenciador de funcionalidades, respetando las reglas.

¿DUPLICAR O UTILIZAR EL MISMO POST-IT/TARJETA?

 Una funcionalidad con sus marcaciones está ubicada en una plantilla (por
ejemplo, en un viaje). Debes estar atento a buscar la tarjeta y colocarla en otra
plantilla: en el secuenciador de funcionalidades. Además de la información
descrita en la tarjeta, su posición en la plantilla contiene más información. Tal
es el caso de la funcionalidad con el viaje y en el secuenciador de
funcionalidades. A estas alturas, te preguntarás: ¿duplico o utilizo la misma
tarjeta? Mi sugerencia es que tomes una foto antes de hacer cualquier cosa.
Considera duplicar la tarjeta siempre que esto no vuelva más lenta la actividad
o más confuso el ambiente (por un sinnúmero de papeles de colores).

Generalmente, todo el equipo estará bastante ocupado decidiendo el orden de

las funcionalidades en el secuenciador. En este momento, todos debieran estar
bien alineados en relación a los principales viajes y sus funcionalidades (con sus
marcas de nivel de confianza, valor de negocio, valor de UX y esfuerzo). Es común
que todos se queden en torno al secuenciador (en la pared o en una mesa)
conversando y explorando posibles opciones, hasta alinear y decidir el orden de
creación y liberación de las funcionalidades.

IDENTIFICANDO LOS MVP EN EL SECUENCIADOR DE FUNCIONALIDADES

Ha llegado el momento de entender los incrementos y la creación evolutiva de tu
producto. Hasta ahora, las actividades han aclarado y priorizado cada aspecto del
producto.
Los pequeños bloques del mismo —las funcionalidades— están ahora
ordenadas lógicamente en el secuenciador de funcionalidades. Por lo demás, las
entiendes y las visualizas para los viajes de usuario. Será navegando por la
plantilla del secuenciador de funcionalidades con sus ondas y funcionalidades,
que vas a identificar los incrementos del producto mínimo viable (MVP).
 Cada vez que la combinación de funcionalidades alcanza una versión simple del
producto que puede hacerse disponible, nombra esa combinación. Por ejemplo:
“MVP1”, “MVP2”, “MVP3”. Abajo se presentan dos ejemplos de los resultados
después de este paso de identificación de los MVP (en post-its naranja) en el
secuenciador de funcionalidades.

A continuación, un ejemplo ilustrativo de un secuenciador de funcionalidades.

En ella tenemos dos MVP y trece funcionalidades. El MVP1 está compuesto por las
funcionalidades F1 hasta la F5. El MVP2 está compuesto por las funcionalidades F6
hasta la F13.
 ¿Por qué MVP2? Como ya sabes, el MVP es el producto mínimo viable, pero
después de él tenemos incrementos del producto. Independientemente de llamar
al próximo incremento “MVP2” o algún otro nombre, lo más importante es seguir
creando el producto a partir de la validación de la hipótesis.

CALCULANDO ESFUERZO, TIEMPO Y COSTO

La mayoría de las empresas que conozco siempre están muy interesadas en
encontrar la respuesta a dos preguntas simples y directas: ¿qué estás
construyendo? y ¿cuándo estará listo?
El secuenciador de funcionalidades responde la primera pregunta (¿qué estamos
construyendo?), ya que presenta el primer MVP y las siguientes iteraciones. Es
realmente un artefacto increíble generado en la Lean Inception. Muchos
stakeholders estarán realmente satisfechos en el momento en que les respondas
esta pregunta tan importante.
Sin embargo, “¿cuándo estará listo?”, algunos preguntarán. ¿Cuándo estará listo
el MVP? ¿Y el siguiente? ¿Y todas las funcionalidades que están en el secuenciador
de funcionalidades?
Si este no es tu caso, tienes mucha suerte y puedes obviar este capítulo; pero si lo
es, puede interesarte seguir leyendo, ya que comparto cómo he ayudado a
muchos equipos a responder esta pregunta.
 La secuencia de actividades hasta este momento, así como las reglas del
secuenciador de funcionalidades, generan ondas de tamaño similar. Esto
simplifica la estimación del producto con sus MVP, ya que nos permite utilizar un
tamaño promedio de onda basado en un muestreo más pequeño. En lugar de
detallar cada onda con sus funcionalidades en relación al esfuerzo, tiempo y costo,
solamente se seleccionarán unas pocas ondas. A continuación, se detallan las
funcionalidades, se efectúa la suma de los números y se calcula el promedio para
cada onda.

DETALLANDO LAS FUNCIONALIDADES DE MUESTRA EN TAREAS

El tamaño de las ondas es similar. Escoge dos o tres ondas y utilízalas para generar
información detallada de esfuerzo, tiempo y costo. Dos o tres ondas son
suficientes para tener una buena idea de los parámetros y generar una media
efectiva.

El paso a paso de la actividad

1.Escoge dos o tres ondas a ser detalladas.
2.Selecciona una funcionalidad de una de las ondas de muestra.
3.Describe, en otras tarjetas, las tareas (o piezas) más pequeñas para la
funcionalidad seleccionada.
4.Vuelve al paso 2 y selecciona otra funcionalidad hasta que hayas detallado todas
las funcionalidades de las ondas de muestra.

Al seleccionar las ondas de muestra (paso 1), recuerda que en este momento
estás interesado en la estimación de la totalidad y el tamaño promedio de una
onda, y no en el detalle del trabajo en sí. Por lo tanto, las ondas a ser elegidas
deben proporcionar una buena combinación del nivel de riesgo (marcado por el
color de las tarjetas), así como una buena variación en la suma de los niveles de
esfuerzo (marcado con “E” en las funcionalidades).
 La pieza más pequeña (paso 3) debe ser algo que tenga sentido para cada
equipo. Los equipos de desarrollo de software que siguen la metodología Scrum
utilizan a menudo las historias de usuario como aquellas piezas más pequeñas.
Otros equipos prefieren llamar a las piezas más pequeñas “tareas” y describirlas sin
un formato predefinido.
En el resto de este capítulo, llamaré a las piezas más pequeñas de una
funcionalidad “tareas”. Generalmente recomiendo a los equipos ser muy
específicos a la hora de crear estas tarjetas de tareas, ya que esto ayudará a la
actividad. Sin embargo, no hay que preocuparse de documentarlas
perfectamente, ya que esto debiera realizarse posteriormente y no durante la lean
inception.
Durante el paso 3, haz una marca de identificación tanto en las tarjetas de
funcionalidad, como en las tarjetas de tarea. Por ejemplo, marca con F1 a todas las
tareas de la funcionalidad 1, F2 a las tareas de la funcionalidad 2, y así
sucesivamente. Esto se hace para evitar confusiones y la mezcla de
funcionalidades requeridas con sus tareas.

Al final de esta actividad, las funcionalidades seleccionadas como muestra serán

detalladas con sus diversas tareas.
ESTIMACIÓN COMPARATIVA
La siguiente actividad es muy simple, pero es esencial para entender el esfuerzo
relativo de las tareas.

El paso a paso de la actividad

1.Escribe las siguientes tallas de camisetas en post-its: pequeña, mediana y grande.
2.Coloca los post-it en un papelógrafo, una pared, una pizarra, una mesa o en el
suelo, dejando la talla “pequeña” en la esquina superior izquierda y la talla
“grande” en la esquina inferior izquierda.
3.Selecciona dos tareas y luego haz la siguiente pregunta: ¿cómo se compara esta
tarea (en cuanto a esfuerzo) con esta otra? ¿Ambas pequeñas? ¿Una pequeña la
otra mediana? ¿Grande?
4.Coloca ambas tareas en el papelógrafo, con sus relativas posiciones indicando
cómo se comparan en cuanto al nivel de esfuerzo (pequeño, medio o grande).
Coloca una al lado de la otra, si ambas requieren el mismo nivel de esfuerzo; o
bien pon una debajo de la otra, indicando que una requiere más esfuerzo que la
otra.
5.Define los límites entre tallas y vuelve a posicionar las tareas para dejar claras sus
tallas. En caso de ser necesario, considera crear una talla de camiseta extra como,
por ejemplo, extra pequeña (XS) o extra grande (XL).
6.Mientras haya tareas por ser comparadas, colócalas en la pizarra de acuerdo al
nivel de esfuerzo y repite los pasos 3 y 4.
 Al final de esta actividad, todas las tareas estarán asociadas a una talla de
camiseta: pequeña, mediana o grande.
Las dos actividades anteriores (“detallando las funcionalidades de muestra en
tareas y “estimación comparativa”) pueden ser hechas al mismo tiempo, tal como
se presenta en la siguiente imagen.
 En ella, las tareas (en tarjetas blancas) son colocadas debajo de su respectiva
funcionalidad de muestra, y cerca de tareas de tamaño similar (post-it rojos con
marcas S, M o L, respectivamente para pequeña, mediana o grande).

ENTENDIENDO EL COSTO Y EL TIEMPO

Esta actividad es esencial para generar números para calcular los costos y el
tiempo para cada onda, así como para todo el secuenciador de funcionalidades.
Luego de esto, podrás responder la pregunta: ¿cuándo estará listo?

El paso a paso de la actividad

1.Selecciona una tarea pequeña y pregunta cuánto tiempo le toma a una persona
completarla.
2.Escoge dos o tres tareas más del mismo tamaño y repite la pregunta.
3.Calcula el tiempo promedio y anótalo.
4.Repite los pasos anteriores para tareas de diferentes tamaños.

Al final de esta actividad, todas las tareas tendrán una estimación de tiempo y
costo. Por ejemplo, se obtuvieron los siguientes resultados durante esta actividad:
medio día para tareas pequeñas, dos días para tareas medianas, cuatro días para
las tareas grandes y ocho días para las tareas extra grandes.
Las respuestas sobre el tiempo influirán en el resultado final. Por ello, sé enfático
en relación a esta pregunta. Si es posible, pide comparaciones con trabajos
anteriores, y trata de entender la motivación y la capacidad de las personas que
responden a esta pregunta.
A los desarrolladores no les gusta responder a la pregunta “¿cuánto tiempo es
necesario para completar dicha tarea?”. Por esto es muy importante que todo el
mundo se sienta cómodo con la descripción de la tarea. Si hay algún malestar en
relación a una de ellas, deberán reescribirla y considerar dividirla en bloques más
pequeños.
Otra forma de hacer esta pregunta es formularla en plural:

Consideremos un par de desarrolladores. Uno conoce más acerca

del negocio y el otro conoce menos. Uno es mayor, el otro es más
joven. Uno tiene más experiencia en la tecnología en cuestión, el
otro es un principiante. ¿Cuánto tiempo se demoran el par de
desarrolladores en completar dicha tarea?

En mi experiencia, las personas se sienten más cómodas dando este tipo de

respuestas, cuando se considera el desarrollo en parejas que trabajan juntas para
completar una tarea.

CALCULANDO EL PROMEDIO DE UNA ONDA

A partir del entendimiento del esfuerzo en la actividad anterior, le agregamos el
tiempo estimado para cada tarea de cada funcionalidad. Luego, le sumamos la
duración estimada por funcionalidad en cada fila de la plantilla del secuenciador.
Por lo tanto, llegamos a un esfuerzo promedio para cada onda, definido por
persona y por unidad de tiempo.
La ilustración a seguir muestra cómo se llevó a cabo el cálculo por parte de un
equipo. Las imágenes muestran, respectivamente, las ondas elegidas como
muestra y el cálculo realizado para obtener el tiempo promedio estimado por
onda.
 Esta foto muestra los cálculos realizados para obtener el promedio de tiempo
estimado por onda. Cada tarea se estimó en días por pareja de desarrolladores. En
la foto, cada línea muestra la suma del tiempo estimado para las tareas de una
funcionalidad. La medida de tiempo estimado para cada tarea fue: 1/4 de día
(pequeño), 1/2 día (medio), dos días (grande) o cinco días (extra grande).
Realizando la sumatoria de las tareas por funcionalidades y luego por onda, el
equipo alcanzó valores de 11 días, 11 ½ días y 9 días, respectivamente, para las
ondas 2, 3 y 4. Por lo tanto, el promedio que se utilizó para este equipo fue de diez
días por pareja de desarrolladores por onda.
A continuación, se muestran los resultados de otro equipo:
 La imagen muestra el resultado de una lean inception para dos ondas de muestra:
nueve semanas y catorce semanas. Después de verificar este resultado, el principal
stakeholder dijo: “Entonces, cada onda toma aproximadamente doce semanas de
un desarrollador. Si tenemos seis desarrolladores en este equipo, pareciera que
podemos entregar una onda cada dos semanas (doce semanas de desarrollo
efectuada por seis desarrolladores), o una onda por sprint14, de acuerdo a su
terminología de Scrum”. Luego agregó: “Ya que nuestro MVP está completo en la
onda cinco… creo que tendré que ajustar un poco la planificación”.

CONSTRUYENDO EL CANVAS MVP

Por fin alcanzamos la cumbre de Lean Inception: el canvas MVP. En él, vamos a
detallar el producto mínimo viable (MVP) y sus funcionalidades respecto a las
perspectivas de Design Thinking y Lean Startup.
El canvas MVP fue concebido como una actividad Lean Inception, y es la última
actividad del taller de Lean Inception. Sin embargo, se puede usar de forma
separada, independiente de la secuencia de Lean Inception.
Sin embargo, quisiera enfatizar que es muy importante alinear a los
participantes sobre la visión del producto, los objetivos, las personas, las
funcionalidades, los viajes y la secuencia de funcionalidades que abarca cada
MVP, pues esto ayuda a completar el canvas MVP.
Una hora. Este es el tiempo aproximado para completar el canvas MVP si se han
seguido las actividades de Lean Inception como se describió en los capítulos
anteriores. Una hora trabajando en el canvas MVP proporcionará un buen nivel de
detalle y mucha discusión para cada cuadrante del canvas.
Por otro lado, un equipo que no haya seguido paso a paso la lean inception
necesitará más tiempo y mucha más conversación para crear un MVP Canvas.

COMPLETANDO EL CANVAS MVP

Teniendo en cuenta que el equipo ya ha discutido qué es lo que compone el MVP y
ya ha conversado sobre lo que esperan de él, ahora es el momento de poner todo
en papel. Mejor aún, define el pensamiento esencial acerca del MVP en una sola
hoja de papel: el canvas MVP.

El paso a paso de la actividad

1.Imprime el canvas MVP15 o dibújalo en papelógrafo.
2.Elige el MVP que va a ser elaborado.
3.Completa cada una de las siete secciones del canvas MVP.

El MVP Canvas está dividido en siete secciones. Las preguntas a responder en

cada una de ellas:
1.Propuesta o visión del MVP – ¿Cuál es la propuesta de este MVP?
2.Segmentos de personas – ¿Para quién es este MVP? ¿En qué plataforma estará
disponible?
3.Viajes de usuario – ¿Qué viajes se mejorarán con este MVP?
 Funcionalidades – ¿Qué estamos construyendo en este MVP? ¿Qué acciones se
4.
van a simplificar o mejorar en este MVP?
5.Resultado esperado – ¿Qué aprendizaje o resultado buscamos en este MVP?
6.Métricas para la validación de hipótesis de negocio – ¿Cómo podemos medir
los resultados de este MVP?
7.Costo y cronograma – ¿Cuál es el costo esperado y la fecha de entrega y
validación de este MVP? ¿Hay alguna restricción de tiempo?

EL SECUENCIADOR DE FUNCIONALIDADES Y EL CANVAS MVP

El secuenciador de funcionalidades ayuda en la organización y visualización de
funcionalidades. Este organiza y planifica la entrega del producto más allá del
primer MVP, representando claramente la secuencia de liberación de las
funcionalidades del producto.
Además de mostrar las tarjetas de funcionalidades ordenadas, el secuenciador
muestra claramente la agrupación de funcionalidades para cada MVP. Esto es
representado en los post-its del secuenciador, delimitando el MVP1, el MVP2 y así
sucesivamente.
Si utilizaste el secuenciador de funcionalidades y marcaste uno, dos o tres MVP,
te sugiero que imprimas tres canvas MVP y completes uno por cada MVP
identificado en el secuenciador. Sin embargo, si utilizaste el secuenciador y hay
demasiados MVP, también sugiero que imprimas tres plantillas y solamente
completes los primeros tres MVP.
La realidad es que estamos trabajando con los MVP y no queremos
extralimitarnos. Tal vez el secuenciador de funciones tiene demasiadas
funcionalidades y, al ordenarlas y agruparlas, pueden aparecer algunos MVP. Esto
sucede porque, en general, los participantes de una lean inception primero piensan
de una manera más amplia, para luego tratar de determinar la secuencia de los
entregables mínimos y viables. El secuenciador de funcionalidades demuestra
claramente el pensamiento colectivo sobre la evolución del producto a través de
los MVP.
Pero el secuenciador es solo un mapeo, un plan que creamos de acuerdo con el
entendimiento actual. Y esta secuencia se crea suponiendo que los primeros MVP
logran lo que esperamos de ellos. Sin embargo, no te dejes engañar. El
aprendizaje del MVP1 y posteriormente del MVP2 portará algunas nuevas
explicaciones. El equipo tendrá que volver a pensar el producto y los próximos
MVP con sus funcionalidades.
Construir un canvas MVP y ponerlo en el armario sería un desperdicio. Construye
uno o dos, pero no más de tres.
La imagen del ejemplo es real: ese equipo construyó solo un canvas MVP para el
primer MVP. Sigue el ejemplo de ellos. Solo construye un nuevo canvas MVP
cuando estés cerca de trabajar en aquel MVP, teniendo en cuenta los
conocimientos adquiridos hasta el momento.
 Canvas MVP al lado del secuenciador de funcionalidades

FOCO EN LA PROPUESTA
Cuanto más focalizado esté el MVP, mejor. Este debe validar una necesidad para
un segmento de personas y una hipótesis de negocio, y estas generalmente están
relacionadas. En algunos contextos, sin embargo, el MVP es más amplio. Sea cual
sea el escenario, sé claro sobre la propuesta del MVP.

Pregúntate hasta tener certeza: ¿cuál es la propuesta de este MVP?

Un ejemplo de propuesta de MVP: validar si los residentes del barrio Madureira

llamarían taxis a través del sitio web. Esta propuesta es muy similar a la historia
de EasyTaxi en 2011: “la aplicación comenzó con un MVP ‘conserje’. El equipo de
fundadores dejó a disposición una página en internet para que los usuarios
ingresaran manualmente la dirección en la que estaban, y cuando daban un
clic en el botón ‘llamar mi taxi’ se generaba un e-mail para los socios. Ellos,
cuando recibían el mensaje, llamaban a sus cooperativas pidiendo un taxi para
esa dirección. ¡Bingo! Con esto, ¡todo comenzó! Los fundadores habían
validado una hipótesis básica: muchas personas estaban dispuestas a usar un
servicio que llamara taxis por ellas”.

MINIMIZA LOS RIESGOS CON LA SEGMENTACIÓN DE PERSONAS

Los participantes de la lean inception ya pensaron en el MVP y sus funcionalidades.
También realizaron la actividad sobre personas y, probablemente, hicieron
consideraciones sobre ellas para decidir sobre el MVP.
 Sin embargo, a medida que van completando la sección de personas y
plataformas en el canvas MVP, estarán demostrando sus decisiones de inmediato.
Al llenar el canvas MVP, la pregunta sobre las personas es diferente de la reflexión
sobre las personas en el comienzo de la inception. Ya no estamos hablando de las
personas del producto como un todo, estamos siendo más específicos.

¿Para quién es este MVP específico? ¿En qué plataforma estará

disponible?

Al responder estas preguntas, el grupo debe deliberar sobre el lanzamiento de

MVP y cómo minimizar sus riesgos. Por ejemplo, el grupo puede decidir que un
MVP estará restringido a un grupo de personas más pequeño y que el mismo
conjunto de funcionalidades solo se lanzará para un grupo más grande después
de verificar el resultado esperado. La misma lógica se aplica a la plataforma. Por
ejemplo, el grupo puede decidir que un MVP se restringe a una plataforma móvil
específica y que el mismo conjunto de funcionalidades solo se lanzará a otra
plataforma después de verificar el resultado esperado.

MEJORA LA EXPERIENCIA EN LOS VIAJES

Si el grupo siguió las actividades de Lean Inception, los viajes debieran estar
visibles. En ellos se puede ver el paso a paso del segmento de persona hasta
alcanzar sus objetivos. E incluso si el grupo no tiene los viajes visibles, la siguiente
pregunta debe ser respondida en el bloque viajes:
 ¿Cuáles viajes serán cumplidos o mejorados con este MVP?

El viaje mapea la experiencia que entregas a tus usuarios. La respuesta a esta

pregunta presenta, claramente, qué es lo que tu producto está proveyendo en el
MVP.
Durante el proceso de completar el canvas MVP, la conversación sobre los viajes
debe estar más focalizada de lo que estuvo en la actividad “Mostrando los viajes de
usuario” de Lean Inception. En esta instancia, solamente se reevalúan y anotan los
viajes de las personas segmentadas que han sido cumplidos o mejorados en el
MVP.
Si tuvieses dificultad en describir al menos un viaje, reevalúalo, pues quizás tu
MVP realmente no contempla nada para nadie (es menos que el mínimo viable).
Si describes muchos, también reevalúa, pues quizás tu MVP es demasiado amplio
(recuerda que la “M” de MVP significa mínimo, no máximo). No debes cumplir
todos los viajes. Aquellos se irán cumpliendo a medida que el producto
evolucione.

REEVALÚA LAS FUNCIONALIDADES DEL MVP

El secuenciador presenta la lista de funcionalidades para el MVP, comienza por
ahí. A continuación, verifica los bloques que ya fueron completados: propuesta del
MVP, segmentos de personas y viajes. Reevalúa la lista y haz las siguientes
preguntas sobre las funcionalidades:
» ¿Son realmente el mínimo?
» ¿Van a conseguir un producto viable?
 » ¿Podríamos crear algo aún más simple?
» ¿Olvidamos de incluir algo esencial para el MVP?
Conversa, haz los ajustes y las alteraciones necesarias. Al final, relee todo el
bloque de funcionalidades y verifica si las siguientes preguntas están siendo
respondidas:

¿Qué vamos a construir en este MVP? ¿Qué acciones serán

simplificadas o mejoradas en este MVP?

DESARROLLO IMPULSADO POR HIPÓTESIS

Lo que queremos es un diseño centrado en el usuario. Para crear el MVP,
debemos considerar a los usuarios y sus viajes. Deberíamos trabajar en las
acciones que mejoran o simplifican sus vidas. Pero eso no es todo. También
debemos describir las hipótesis del negocio para entender si estamos realmente
avanzando, si realmente estamos alcanzando los resultados deseados o
aprendiendo.
Luego de definir las funcionalidades del MVP, debemos relacionarlas con los
resultados esperados y las hipótesis de negocio. El siguiente modelo ayuda con
dicha declaración:
 Este modelo es una adaptación del modelo de Jeff Gothelf de desarrollo
orientado a la hipótesis. El equipo debe completar este modelo, porque si no lo
hace no se sabrá qué esperar del MVP o no se sabrá cómo medirlo. En ambos
escenarios, el producto está a la deriva, sin dirección.
Este poderoso modelo para decisiones basadas en hipótesis se incluye en el
canvas MVP, en las secciones resultado esperado y métricas para validar las
hipótesis de negocio.

¿Qué aprendizaje o resultado estamos buscando en este MVP?

¿Cómo podemos medir esto? Importante: no crees funcionalidades
para un producto si no sabes describir lo que esperas como
resultado ni cómo medirlo.

Es importante resaltar que el aprendizaje también es un resultado. Pero, para

aprender debemos, al menos, declarar esto: el resultado esperado es aprender.
Luego intentamos recolectar datos para alcanzar el aprendizaje deseado.

CONVERSA SOBRE EL COSTO Y EL CRONOGRAMA

Inevitablemente, luego de responder “¿cuál es el MVP?” (pregunta que estará muy
bien respondida en los seis primeros bloques del canvas MVP), nos preguntaremos
“¿cuándo?” y “¿cuánto?”.

¿Cuál es el costo y el cronograma para este MVP?

En el canvas MVP, esta pregunta es dejada a propósito para el final, ya que debe
ser respondida después de que los otros bloques sean completados.
Es importante que todos participen de este momento, conversen y respondan
esta pregunta. Estimar es un asunto delicado, y es necesario servirse de muchas
técnicas y contar con muchas personas alertando sobre el problema de las
estimaciones.
Como dice Ron Jeffries, uno de los precursores de Extreme Programming, “las
estimaciones son difíciles cuando los requisitos son vagos, y parece que siempre lo
son. [...] Incluso con requisitos claros —y parece que nunca lo son— es casi
imposible saber cuánto tiempo se va demorar”.
Anteriormente, en este libro se presentó un cálculo por muestreo para ayudar en
la comprensión del esfuerzo, tiempo y costo asociado a la creación de
funcionalidades del MVP. Además del costo de la creación, ¿qué otros costos están
asociados al MVP? Por ejemplo, ¿tenemos alguna campaña de marketing asociada
al trabajo? ¿algún otro gasto? Considera las respuestas de todas las preguntas que
surjan para detallar el costo del MVP.
 Muchas veces la pregunta sobre el cronograma está asociada a la pregunta de
costo. Una vez más, será el cálculo por muestreo, presentado anteriormente, el
que nos ayude a la comprensión del tiempo necesario para crear las
funcionalidades del MVP.
Ahora bien, además de aquellas, ¿qué más es necesario para el MVP? ¿Algún
trabajo de infraestructura antes de comenzar el MVP? ¿existe alguna dependencia
externa? ¿Se tiene alguna fecha o tiempo para que aquello acontezca? Considere
las respuestas de todas las preguntas que surgieran para crear el cronograma del
MVP.

LA ESTRATEGIA MVP
El canvas MVP es una herramienta para validar ideas de productos. Es una pizarra
visual que ayuda a un grupo de personas a alinearse y definir la estrategia del
MVP. El canvas tiene elementos que describen la propuesta o visión del MVP, las
hipótesis de negocio con sus métricas, las personas y sus viajes, las
funcionalidades, cuánto cuestan estas y cuánto tiempo lleva crearlas. A partir de
Lean Startup, tenemos el ciclo construir-medir-aprender. Este ciclo está
representado por las secciones funcionalidades, resultados esperados y métricas
para la validación de hipótesis, que responden a las siguientes preguntas: ¿qué
vamos a construir en este MVP? ¿Cómo mediremos los resultados de este MVP?
¿Qué aprendizaje o resultados buscamos en este MVP?
 Canvas MVP y el ciclo construir-medir-aprender

El ciclo construir-medir-aprender parece ser directo, pero es difícil ponerlo en

práctica debido a la combinación de un enfoque de experimentación (construir
para aprender) con una mentalidad de diseño (aprender a construir). Para ayudar
a comprender y construir el MVP, complementamos este ciclo con otro: usuario-
viaje-acción, que nos brinda un enfoque de Design Thinking, centrándonos en el
aprendizaje de las personas y sus viajes.

Construir para aprender o aprender para construir

 ¿Para quién es este MVP? ¿Qué viaje mejorará en este MVP? ¿Qué acción se
simplificará o mejorará en este MVP? La respuesta a estas tres preguntas completa
el ciclo usuario-viaje-acción.

Canvas MVP y el ciclo usuario-viaje-acción

Mientras completamos el canvas MVP, colocamos dos ciclos, uno al lado del otro:
el ciclo construir-medir-aprender de Lean Startup, y el ciclo de usuario-viaje-
acción de Design Thinking.
 Canvas MVP = aprender para construir + construir para aprender

Los ciclos se superponen en la sección de funcionalidades: ¿qué funcionalidades

se van a construir para este MVP? Ten en cuenta que esta pregunta se puede
expresar de dos maneras diferentes: (1) ¿qué vamos a construir en este MVP? y (2)
¿qué acciones van a simplificarse o mejorarse en este MVP?
Construir, de Lean Startup, o acción, de Design Thinking. Ambos se refieren a las
funcionalidades del MVP disponibles para sus usuarios. Por tal razón, la sección de
funcionalidades está en medio del canvas, representando su punto central.

“Las grandes cosas se hacen por una serie de pequeñas cosas

reunidas.”
Vincent Van Gogh

Muchas gracias por haberme acompañado en este viaje por Lean Inception,
espero que marque la diferencia en tus negocios y que tu producto mínimo viable
(MVP) sea todo un éxito.

8 Plantilla “La visión del producto”, descrita en el libro Crossing the Chasm: Marketing and Selling High-Tech
Products to Mainstream Customers, de Geoffrey A. Moore (1999).
 Sabbagh, Rafael (2013). Scrum: Gestão ágil para projetos de sucesso, Casa do Código, www.casadocodigo.com.
9 br/products/livro-scrum.
10Sutherland, Jeff (2014). Scrum: The Art of Doing Twice the Work in Half the Time, Crown Business.
11 Patton, Jeff (2010). “Personas pragmáticas”, StickyMinds, www.stickyminds.com/article/pragmatic-persona
s.
12Empresa de visual thinking, fundada en 1993 por Dave Gray.
13 Osterwalder, A., Pigneur, Y. (2009). Business Model Generation, A Handbook for Visionaries, Game Changers, and
Challengers, OSF, Amsterdam.
14Intervalo prefijado durante el cual se crea un incremento del producto utilizable, potencialmente
entregable.
15 Artículo sobre el canvas MVP (incluye archivo para impresión) por Paulo Caroli (2018). Disponible en:
www.caroli.org/el-canvas-mvp. Acceso en septiembre de 2018.
EJEMPLO DE UNA LEAN INCEPTION
“Me gustaría ver un ejemplo completo de una lean inception”. Este es un pedido
recurrente que he recibido de los lectores de este libro. Imagino que será más fácil
leer este libro para quien ha participado en un taller, o en una inception al estilo
lean. Por más que un libro explique los ingredientes de la receta y los pasos de cada
actividad, entiendo que algunos lectores pidan un ejemplo completo. Es como
seguir una receta para hacer un brownie especial de chocolate después de haber
experimentado un brownie de chocolate tan especial. Y esto es lo que quiero
compartir en este capítulo.
Por motivos de confidencialidad de las empresas que me contrataron para
facilitar dichas lean inception, no puedo compartir el resultado de las actividades
para sus productos. Muchos de estos productos comenzaron como lean, con sus
MVP incrementales, y hoy en día son productos únicos en sus áreas de acción. Por
esta razón, he seleccionado un ejemplo real, muy ilustrativo, y que puede ser
compartido. Este producto lean se diseñó para un taller de Lean Inception en una
gran conferencia, y como este taller tuvo más de veinte participantes, la idea del
producto fue concebida y compartida con todos los participantes.
Como el taller fue de ocho horas, la agenda semanal típica de una lean inception
fue comprimida con el fin de encajar en unas pocas horas. La agenda burn-up fue
esencial para mantener a todos alineados en la rapidez con que tendríamos que
seguir el ritmo de la lean inception.
Reitero que el contenido y las fotos que vienen son solo un ejemplo ilustrativo
logrado en un día, así que probablemente se redujo la cantidad de artefactos
generados: personas, viajes y funcionalidades. El propósito era alcanzar el mínimo
necesario para cada actividad con el fin de demostrar la técnica de Lean Inception,
y simular el ambiente colaborativo de una lean inception.
KICK-OFF
El día comenzó con un rompehielos. He utilizado Zip Zap Zoom. Duró menos de
diez minutos, y fue útil para compartir los nombres. Empezamos el día con mucha
energía y nos reímos mucho.
En lugar de un kick-off típico, generalmente realizado por stakeholders hablando
sobre un producto o idea a ser concebida durante la lean inception, el kick-off de un
taller de simulación tiene otro estilo. Pregunté a los participantes qué ideas tenían
de producto y que quisieran explorar como un ejemplo del taller durante el día. Se
presentaron tres ideas de productos, y luego todos los participantes votaron a
favor de la idea que querían utilizar como un ejemplo para el taller.

VISIÓN DEL PRODUCTO

El producto más votado fue una aplicación para aficionados del fútbol. Personas
que les gusta jugar con sus amigos de trabajo, del gimnasio o con algún grupo de
colegas dispuestos a coordinar un partido.
Para ayudar a las tres personas que propusieron ideas y describir sus ideas,
fomentar la participación de todos y proveer una votación con un buen
entendimiento de las mismas, utilizamos una plantilla de visión de producto para
cada idea. En grupos de siete personas, quienes propusieron las ideas y otros
participantes describieron la visión de cada producto.

Para aficionados
Que tienen dificultad para encontrar partidos de fútbol
Easy-ball
Es una aplicación móvil
Que facilita el encontrar partidos de fútbol
En lugar del boca a boca
Nuestro producto maximiza las posibilidades de encontrar un partido de fútbol
 Este es el resultado de visión del producto para la idea de la aplicación para
aficionados. Las siguientes actividades en este capítulo se relacionan con el
producto Easy-ball. Tales actividades ayudan a la comprensión del producto lean,
los MVP que serán construidos para la creación y validación de esta aplicación
móvil.

EL PRODUCTO ES/NO ES/HACE/NO HACE

A continuación, se realizó la actividad “Es/No es/Hace/No hace” para ayudar con la
definición de Easy-ball. Esta actividad ayudó a clarificar más la idea del producto,
centrándose en el MVP y en eliminar el exceso de funcionalidades iniciales. En este
momento surgieron conversaciones importantes como:
» Esta aplicación será gratuita
» Va a tener un sitio en línea
» La geolocalización es muy interesante
» Esta aplicación no crea equipos, gestiona pagos u organiza campeonatos

Y el resultado logrado fue el siguiente:

» El producto es: app, app móvil, multiplataforma, facilitador para organizar
partidos, gratuito.
» El producto no es: FB, twitter, whatsapp, sitio, no es un chat, messenger (chat).
» El producto hace: programa los partidos (agenda), agenda canchas, lista de
partidos, encuentra partidos cercanos, geolocalización, notificaciones sobre
eventos, notifica a los usuarios, rankea usuarios, guarda reputación.
» El producto no hace: organiza partidos, define partidos a pedido, organiza
partidos y equipos, arma equipos, gestiona los pagos, provee pago en línea del
partido, agenda juegos privados, organiza campeonatos, provee campeonatos.

ENTENDIENDO LOS OBJETIVOS

Después de las actividades de visión del producto y “Es/No es/Hace/No hace”
realizamos una actividad para aclarar el objetivo del producto. En este momento
solicitamos a todos los participantes que compartieran el conocimiento que
tenían de los tres objetivos principales del producto. Cada participante escribió
tres post-its. Al recoger los post-its y ponerlos en grupos de afinidad, se
identificaron tres objetivos principales para el producto:
» Búsqueda de partidos
» Divulgación de partidos
» Opciones de partidos

IDENTIFICANDO A LAS PERSONAS

Después de una buena comprensión del producto, era el momento de cambiar el
enfoque y conseguir un buen entendimiento con respecto a las personas, los
usuarios del sistema. Para ello, se utiliza la plantilla de los cuadrantes para
identificar los tipos de personas. Con esta plantilla, creamos alias para cada tipo de
persona, describimos sus respectivos perfiles, sus características de
comportamiento y sus necesidades específicas. Incluso teniendo poco tiempo,
todos los participantes participaron en los grupos de creación de personas
mientras se divertían con sus descripciones, dibujos y apodos.
Para crear a las personas, los veinte participantes se dividieron en tres grupos
más pequeños. Cada grupo creó dos o tres personas, y las presentaron a todos los
participantes. Luego, las personas duplicadas (o muy parecidas) fueron
descartadas, y todos los participantes votaron por las primeras cuatro personas
mas importantes para el producto.
Esta fue la persona más votada: fanático del fútbol.
» Nombre: Fanático del fútbol
» Perfil: 28 años, casado, jugador frustrado, trabaja en un banco y está graduado
 » Comportamiento: bueno para quejarse, competitivo, activo, exigente, pasa
horas en las redes sociales
» Necesidades: jugar cada semana con cualquier persona y en cualquier lugar,
pero busca partidos de un buen nivel, jugar en la noche los fines de semana

DESCUBRIENDO LAS FUNCIONALIDADES

Después de haber desarrollado el producto, los objetivos y las personas, llegó la
hora de pensar nuevas funcionalidades (características previstas para el producto
lean). Para eso utilizamos la actividad “Descubriendo las funcionalidades”.
Los objetivos estaban presentados como encabezados de columnas, y las
personas como encabezados de filas, lo cual conforma el tablero para el
brainstorming de funcionalidades. Y, con ello, el facilitador puede promover la
actividad.
¿Qué es lo que debe tener el producto para cubrir las necesidades de la persona?
¿Cuáles funcionalidades debemos construir para cumplir el objetivo del producto?
Con estas preguntas, la discusión es guiada para descubrir las funcionalidades
que son necesarias para alcanzar los objetivos y las personas. Son anotadas en
post-its y colocadas en el tablero. Las preguntas se repiten para cada combinación
de persona y objetivo y, con ello, son priorizados los principales objetivos y las
principales personas.
Sigue a continuación el resultado de la actividad:
» Revisar si hay partidos con geolocalización
» Revisar si hay partidos sin geolocalización
» Ranking de canchas
» Rankear un jugador
» Detalles del partido (lugar, fecha y hora)
» Ranking de jugadores (visualización)
 » Detalles financieros del partido
» Registro del jugador
» Registro del partido
» Invita a un amigo al partido
» Filtro detallado
» Módulo de notificaciones
» Confirmación de asistencia (RSVP)
» Notificación de partido confirmado
» Notificación de partido cancelado
» Cancelar asistencia
» Cancelar partido

ENTENDIMIENTO TÉCNICO, DE NEGOCIO Y DE EXPERIENCIA DE USUARIO

Las funcionalidades fueron descubiertas, pero fueron aceptadas sin
cuestionamientos, sin perder mucho tiempo en comprenderlas en detalle,
tomando notas y hablando de las certezas, el esfuerzo y valor para el negocio.
Sin embargo, estas conversaciones e información más detallada son muy útiles
para una mejor comprensión y planificación a la hora de crear productos lean. Las
actividades y gráficos de comprensión técnica, de negocio y esfuerzo; experiencia
de usuario y valor de negocio, buscan dicha información de forma rápida y
eficiente.
 Cada funcionalidad pasa a través del gráfico y de la tabla, y, por lo tanto, gana
marcas de niveles de certeza, esfuerzo, experiencia de usuario y de valor de
negocio. En el gráfico del semáforo la funcionalidad recibe un color. En la tabla, la
funcionalidad recibe marcas de experiencia de usuario, valor de negocio y
esfuerzo técnico. Además de estas marcas, cualquier información adicional acerca
de la funcionalidad se escribe en el post-it y se coloca en la parte posterior de la
tarjeta de la funcionalidad. Algunos ejemplos de esas anotaciones son: (1) utilizar
API de Google para la geolocalización, y (2) se asume que solo funcionarán con los
dispositivos móviles más modernos.
 Durante la actividad, se definió que color de la tarjeta representa el nivel de
certeza: rojo para un bajo nivel de certeza, amarillo para un medio y verde para
alto. Mientras que las marcas de experiencia de usuario, valor técnico y valor de
negocio varían en una escala de uno, dos o tres veces comparativamente. Los
colores y marcas características ayudaron a los participantes en las actividades
posteriores a priorizar, estimar y planificar el MVP.
VALOR VALOR
FUNCIONALIDAD CERTEZA ESFUERZO UX NEGOCIO

REVISAR PARTIDOS CON <3 <3

GEOLOCALIZACIÓN AMARILLO EE <3 $$$

REVISAR PARTIDOS SIN

GEOLOCALIZACIÓN VERDE E <3<3 $$

RANKING DE CANCHAS VERDE E <3<3<3 $

RANKEAR UN JUGADOR ROJO EE <3<3 $

DETALLES DEL PARTIDO (LUGAR, FECHA Y

HORA) VERDE E <3<3<3 $$

RANKING DE JUGADORES (VISUALIZAR) AMARILLO EE <3<3 $

DETALLES FINANCIEROS DEL PARTIDO VERDE E <3 $$

REGISTRO DEL PARTIDO VERDE E <3 $

REGISTRO DE JUGADORES VERDE E <3<3<3 $$$

INVITAR AMIGO PARA EL PARTIDO AMARILLO EE <3<3<3 $$

FILTRO DETALLADO VERDE EE <3 $$

MÓDULO DE NOTIFICACIONES ROJO EEE <3<3 $

CONFIRMACIÓN DE ASISTENCIA VERDE E <3<3 $$$

NOTIFICACIÓN DE PARTIDO
CONFIRMADO VERDE EE <3<3 $$$

NOTIFICACIÓN DE PARTIDO CANCELADO VERDE EE <3 $$$

CANCELAR ASISTENCIA VERDE E <3<3 $$$

CANCELAR PARTIDO VERDE EE <3<3 $$$

DESCRIBIENDO LOS VIAJES

En este punto volvemos a la perspectiva de las personas. Ahora se centra en sus
viajes, el paso a paso que lleva a cabo para lograr un objetivo. Los participantes se
dividieron en grupos nuevamente. Cada grupo seleccionó una persona, e
identificó los principales escenarios para que tal persona alcance sus objetivos
principales. El paso a paso de cada escenario fue descrito con los post-it colocados
en un papelógrafo.
Las siguientes preguntas ayudaron con el comienzo de la descripción de los
viajes:
» ¿Cuál es el objetivo que tal persona quiere alcanzar?
» ¿Cómo comienza su día?
» ¿Qué hace después de eso para alcanzar su objetivo?
Los siguientes son dos ejemplos de viajes de usuario:

FANÁTICO DEL FÚTBOL: INVITA AMIGOS A UN PARTIDO

» Se despierta temprano para ir al trabajo.
» Toma un gran desayuno.
» Llega al trabajo a las 9:00 a.m.
» Durante una reunión decide realizar alguna actividad física.
» En el almuerzo convence a un amigo del trabajo para jugar al fútbol después
del trabajo.
» Llama y reserva una cancha
» Abre la aplicación móvil Easy-ball.
» Registra el partido a las 8:00 p.m. de ese mismo día
» Coloca la información de la cancha
» Envía la invitación a los amigos.

AMIGO DEL TRABAJO: ACEPTA LA INVITACIÓN AL PARTIDO

 » Se despierta tarde para el trabajo
» Come una barra de cereal en el metro
» Llega al trabajo a las 9:30 a.m.
» Va al gimnasio a la hora de almuerzo
» Durante una reunión, recibe una notificación de Easy-ball
» Verifica la información del partido
» Comprueba el ranking de las canchas
» Confirma su asistencia al partido
» Deja la reunión para ir a otra reunión
» A las 5:14 p.m. recibe la confirmación del partido

EXPONIENDO FUNCIONALIDADES EN LOS VIAJES

Ten en cuenta que algunos de los pasos que se describen en los viajes representan
diferentes puntos de contacto con el producto, caracterizando la interacción del
usuario con esta. Este es el momento de revisar todos los análisis realizados hasta
ahora, comparando estos puntos de contacto con el producto, y con las
funcionalidades y su información.
Sigue el ejemplo de viaje anterior, al cual ahora se le han agregado
funcionalidades en algunos de los pasos.

AMIGO DEL TRABAJO: ACEPTA LA INVITACIÓN AL PARTIDO

PASO FUNCIONALIDAD

SE DESPIERTA TARDE PARA EL TRABAJO -

COME UNA BARRA DE CEREAL EN EL METRO -

LLEGA AL TRABAJO A LAS 9:30 A.M. -

VA AL GIMNASIO A LA HORA DEL ALMUERZO -

DURANTE UNA REUNIÓN, RECIBE UNA NOTIFICACIÓN DE MÓDULO DE NOTIFICACIONES

EASY-BALL
 DETALLE DEL PARTIDO (LUGAR, HORA Y
VERIFICA LA INFORMACIÓN DEL PARTIDO FECHA)

COMPRUEBA EL RANKING DE LAS CANCHAS RANKING DE CANCHAS

CONFIRMA SU ASISTENCIA AL PARTIDO CONFIRMACIÓN DE ASISTENCIA

DEJA LA REUNIÓN Y VA A OTRA REUNIÓN -

A LAS 5:14 P.M. RECIBE LA CONFIRMACIÓN DEL PARTIDO NOTIFICACIÓN DE PARTIDO CONFIRMADO

SECUENCIANDO LAS FUNCIONALIDADES

Ahora es momento de construir el “secuenciador de funcionalidades”. Este es el
momento en que se coloca todo el análisis hasta la fecha (producto, personas,
funcionalidades y viajes) en un papelógrafo en base a reglas simples y esenciales
para organizar y visualizar las funcionalidades y su relación con los MVP.
Como facilitador, describí las reglas del secuenciador de funcionalidades y dejé
que los participantes organizaran a voluntad las funcionalidades en el
secuenciador.
Si bien los participantes eligieron y ordenaron a las funcionalidades en el
secuenciador de funcionalidades, escribí en algunos post-its: MVP1, MVP2, MVP3, y
así sucesivamente. Entonces, les pregunté “¿cuándo una composición de
funcionalidades alcanza una versión simple del producto que podría estar
disponible?”. Al identificar lo anterior, se coloca un post-it al lado derecho del
papelógrafo para identificar las funcionalidades de ese MVP.
A continuación, el secuenciador de funcionalidades de Easy-ball, con sus MVP
identificados y sus funcionalidades.
FUNCIONALIDAD ONDA MVP

REGISTRO DEL PARTIDO 1 1

REGISTRO DEL JUGADOR 1 1

REVISAR PARTIDOS SIN GEOLOCALIZACIÓN 1 1

CONFIRMACIÓN DE ASISTENCIA 2 2
 DETALLES DEL PARTIDO (LUGAR, HORA Y FECHA) 2 2

CANCELAR ASISTENCIA 2 2

CANCELAR PARTIDO 3 3

MÓDULO DE NOTIFICACIONES 3 3

NOTIFICACIÓN DE PARTIDO CONFIRMADO 4 3

NOTIFICACIÓN DE PARTIDO CANCELADO 4 3

DETALLES FINANCIEROS DEL PARTIDO 4 4

INVITAR A UN AMIGO AL PARTIDO 5 4

RANKING DE JUGADORES (VISUALIZACIÓN) 5 4

CONSTRUYENDO EL CANVAS MVP

Luego de decidir los MVP en el secuenciador de funcionalidades, es hora de
detallar el primer MVP. Para esto, usamos el canvas MVP.
A continuación, la transcripción del canvas MVP para el MVP1 de Easy-ball
elaborado en esa ocasión.

PROPUESTA DEL MVP:

» Validar si los residentes del barrio Pinheiros usarían la aplicación para organizar
partidos.

PERSONAS SEGMENTADAS:
» Juanito fanático del fútbol
» Jugador solitario
» Solo en el barrio Pinheiros

VIAJES:
» Juanito registra un partido
» Jugador se registra y busca un partido
FUNCIONALIDADES:
» Registrar jugador
» Registrar partido de fútbol
» Buscar partido de fútbol sin geolocalización

RESULTADOS ESPERADOS
» 200 usuarios en un mes
» 50 partidos en el primer mes
» 300 descargas en un mes

MÉTRICAS PARA LA VALIDACIÓN DE HIPÓTESIS DE NEGOCIO

» Número de usuarios registrados en la base de datos
» Número de coincidencias registradas en la base de datos
» Número de descargas de aplicaciones en Play Store

COSTOS Y CRONOGRAMA
» Dos semanas para crear las aplicaciones, dos desarrolladores
» USD 3.000 en marketing online y panfletos (en las calles del barrio)
E
n este libro utilizo una lista breve de términos técnicos. Cada uno de estos
conceptos es explorado en detalle en los capítulos principales. Sin
embargo, creo necesario aclarar, incluso a un alto nivel, estos términos
desde el principio.
Esta lista de términos debe estar visible durante el taller de inception. Sugiero que
imprimas este glosario y lo coloques en la pared de la sala de guerra.

PERSONAS Una persona representa un usuario del sistema, describiendo no solo

su rol, sino también sus necesidades específicas. Esto crea una representación
realista de los usuarios, ayudando al equipo a describir funcionalidades desde el
punto de vista de quién interactuará con el producto final.

FUNCIONALIDAD (FEATURE) Funcionalidad es la descripción de una acción o

interacción de un usuario con el producto. Por ejemplo, imprimir un recibo, ver
detalles e invitar a amigos de Facebook.

CERTEZA TÉCNICA DE LA FUNCIONALIDAD La comprensión de la funcionalidad

de acuerdo con los desafíos técnicos y los requisitos de infraestructura. ¿Lo haz
 hecho antes? ¿Sabes cómo hacerlo? Un “sí” muy firme indica un elevado nivel de
certeza técnica.

ENTENDIMIENTO DE NEGOCIO DE LA FUNCIONALIDAD La claridad del objetivo

de la funcionalidad, del beneficio para el negocio y de lo que debe ser
construido. ¿Qué hacer? Una respuesta directa y clara indica un alto nivel de
concordancia.

NIVEL DE CERTEZA DE LA FUNCIONALIDAD El nivel de certeza de la

funcionalidad se refiere al grado en que una funcionalidad es segura, desde el
punto de vista del entendimiento de negocio y de la certeza técnica. Aquello es
indicado por el color de la tarjeta que puede ser verde, amarillo o rojo, indicando
nivel alto, medio o bajo de certeza, respectivamente.

ESFUERZO DE LA FUNCIONALIDAD El nivel de trabajo que requiere una

funcionalidad. El entendimiento del equipo en cuanto a la dificultad y al trabajo
que va a ser necesario para completar la funcionalidad en cuestión.

VALOR DE NEGOCIO DE LA FUNCIONALIDAD El valor de negocio, o ROI (return

on investment) asociado a la funcionalidad, es una medida de negocio sobre el
valor previsto para tal funcionalidad. ¿Cuál es el retorno de la inversión o el
ahorro que la funcionalidad va a acarrear?

VALOR UX DE LA FUNCIONALIDAD El valor de experiencia de usuario, es el valor

esperado de la funcionalidad para los usuarios, una medida realizada por los
usuarios sobre cuánto desean esta funcionalidad. ¿Cuál es el valor percibido (en
corazones) que una funcionalidad aportará a los usuarios?

VIAJE DE USUARIO El viaje de usuario describe la trayectoria de un usuario a

través de una secuencia de pasos dados para lograr un objetivo. Algunos de estos
 pasos representan diferentes puntos de contacto con el producto, representando
la interacción del usuario con el producto.

MVP El mínimo producto viable, en inglés minimum viable product (MVP), es la

versión más simple de un producto que puede estar disponible para el negocio.
El MVP determina cuáles son las funcionalidades esenciales para que se tenga el
mínimo producto funcional que pueda agregar valor al negocio (producto
mínimo) y que pueda ser efectivamente utilizado y validado por el usuario final
(producto viable).
ACTIVIDADES ROMPEHIELOS
Los rompehielos son actividades que sirven para promover la interacción del
grupo. Son un buen comienzo para cualquier reunión de equipo y son muy
valiosas para las fases iniciales de formación de equipos y lean inceptions. Una
actividad llamada Paulo Puntual, fue descrita en el capítulo “El taller de Lean
Inception”.
Este anexo trae otras nueve actividades, completando así una decena de
actividades para romper el hielo que puedes utilizar en tu lean inception. Estas
actividades fueron extraídas del libro Fun Restrospectives que escribí junto a Taiña
Caetano.
Revisa más actividades en: www.funretrospectives.com/category/energizer

LOCALIZACIÓN GEOGRÁFICA
Esta actividad es excelente para quebrar el hielo y también ayuda a los miembros
del equipo a conocer un poco más de cada uno.

El paso a paso de la actividad

 Explica a los participantes que cada uno será una localización geográfica (por
1.ejemplo, su país, ciudad o barrio).

2.Muestra donde está el norte y el sur en la sala.

3.Pide a cada participante que vaya al lugar de la sala donde él o ella se localiza
para hacer un mapa lo más realista posible.
4.Después de que todos estén en sus lugares, solicita a un voluntario que diseñe
un mapa representando la sala.

TELÉFONO VISUAL
El “teléfono visual” es un excelente energizante para dejar a todos enganchados y
promover una discusión sobre la comunicación y sus interpretaciones.

El paso a paso de la actividad

1.Divide el grupo en subgrupos de tres personas (uno o dos grupos pueden tener
cuatro personas).
2.Coloca tres post-its y un bolígrafo en frente de cada persona.
3.Pide a cada uno que escriba una frase, y que luego coloque un post-it en blanco
encima del primero (solo el autor de la frase la conoce).
4.Todo el mundo pasa el post-it al compañero de al lado, en sentido horario.
5.Cada participante lee la frase del post-it que le ha tocado y crea un diseño
representando la frase (en un post-it en blanco).
6.Se pasa el post-it al compañero de al lado, en sentido horario.
7.En un nuevo post-it, cada persona escribe una frase sobre el diseño que le ha
tocado y coloca encima del conjunto de post-its (ahora el conjunto tiene tres post-
its: uno con la frase original, uno con el diseño y uno con una nueva frase).
8.Se pasan nuevamente los post-its al compañero de al lago (en los grupos de tres
personas, el conjunto de post-it, en este momento, debe haber regresado al
autor de la primera frase).
9.Abre el conjunto de post-its para que todos puedan ver las frases y sus diseños
respectivos.

Normalmente, los participantes ríen y se divierten comparando los diseños y las

frases.
Este es un excelente energizante con un mensaje sutil sobre la comunicación
(visual y escrita), el contexto y las interpretaciones. Esta es la adaptación de una
actividad que aprendí en un taller de UX (user experience) dictado por mis queridos
amigos Natalia Arsand, Glauber Ramos, Juliana Dorneles y Gabriel Albo. Ellos, a
su vez, lo aprendieron en el taller de IDEO, Human Centered Design.

UNO DOS PING CUATRO PONG

Esta es una actividad corta para comenzar una reunión con un buen clima y dejar a
los participantes enganchados.

El paso a paso de la actividad

1.Pide a los participantes que formen un círculo.
2.Los participantes deben decidir en qué sentido seguir (horario o antihorario).
3.Alguien comienza diciendo cualquier número positivo que no sea múltiplo de 3
o 5.
4.La siguiente persona, siguiendo la dirección elegida por todos, mentalmente
aumenta 1 al número. Entonces:
» Si el número no es múltiplo de 3 o 5: dice el número
» Si el número es múltiplo de 3: dice ping y aplaude
» Si el número es múltiplo de 5: dice pong y salta
 Para grupos grandes es recomendable remover una persona del grupo si se
equivoca o acusa a alguien de haberse equivocado erróneamente. Luego, todos
estarán riendo y apoyando a los que permanecen en el círculo.

FORMANDO TRIÁNGULOS
Esta actividad es un excelente energizante con un mensaje muy valioso, es muy
útil para comenzar una conversación acerca de equipos autoorganizados.

El paso a paso de la actividad

Esta actividad está divida en dos partes.

PRIMERA PARTE:
1.Pide a los miembros del grupo que caminen individualmente en direcciones
aleatorias.
2.Después de un tiempo, di la palabra mágica “triángulo”: cada miembro del
grupo tendrá que encontrar a otras dos personas y formar un triángulo
equilátero (cada uno es un vértice del triángulo y debe apuntar el brazo en
dirección a las otras dos personas representando los otros vértices del triángulo.
Cada persona es un vértice en solo un triángulo).
3.Mide cuánto tiempo le tomó a cada grupo formar los triángulos.

SEGUNDA PARTE:
1.Selecciona a una persona para ser el organizador del grupo.
2.Pide a los miembros del grupo que caminen en una dirección cualquiera.
3.Después de un tiempo, di la palabra mágica “triángulo”: el organizador del grupo
tiene que formar triángulos equiláteros con todos los miembros del grupo
(incluyéndose a él mismo en uno de los triángulos).
4.Mide cuanto tiempo le tomó a cada grupo formar los triángulos.

La primera parte muestra un grupo autoorganizado; la segunda, muestra un

grupo guiado por un organizador (u orientador del grupo).
Normalmente, la formación del triángulo autoorganizado es más rápida que la
otra opción y el equipo se siente más enganchado en la actividad.
Esta actividad fue inventada por Heitor Roriz, un colega y coach de equipos.
Felicitaciones a él por aplicar una actividad divertida para promover la discusión
sobre un concepto esencial para los equipos ágiles bien logrados:
autoorganización.

ZIP ZAP ZOOM

Este es un buen inicio para reuniones, especialmente para nuevos equipos. Trae
energía a la sala y la dinámica de la actividad ayuda a los participantes a recordar
los nombres de los otros.

El paso a paso de la actividad

1.Pide al equipo que forme un círculo y que cada participante cierre sus manos
mientras señala con su dedo índice.
2.Explica los comandos Zip/Zap/Zoom.
3.Pide a un participante que haga el primer movimiento, diciendo los comandos y
escogiendo la dirección inicial (horario o antihorario).
LOS COMANDOS:
Cada participante debe, en su turno, dar un comando verbalmente, apuntando
para un receptor. El comando verbal debe ser uno de los siguientes:
» Zip: apunte a la persona exactamente a su lado, manteniendo la dirección
anterior.
» Zap: apunte a la otra persona que está a su lado, cambiando la dirección
anterior.
» Zoom: apunte a cualquier persona en el círculo, diciendo su nombre. El
receptor debe decidir la dirección para el próximo movimiento en su turno.

Cuando un participante ejecute un comando incorrectamente (o un comando

que no existe, o apunte para una dirección errada en un comando zip/zap), él o
ella debe salir del círculo.

Esta actividad no es solamente un buen energizante, sino además ayuda a que

los participantes se enfoquen y puedan recordar los nombres unos de otros.

DESENREDARSE
Desenredarse es un excelente energizarte para generar movimiento en las
personas. Permite transmitir un mensaje muy interesante acerca de encontrar una
solución a una situación complicada.

El paso a paso de la actividad

1.Pide al grupo que forme un círculo.
2.Pide a todo el mundo que coloque las manos arriba.
3.Da las instrucciones para enredarse.
» “Con tu mano derecha toma la mano izquierda de alguien.
» Con tu mano izquierda toma la mano derecha de alguien.
» No puedes tomar las manos de las personas que están a tu lado”.
4.Pide al grupo que se desenrede sin soltarse las manos e intente formar un
círculo.

El grupo saltará manos, se alternará para encontrar una salida, ya sea formando
uno o más círculos. Algunas veces, es imposible desenredarse. En este caso, pide al
grupo que remueva a una persona. Las manos que continúen libres deben
conectarse con la persona que queda en el grupo enredado.
El tamaño del grupo: deben ser por lo menos seis personas, hasta cualquier
número. Los grupos muy grandes sepáralos en grupos pequeños con,
aproximadamente, doce personas cada uno.
PIEZAS COMPLEJAS
Piezas complejas es un excelente energizante para hacer que las personas se
integren mientras conversan sobre sistemas complejos y piezas interconectadas.

El paso a paso de la actividad

1.Todos se colocan de pie y caminando.
2.Cada persona piensa en otras dos personas.
3.Sin decir nombres, cada persona debe estar equidistante de las dos personas en
las que pensó. Eso debe tomar un minuto mientras las personas se mueven.
4.Después de que todos paren, pide a la persona más alta del grupo que vaya a
una esquina de la sala.
5.Solicita a todos que vuelvan a encontrar una posición equidistante.

Aprendí esta actividad con Bethlem Migot. Ella la usaba como energizante
durante un taller de análisis. La actividad dejó a todos con energía antes de tener
una breve conversación sobre sistemas complejos, cambios y requerimientos
interconectados. Esta actividad funciona mejor en grupos de diez a treinta
personas.

DIBUJO COLABORATIVO DE CARAS

El dibujo colaborativo de caras es una actividad interactiva divertida que ayuda
con la memorización del nombre.

El paso a paso de la actividad

1.Entrega a cada participante un papel de tamaño carta o A4 y un bolígrafo.
2.Indica a los participantes que escriban su nombre en la parte inferior del papel.
3.Pídeles a todos que caminen aleatoriamente por la sala hasta que pronuncies la
palabra “paren”.
4.Cada persona debe emparejarse con alguien cercano.
5.Indica a la pareja que intercambie papeles.
6.Cada persona deberá dibujar la mirada de la otra.
7.Indica a las parejas que intercambien papeles nuevamente (ahora cada persona
debe tener el papel con su nombre de nuevo).
8.Repite los pasos 3 a 7 para todas las partes de la cara (ojos, nariz, orejas, mentón,
cabello, vello facial y accesorios).
ESPALDA CON ESPALDA
Espalda con espalda es una actividad energética y divertida que transmite un
mensaje fuerte y simple sobre el trabajo colaborativo.

El paso a paso de la actividad

1.Dile a los participantes que encuentren una pareja con altura y peso similares al
suyo.
2.Pide a todos que se sienten en el piso, espalda con espalda con su pareja.
3.Pide a las parejas que entrelacen los brazos cuando estén de espaldas.
4.Dile a todos que el objetivo es quedar de pie, manteniendo brazos y espaldas
juntos.
 Esta actividad es muy divertida y hará que las personas rían. Normalmente,
pocas parejas conseguirán quedar en pie rápidamente, la mayoría tendrán
dificultadas. Considera no hacer esta actividad si percibes que algún participante
no es capaz de quedar en pie o no le gustaría sentarse en el piso.

ENCUENTRA TU PAR
Encuentra tu par es un energizarte muy divertido para mover a las personas y
hacerlas reír.

El paso a paso de la actividad

1.Cuenta el número de participantes (se necesita un número par de participantes,
por lo tanto, decide si participarás o no de acuerdo al número de personas).
2.Divide el número de participantes en dos para decidir cuántos animales existirán
(si son veinte participantes, entonces existirán diez especies de animales
diferentes).
3.Escribe el nombre en post-its para cada animal (fíjate que haya dos animales por
especie).
4.Distribuye los post-its a los participantes y diles que no lo muestren a nadie.
5.Pide a todos que caminen por la sala.
 Dile a todos que se cubran los ojos con las manos y hagan el sonido de su animal
6.para intentar descubrir dónde está su par.

Esta actividad también la aprendí con Bethlem Migot. Confieso que me demoré
un poco en usarla y decidí intentarla solo después de verla siendo usada muchas
veces y percibir que a las personas les gustaba. Recomiendo tener cuidado con
ciertas culturas y tener certeza de que los participantes están acostumbrados a los
energizantes.
Agenda burn-up. Disponible: <www.caroli.org/la-agenda-burn-up/>. Acceso en
septiembre de 2018.
AGUIAR, Fábio; CAROLI, Paulo. Product backlog building: construindo um Product
Backlog efetivo. LeanPub, 2018.
BECK, Kent. Extreme programming explained: Embrace change. 1ª ed. Addison-Wesley,
1999.
BLANK, Steve G. The four steps to the epiphany: Successful strategies for products that
win. K & S Ranch; 5ª ed., 2013.
CAROLI, Paulo; CAETANO, Tainã; Fun retrospectives: activities and ideas for making
agile retrospectives more engaging, LeanPub, 2014.
CAROLI, Paulo. Direto ao ponto: Criando produtos de forma enxuta. Casa do Código; 1ª
edição, 2014.
CAROLI, PAULO. “Lean Inception”. Disponible: <martinfowler.com/articles/lean-in
ception>. Acceso en agosto de 2018.
CAROLI, Paulo. Lean Inception: How to align people and build the right product. Editora
Caroli; 1ª ed., 2018.
CAROLI, Paulo. “MVPs no mundo real: o caso do EasyTaxi”, (2015). Disponible:
<www.infoq.com/br/articles/mvp-easy-taxi>. Acceso en agosto de 2018.
CAROLI, PAULO. “O canvas MVP”. Disponible: <www.caroli.org/el-canvas-mvp/>.
Acceso en septiembre de 2018.
COHN, Mike. User stories applied: For agile software development. Addison-Wesley
Professional; 1ª ed., 2004.
COOPER, A.; REIMANN, R.; CRONIN, D.; NOESSEL, C. About face: The essentials of
interaction design. Wiley; 4ª ed., 2014.
GOTHELF, Jeff; SEIDEN, Jeff. Lean UX: Applying lean principles to improve user
experience. O’Reilly Media; 1ª ed., 2013.
GRANDONI, Dino. “How Long People Waited to Be First in Line to Buy Apple
Products” (2011). Disponible: <www.theatlantic.com/technology/archive/2011/10
/how-long-people-waited-be-first-line-buy-apple-products/337087>. Acceso en
agosto de 2018.
HUMBLE, Jez; FARLEY, David. Continuous delivery: Reliable software releases through
build, test and deployment automation. Addison-Wesley, 2010.
JEFFRIES, Ron. “The noestimates movement” (2013). Disponible:
<ronjeffries.com/xprog/articles/the-noestimates-movement>. Acceso en
septiembre de 2018.
LOWDERMILK, Travis. User-centered design: A developer’s guide to building user-friendly
applications. O’Reilly Media; 1ª ed., 2013.
MCCLURE, Dave. Métricas de pirata – AARRR. Disponible: <pt.wikipedia.org/wiki/A
ARRR>. Acceso en agosto de 2018.
OHNO, Taiichi. Toyota production system. Productivity Press, 1988.
OSTERWALDER, A.; PIGNEUR, Y. Business model generation: A handbook for
visionaries, game changers and challengers. Amsterdam: OSF, 2009.
PATTON, Jeff. User story mapping: Discover the whole story, build the right product.
O’Reilly Media, 2014.
“Pragmatic Personas”. Disponible: <www.stickyminds.com/article/pragmatic-pers
onas>. Acceso en septiembre de 2018.
“Principles behind the Agile Manifesto” (2001). Disponible en
<www.agilemanifesto.org/principles.html>. Acceso en septiembre de 2018.
RASMUSSON, Jonathan. The Agile Samurai: How agile masters deliver great software.
Pragmatic Bookshelf; 1ª ed., 2010.
RIES, Eric. The lean startup: How today’s entrepreneurs use continuous innovation to
create radically successful businesses. Crown Publishing, 2011.
SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. Casa do Código, 2013.
SCHWABER, Ken; BEEDLE, Mike. Agile software development with Scrum. Pearson; 1ª
ed., 2001.
SUTHERLAND, Jeff. Scrum: The art of doing twice the work in half the time. Crown
Business, 2014.
TAYLOR, Jeffrey L. “Hypothesis-Driven Development”, Article on Dr. Dobb’s (2011),
Disponible: <www.drdobbs.com/architecture-and-design/hypothesis-driven-
development/229000656>. Acceso en agosto de 2018.
WILLIAN, S. Junk. The dynamic balance between cost, schedule, features and quality in
software development projects. Computer Science Dept., University of Idaho,
SEPM-001, 2000.
WOMACK, James P.; JONES, Daniel T.; ROOS, Daniel. The machine that changed the
world: the story of lean production – Toyota’s secret weapon in the global car wars that is
now revolutionizing world Ind. Free Press; Reprint, 2007.
WOMACK, James P.; JONES, Daniel T. Lean thinking: Banish waste and create wealth
in your corporation – revised and updated. Free Press; 2ª ed., 2003.
A
l principio, creía que con escribir en el libro el paso a paso de las
actividades de Lean Inception sería suficiente. Sin embargo, con el tiempo
percibí que la conexión entre las personas facilitadoras y el intercambio de
experiencias entre ellas era muy rica, y aquello no tiene cómo suceder solamente a
través de un libro.
Por lo demás, la demanda de facilitadores de Lean Inception estaba
aumentando vertiginosamente: las empresas me buscaban para pedir
recomendaciones de facilitadores y había quienes me pedían entrenamientos.
Entonces, decidí reunirme con personas de mucha experiencia en Lean Inception y
juntos, en diciembre de 2017, comenzamos a organizar comunidades y
entrenamientos para compartir la práctica.
Revisa las comunidades de Lean Inception en:
www.caroli.org/comunidad-lean-inception.

Revisa el entrenamiento de Lean Inception en:

www.caroli.org/formacion-lean-inception.
Este libro llega a ti gracias al trabajo de estos excelentes profesionales,
especialistas en esta área de conocimiento.

PATRICIA TREJO
Patricia Trejo es actualmente senior consultant en ThoughtWorks, empresa a la que
pertenece desde 2016. Ingeniero civil informático, magíster en Ciencias de la
Ingeniería Informática e ingeniero civil industrial y con más de diez años de la
industria de desarrollo de software, Patricia se ha desempeñado como analista de
negocio y project manager en diversos proyectos, contextos e industrias.
Actualmente se desempeña como project manager y está dedicada a la utilización
de prácticas ágiles y lean en el desarrollo de proyectos y productos de software.

MARÍA FERNANDA ESCUDERO

María Fernanda (Mafer) ha trabajado en la industria de desarrollo de software por
casi veinte años, la mayoría como líder de proyecto, project manager y program
manager. Ella ha estado usando Fun Retrospectives (versión en inglés) desde 2013
para desarrollar habilidades y capacidades en sus equipos para proyectos en
Sudamérica y Centroamérica.
Se unió a ThoughtWorks hace dos años como gerente de proyecto y, hace un par
de meses, fue ascendida a jefa de operaciones de ThoughtWorks Ecuador.

FREDDY CORONEL
Freddy se unió a ThoughtWorks en 2015, como nuevo project manager. Utiliza
todas las herramientas que puede con los equipos para hacer su experiencia lo
mejor posible. Le gustan los deportes, especialmente el ciclismo de montaña, por
lo que siempre lo encontrarás tratando de escalar “montañas” con su bicicleta. Él
cree que esta actividad es una especie de analogía de la vida, el trabajo y los
proyectos, y disfruta cada momento de ellos.
Para los lectores y autores que buscan y comparten conocimiento de forma ágil, la
Editora Caroli es una editorial boutique —todos los libros son escritos, leídos,
editados y/o revisados por Paulo Caroli— que ayuda en la producción, divulgación
y distribución de libros y e-books. A diferencia de las editoriales tradicionales, la
Editora Caroli busca esencialmente facilitar el acceso al conocimiento, ofreciendo
el texto de las nuevas obras vía e-books gratuitos, además de apoyar eventos y
entidades de enseñanza, regalando ejemplares impresos de los libros.
En www.caroli.org podrás encontrar este y otros contenidos de calidad. Disfruta,
pues los libros y los e-books WIP están disponibles gratuitamente.

WIP (WRITING IN PROGRESS)

La Editora Caroli presenta una nueva propuesta de trabajo, acercando a los
autores a sus lectores desde el inicio de la generación del contenido. ¿Por qué
esperar a que el autor termine de escribir para ver si el contenido es bueno? En el
mundo actual, esto ya no tiene sentido. La Editora Caroli promueve el intercambio
(gratuito, siempre que sea posible) del WIP a través de formatos e-book (pdf, mobi
y epub). De esta manera, los lectores tienen acceso rápido a las nuevas ideas, y
pueden formar parte de la evolución de la obra. Para los autores, esta es una
forma efectiva de retroalimentación y motivación para la generación de
contenido.
 SOBRE EL AUTOR

PAULO CAROLI Consultor principal en ThoughtWorks Brasil y cofundador de

AgileBrazil, Paulo Caroli tiene más de veinte años de experiencia en desarrollo de
software, habiendo trabajado en varias empresas en Brasil, India, Estados Unidos y
Latinoamérica. En 2000, descubrió Extreme Programming y desde entonces ha
centrado su experiencia en procesos y prácticas Agile & Lean. Se unió a
ThoughtWorks en 2006 y ha ocupado posiciones de agile coach, trainer y project
manager. Recibió una Licenciatura en Ciencias de la Computación y una Maestría
en Ingeniería de software, ambas de la Pontifica Universidad Católica de Río de
Janeiro (PUC-Rio).