1. Blog de Pulsión Digital
2. Empresas

• Actualizado: octubre 21, 2026

Qué es product discovery y cómo hacerlo paso a paso con IA

Product discovery es la parte del trabajo de producto que decide qué construir antes de invertir semanas de desarrollo en construirlo. Si alguna vez viste un equipo lanzar una función que nadie usó, ya conoces el problema que resuelve: no faltó talento para programar, faltó evidencia para elegir 🔍

En esta guía vas a ver qué es el discovery según los autores que más lo trabajaron, en qué se diferencia del delivery, un proceso de seis pasos que puedes aplicar desde la semana que viene y dónde la inteligencia artificial te ahorra horas (y dónde no debe reemplazarte). Al final tienes un ejercicio práctico y una plantilla de entrevista.

¿Quieres aprender a decidir qué construir con método y con IA?

Qué es product discovery

La forma más simple de definirlo la da Teresa Torres, autora de Continuous Discovery Habits (Product Talk, 2021): discovery son todas las actividades que hace un equipo para decidir qué construir. Delivery, en cambio, es el trabajo de escribir código, empaquetar versiones y lanzar productos para entregar valor a los clientes.

Dicho de otra manera, el discovery responde a la pregunta «¿estamos construyendo lo correcto?» y el delivery a «¿lo estamos construyendo bien?». Las dos importan, pero la primera es más barata de responder: cambiar una idea en una pizarra cuesta minutos; cambiar una función ya programada cuesta sprints.

El discovery no es una fase de investigación académica ni un documento de cien páginas. Es un trabajo práctico y de ritmo corto, hecho por el mismo equipo que después va a construir. Incluye:

• Hablar con usuarios para entender cómo resuelven hoy su problema.
• Detectar oportunidades: necesidades, dolores y deseos que, si se atienden, mueven un resultado de negocio.
• Formular hipótesis y explicitar los supuestos de cada idea.
• Probar barato: prototipos, pruebas de usabilidad, landings, pruebas «de mago de Oz» en las que una persona hace a mano lo que después hará el software.
• Decidir con la evidencia reunida qué pasa a desarrollo, qué se descarta y qué necesita otra prueba.

Si estás empezando en producto, conviene leer antes qué es un product manager y qué hace, porque el discovery es una de sus responsabilidades centrales.

Product discovery vs. delivery: en qué se diferencian

La confusión más frecuente es pensar que discovery y delivery son etapas en fila: primero se investiga durante meses y después se construye. En los equipos que mejor funcionan son dos carriles que avanzan en paralelo: mientras desarrollo construye lo que ya se validó, el equipo sigue investigando lo que viene. A esto se le suele llamar dual-track.

Aspecto	Product discovery	Product delivery
Pregunta que responde	¿Qué deberíamos construir y por qué?	¿Cómo lo construimos y lanzamos bien?
Resultado típico	Evidencia, decisiones, ideas descartadas	Software funcionando en producción
Unidad de trabajo	Entrevista, prototipo, prueba de supuesto	Historia de usuario, sprint, release
Costo de equivocarse	Bajo: se descarta una prueba	Alto: se rehace código ya entregado
Velocidad	Horas o días por experimento	Semanas por funcionalidad
Quién participa	Producto, diseño e ingeniería juntos	Todo el equipo de desarrollo, con producto acompañando
Señal de éxito	Aprendiste algo que cambia una decisión	Se lanzó con calidad y se mide el impacto

Fíjate en la fila del costo: esa es la razón de ser del discovery. No elimina el riesgo, pero lo traslada a un lugar donde equivocarse es barato.

Los cuatro riesgos que el discovery intenta reducir

Marty Cagan, fundador de Silicon Valley Product Group (SVPG) y autor de Inspired, resume el objetivo del discovery en enfrentar cuatro riesgos antes de construir. En su artículo «The Four Big Risks» los describe así:

1. Riesgo de valor: si los clientes lo comprarán o si los usuarios elegirán usarlo.
2. Riesgo de usabilidad: si los usuarios sabrán cómo usarlo.
3. Riesgo de factibilidad: si los ingenieros pueden construir lo necesario con el tiempo, las habilidades y la tecnología disponibles.
4. Riesgo de viabilidad de negocio: si la solución también funciona para el resto del negocio (ventas, legales, finanzas, marca).

Cagan también propone repartir la responsabilidad: producto se ocupa sobre todo del valor y la viabilidad, diseño de la usabilidad e ingeniería de la factibilidad. Por eso el discovery no es tarea de una sola persona. Torres llama trío de producto a ese equipo mínimo de producto, diseño e ingeniería que investiga junto.

