Discovery de producto: cómo entender de verdad al usuario
El discovery de producto es el trabajo de entender a fondo a quién sirves y qué necesita antes y durante la construcción. Suena obvio, pero la mayoría de los equipos lo saltan o lo hacen mal: dan por hecho que ya conocen al usuario y se lanzan a construir sobre suposiciones que nunca contrastan. El resultado son productos técnicamente correctos que nadie usa.
Hacer discovery bien no es un lujo de equipos grandes ni una fase que se hace una vez y se cierra. Es una práctica continua de salir a buscar la realidad del usuario en lugar de imaginarla desde la oficina. En este artículo explicamos en qué consiste, cómo evitar las trampas que lo invalidan y cómo convertir lo que aprendes en decisiones de producto mejores.
Observa el comportamiento, no solo las opiniones
La fuente más fiable de aprendizaje no es lo que el usuario dice, sino lo que hace. Las opiniones están llenas de cortesía, racionalizaciones y deseos que no se traducen en acciones. El comportamiento real (qué herramientas usa hoy, dónde se atasca, qué apaños se monta) revela el problema de verdad. Por eso el discovery combina conversaciones con observación directa siempre que es posible.
Cuando hables con usuarios, ancla las preguntas en hechos pasados y concretos en lugar de hipótesis futuras. "¿Cómo lo resolviste la última vez?" enseña mucho más que "¿qué te gustaría?". El pasado revela el comportamiento; el futuro solo recoge buenas intenciones.
Cómo hacer discovery sin perder tiempo
El discovery no tiene por qué ser un proceso largo y costoso. Unas pocas prácticas bien ejecutadas dan la mayor parte del valor y se integran en el ritmo normal de trabajo.
- Habla con usuarios reales de forma regular, no solo al principio del proyecto.
- Pregunta por situaciones pasadas concretas en lugar de preferencias generales.
- Busca patrones que se repiten entre varias personas, no anécdotas sueltas.
- Contrasta lo que dicen con lo que hacen siempre que puedas observarlo.
Convierte el aprendizaje en decisiones
El discovery solo vale si cambia lo que construyes. Demasiados equipos investigan, generan un montón de notas y luego siguen haciendo lo que ya habían decidido. El aprendizaje tiene que llegar a la priorización y al diseño, descartando ideas que el usuario no necesita y reforzando las que resuelven un dolor real y repetido.
También sirve para distinguir lo que parece un problema de lo que lo es de verdad. Muchas peticiones de usuarios son soluciones disfrazadas; el discovery te ayuda a llegar al problema que hay debajo, que casi siempre se resuelve mejor de otra forma. Entender eso es lo que separa construir lo que piden de construir lo que necesitan.

Escrito por
Fernando Blanco DosilProduct Engineer al que le mueve convertir ideas en producto. Escribe sobre desarrollo, datos y cómo llevar proyectos de la chispa a la realidad.
Ver perfil →Artículos relacionados
Cómo trabajar con un estudio de software externo
Claves para trabajar con un estudio de software externo: cómo colaborar, qué esperar y cómo lograr que entregue resultados y no solo horas.
Deuda técnica: cuándo asumirla y cuándo pagarla
Qué es la deuda técnica, cuándo conviene asumirla para ir rápido y cuándo toca pagarla antes de que frene el desarrollo del producto.
Cómo construir en ciclos cortos sin perder calidad
Cómo desarrollar producto en ciclos cortos manteniendo la calidad: prácticas para iterar rápido sin acumular deuda ni romper lo que ya funciona.