Product Discovery: Validar Antes de Construir

Qué es Product Discovery

Discovery es el proceso de responder una pregunta antes de construir la respuesta: "¿Esto vale la pena?" No es un workshop de un día ni un Design Sprint. Es un conjunto de actividades continuas donde el equipo de producto valida supuestos antes de invertir semanas de desarrollo.

Teresa Torres, en "Continuous Discovery Habits", lo resume así: el equipo de producto debe tomar al menos una decisión de producto basada en evidencia cada semana. No cada quarter, no cada roadmap — cada semana.

Los 4 riesgos que Discovery valida

Cada idea de producto tiene cuatro tipos de riesgo. Discovery existe para reducir los cuatro antes de escribir código:

El Opportunity Solution Tree

El Opportunity Solution Tree (Teresa Torres) es la herramienta visual que conecta los outcomes del negocio con las soluciones del equipo:

Outcome del negocio
  → Oportunidad 1 (pain point del usuario)
      → Solución A → Experimento 1
      → Solución B → Experimento 2
  → Oportunidad 2 (necesidad no cubierta)
      → Solución C → Experimento 3
      → Solución D → Experimento 4

Ejemplo real:
"Aumentar retención D30" (outcome)
  → "Usuarios no entienden el valor en los primeros 5 minutos"
      → Onboarding interactivo → Test con 20 usuarios
      → Video tutorial de 90 seg → A/B test en producción
  → "Usuarios no vuelven después del primer uso"
      → Push notification de recordatorio → Test de engagement
      → Email con caso de uso personalizado → Cohorte test

Técnicas de Discovery por fase

Entender el problema

• Entrevistas de usuario (5-8 usuarios es suficiente para patrones)
• Análisis de datos de comportamiento (funnels, heatmaps, session recordings)
• Support ticket analysis (¿qué dolor se repite?)
• Encuestas de satisfacción (NPS, CSAT, CES) con pregunta abierta
• Shadowing: observar al usuario usar el producto sin intervenir

Explorar soluciones

• Sketching colaborativo con el equipo (no solo diseñadores)
• Prototipos de baja fidelidad (papel, Figma wireframes)
• Análisis competitivo: ¿cómo resuelven otros este problema?
• Story mapping: visualizar el journey del usuario con la solución
• Assumption mapping: listar los supuestos más riesgosos

Validar antes de construir

• Tests de usabilidad con prototipo (5 usuarios = 85% de los problemas)
• Fake door test: medir interés antes de construir
• Wizard of Oz: simular la feature manualmente para validar valor
• Concierge: entregar el servicio a mano antes de automatizar
• Spike técnico: validar que la solución es construible en el tiempo estimado

Discovery en la realidad de LATAM

El contexto de LATAM presenta desafíos específicos para Discovery:

• Equipos pequeños: el PM hace discovery, definición y a veces también project management
• Presión por entregar: stakeholders quieren features, no experimentos
• Acceso a usuarios: a veces es difícil reclutar para entrevistas en mercados pequeños
• Madurez de data: muchos productos no tienen analytics bien implementados

La solución no es copiar el proceso de Google o Spotify. Es adaptar: entrevistas más cortas (30 min), experimentos más rápidos (1-3 días), y documentación mínima pero accionable. Discovery no tiene que ser un proceso formal — tiene que ser un hábito.

Cómo empezar con Discovery esta semana

1. Elige la feature más grande de tu roadmap actual
2. Lista 3 supuestos que tienes sobre por qué los usuarios la necesitan
3. Habla con 3 usuarios esta semana y pregunta sobre el PROBLEMA (no la solución)
4. Documenta qué aprendiste en un párrafo — ¿tus supuestos se confirmaron?
5. Comparte el aprendizaje con tu equipo en la próxima standup