Casi ningún fundador nos pide que le expliquemos qué es product discovery. Preguntan otra cosa, más concreta: si trabajamos juntos antes de escribir código de producción, ¿qué pasa realmente en esas semanas?
Sobre por qué importa el discovery ya escribimos, y la mayoría de los equipos fondeados ya lo sabe. Lo que cuesta más encontrar es cómo se ve en la práctica: cuánto tiempo lleva, con qué salís, y qué pasa con el runway mientras tanto.
En BlackBox Vision un discovery sprint es corto, lo lideran seniors, y tiene una sola misión: dejar en claro qué problema vale la pena atacar ahora, cómo se ve el producto mínimo viable, y qué se queda afuera del primer release.
Con qué te vas
Salís con un problema afilado: sabés a quién le duele, cuándo le duele, y por qué las alternativas que existen hoy no alcanzan (o si). También salís con un plan de validación que te dice qué supuestos todavía necesitan evidencia antes de que le metas presupuesto grande a un build. Nada de un deck de 40 páginas con un "próximos pasos" que no dice nada concreto.
También te llevás una definición de MVP acotada: la superficie mínima que alcanza para probar demanda, usabilidad o confianza de un inversor. Y, tan importante como eso, una lista explícita de lo que se corta: las features que se sienten importantes pero no se ganaron un lugar en la v1. Sumale una lectura de factibilidad técnica (riesgos, integraciones, decisiones de arquitectura que mueven costo y timeline) y terminás con un camino listo para construir: suficiente claridad como para estimar un MVP enfocado sin inventar scope en el medio del proyecto.
La idea de fondo es esa: que no empieces a gastar plata construyendo algo que no va a servir o que nadie quiere usar.
Para quién es este sprint
Encaja con fundadores Pre-Seed y Seed, técnicos o no, que acaban de levantar una ronda de capital (o están por hacerlo) y necesitan un camino de producto creíble, no una wishlist. También con los que ya pasaron por freelancers, por una software factory o por un prototipo vibecodeado y sienten que el scope se les fue de las manos o lo que tienen está lleno de errores conceptuales, técnicos o de negocio. Y con los que quieren tener criterio de producto e ingeniería sentados en la misma mesa antes de cerrar presupuesto, porque les da miedo quemar meses en algo que nadie termina usando.
Importante: Encaja mal si lo que querés es "la app completa" sin hipótesis de por medio, o si estás comparando únicamente quién cobra menos la hora. El discovery solo sirve cuando estás dispuesto a cortar cosas y aprender durante el proceso.
Cómo corre el sprint en la práctica
Cada engagement se adapta al cliente, pero la lógica de fondo se mantiene siempre igual.
Arrancamos por la decisión de negocio que el producto tiene que destrabar, no por la lista de features. A veces es probar demanda con usuarios tempranos, a veces es tener una demo en el que un inversor confíe, otras es bajar el riesgo de un mecanismo técnico o de IA antes de comprometer presupuesto de producto, y en más de un caso es directamente rescatar un prototipo frágil y volverlo presentable. Hasta que esa decisión no está explícita, cualquier debate de features es puro ruido. Y ahí es donde más énfasis hacemos, porque construir más rápido sobre un backlog borroso solo te deja un producto equivocado.
Después presionamos los supuestos con evidencia. Convertimos la idea en afirmaciones testeables: quién es el usuario, qué hace hoy, qué emociones siente al hacerlo, qué lo haría cambiar de comportamiento, y cómo se ve el éxito en los primeros 30 a 90 días después del lanzamiento. Eso puede implicar entrevistas con founders, charlas con usuarios target, teardown de la competencia, mapeo de workflows o prototipos livianos. No hace falta research exhaustivo: alcanza con la evidencia suficiente para justificar o matar alcance. Venimos viendo el mismo patrón hace años: los equipos que se saltean este paso optimizan por velocidad y después lo pagan con retrabajo. Los que se animan a dar respuestas incómodas temprano terminan trabajando menos y aprendiendo más.
Con el problema una vez claro, diseñamos la experiencia mínima que responde esa decisión: wireframes, flujos, decisiones de interacción, siempre atados al backlog del principio. Acá la lista de cortes se vuelve concreta: los nice-to-haves se nombran en voz alta para que dejen de colarse entre los estimados de tareas principales. Un buen discovery a veces suele incomodar un poco a los fundadores acostumbrados a que les digan que sí a todo, y esa incomodidad casi siempre es una muy buena señal.
Por último entra la ingeniería, lo bastante temprano como para matar cualquier arquitectura de fantasía: riesgo de integración, restricciones del modelo de datos, necesidades de seguridad o compliance, y qué tiene que ser cierto para que el MVP siga siendo mantenible una vez que llega la tracción. Lo que queda es un plan que un equipo senior pueda ejecutar, con alcance, prioridades, riesgos y un camino crítico recomendado hacia MVP Builders, o directamente una pausa deliberada si la evidencia dice que conviene esperar.
Qué queda afuera de un discovery sprint
Todo aquello que genere un roadmap de varios años disfrazado de "MVP", branding que no tiene nada que ver con la decisión de producto, o workshops infinitos con stakeholders que nadie pidió. Si alguien te vende discovery como facilitación sin fin, lo que te está vendiendo es tiempo en el calendario y cobrando por ello. Un product studio te tiene que vender una decisión de construcción de producto lo más pequeña y afilada posible.
Cómo sabés que el sprint funcionó
Hay una forma simple de chequearlo. Fijate si podés explicar el producto en una oración sin listar features, si podés nombrar tres cosas que no vas a construir en la v1 y por qué, si un software engineer senior puede estimar el primer release sin inventar requerimientos, y si seguirías fondeando ese mismo alcance aunque mañana el runway se te achique un 20%. Si todo eso te sale natural, estás listo para construir. Si alguna respuesta todavía es borrosa, te falta discovery.
Discovery es el "cómo un product studio se gana la confianza"
Una agencia te garantiza "entregables", una factory te cierra "tickets" y un freelancer te cobra horas. Un product studio se gana el derecho a construir cuando demuestra que va a analizar, pensar y discutir con vos el roadmap antes de hacerte gastar tu capital porque sí. Por eso el discovery va adelante en cómo trabajamos, y por eso conecta tan directo con cómo evaluás un partner de desarrollo: si nadie es responsable por la calidad de la decisión, el discovery termina siendo teatro y el build termina siendo una feature factory.
Qué sigue
La mayoría de los fundadores sale de un discovery sprint en uno de tres lugares: con el scope claro y listo para pasar a un MVP enfocado, con uno o dos supuestos que todavía necesitan evidencia barata antes de meterle ingeniería, o con la conclusión de que la idea original todavía no merece un presupuesto grande. Los tres son buenos resultados si protegen el runway. Lo caro de verdad es shippear seis meses del producto equivocado, con mucha confianza y poca evidencia.
Si estás comparando partners, pediles que te expliquen paso a paso cómo sería su discovery sprint, igual que hicimos acá: entregables, criterios de corte, criterios de aceptación, y qué significa "terminado" (DoD). Si no pueden, no te están vendiendo claridad. Te están vendiendo un kickoff.
