Adaptamos los procesos de product discovery y del design sprint por una única razón.
La razón por la cual hicimos este cambio:
Cuando hablamos de las metodologías en las entregas del “Startup Rollercoaster”, mencionamos la importancia del Product Discovery y del Design sprint. Cada etapa, correspondientemente, te permite entender qué problema vas a resolver, cómo, por qué y además definir un prototipo de la solución. Esto es para que luego puedas validar la idea con usuarios reales sin invertir demasiado en esta etapa temprana.
Muchos de nuestros clientes suelen realizar el proceso de Discovery antes de comenzar a trabajar juntos: algunos lo hacen de manera intuitiva y otros un poco más sistematizada.
La conclusión es siempre la misma: Algunas cositas hay que terminar de pulir, revisitar y además nuestro equipo debe estar al tanto de lo que se haya avanzado no sólo por una cuestión comunicacional, si no por una cuestión imperativa de que todos estemos en la misma página: Que la empatía no sea sólo una palabra linda, si no que se practique.
Luego de finalizado el discovery, nos queda la etapa del design sprint y el prototipo, pero acá nos encontramos con algunos problemas operativos: Nos falta tiempo. La metodología implica estar muchísimo tiempo enfocado en el proyecto, y si bien sabemos que sin foco es muy difícil sacar algo adelante, nuestros stakeholders (ó responsables del proyecto) tienen también otras responsabilidades profesionales ó personales.
Esto implica que muchas veces no tengamos el tiempo suficiente para disponer de todo el equipo de nuestro cliente durante una semana ó dos. Es fácticamente imposible.
Shopify hizo su experiencia con un sprint de 4 horas, acá cuentan cómo les fue y cuáles fueron sus conclusiones, además de definir si lo seguirían usando ó no (spoiler alert: Funcionó de maravillas).
Por todo esto, decidimos acortar estas metodologías y hacerlas más breves, de manera de no perder calidad en el feedback ni en los resultados, pero sí hacer foco en lo que más nos interesa.
En nuestro caso decidimos separar Product Discovery por un lado y Design sprint por el otro.
El primero, más orientado a analizar el problema que resolvemos, a la visión, al negocio y a la parte más estratégica, decidimos hacerlo en dos talleres:
Taller 1:
- El cliente nos introduce el proyecto en detalle (20 min)
- Lean canvas (30 min)
- Elevator pitch (20 min)
- Users personas (40 min)
Taller 2:
- User story mapping (2hs)
- Identificación de problemas, cosas que nos quitan el sueño, miedos de cómo resolver algo. Puntos de dolor del mapa (10/20 min)
En este post te contamos un poco más sobre cada método y su aplicación.
De esta manera y con estos dos talleres, podemos definir si estamos ante el camino correcto y si estamos resolviendo un problema a través de un producto digital útil.
Luego pasamos al design sprint, en donde sí hacemos una reducción drástica de la cantidad de horas de talleres y trabajo en equipo. Al final del proceso dejamos una etapa offline en donde nuestro equipo trabaja en algunos prototipos que luego se validarán con usuarios reales.
Redujimos el proceso a 2 días de taller con los siguientes temas:
Dia 1 (4hs)
- Ver qué hace la competencia.
- Dividimos quien esboza cada parte del mapa propuesto (esto sucede si el mapa abarca muchas instancias y si tenemos la suficiente cantidad de personas en el equipo para dividir los dibujos).
- Bocetos, anotaciones, garabatos.
- Esbozar una solución.
- Decisión adhesiva.
- Museo de arte.
- Evaluación veloz.
- Votación silenciosa.
- Supervoto.
Día 2 (4hs)
- Elaboración del guión gráfico.
Día 3 (en realidad son varios días offline del lado de nuestro team)
- Prototipo realista.
- Probarlo con usuarios.
- Corregir en base a las pruebas.
Si bien el día 3 es el día 5 del típico design sprint, preferimos darle una vuelta más de rosca, pensarla internamente y luego iterar con entrevistas a usuarios.
Querés saber un poco más sobre el Design Sprint?. Entrá acá.
Así es como reducimos la carga horaria de nuestros clientes sin dejar de trabajar en equipo y al proponer metodologías que se adapten al cliente y no al revés.
Si bien hay cuestiones que sí son imperativas para el éxito de esta etapa, también creemos que mejorar, iterar e innovar son parte del día a día, y si una metodología adaptada funciona de manera exitosa, entonces, por ahí es el camino.
Siempre habrán cosas para mejorar ó modificar, pero hacer, probar y fallar es el primer paso.
Soy Facu Gandini, Co-Founder de Braintly. Escribo sobre los problemas y las soluciones en este mundo tan digital. ¿Necesitás una mano con un proyecto?. Escribime y tomemos un e-café.
