‍

A veces, siento que el acercamiento que se le quiere dar al concepto de “Product Discovery”, es un poco genérico o repite muchos consejos bien intencionados pero trillados:

📌 Hablar con los usuarios.

📌 Definir el problema.

📌 Valida la solución.

No es que estén mal: al contrario, estos consejos tienen fundamento en la experiencia y son verdades compartidas con justa razón.

El problema está en que se venden como insights cuando ya son parte del mindset de producto hace años.

Ya todos, al menos teóricamente, los conocemos.

Dicho esto, los desafíos por los que pasa hoy en día, a mayo 2025, un Product Manager o un Product Designer en un Product Discovery son otros.

Son mucho más sutiles y no pasan tanto por no conocer las “reglas”, sino de cómo adecuarlas al contexto adecuado para implementarlas bien.

En esta publicación, me gustaría compartirte 7 principios no tan obvios para llevar un Product Discovery de forma efectiva.

¡Vamos a ello!

‍

1) Enamorarse del problema está bien... solo luego de entender qué causa o sistema lo sostiene.

¿Cuántas veces has leído “Enamorarse del problema, no de la solución”?

Bueno, la acabas de leer una vez más. 😅

Todo proceso de Product Discovery entiende muy bien de la prioridad que tiene el problema en un research.

Después de todo, es la base que sostiene las soluciones.

Si está mal definido, entonces todo lo que sigue no tiene mucho sentido.

Pero, la verdad es que, el problema no deja de ser un síntoma.

Y abandonar un research justo después de haber encontrado el problema, es un grave error.

De hecho, muchas veces, ¡es la parte más fácil!

Imagina que un equipo se obsesiona con la baja retención en su app.

Investigan, mapean fricciones, diseñan nuevas experiencias… y nada funciona.

Resulta que el problema no estaba en la UX: era el propio modelo de negocio que incentivaba la adquisición de cuentas no calificadas desde canales de bajo valor.

Un buen Product Discovery no se queda en la superficie del problema, busca enamorarse de sus raíces, de sus causas, de los sistemas que lo sostienen y lo habilitan en primer lugar.

Interroga al problema.

Lo desarma, lo contextualiza.

Por eso es importante comprender que el impacto no solo está en solucionar cosas rotas, sino entender en primer lugar por qué se rompieron.

‍

2) El Discovery no empieza con el usuario, sino con el negocio.

El enfoque en el usuario está muy bien, pero no debe ser lo único.

No solo se trata de “resolver necesidades”, sino de hacerlo desde una intención estratégica.

No olvidar que, así como un cliente o usuario tiene sus propios objetivos, también los tiene el negocio.

Y no tiene sentido volverse experto en entender al usuario si uno no sabe para qué estás investigando en primer lugar.

Es Product Discovery en abstracto, sin ningún norte.

Esto lleva luego a la identificación de oportunidades que están desalineadas con el impacto que se quiere lograr.

Por tal razón, es importante siempre partir el Discovery desde una intención clara del negocio, así tus hallazgos se vuelven relevantes y accionables.

El usuario importa, pero el contexto de negocio le da sentido.

‍

3) El riesgo no se elimina. Se mitiga.

El punto principal de un Product Discovery es gestionar la incertidumbre, no erradicarla.

No tiene sentido pasarse semanas e incluso meses buscando certezas absolutas.

Hacerlo lleva a que un equipo no avance porque “aún no validaron del todo” una hipótesis.

Equipos con esa mentalidad llevan 3 meses paralizados y, en lugar de construir un producto de forma progresiva, busca una señal definitiva.

Spoiler: nunca llega.

Por eso, creo que un buen discovery se mueve en zonas grises.

Aprende a decir: “esto no es 100% seguro, pero es lo suficientemente probable para el próximo paso”.

La idea no es buscar garantías, sino buscar márgenes seguros de aprendizaje.

Abrazar el riesgo, y trabajar para incrementar nuestras chances de éxito.

Y en caso de que no suceda, aprenderemos rápido y nos irá mejor la próxima vez.

‍

4) Los usuarios no se promedian.

Sé que existen User Persona, pero después de todo, en las conversaciones de muchos equipos se sigue refiriendo al usuario como “el usuario”.

“El usuario quiere esto”, el usuario quiere lo otro…

La cuestión es: ¿qué usuario?, ¿en qué contexto?, ¿bajo cuál necesidad?.

Diseñar una solución durante un Product Discovery considerando al usuario promedio puede traer más de un problema debido a que, muchas veces, ese promedio no existe.

Cuando hay necesidades diferenciadas con claridad.

Cuando hay distintos objetivos bien definidos.