Una forma útil de usar los cuatro riesgos: antes de cada idea, escribe una frase por riesgo empezando con «Creemos que…». Las frases en las que tengas menos evidencia son las que debes probar primero.

Continuous discovery: el discovery como hábito semanal

Durante años, muchas empresas hicieron «discovery» como un proyecto puntual: una gran investigación al inicio y después nada. Torres propone lo contrario. Define el continuous discovery como contactos semanales con clientes, hechos por el mismo equipo que construye el producto, en los que se realizan pequeñas actividades de investigación en busca de un resultado deseado.

Tres ideas de esa definición cambian la forma de trabajar:

• Semanal: el contacto con usuarios es una rutina, no un evento. Una entrevista por semana, sostenida un año, da unas cincuenta conversaciones.
• El equipo que construye: no se delega todo en un área de investigación que entrega un informe. Quien decide escucha de primera mano.
• Un resultado deseado: se investiga para mover una métrica concreta (por ejemplo, activación o retención), no por curiosidad general.

El Opportunity Solution Tree

La herramienta más conocida de Torres es el árbol de oportunidades y soluciones (Opportunity Solution Tree), que presentó en 2016. Es una forma visual de mostrar los caminos posibles hacia un resultado deseado y tiene cuatro niveles:

1. Resultado (la raíz): la necesidad de negocio que el equipo quiere mover.
2. Oportunidades: necesidades, dolores y deseos de los clientes que, si se atienden, mueven ese resultado.
3. Soluciones: las ideas que se exploran para cada oportunidad.
4. Pruebas de supuestos: cómo se evaluará qué soluciones crean valor para el cliente de una forma que también genere valor para el negocio.

Su fuerza está en que obliga a no saltar de un resultado («subir la retención») directo a una solución («hagamos un programa de puntos») sin pasar por el problema real del usuario. Cuando un stakeholder propone una idea, el árbol permite preguntar: ¿a qué oportunidad responde esto?

Cómo hacer product discovery paso a paso

Este proceso de seis pasos sirve para un equipo de producto que empieza o para una persona emprendedora que valida una idea sola. Ajusta los tiempos a tu contexto, pero no te saltes pasos.

Paso 1. Define el resultado que quieres mover

Empieza por una métrica, no por una función. «Que el 40 % de quienes se registran complete su primera tarea en la primera semana» es un buen resultado; «lanzar un tutorial interactivo» no lo es, porque ya es una solución. Si te cuesta formularlo, vuelve a la estrategia: ¿qué tiene que pasar en el negocio este trimestre?

Paso 2. Habla con usuarios cada semana

Las entrevistas de discovery no preguntan «¿te gustaría que la app hiciera X?», porque la gente es mala prediciendo su comportamiento futuro. Preguntan por historias concretas del pasado: «Cuéntame la última vez que tuviste que…». Cuanto más específica la historia, mejor la evidencia.

Algunas reglas que ayudan:

• Recluta de forma automática (por ejemplo, un mensaje dentro del producto que ofrece una charla de 20 minutos) para no depender de la buena voluntad de cada semana.
• Entrevisten de a dos: una persona conduce y otra toma notas.
• Pide permiso para grabar y aclara para qué se usará la grabación.
• Resume cada entrevista en una ficha de una página el mismo día.

Si quieres profundizar en técnicas de investigación, te servirá la guía sobre qué es UX research, y para no perder de vista para qué contrata el usuario tu producto, la metodología Jobs to Be Done.

Paso 3. Mapea las oportunidades

Después de varias entrevistas aparecen patrones: dolores que se repiten, momentos de frustración, atajos caseros que la gente inventó. Esas son tus oportunidades. Ordénalas en el árbol bajo el resultado y agrúpalas: las oportunidades grandes («no entiendo si estoy usando bien la herramienta») se dividen en otras más pequeñas y accionables («no sé qué hacer después de crear mi primer proyecto»).

Paso 4. Genera varias soluciones y explicita sus supuestos

Para la oportunidad elegida, piensa al menos tres soluciones distintas. Compararlas evita enamorarse de la primera. Luego, para cada una, escribe sus supuestos con los cuatro riesgos: ¿qué tiene que ser cierto para que funcione? Ejemplo: «Los usuarios abren el correo de bienvenida» o «Podemos integrar el calendario sin rehacer la base de datos».

Paso 5. Prueba los supuestos más riesgosos, no la solución entera

No hace falta construir la función para aprender. Elige la prueba más barata que pueda darte una señal clara:

