Todos nuestros experimentos tienen un ciclo de vida, es decir, están vivos desde que empezamos su definición, hasta que obtenemos aprendizajes con los que tomamos las decisiones de qué incorporar o no a nuestro producto. Os cuento mi experiencia más reciente.
Ciclo de vida de los experimentos
El ciclo de vida de los experimentos es su flujo de trabajo, lo que nos permite tener visibilidad de los experimentos en los que estamos trabajando y en qué estado está cada uno de ellos. El flujo de trabajo con que el que he trabajado recientemente es el siguiente:
- Backlog – donde se apilaban los experimentos propuestos
- Analysing – analizar el contexto y la hipótesis de cada idea que provenía de equipos de producto o Stakeholders para poder priorizar su definición
- Ready to define – lista de experimentos priorizados listos para ser definidos
- Defining – definir la ejecución del experimento para poder validar/refutar las hipótesis
- Ready to build – lista de experimentos priorizados listos para ser construidos
- Building – construir el experimento para poder ejecutarlo en las herramientas correspondientes
- Ready to validate – lista de experimentos priorizados listos para ser validados con el cliente
- Validating – experimento activo en sus condiciones de ejecución
- Done – cuando obtenemos las conclusiones
Si os dais cuenta, en cada paso de este flujo de trabajo, vamos completando paso a paso toda la información que definen los experimentos, es como si nosotros mismos fuéramos descubriendo como es nuestro experimento progresivamente.
Experimentación weekly review
El ciclo de vida de los experimentos está configurado en JIRA. Tenemos un item de trabajo para los experimentos y todos los experimentos están en una board Kanban a la que todos los equipos tenían acceso.
Cada semana hay una hora reservada para revisar el flujo de los experimentos que se facilita con la board Kanban y se lee de derecha a izquierda – start finishing stop starting – siendo la agenda algo similar a:
- ¿Qué necesitamos para terminar los experimentos que se están validando?
- ¿Qué experimentos listos para validar podemos ejecutar?
- ¿Qué necesitamos para terminar de construir los experimentos?
- ¿Qué experimentos listos para construir podemos empezar?
- …
El beneficio de esta sesión de trabajo es que la visibilidad completa nos permitía gestionar nuestro work-in-progress, los experimentos que podían estar validándose al mismo tiempo, los experimentos que podían aportar con sus aprendizajes a diferentes equipos, y lo más importante, apoyarnos en cada una de las etapas del ciclo de vida de los experimentos, aprendiendo a experimentar juntos.
Roles trabajando con Experimentación
En el contexto que os describo, no hay un equipo dedicado a experimentar, sino que todos los equipos de producto tienen la posibilidad experimentar. El reto no es fácil, ya que los mismos equipos tienen que aprender a trabaja en modo dual track gestionando discovery y delivery al mismo tiempo, lo cual es maravilloso desde mi punto de vista.
Desde el primer momento se deja claro que la experimentación es un trabajo de todo el equipo de producto y no de un rol en concreto. Si bien es cierto que generalmente el Product Owner dedica más tiempo al discovery que al delivery, el trabajo lo tiene que hacer junto con todo el equipo al que pertenece.
A la sesión de trabajo Experimentación weekly review asisten obligatoriamente al menos un persona de cualquier rol del equipo que está experimentando o tiene una idea para experimentar, confiando en que esa persona compartirá después todo lo trabajado con sus compañeros. De forma opcional, cualquier otra persona puede asistir a la sesión de trabajo pues es abierta, permitiendo que compañeros pudieran aprender de las experiencias de otros.
Las sesiones abiertas de trabajo son ese tipo de detalles que impactan en la cultura de la empresa creando así una learning organization.
En el próximo artículo, veremos cómo calcular el tiempo que nos lleva experimentar par descubrir el producto correcto que tenemos que construir, nuestro time-to-discover (TTD).
Foto destacada de Retha Ferguson desde Pexels.
Vanesa Tejada 
Muy interesante. Da la impresión de que lo que hacéis es aplicar la metodología Lean de Diseña-Construye-Mide, pero aterrizado al día a día, ¿verdad?
Hola Federico,
Así es, siempre que defino y optimizo cómo hacemos producto, me baso en esos 3 momentos descritos por Lean Startup y les añado otros elementos para conseguir la adopción por la organización.
Gracias por tu comentario