Product discovery: qué es y cómo evita construir lo que nadie usa

El product discovery (descubrimiento de producto) es el proceso de entender a fondo un problema de los usuarios y validar qué solución lo resuelve antes de dedicar tiempo y dinero a desarrollarla. Su objetivo es reducir la incertidumbre: comprobar que el problema existe, que a los usuarios les importa lo suficiente y que la solución propuesta es usable, viable para el negocio y técnicamente posible.

Se suele contraponer al delivery, que es la fase de construir y entregar el producto. El discovery responde a qué construir y por qué; el delivery, a cómo construirlo bien. Muchos problemas de los proyectos de software no están en el desarrollo, sino en haber construido algo que nadie necesitaba o de una forma que nadie entendía.

En la literatura de producto se habla de cuatro riesgos. El de valor: ¿los usuarios lo querrán o lo pagarán? El de usabilidad: ¿sabrán usarlo? El de viabilidad: ¿encaja con el negocio, sus costes y su forma de vender? Y el técnico: ¿se puede construir con los recursos disponibles?

Un buen discovery no elimina esos riesgos, pero los hace visibles cuando todavía es barato cambiar de rumbo.

No solo para empresas tecnológicas. Cualquier empresa que vaya a lanzar un producto digital (una aplicación para sus clientes, un portal, una plataforma nueva) se beneficia de pararse a validar antes de construir.

Un discovery clásico tiene dos grandes momentos. Primero, explorar el problema: entrevistas con usuarios, observación de cómo trabajan hoy, análisis de datos existentes y de la competencia. El resultado es una definición clara del problema y de para quién se resuelve.

Después, explorar la solución: generar ideas, priorizarlas y probarlas de la forma más barata posible. Aquí entran los prototipos, las pruebas con usuarios y pequeños experimentos (una página de prueba, una versión manual del servicio) para comprobar si la solución funciona antes de programarla.

Entre las más usadas están las entrevistas en profundidad, los mapas del recorrido del usuario, la priorización por impacto y esfuerzo, los prototipos navegables y los test de usabilidad, en los que se pide a usuarios reales que completen tareas con el prototipo mientras se observa dónde se atascan.

Las grandes empresas suelen dedicar equipos completos y semanas de entrevistas a esta fase. No siempre hace falta tanto: lo importante es no saltarse la validación.

Una definición clara del problema y del usuario, una propuesta de solución validada (o descartada a tiempo), un prototipo y un alcance priorizado para la primera versión del producto.

No hacemos un product discovery como el de una gran empresa que entrevista a decenas de usuarios antes de escribir una línea de código. Trabajamos con empresas que tienen un proyecto claro y conocen su mercado, y nuestro papel es aportar experiencia de negocio y de producto digital para llevarlo a su versión más pequeña capaz de aportar valor.

En la práctica, hacemos muchas preguntas: qué problema resuelve el producto, para quién, qué tiene que pasar para que el usuario lo considere útil. El cliente aporta su conocimiento del mercado y, cuando puede, contrasta las ideas con sus propios clientes. Nosotros traducimos esa propuesta de valor en funcionalidades concretas y en una experiencia de usuario sencilla.

La pieza central es el prototipo. Diseñamos directamente en Figma las pantallas y los flujos principales, y ese prototipo permite visualizar el producto, compartirlo con el equipo, la dirección o futuros usuarios, y tomar decisiones con algo tangible delante. En dos a cuatro semanas se puede tener un prototipo de un producto relativamente amplio que genera discusiones útiles y cierra muchas decisiones.

Ese prototipo se convierte después en la fuente de verdad del desarrollo, de modo que lo validado es exactamente lo que se construye.

Con las herramientas de IA, pasar de una idea a algo que se puede enseñar y probar es hoy mucho más rápido que hace unos años. No siempre se obtiene un producto funcional, pero sí un prototipo suficiente para preguntar a usuarios reales. Eso cambia el discovery: en lugar de muchas rondas de preguntas abstractas, se puede preguntar antes y con algo concreto.

El discovery desemboca en el MVP, el producto mínimo viable: la primera versión que se pone en manos de usuarios reales. El error más común en ese paso es sobredimensionar: añadir funcionalidades por intuición, sin que nadie las haya pedido, y retrasar el lanzamiento meses.

El discovery ayuda a evitarlo porque deja claro cuál es el valor mínimo que el usuario necesita. Todo lo demás (una administración más cómoda, funciones avanzadas, capacidad para miles de usuarios) puede esperar a que los primeros clientes lo pidan.

Depende del proyecto y de lo claro que tenga el cliente su mercado. En nuestros proyectos de MVP, la definición y el prototipo suelen llevar unas dos semanas, y el desarrollo, unas seis: en unas ocho semanas puede estar lista una primera versión del producto, según el alcance.

Si el producto es para un mercado que el cliente no conoce bien, conviene dedicar más tiempo a hablar con usuarios antes de cerrar el alcance.

Nuestro servicio de desarrollo de MVP incluye la definición del alcance, el prototipo en Figma y el desarrollo de una primera versión sólida, preparada para crecer con lo que aprendas de tus usuarios.

El product discovery sirve para comprobar qué problema merece resolverse y con qué solución antes de invertir en desarrollarla, y hace visibles los riesgos de valor, usabilidad, viabilidad y técnico cuando todavía es barato cambiar de rumbo. No siempre hace falta un gran estudio: con un prototipo en la mano se valida lo esencial y se define qué debe incluir el MVP.

Definimos el alcance contigo, diseñamos el prototipo en Figma y desarrollamos la primera versión de tu producto con nuestro servicio para crear un MVP.

Si tienes un producto digital en mente, cuéntanoslo. En una primera conversación te ayudamos a identificar su propuesta de valor y a definir qué debería incluir la primera versión.