• Prototipo navegable en una herramienta de diseño para probar usabilidad con cinco personas.
• Landing de demanda: una página que describe la propuesta y mide cuántas personas dejan su correo.
• Prueba de mago de Oz: el usuario ve el servicio, pero detrás una persona lo resuelve a mano.
• Prueba de una pregunta dentro del producto para medir cuántos usuarios tienen el problema.

Define antes de empezar qué resultado te haría seguir y cuál te haría descartar. Si decides el criterio después de ver los datos, cualquier resultado parecerá un éxito. Cuando una solución supera las pruebas, puedes pasar a una versión mínima: la guía sobre qué es el producto mínimo viable te ayuda a recortarla bien.

Paso 6. Decide, comunica y vuelve a empezar

Con la evidencia en la mano, decide: construir, ajustar o descartar. Comparte el aprendizaje con el resto de la empresa en un formato breve (qué creíamos, qué probamos, qué aprendimos, qué hacemos ahora). Lo que pasa a desarrollo entra al carril de delivery y al roadmap de producto; el discovery sigue con la siguiente oportunidad.

Técnicas de product discovery más usadas

Técnica	Qué riesgo reduce	Cuándo usarla	Tiempo aproximado
Entrevistas basadas en historias	Valor	Siempre, de forma semanal	30 minutos por entrevista
Proto-personas	Valor	Al inicio, para alinear hipótesis sobre quién es el usuario	Un taller corto
Prototipo de baja o alta fidelidad	Usabilidad y valor	Cuando ya hay una solución candidata	De horas a pocos días
Landing de demanda	Valor y viabilidad	Producto nuevo o funcionalidad paga	Uno o dos días
Mago de Oz o concierge	Valor	Servicios que serían caros de automatizar	Días o semanas
Spike técnico	Factibilidad	Integraciones o tecnología nueva	Uno a tres días
Revisión con ventas, legales o finanzas	Viabilidad de negocio	Precios, contratos, datos personales	Una reunión

Las proto-personas son útiles como punto de partida siempre que las trates como hipótesis a validar; aquí explicamos qué es una proto-persona y cómo crearla.

Cómo usar la IA en el product discovery (y dónde no)

La inteligencia artificial cambió la parte más lenta del discovery: procesar lo que se escucha. Hoy es razonable transcribir una entrevista, resumirla y agrupar patrones en minutos. Pero su mejor uso es acelerar la síntesis, no reemplazar la conversación.

Dónde la IA ayuda de verdad

• Preparar la guía de entrevista: pídele que convierta tus hipótesis en preguntas abiertas sobre el pasado y que marque las preguntas que inducen la respuesta.
• Transcribir y resumir: una ficha por entrevista con citas textuales, momentos de frustración y soluciones caseras.
• Agrupar patrones entre muchas entrevistas y proponer oportunidades candidatas para el árbol.
• Generar variantes de solución para salir de la primera idea.
• Prototipar rápido pantallas o textos de una landing.

Dónde no debe reemplazarte

• La conversación misma. Un modelo de lenguaje puede simular un «usuario promedio», pero no conoce la historia concreta de tu cliente ni el contexto en el que usa tu producto. Las respuestas inventadas suenan convincentes justamente porque son genéricas.
• La decisión. La IA puede ordenar evidencia; decidir qué riesgo aceptar es responsabilidad del equipo.
• La verificación de citas. Comprueba siempre que una frase atribuida a un usuario esté en la transcripción original. Un resumen puede mezclar entrevistas.

Un cuidado práctico: antes de subir grabaciones a una herramienta externa, revisa qué consentimiento diste a los usuarios y qué política de datos tiene esa herramienta. Si las entrevistas contienen información sensible, quita nombres y datos identificables.

Un prompt para sintetizar entrevistas

«Te paso la transcripción de una entrevista de discovery. Devuélveme: 1) la historia principal en cinco líneas, 2) los dolores mencionados con la cita textual que los respalda, 3) las soluciones que la persona usa hoy, 4) supuestos nuestros que esta entrevista confirma o contradice. No inventes nada que no esté en el texto; si algo no aparece, escribe «no surge de la entrevista».»

Errores comunes en product discovery

1. Validar en lugar de aprender. Si el equipo entra a las entrevistas buscando que le digan que sí, va a encontrar cómo escucharlo.
2. Preguntar por el futuro. «¿Pagarías por esto?» genera respuestas amables, no evidencia.
3. Hacer discovery una sola vez. Las necesidades cambian; el contacto semanal evita decidir con datos viejos.
4. Dejar afuera a ingeniería. Los riesgos de factibilidad aparecen tarde y caros.
5. Probar la solución entera cuando bastaba probar un supuesto.
6. No documentar lo descartado. Las ideas que no pasaron la prueba también son aprendizaje y evitan repetir discusiones.

