¿Qué es el discovery de producto? La etapa que decide si el proyecto sale bien

Discovery de producto es el proceso de entender a fondo qué necesita realmente un proyecto —el problema de negocio, las restricciones técnicas, la escala esperada y qué es lo mínimo indispensable para resolverlo— antes de escribir la primera línea de código o de elegir con qué equipo se va a construir. No es "juntar requerimientos" en una reunión inicial: es el trabajo que reduce cuatro riesgos concretos antes de invertir presupuesto y tiempo de desarrollo —si el problema vale la pena resolver, si alguien va a poder usar la solución, si es técnicamente viable con el tiempo y el equipo disponibles, y si el negocio la sostiene— antes de comprometerlos en construirla.

Existe porque lo que una empresa pide al arrancar casi nunca es una especificación completa: es una necesidad expresada en lenguaje cotidiano —"necesitamos un sistema que ordene mejor los pedidos"— que hay que traducir en un alcance concreto y accionable antes de que alguien empiece a programar. Saltear ese paso no ahorra tiempo: lo traslada más adelante, a un punto donde corregir un malentendido de alcance cuesta bastante más que haberlo resuelto en una conversación.

¿Por qué importa el discovery antes de escribir código?

Porque el costo de un error de alcance crece cuanto más tarde se detecta. El framework de los "cuatro grandes riesgos" de Marty Cagan (Silicon Valley Product Group) organiza el discovery justamente alrededor de esa idea: antes de construir, un equipo tiene que resolver el riesgo de valor (¿a alguien le importa este problema?), el de usabilidad (¿alguien va a poder usarlo?), el de factibilidad (¿se puede construir con el tiempo y la tecnología disponibles?) y el de viabilidad de negocio (¿funciona para el negocio, no solo para el usuario?). Ninguno de los cuatro se resuelve mirando código —se resuelve conversando, investigando y, sobre todo, antes de escribir la primera línea.

• Riesgo de valor — si el problema que se va a resolver le importa de verdad al usuario o al negocio.
• Riesgo de usabilidad — si las personas van a entender cómo usar lo que se construye.
• Riesgo de factibilidad — si el equipo puede construirlo con el tiempo, el stack y la gente disponibles.
• Riesgo de viabilidad de negocio — si la solución funciona también para legal, finanzas o la estrategia comercial, no solo para el usuario.

Cuando el discovery se salta o se hace mal, esos riesgos no desaparecen: aparecen después, ya con desarrollo hecho. El PMI (Pulse of the Profession, 2014) encontró que el 47% de los proyectos que no cumplen sus objetivos fallan por una gestión de requerimientos inexacta —la causa individual más citada de fracaso de proyecto en ese estudio, por encima de problemas de presupuesto o de cronograma.

¿El discovery es una etapa única o un hábito continuo?

Depende del modelo que se use, y la diferencia importa. El enfoque tradicional trata el discovery como una fase que pasa una vez, al principio, antes de pasar a "delivery" y no volver atrás. Teresa Torres, en Continuous Discovery Habits (2021), plantea un modelo distinto: discovery como un hábito semanal del equipo, no un proyecto de una sola vez —conversar con usuarios reales, probar supuestos chicos y ajustar el rumbo de manera constante, en paralelo a que el desarrollo avanza (lo que ella y Cagan llaman "dual-track": discovery y delivery corriendo en simultáneo, no en secuencia).

La diferencia práctica es esta: en el modelo de una sola fase, un cambio de contexto —el negocio cambia de prioridad, aparece un competidor, el usuario reacciona distinto a lo esperado— rompe un plan que ya se cerró. En el modelo continuo, ese cambio se detecta en la conversación de la semana siguiente, no seis meses después, cuando el producto ya está construido y no encaja.

¿Qué cambia cuando el discovery se arma escuchando reuniones con IA en vez de un PM tomando notas a mano?

La mayor parte de la información de discovery no vive en un documento: vive dispersa en reuniones —la que se tuvo con el equipo de producto, la que se tuvo con soporte, la que se tuvo con un cliente enojado por una funcionalidad rota. Un PM que toma notas a mano pierde matices entre una conversación y la siguiente, y reconstruye el panorama completo de memoria. Por eso el software de transcripción y notas con IA en reuniones dejó de ser una curiosidad: según la encuesta State of AI Meeting Notetakers 2025 de Fellow.ai, el 75% de los profesionales relevados ya usa un asistente de IA en sus reuniones de trabajo.

Pero la misma encuesta muestra el lado incómodo de esa adopción: el 84% de los encuestados dijo que modifica lo que dice cuando nota que hay un bot de IA grabando, y el 47% reportó que un asistente de este tipo grabó o compartió algo que no pretendía que quedara registrado. Adoptar IA en las reuniones sin ser explícito sobre qué se graba y para qué no resuelve el problema del discovery disperso —lo empeora, porque además rompe la confianza de la conversación que se supone que hay que entender a fondo.

¿Cómo lo hace Kaizen en Zenit?

Kaizen es el motor de discovery de Zenit, y arranca ahí —no en un formulario de intake. Se suma a las reuniones del equipo del lado empresa como un participante más, no como un bot escondido, y cruza lo que escucha en distintas conversaciones para armar un solo mapa del proceso real: qué existe, qué falta, dónde aparecen versiones contradictorias de la misma prioridad. Ese mapa se convierte en un brief vivo —alcance, milestones, requisitos de equipo— antes de que arranque cualquier match con un squad.

La diferencia frente a un discovery tradicional no es solo la velocidad: es que ese brief no se pierde ni se vuelve a redactar de memoria seis meses después. Es la misma memoria que después guía el matching, la ejecución milestone a milestone y —si hace falta— la transferencia de contexto a un squad de reemplazo.

El discovery también es la razón por la que el matching automático por keywords no alcanza: sin entender el contexto real del proyecto, cualquier match es una apuesta con información incompleta.