Todo empieza fuera del producto

Los equipos de producto suelen tener buena intuición. Conocen su producto, usan datos, tienen criterio. Y precisamente por eso es tan fácil caer en este error: la familiaridad con el producto les hace dar por hecho que entienden el problema de los usuarios. 

El false consensus effect es el sesgo por el cual tendemos a asumir que los demás piensan, sienten y se comportan como nosotros. En producto esto se traduce en construir las funcionalidades que tú usarías, no las que tus usuarios necesitan. El resultado: métricas estancadas y un backlog lleno de soluciones a problemas que nadie ha validado.

Si hubieras hablado con usuarios de la app de fitness, habrías descubierto que tu audiencia no es «alguien que quiere ponerse en forma». Es una persona que entrena sola por las mañanas antes del trabajo, que necesita sentir que progresa, pero se desmotiva por no tener con quién compartirlo. El problema se descubre saliendo del producto, en la experiencia real de quien lo usa.

Este tipo de insights no surgen de los datos observados en dashboards. Solo el discovery los hace visibles.

«Los productos exitosos surgen de una comprensión profunda de las necesidades del usuario, combinada con una comprensión igualmente profunda de lo que ahora es posible.» — Marty Cagan, Inspired

El product discovery es el proceso de reducir la incertidumbre sobre qué problemas vale la pena resolver antes de comprometer recursos en desarrollar soluciones. No es una fase previa al desarrollo ni recae solo sobre el PM. Es un proceso continuo y transversal.

Antes de arrancar cualquier iniciativa, el equipo debería conocer quién es el usuario real, qué está intentando resolver cuando usa el producto, y cómo reconocería que ese problema está resuelto. Tres preguntas aparentemente simples que la mayoría de los equipos nunca se hace de forma explícita.

Slack es un buen ejemplo de todo esto. No nació como herramienta de comunicación, antes fue un estudio de videojuegos llamado Glitch que fracasó. Al cerrar el proyecto, el equipo se dio cuenta de que lo más valioso que habían construido era la herramienta interna con la que se coordinaban los developers. En lugar de asumir que les serviría a otros, salieron a hablar con decenas de equipos de desarrollo para entender sus necesidades y pain points. Esas entrevistas iniciales moldearon el producto de éxito que es hoy.

Una vez entiendes el problema, necesitas una forma de abordarlo sin perderte. Teresa Torres, autora de Continuous Discovery Habits, propone el Árbol de Oportunidades: en la cima hay un objetivo medible (por ejemplo: aumentar la retención a 30 días un 25%), del que cuelgan oportunidades, los problemas reales del usuario que, si se resuelven, acercan al equipo a ese resultado. Cada oportunidad genera varias soluciones posibles, y cada solución se convierte en un experimento antes de desarrollar la feature definitiva.

Aplicado a la app de fitness: después de las entrevistas, tu equipo deja de hablar de notificaciones o variedad de ejercicios. Habla de soledad, de no tener referencia de progreso, de rutinas que no encajan con horarios reales. Las soluciones que emergen son retos compartidos, entrenamientos de diez minutos, comunidades dentro de la app… Ideas que se pueden testear antes de escribir una línea de código.

Strava construyó su propuesta de valor sobre ese tipo de insights. Su apuesta por la capa social viene de entender que el deporte individual falla en lo emocional, algo que su informe anual de 2024 confirma: la conexión social sigue siendo el principal motivador de sus usuarios para mantenerse activos, por encima de la salud o el rendimiento.

«El discovery continuo consiste en desarrollar el hábito de hablar regularmente con clientes para informar tus decisiones de producto.» — Teresa Torres, Continuous Discovery Habits

Hablar con usuarios es el core del product discovery. El reto es hacerlo de forma sostenible cuando los equipos manejan cada vez más volumen de información y menos tiempo. En los últimos años, se han acelerado tareas que antes consumían semanas de trabajo: sintetizar respuestas de encuestas, identificar patrones en transcripciones, preparar guías de preguntas. Para todo esto la IA es increíble. 

Pero también hay que ser conscientes de sus limitaciones. La IA puede decirte que los usuarios de tu app «mencionan frecuentemente la falta de motivación». No puede decirte que detrás hay soledad, porque eso solo aparece en una conversación real, cuando alguien lo dice casi de pasada, con cierta incomodidad. La IA trabaja con lo que la gente dice o escribe. El contexto emocional de la experiencia va mucho más allá.

El caso de Peloton sigue esta misma lógica. A partir de conversaciones con personas que describían el ejercicio en casa como monótono y poco motivador se plantearon una pregunta clave: ¿cómo podríamos hacer que entrenar solo en tu salón no sea aburrido? Ahora su app incluye clases con instructores famosos, música en directo, tablas de clasificación… ideas nacidas de escuchar a los usuarios.

El riesgo de apoyarse demasiado en la IA es confundir síntesis con comprensión. 

Empezar a hacer product discovery no requiere un proceso formal. Tan solo necesitas cinco conversaciones.

Busca cinco usuarios de tu producto, de perfiles diversos, no solo los más activos. Pídeles 45 minutos. Prepara algunas preguntas sobre el problema que tu producto intenta resolver, pero sin mencionarlo explícitamente. Escucha. Toma notas, sobre todo de lo que contradice lo que creías saber.

Para aprender a formular bien esas preguntas, hay un libro de referencia: The Mom Test, de Rob Fitzpatrick. Su tesis es sencilla: si le preguntas a los usuarios si tu idea es buena, te dirán que sí porque todos tendemos a decir lo que creemos que el otro quiere oír. La solución es preguntar por comportamientos reales, no por opiniones. No «¿te parece útil una app de fitness?», sino «¿qué hiciste la última vez que no te apetecía entrenar?». Con la primera pregunta recibirás validación sesgada, con la segunda, información honesta y valiosa. 

El discovery no elimina la incertidumbre, pero pone al usuario en el centro de cada decisión. Es la diferencia entre un PM que reacciona y uno que anticipa.