En una empresa normal, una decisión importante de producto tarda meses en probarse: se debate, se diseña, se construye, se lanza, y solo entonces se descubre si a alguien le importaba. Jake Knapp, con John Zeratsky y Braden Kowitz, diseñó en Google Ventures un proceso para comprimir ese ciclo completo, desde la idea hasta la reacción de un usuario real, en cinco días de trabajo estructurado.
Lunes: mapea el problema y elige un objetivo a largo plazo
El sprint no arranca con soluciones, arranca con una pregunta bien planteada. La mañana del lunes se dedica a fijar una meta ambiciosa a largo plazo, dónde quiere estar el proyecto dentro de seis meses o un año, y a listar las preguntas críticas que, si no se responden, pueden hundirlo. Después el equipo dibuja un mapa simple: los actores involucrados a un lado, los pasos que siguen hasta completar su objetivo al otro, con flechas entre medio. No es un diagrama exhaustivo, es un boceto que cabe en una pizarra.
Por la tarde entran los expertos: quien lleva ventas, quien atiende soporte, quien conoce los datos, cada uno aporta quince minutos de contexto que el equipo no tendría de otro modo. Con ese mapa y esas preguntas, el grupo elige un objetivo concreto: un cliente específico y un momento exacto del mapa donde ese cliente toma una decisión crítica. Ese recorte pequeño es lo que se va a resolver esta semana, no el problema entero. Intentar arreglarlo todo a la vez es la manera más segura de no arreglar nada en cinco días.
Martes: cada uno boceta su propia solución, en silencio
Martes empieza mirando hacia afuera: el equipo repasa productos ajenos, propios y de otros sectores, buscando piezas de solución que ya funcionan en otro contexto y podrían adaptarse. A esa fase Knapp la llama «remezclar y mejorar», y sirve para no partir de cero ni para copiar sin criterio.
Lo que sigue es la parte que más sorprende a quien nunca ha hecho un sprint: nadie hace una lluvia de ideas en grupo. Cada persona boceta su propia propuesta, sola, en un proceso de cuatro pasos que va de notas sueltas a un boceto final con tres viñetas, pasando por una ronda de ocho ideas rápidas en ocho minutos para forzar variantes. La razón de trabajar en silencio y por separado es evitar que la persona con más autoridad o más labia de la sala termine marcando el rumbo de todos. Una idea dibujada de forma anónima se juzga por lo que propone, no por quién la propuso.
Miércoles: se decide una sola idea y se convierte en storyboard
El miércoles empieza con todos los bocetos pegados en la pared, sin nombres. Cada persona los revisa en silencio y marca con puntos adhesivos lo que le convence; después hay una ronda corta donde cada uno defiende en un minuto la idea que más votos recibió, sin que el autor original hable primero. La discusión se mantiene breve a propósito: el objetivo es decidir, no debatir hasta el cansancio.
La decisión final no la toma el grupo por consenso. La toma una sola persona designada al principio de la semana, el Decisor, normalmente quien tiene la autoridad real sobre el proyecto. Delegar la decisión en un comité diluye la responsabilidad y alarga la reunión; una sola persona que responde por el resultado la acorta. Con la idea ganadora elegida, el equipo arma un storyboard: una secuencia de viñetas, como un guion de cómic, que detalla paso a paso lo que un usuario va a ver y hacer al día siguiente frente al prototipo.
Jueves: se construye una fachada, no un producto
Jueves es el día de fingir. El equipo no programa nada funcional: arma una fachada creíble con herramientas de diseño ligeras, el equivalente a un decorado de cine. Una pantalla puede parecer una aplicación completa aunque detrás no haya una sola línea de código real conectada a una base de datos.
La regla que sostiene todo el día es la del punto justo: ni tan pulido que parezca terminado y genere respuestas educadas en vez de sinceras, ni tan tosco que la persona que lo pruebe se distraiga señalando que un botón tiene el color equivocado. Tiene que parecer real lo suficiente como para que quien lo use al día siguiente olvide que está frente a una maqueta y reaccione como reaccionaría frente al producto de verdad. Construir esa fachada en un día exige dividir el trabajo: alguien arma la estructura, alguien escribe los textos, alguien cose las piezas y alguien ensaya el guion de la entrevista del viernes. El objetivo no es tener algo bonito. Es tener algo que se pueda poner delante de un desconocido sin que se note el truco.
Viernes: cinco usuarios reales bastan para saber si funciona
El viernes, una persona del equipo entrevista a cinco usuarios reales, uno por uno, durante unos sesenta minutos cada uno, mientras el resto observa desde otra sala y va anotando patrones. Cinco no es un número arbitrario: la investigación clásica sobre pruebas de usabilidad muestra que, a partir de la quinta persona, los problemas nuevos que aparecen empiezan a repetirse; la sexta y la séptima casi no aportan nada que las anteriores no hayan mostrado ya.
Cada entrevista sigue una estructura fija: una charla inicial para relajar a la persona, unas preguntas de contexto sobre sus hábitos, la presentación del prototipo como si fuera real, y un cierre para recoger la impresión general. Quien entrevista hace preguntas abiertas y evita explicar el prototipo, si hay que explicarlo, ya se sabe algo importante. Al final del día, el equipo compara notas y agrupa lo que vio en patrones: qué parte confundió a casi todos, qué parte entusiasmó a casi todos. Esa tarde el equipo ya sabe, con evidencia y no con opiniones, si la idea merece construirse.
La apuesta del método: cinco días valen más que cinco meses de reuniones
La conclusión de Knapp y Zeratsky es incómoda para cualquier cultura de reuniones interminables: casi todo lo que se discute durante semanas se puede decidir en cinco días si se obliga a un grupo pequeño a bocetar, decidir y probar con usuarios reales antes de escribir una sola línea de código de producción. El sprint no reemplaza el trabajo de construir; reemplaza las semanas de indecisión que suelen preceder a esa construcción.
Cómo aplicarlo esta semana
No hace falta un problema del tamaño de una empresa completa para probar el método. Sirve igual para decidir el rediseño de una página de precios, el flujo de alta de un cliente nuevo o la primera pantalla de una aplicación.
Antes del lunes: consigue un Decisor. Sin una persona con autoridad real comprometida a estar presente los cinco días, el sprint se convierte en un ejercicio bonito que nadie ejecuta después. Bloquea también a cuatro o cinco personas más, de áreas distintas, diseño, desarrollo, atención al cliente, quien conozca al usuario de cerca.
Lunes: escribe la meta y las preguntas críticas en una pizarra o un documento compartido, y dibuja el mapa del recorrido del cliente en menos de una hora. Resiste la tentación de hacerlo perfecto; sirve un boceto de diez cajas y unas flechas.
Martes: da veinte minutos a cada persona para bocetar su propia solución en papel, sin hablar con nadie mientras lo hace. Usa la estructura de cuatro pasos: notas, ideas sueltas, ocho variantes rápidas de un minuto cada una, y un boceto final con tres viñetas y texto explicativo.
Miércoles por la mañana: pega todos los bocetos sin nombres y vota con puntos adhesivos. Da a cada persona tres votos y al Decisor el doble. Arma el storyboard esa misma tarde, viñeta por viñeta, con quién hace qué en cada pantalla.
Jueves: reparte el trabajo de la fachada entre quienes sepan diseño, quienes escriban textos y quien prepare el guion de entrevista. Usa la herramienta de prototipado que ya conozcas, no aprendas una nueva esta semana, perderías medio día en tutoriales.
Viernes: agenda cinco entrevistas de una hora, con quince minutos de margen entre cada una para que el equipo compare notas mientras la conversación sigue fresca. Al final del día, reúne al grupo media hora y escribe en una hoja qué patrones vio cada uno, sin discutirlos todavía. La discusión de qué hacer con esos patrones queda para el lunes siguiente, con la cabeza descansada.
Los errores que casi todo el mundo comete con este método
Convocar al sprint como si fuera una reunión de brainstorming ampliada. Si en algún momento del martes la sala empieza a hablar en voz alta sobre qué solución parece mejor, el sprint ya se rompió. El silencio al bocetar no es una formalidad: es lo que impide que la persona más segura de sí misma arrastre al resto antes de que las ideas se hayan puesto sobre la mesa.
No conseguir un Decisor real, y sustituirlo por consenso de grupo. Un sprint sin una persona que decida termina el miércoles con tres ideas empatadas y nadie dispuesto a soltar la propia. El método no es más democrático que una reunión normal; es más rápido porque alguien concreto asume la responsabilidad de elegir.
Pulir demasiado el prototipo del jueves. Un equipo con buenas intenciones y ganas de quedar bien tiende a construir de más, y termina la noche del jueves sin tiempo para ensayar las entrevistas del viernes. El prototipo solo necesita sobrevivir a sesenta minutos de conversación con un desconocido, no a una auditoría técnica.
Elegir un objetivo demasiado amplio el lunes. «Mejorar la experiencia del cliente» no es un objetivo de sprint, es una misión de varios años. El recorte tiene que ser tan concreto que el viernes puedas señalar la pantalla exacta que se probó.
Reclutar usuarios que ya conocen el producto o que se parecen demasiado al equipo. Cinco entrevistas con las personas equivocadas no dicen nada, aunque parezcan cinco datos sólidos. El valor del viernes depende por completo de que quien se sienta frente al prototipo se parezca de verdad al cliente real.
Qué hacer si tu equipo no puede bloquear una semana entera
El supuesto de partida del libro es que puedes reunir a cinco o seis personas durante cinco días completos, sin reuniones ajenas, sin correo, sin apagar incendios de otros proyectos. En una startup de tres personas, en un equipo con guardias rotativas o en cualquier organización donde nadie tiene una semana libre en el calendario, ese supuesto se cae solo. El mecanismo, aun así, se puede adaptar.
Comprime el mapa y el objetivo a una sola mañana. No necesitas un día entero para fijar una meta y dibujar un recorrido de cliente si el problema ya es conocido por el equipo. Dos o tres horas bien enfocadas alcanzan si nadie llega a improvisar.
Reparte los días en vez de juntarlos. Si no puedes bloquear lunes a viernes seguidos, respeta al menos el orden (mapear antes de bocetar, bocetar antes de decidir, decidir antes de construir, construir antes de probar) aunque cada etapa ocupe una tarde suelta en semanas distintas. Lo que no conviene romper es la secuencia: bocetar sin haber decidido el objetivo, o probar sin haber construido nada, deshace el método entero.
Si trabajas solo, sigue siendo tu propio Decisor y recluta a dos o tres personas de confianza solo para las horas de bocetos y la ronda de votos; el resto del proceso lo puedes sostener sin compañía.
Sustituye las cinco entrevistas presenciales por videollamadas cortas si reunir gente en un mismo lugar no es viable por turnos o por distancia. Se pierde algo del lenguaje corporal, pero el patrón que buscas, dónde se confunden casi todos, se ve igual de claro en pantalla.
Lo que no tiene sustituto es el orden y la disciplina de probar con alguien real antes de construir en serio. Eso se puede estirar en el tiempo; no se puede saltar.
Qué ha envejecido mal
Un resumen honesto también señala dónde cojea el libro, publicado en 2016.
El método nació dentro de Google Ventures y lo asume todo. Da por hecho que puedes reservar cinco días completos de un equipo multidisciplinar sin que nadie tenga que atender clientes, arreglar un error en producción o responder a su jefe. Para una empresa con financiación de riesgo y un equipo dedicado, eso es una molestia organizativa. Para un fundador solo, un equipo de tres personas o cualquiera sin ese margen de tiempo, es directamente inviable tal como está descrito.
La muestra de casos de éxito está sesgada. Casi todos los ejemplos del libro son empresas en las que Google Ventures ya había invertido, con acceso a diseñadores expertos, presupuesto y el propio Knapp facilitando la sesión. Eso no prueba que el método funcione igual de bien en manos de un equipo sin ese acompañamiento ni esos recursos extra; prueba que funciona cuando además hay inversión y apoyo profesional detrás.
El «design sprint» se volvió un ritual vacío en muchas empresas. Con los años, la metodología se popularizó tanto que se convirtió en una casilla que marcar antes de cualquier proyecto: se agenda la semana, se compran notas adhesivas, se sigue el guion al pie de la letra, y se pierde el rigor de fondo, sobre todo la disciplina de probar con usuarios reales, en favor de la ceremonia. El resultado en muchos equipos no es mejor criterio, es fatiga de metodología.
Funciona mejor para pantallas que para el resto del mundo. El proceso está pensado para decisiones de producto digital, donde un prototipo de fachada se puede montar en un día. Para un cambio organizacional, una decisión regulatoria o un problema de hardware complejo, no hay fachada que valga: no se puede fingir una pieza física o una política interna delante de un usuario y sacar conclusiones en sesenta minutos.
¿Vale la pena leer el libro entero?
Sí, si vas a facilitar un sprint de verdad. El libro funciona como manual paso a paso, con frases exactas sugeridas para quien facilita y plantillas de horario minuto a minuto. Ese nivel de detalle no cabe en ningún resumen y es la razón de ser del libro.
Sí, si tomas decisiones de producto en equipo y nunca has probado nada con un usuario real antes de construirlo. El cambio de hábito que propone, decidir con evidencia de una tarde de entrevistas en vez de con la opinión de quien habla más fuerte en la reunión, vale la lectura completa aunque nunca sigas el proceso de los cinco días al pie de la letra.
No, si buscas una teoría nueva sobre innovación. El libro no aporta un marco conceptual original; combina técnicas de investigación de usuarios, bocetado individual y prototipado rápido que ya existían por separado, empaquetadas en un calendario. El mérito está en la ejecución, no en la novedad.
No, si tu problema no es de producto digital. Si lo que necesitas decidir es una reestructuración de equipo, una alianza comercial o el diseño de una pieza física compleja, el libro te da poco: el proceso completo asume que al final de la semana hay algo que un usuario puede tocar en una pantalla.
Una advertencia: el libro repite la misma estructura de caso (problema, sprint, éxito) una docena de veces. Con este resumen y las adaptaciones de esta guía tienes el mecanismo completo; el resto son variaciones sobre el mismo tema.
Si te interesó esto, sigue por aquí
- El Método Lean Startup, de Eric Ries, la otra gran escuela para validar antes de construir, con el producto mínimo viable como unidad de prueba en vez del prototipo de fachada de una semana.
- De Cero a Uno, de Peter Thiel, porque el sprint resuelve bien qué construir esta semana, pero no responde si el mercado que persigues merece la pena a largo plazo.
- La Startup de 100$, de Chris Guillebeau, para cuando el problema no es qué prototipo probar, sino si hace falta un equipo de cinco personas y no una sola tarde de trabajo.