Cuando existen contextos de uso particulares.

En estas situaciones, deberíamos estar hablando de segmentos, con motivaciones y comportamientos especiales.

Un promedio de distintas necesidades, objetivos y contextos lleva a una definición de usuario genérica y poco accionable.

Para un discovery efectivo, necesitas segmentar en función los jobs, comportamientos y los momentos de uso.

‍

5) El discovery debe ser incómodo, debe despertar fricciones.

A veces, siento que los Product Discovery son demasiado “políticamente correctos”.

Entrevistas agradables con usuarios, talleres creativos de brainstorming y sesiones creativas de prototipado.

Algo que me parece súper necesario al validar oportunidades y soluciones en un discovery, es introducir “conflicto saludable”.

Y una gran manera de hacerlo es a través del cuestionamiento, ya sea sobre creencias colectivas sobre diseño de producto o ideas de una colaborador en particular.

Si un desarrollador o diseñador cree que una solución no tiene sentido, es necesario tener sistemas y procesos para que puedan levantar la mano y expresar puntos de vista distintos.

No tiene porque ser armonioso el proceso de Discovery.

Debe poder adecuarse a conversaciones difíciles sobre la deseabilidad, viabilidad y factibilidad de las ideas.

Si el proceso no incomoda a nadie, es probablemente que no estemos descubriendo nada nuevo en particular.

‍

6) No valides tu idea. Invalidá tu ego.

No hay nada peor que diseñar un experimento solo para confirmar lo que el equipo quiere creer.

En un Product Discovery, hay que tener cuidado de las “validaciones tramposas”.

Por ejemplo, un diseñador construye un prototipo para confirmar una hipótesis.

Luego, en la prueba de usabilidad, guía al usuario hacía cada respuesta deseada.

Después de 5 pruebas, da por finalizado el test con éxito.

Pero, ¿realmente fuimos lo suficientemente neutrales?

Hacer discovery debe estar apuntado a romper con tus creencias, no confirmarlas.

A demostrar que estás equivocado.

Hacer preguntas sin sugestión, escuchar sin filtrar información e invitar a la contradicción son algunas maneras en las que podemos hacer research de manera más inteligente.

Está bien validar, pero ante todas las cosas, primero hay que dudar de nosotros mismos.

‍

7) El Discovery debe llevar siempre a una decisión.

Las actividades de un Product Discovery están muy bien definidas:

📌 Investigación de usuarios para relevar oportunidades.

📌 Análisis y priorización de problemas.

📌 Interpretación de insights y brainstorming.

Pero, más allá de toda la evidencia recolectada, ¿cuáles son las decisiones concretas sobre los hallazgos de un Discovery?

He visto muchos equipos (y también me lo han contado otros colegas) que carecen de autonomía para poder tomar decisiones sobre los resultados de su investigación.

Su trabajo llegaba hasta a un conjunto de documentos y entregables, que muchas veces no tenían un uso posterior.

Un Discovery efectivo debe siempre llevar a decisiones concretas sobre diseño y desarrollo de producto.

A accionables sobre qué features desarrollar, cuáles eliminar, y qué priorizar.

Si luego de investigar, no hay una apuesta clara, cambio de rumbo o enfoque renovado, entonces no tuvo ningún sentido el esfuerzo invertido.

‍

En resumen..

Un Product Discovery efectivo no solo debe seguir reglas universales, sino también debe ser llevado a cabo bajo un profundo entendimiento del contexto y del negocio.

En concreto:

📌 Además de encontrar un problema, encontrar su causa.

📌 Además de pensar en necesidades del usuario, pensar en las del negocio.

📌 Además de identificar riesgos, priorizarlos y armar un plan de mitigación.

📌 Además de identificar a “tu usuario”, segmentar y crear grupos específicos.

📌 Además de proponer ideas, cuestionarlas hasta el fondo.

📌 Además de validar tu idea, identificar tus propios sesgos.

📌 Además de documentar, decidir asertivamente.

Hacer Discovery de verdad es incómodo, iterativo y muy exigente.

Implica no solo seguir verdades compartidas por toda una industria, sino estar muy despierto a desvíos y desafíos no tan obvios que son igual de dañinos que “no hablar con usuarios”.

Aún es así, es una fase fundamental porque es justamente donde la estrategia cobra sentido.

Es en el Discovery, donde las ideas dejan de ser suposiciones y empiezan a tener un peso.

Espero que estos principios puedan ayudarte a mejorar la dirección de tu Product Discovery, ya sea como una señal de que vas por buen camino o una advertencia de desvío.

¡Eso fue todo por hoy!

Éxitos.