Un sprint sirve para responder una pregunta

01 / LA IDEA EN UN MINUTO

La pregunta decide qué construir.

Un equipo puede pasar una semana produciendo pantallas y terminar sin saber más sobre su principal incertidumbre. O puede construir una representación sencilla y descubrir que los usuarios no entienden el servicio. La diferencia está en la pregunta que organiza el trabajo.

Un Design Sprint sirve para concentrar decisiones, construir un prototipo y observar reacciones. No es una semana para resolver todas las tareas atrasadas ni un sinónimo de trabajar deprisa. Antes de convocarlo, conviene saber qué decisión cambiaría según el resultado.

Si la duda es si la persona comprende una oferta, un prototipo puede ayudar. Si la duda es cuánto costará fabricar mil unidades, hablar con proveedores y hacer una prueba técnica puede ser más pertinente. El método debe encajar con la incertidumbre.

02 / LA SEMILLA DE ESTA IDEA

Buscar un modo de desbloquear proyectos.

En primero, Iván preparó un LP sobre SPRINT porque los proyectos del equipo estaban estancados. Organizó material de Jake Knapp y sus colaboradores para que los responsables de proyecto pudieran usarlo como guía.[1]

La fuente es una síntesis de un método ajeno, no una técnica inventada por Iván ni una demostración de que aplicarlo garantizase tracción. Su valor como semilla está en la necesidad concreta: pasar de discutir a aprender mediante una prueba organizada.

Los creadores del método lo presentan como una forma de construir prototipos realistas y probar preguntas clave con clientes antes de invertir en el producto completo.[2] Ese alcance es más preciso que prometer que una semana certifica la viabilidad de una empresa.

03 / PREPARA LAS CONDICIONES PARA APRENDER

El calendario no sustituye la prueba.

Necesitas una pregunta relevante, personas capaces de aportar perspectivas y alguien con capacidad de decidir. También acceso a participantes adecuados. Dejar la búsqueda de usuarios para el final puede convertir la prueba en opiniones de compañeros disponibles.

El prototipo debe representar lo necesario para observar la respuesta. Puede simular una parte del servicio sin construir todo el sistema. Pero no debería ocultar limitaciones que cambien la decisión del participante ni presentar como existente algo que después no podrás entregar.

Durante la prueba, observa qué hace la persona y dónde duda. Evita explicar cada paso hasta que todo parezca funcionar. Si necesita tu ayuda constantemente, esa dependencia forma parte del resultado.

Al interpretar, distingue comprensión, utilidad percibida, uso y compra. Un grupo pequeño de entrevistas puede descubrir problemas y orientar mejoras; no demuestra por sí solo demanda general, retención o rentabilidad. Cada conclusión debe corresponder a lo que realmente se ha puesto a prueba.

04 / UNA PROPUESTA DE MENTORÍAS

Probar el recorrido adecuado.

Imagina un equipo que quiere ofrecer mentorías para estudiantes. Es un ejemplo hipotético. La duda central es si alguien entiende qué problema resuelve cada sesión y puede elegir la adecuada. El equipo prepara una página simulada con tres opciones y un recorrido de solicitud.

En la prueba, varias personas eligen por el nombre más atractivo, pero no pueden explicar qué recibirían. Esa observación cuestiona la claridad de la oferta. Añadir más sesiones no resuelve necesariamente el problema.

El equipo reformula las descripciones y vuelve a observar. Si mejora la comprensión, puede avanzar hacia una prueba de contratación y entrega. No debería anunciar que el modelo está validado solo porque la segunda versión se entiende mejor.

La siguiente decisión queda delimitada por el aprendizaje: ajustar la propuesta, explorar otro público o probar una sesión real. Así la semana deja una dirección y no únicamente un mural lleno de trabajo.

05 / LLÉVALO A TU PROYECTO

Decide qué debe cambiar después.

Formula la incertidumbre más importante y explica por qué merece una prueba concentrada. Pregunta qué decisión tomarías con un resultado favorable, ambiguo o contrario. Si continuarías igual en todos los casos, revisa la pregunta.

Reúne a las personas necesarias y aclara su disponibilidad. El tiempo protegido ayuda, pero no justifica convocar a todo el equipo sin función. Prepara también la selección de participantes y el modo de registrar observaciones.

Construye el mínimo recorrido creíble para esa pregunta. Decide qué se simula y qué debe funcionar realmente. Durante la prueba, separa lo que observas de la explicación que te gustaría encontrar.

Cierra con una decisión y una limitación explícita. Puedes haber aprendido mucho sin haber validado el negocio. Guardar esa frontera permite diseñar una siguiente prueba más útil y evita convertir el método en una ceremonia que se repite por costumbre.

06 / APRENDIZAJES

Aprendizajes

• Empieza por una incertidumbre. El prototipo debe responder a una pregunta.
• Prepara participantes. Disponibilidad no equivale a pertinencia.
• Observa sin rescatar. La ayuda constante también es un resultado.
• No confundas señales. Entender, usar y comprar son cosas distintas.
• Cierra con una decisión. Explica qué cambia y qué falta comprobar.

07 / PREGUNTAS DETONANTES

Preguntas detonantes

1. ¿Qué decisión queremos poder tomar al terminar?
2. ¿Qué participante representa la situación que estudiamos?
3. ¿Qué debe simular el prototipo y qué debe funcionar?
4. ¿Qué ayuda nuestra puede estar distorsionando la prueba?
5. ¿Qué no podremos concluir con esta muestra?

08 / CONEXIONES

Para seguir aprendiendo