Sprint. Jake Knapp

Sprint es un framework ideado por Google Ventures con el objetivo de analizar problemas, idear soluciones y validarlas con clientes objetivos en 5 días. Resulta muy optimista a priori pensar que algo así puede hacerse, pero el método a través de múltiples ejemplos reales demuestra que es viable.

Empresas como Starbucks o Slack han ideado alguna de sus estrategias de negocio y de su validación en Sprint.

Consta de un roadmap establecido muy estricto, que va guiando en el proceso de detección de los problemas o retos a los que se enfrenta, un brainstorming de soluciones potenciales, un prototipado de aquellas más interesantes y una validación del mismo con usuarios reales, con objeto de obtener insights, validar la solución, aprender y pivotar en busca de mejorar. Requiere de una fuerte dedicación de personas clave de la organización que quiera aplicarlo, pues son 5 días completos de dedicación exclusiva al método.

¿En qué consiste?

En primer lugar, y antes de iniciar el ciclo en sí, ha de definirse el reto al que se quiere dar respuesta e identificar el equipo que participará. Ha de contarse con un conjunto multidisciplinar que tenga una visión 360º del problema y que asuma los siguientes roles:

1. Decisor. Ha de haber una persona que tenga capacidad de decisión dentro de la organización, puesto que han de tomarse decisiones clave que afectarán a la estrategia de la compañía.
2. Stakeholders de Finanzas, Marketing, Ventas
3. Expertos en Tecnología
4. Expertos en Diseño

El equipo ha de acotarse, siguiendo la esencia agile, a 7-8 personas para que sea gestionable. Es importante que existan pensamientos divergentes, personas que se cuestionen las cosas, "troublemakers".

Estructura:

• Día 1. Se define el objetivo a medio/largo plazo que se pretende obtener, se hace un mapa del reto al que se enfrenta al equipo (uno de los elementos clave para enfocar fases posteriores del método y al que se vuelve constantemente), se entrevista a expertos dentro o fuera de la organización al respecto (se hace uso de preguntas abiertas tipo "how we might" (HWM)), para obtener más información con la que guiar el proceso y finalmente se define el "target" en el que se centrará el esfuerzo.
• Día 2. Se recopila el trabajo del primer día y se hacen sketchs de soluciones de forma individual.
• Día 3. Se presenta cada sketch, se decide en conjunto con cual o cuales se va a seguir trabajando, dado que no se pueden prototipar todas las soluciones potenciales en un plazo tan corto, y para aquéllas que resulten elegidas se genera un storyboard.
• Día 4. Se prototipa la solución. El objetivo no es desarrollar obviamente la solución o producto real, sino algo que transmita claramente lo que se pretende y que permita a usuarios reales experimentar e interactuar, con objeto de obtener sus impresiones reales. Se aplica el criterio 'goldilock' (ni mucho ni poco).
• Día 5. Se valida el prototipo con usuarios reales previamente seleccionados. El equipo visualiza en tiempo real desde otra sala las reacciones del usuario ante el producto, sus impresiones y comentarios, cómo lo utiliza, recoge sus críticas, etc. Esta información es muy valiosa para poder refinar el proceso creador, pivotar y lanzar una nueva iteración más acotada para continuar con el desarrollo de la solución. 

Como conclusiones, es un framework muy guiado, recopilando ideas conocidas (no plantea nuevos conceptos), que permite idear soluciones y validarlas en una semana. Como handicaps, la alta dedicación que requiere de personas clave de la organización y la selección de usuarios reales para validar las ideas.