Sprint de discovery: qué es, cuánto dura y qué entrega
Las tres semanas que evitan construir bien la cosa equivocada. Qué se hace cada semana, qué documento sale al final y cuándo no merece la pena hacerlo.
Discovery es una palabra de oficio que no significa gran cosa fuera del oficio. Lo que hay debajo es sencillo: dedicar unas semanas a averiguar qué hay que construir, antes de gastar meses construyéndolo.
Suena obvio y casi nadie lo hace. El motivo es que discovery parece que no produce nada, mientras que empezar a diseñar pantallas parece progreso.
Qué problema resuelve
El coste de equivocarse no es lineal. Cambiar de opinión sobre qué construir cuesta una conversación si estás en un documento, un día si estás en un dibujo, y una sprint más una discusión sobre quién se equivocó si ya está en código.
El discovery es comprar esas decisiones cuando todavía son baratas. Nada más.
Las tres semanas, por dentro
Semana 1: entender. Sesiones con quien conoce el negocio y con quien conoce a los clientes. En paralelo, mirar lo que ya existe: tickets de soporte, grabaciones de sesiones, lo que la gente pide por correo. La materia prima ya suele estar dentro de la empresa, dispersa entre tres herramientas y la cabeza de cuatro personas.
Lo que sale de aquí es una lista de problemas candidatos, no una solución.
Semana 2: contrastar. Hablar con usuarios reales, entre cinco y ocho. La regla que hace útil esta semana es preguntar por lo que hicieron la última vez, no por lo que harían. Las respuestas hipotéticas son educadas y falsas; las descripciones de la semana pasada son incómodas y ciertas.
Aquí es donde se caen la mitad de los problemas candidatos. Es la semana que más incomoda y la que más dinero ahorra.
Semana 3: aterrizar. Con un problema que ha sobrevivido, se dibujan los flujos de principio a fin y se resuelven en papel los puntos donde la gente duda. Se especifica lo que haga falta especificar, incluidos los usos de IA si los hay, con qué entra y qué sale.
Sale un documento que el equipo puede presupuestar.
Qué entrega, en concreto
- El problema por escrito: quién lo sufre, en qué momento, qué hace hoy cuando ocurre.
- Dos flujos dibujados completos, con los estados de error y de vacío incluidos.
- Wireframes de los puntos que se atascan.
- Los usos de IA especificados, si aplica, con un ejemplo real y no una promesa.
- La lista de trabajo ordenada, lista para el board.
Lo que no entrega: diseño final, prototipo navegable ni código. Si necesitas algo que se pueda enseñar a un cliente o a un inversor, eso es la fase siguiente y lo explico en prototipo o MVP: cuál necesitas.
Discovery no es lo mismo que auditoría
Se confunden porque las dos empiezan mirando y terminan en un informe. La diferencia es cuándo se hacen.
El discovery va antes de construir: no hay producto todavía, o no hay esa parte del producto. La auditoría de producto va después: hay algo en producción, hay usuarios y hay datos, y lo que quieres saber es por dónde se te están yendo.
Si no hay nada que medir, lo que necesitas es discovery. Si hay usuarios y la métrica baja, es auditoría.
Las tres señales de que hace falta
- El equipo discute soluciones y nadie ha escrito el problema. Si la conversación va de si un desplegable o unas pestañas, y no hay un párrafo que diga a quién le pasa qué, falta discovery.
- Cada área pide algo distinto y todas tienen razón. Sin un problema priorizado, la agenda la marca quien más insiste.
- La última cosa que construisteis no la usa nadie. No es un problema de ejecución. Nadie comprobó antes que hiciera falta.
Cuándo saltárselo
Cuando ya tienes clientes pagando por el problema resuelto a mano, con hojas de cálculo y correo. Ahí la validación la hiciste vendiendo, y meter tres semanas de descubrimiento es ceremonia.
También cuando el cambio es pequeño y reversible. Para decidir el texto de un botón, probar cuesta menos que investigar.
Lo que cuesta no hacerlo
Un sprint de discovery se mueve en torno a las tres semanas y los 2.500 €. Un desarrollo mal dirigido son tres meses y una cifra con un cero más, y el daño de verdad no es ese dinero: es que el producto arrastra durante años una estructura que responde a una hipótesis que ya nadie defiende.
Si quieres ver el alcance exacto y qué se lleva tu equipo al terminar, está en la definición para desarrollo. Y si lo que tienes es producto vivo con la activación cayendo, empieza por cómo diagnosticar una tasa de activación baja.
¿Qué es el discovery en producto?
Es la fase en la que averiguas qué problema hay que resolver y para quién, antes de decidir cómo. Termina con un problema definido, los flujos dibujados y una lista de trabajo ordenada. Sin discovery, el equipo construye la primera solución que se le ocurrió a alguien en una reunión.
¿Cuánto dura un sprint de discovery?
Tres semanas para un alcance de dos flujos críticos. Menos de dos semanas no da tiempo a hablar con usuarios y contrastar lo que dicen con lo que hacen. Más de cuatro suele indicar que el alcance no estaba cerrado al empezar.
¿Qué se lleva mi equipo de desarrollo al terminar?
El problema por escrito con los roles implicados, dos flujos dibujados de principio a fin, wireframes de los puntos donde la gente duda, y la lista de trabajo ordenada por lo que aporta. Suficiente para presupuestar y empezar sin volver a preguntar.
¿Cuándo NO merece la pena hacer discovery?
Cuando ya tienes clientes pagando por el problema resuelto a mano y sabes exactamente qué automatizar. Ahí el descubrimiento ya lo hiciste vendiendo, y lo que toca es construir. También cuando el cambio es pequeño y reversible: para eso el discovery cuesta más que equivocarse.