Ejercicio práctico: tu primera semana de discovery

Elige un producto real (el tuyo, el de tu empresa o una app que uses) y sigue este plan de cinco días, unos 45 minutos por día:

Día	Tarea	Entregable
Lunes	Escribe el resultado que quieres mover y por qué importa	Una frase con métrica
Martes	Prepara una guía de 6 preguntas sobre historias pasadas	Guía de entrevista
Miércoles	Haz dos entrevistas de 20 a 30 minutos	Dos fichas de una página
Jueves	Dibuja el árbol: resultado, 3 oportunidades, 3 soluciones para una	Árbol en papel o pizarra
Viernes	Elige el supuesto más riesgoso y diseña una prueba con criterio de éxito	Plan de prueba de una página

Preguntas de ejemplo para el martes: «Cuéntame la última vez que…», «¿Qué hiciste justo antes?», «¿Qué fue lo más difícil?», «¿Cómo lo resolviste?», «¿Qué pasó después?», «¿Hay algo más que debería haberte preguntado?».

Cómo lo aprendes en Pulsión Digital

En Pulsión Digital creemos que la IA vuelve más valiosas las habilidades humanas de escuchar, decidir y comunicar. El curso de Product Manager con IA dedica un módulo entero a «Descubrimiento: hablar con usuarios y sintetizar con IA» y lo conecta con el resto del ciclo: visión y estrategia, priorización con RICE y Kano sobre un backlog de ejemplo, PRDs, roadmap y comunicación con stakeholders, trabajo con diseño y desarrollo, métricas de activación, retención y NPS, y lanzamientos.

• A tu propio ritmo, con clases cortas que puedes retomar cuando quieras.
• Examen en cada clase para fijar lo aprendido antes de avanzar.
• Tutor con IA para resolver dudas sobre tu propio producto.
• Comunidad de personas con intereses parecidos para intercambiar casos.
• Certificado al completar el curso.

Si tu rol está más cerca del diseño, el curso de UX Design con IA profundiza en investigación de usuarios, prototipado rápido y testing de usabilidad con pocos recursos. Y si coordinas equipos y entregas, el curso de Project Manager Digital con IA complementa el lado del delivery.

Preguntas frecuentes sobre product discovery

¿Qué es product discovery en pocas palabras?

Es el trabajo que hace un equipo para decidir qué construir: entender problemas reales de los usuarios, generar soluciones y probarlas de forma barata antes de invertir en desarrollo.

¿Cuál es la diferencia entre product discovery y product delivery?

El discovery decide qué construir y por qué; el delivery diseña, desarrolla y lanza lo que ya se validó. En los equipos maduros avanzan en paralelo, no como etapas sucesivas.

¿Qué es continuous discovery?

Es la práctica, propuesta por Teresa Torres, de tener contactos semanales con clientes hechos por el mismo equipo que construye el producto, con pequeñas actividades de investigación orientadas a un resultado deseado.

¿Quién hace el product discovery?

Idealmente el trío de producto: product manager, diseño e ingeniería. Cada uno aporta una mirada distinta sobre los riesgos de valor, usabilidad, factibilidad y viabilidad.

¿Cuánto dura un product discovery?

No tiene una duración fija. Una prueba de supuesto puede durar horas o días; el discovery como práctica es continuo y acompaña al producto mientras exista.

¿Puede la IA hacer el product discovery por mí?

Puede acelerar la preparación de entrevistas, la transcripción, la síntesis y el prototipado. No reemplaza la conversación con usuarios reales ni la decisión del equipo, y sus resúmenes deben contrastarse con las transcripciones.

Conclusión

El product discovery es la diferencia entre construir lo que se le ocurrió a alguien y construir lo que la evidencia respalda. No requiere grandes presupuestos: requiere un resultado claro, conversaciones semanales con usuarios, el hábito de explicitar supuestos y pruebas pequeñas con criterios definidos de antemano. La IA hace más rápida la síntesis, pero la escucha y la decisión siguen siendo humanas. Empieza con el ejercicio de cinco días y, cuando quieras convertirlo en un sistema completo, el curso de Product Manager con IA te acompaña paso a paso.

Fuentes consultadas

• Torres, T. (2021). Continuous Discovery Habits. Product Talk.
• Product Talk. Discovery vs. delivery (glosario).
• Product Talk. Continuous discovery (glosario).
• Product Talk. Opportunity Solution Trees.
• Cagan, M. (2017). The Four Big Risks. Silicon Valley Product Group.
• Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love, 2.ª edición. Wiley.