Hay una conversación que se repite en todas las empresas, todos los meses:
— ¿Qué deberíamos construir? — No sé, pregúntale a los clientes. — Pidieron X. — Bueno, construyamos X.
Seis meses después, X no se usa. Nadie lo pidió realmente, o lo que necesitaban era Y pero no supieron articularlo.
El problema no es que no escuches a los clientes. Es que escuchas la solución que proponen, no el problema que intentan resolver. Un cliente no dice "necesito respuesta menor a 2 minutos con estado en tiempo real"; dice "las autorizaciones tardan mucho".
El Continuous Discovery de Teresa Torres lo resuelve con el Opportunity Solution Tree: no un mapa de features, sino un mapa de problemas. Vas a construir tu primer árbol entrevistando a un usuario real y a sintetizarlo con NotebookLM, alimentando tu backlog con evidencia.
Vamos.
2.1. La Trampa del Feature Factory
Un PM cae en Feature Factory cuando su día se mide por tickets cerrados, no por problemas resueltos. ¿Cuántos de estos síntomas reconoces?
- 🏭 Autodiagnóstico — ¿Estás en un Feature Factory?
- El backlog crece más rápido de lo que se entrega.
- Se construyen features que nadie usa (medir adopción da miedo).
- Las reuniones de priorización son guerras políticas: gana el que grita más fuerte.
- El equipo técnico no sabe por qué construye lo que construye.
Continuous Discovery no es "hablar más con clientes". Es un sistema semanal de decisiones basado en evidencia, no en opiniones.
2.2. El Opportunity Solution Tree (OST)
El OST organiza tu pensamiento en 4 niveles. Despliega las ramas para explorar el ejemplo HealthTech:
🎯 Desired Outcome — Reducir el tiempo de autorización de medicamentos en un 40%
Oportunidad 1 — "Los médicos no saben si la autorización pasó"
Oportunidad 2 — "Las enfermeras llaman a 3 departamentos para obtener datos"
Desired Outcome (Resultado Deseado): Es la métrica de negocio que quieres mover. No es una feature. Es un número. Debe ser medible y tener línea base.
Oportunidades: Son los problemas, dolores o fricciones del usuario que, si se resuelven, deberían mover el resultado deseado. No son soluciones. Son "los médicos no saben si la autorización pasó" — no "notificaciones SMS".
Soluciones: Son las ideas concretas de producto que podrían resolver cada oportunidad. Aquí sí entran las features. Cada oportunidad puede tener múltiples soluciones.
Experimentos: Son las pruebas mínimas para validar si una solución realmente resuelve la oportunidad. No son la solución completa. Son prototipos, entrevistas, tests de humo.
2.3. Por Qué el OST Funciona en Industrias Tradicionales (HealthTech)
El OST se diseñó originalmente para SaaS. Pero su poder real se ve en industrias donde la fricción no es digital sino física y regulatoria.
Caso HealthTech: Un hospital quiere reducir el tiempo de autorización de medicamentos (hoy: 4 horas promedio).
Una oportunidad típica en HealthTech: - Oportunidad: "Los médicos no tienen visibilidad del estado de la autorización después de enviarla." - Por qué duele: El médico pierde 20 min por paciente llamando a farmacia para preguntar si ya autorizaron. En un turno de 30 pacientes, eso son 10 horas de trabajo administrativo. - Por qué es difícil de resolver: No es un problema técnico puro. Es un problema de proceso clínico + datos + regulación de privacidad.
El OST obliga a mapear esta complejidad antes de discutir soluciones. Si el equipo salta directo a "hagamos una app", probablemente construyan algo que: 1. No se integre con el sistema de historia clínica (HCE). 2. No cumpla con políticas de datos sensibles. 3. Los médicos no usen porque requiere 3 clics más que llamar por teléfono.
2.4. La Diferencia entre Síntoma, Oportunidad y Solución
La habilidad más difícil del Continuous Discovery es distinguir estos tres niveles. Un ejercicio práctico:
| Frase del usuario | ¿Es síntoma, oportunidad o solución? |
|---|---|
| "Las autorizaciones tardan mucho" | Síntoma. Describe el dolor pero no la causa. |
| "No sé si mi autorización ya fue aprobada" | Oportunidad. Señala una fricción específica. |
| "Necesito una notificación cuando la autoricen" | Solución. El usuario ya está proponiendo cómo resolverlo. |
"Quiero una notificación cuando autoricen."
Si lo tomas como requerimiento, construyes mil notificaciones.
"Falta visibilidad del proceso."
Un dashboard visible podría resolverlo mejor que cualquier notificación.
Cuando un usuario te da una solución, pregúntate: "¿Qué problema está tratando de resolver con esa solución?" Esa respuesta es la oportunidad.
3.1. Construir tu Primer OST en Miro o FigJam
Paso 1 — Define el Desired Outcome
Antes de hablar con usuarios, define qué métrica quieres mover. Usa este formato:
"Pasar de [valor actual] a [valor deseado] en [plazo] impactando [indicador de negocio]."
Ejemplo HealthTech:
"Reducir el tiempo promedio de autorización de medicamentos de 4 horas a 30 minutos en los próximos 3 meses, impactando la satisfacción del médico (NPS de internistas)."
Paso 2 — Entrevista a 1 usuario real y captura oportunidades
No necesitas 20 entrevistas para empezar. Con 1 entrevista bien hecha puedes iniciar tu árbol.
No preguntes "¿qué necesitas?": pregunta por el pasado. Las historias reales revelan problemas; las opiniones sobre el futuro inventan soluciones.
Preguntas que funcionan:
- "Cuéntame la última vez que pediste una autorización y fue frustrante."
- "¿Qué hiciste exactamente después de enviar la solicitud?"
- "¿Cuánto tiempo pasó entre enviarla y saber el resultado?"
- "¿Qué hiciste mientras esperabas?"
- "Si pudieras cambiar una sola cosa de ese proceso, ¿qué sería?"
Paso 3 — Abre Miro y estructura el árbol
Crea un tablero nuevo. En el centro superior, escribe tu Desired Outcome en un rectángulo.
Debajo, crea 3 columnas de notas adhesivas:
Columna 1: Oportunidades - Escribe cada fricción que identificaste en la entrevista. - Cada nota debe empezar con "Los [usuarios] no pueden / no saben / tienen que..." - No escribas soluciones aquí.
Columna 2: Soluciones (por cada oportunidad) - Para cada oportunidad, escribe 2-3 ideas de solución. - No las evalúes todavía. Solo escríbelas.
Columna 3: Experimentos - Para cada solución, escribe la prueba más barata que puedes hacer para saber si funciona. - Ej: "Entrevista con 3 médicos mostrando mockup" o "Prototipo en Figma probado con 1 usuario".
Paso 4 — Prioriza oportunidades
No puedes atacar todas. Usa estos criterios para elegir la primera oportunidad:
- Impacto estimado: ¿Cuánto movería el Desired Outcome si resolvemos esto?
- Confianza: ¿Qué tan seguros estamos de que esta oportunidad es real? (Basado en evidencia, no corazonadas.)
- Esfuerzo: ¿Cuánto cuesta validar una solución?
Elige la oportunidad que tenga mayor impacto × confianza ÷ esfuerzo.
Ejemplo HealthTech (priorización):
| Oportunidad | Impacto (1-5) | Confianza (1-5) | Esfuerzo (1-5) | Score |
|---|---|---|---|---|
| Médicos no saben estado de autorización | 5 | 4 | 2 | 10 |
| Enfermeras llaman a 3 deptos para datos | 3 | 3 | 4 | 2.25 |
| Pacientes preguntan 3 veces por el proceso | 2 | 2 | 5 | 0.8 |
Primera oportunidad a atacar: "Médicos no saben estado de autorización."
3.2. Usar NotebookLM para Sintetizar Hallazgos de Discovery
NotebookLM es la herramienta ideal para un PM que hace Discovery porque te permite ingerir fuentes (entrevistas, artículos, documentos) y hacer preguntas transversales sin perder contexto.
Paso 1 — Crea una libreta por oportunidad o por sprint
No pongas todo en una misma libreta. Recuerda el límite de 50 fuentes. Crea libretas separadas:
Discovery — Autorizaciones HealthTechDiscovery — Dashboard MédicosDiscovery — Feedback Post-lanzamiento
Paso 2 — Sube tus fuentes de entrevistas
Sube a NotebookLM: - Transcripciones de entrevistas (texto plano o PDF). - Notas de observación de campo. - Capturas de pantalla del proceso actual. - Documentos de políticas o regulación relevantes.
Paso 3 — Usa NotebookLM para encontrar patrones
Pregúntale a la libreta (no a un chat general):
"Basado en las 3 entrevistas que subí, ¿cuáles son los 3 dolores más frecuentes que mencionan los médicos sobre el proceso de autorización?"
"¿Hay alguna solución que los médicos hayan mencionado espontáneamente?"
"¿Qué frases textuales se repiten en todas las entrevistas?"
Paso 4 — Exporta los hallazgos a tu OST
Toma las respuestas de NotebookLM y úsalas para: - Agregar nuevas oportunidades que no habías identificado. - Validar (o invalidar) oportunidades existentes. - Citar textualmente a usuarios en tu árbol (para darle peso a las decisiones).
3.3. Simulación: Ciclo Completo de Discovery
Escenario: Eres PM en una clínica. Tu Desired Outcome es "Reducir el tiempo de autorización de medicamentos de 4h a 30min en 3 meses".
Semana 1 — Entrevistas (3 médicos): Identificas 4 oportunidades: 1. Médicos no tienen visibilidad del estado. 2. Enfermeras pierden tiempo consolidando datos de 3 sistemas distintos. 3. El formato de solicitud cambió hace 2 meses y nadie lo comunicó. 4. Los médicos no saben si la autorización cubre el medicamento exacto o solo el genérico.
Semana 2 — Mapeo en Miro: Construyes el OST con las 4 oportunidades. Para cada una, sugieres 2-3 soluciones. Para cada solución, diseñas un experimento mínimo.
Semana 3 — Subes todo a NotebookLM: Creas una libreta con las transcripciones. Le preguntas: "¿Hay alguna oportunidad que las 3 menciones pero que yo no capturé?" La IA identifica: "Ningún médico mencionó saber si la autorización fue aprobada parcialmente (solo ciertos días de tratamiento)." Agregas esa oportunidad #5 a tu árbol.
Semana 4 — Priorizas y presentas: Usas la matriz de priorización. La oportunidad ganadora es "Médicos no tienen visibilidad del estado" (score más alto). Presentas tu OST al equipo con: - El árbol completo. - Las citas textuales. - El experimento propuesto (un mockup de dashboard compartido con 2 médicos la próxima semana).
4. Cómo Usar Esto para Mejorar tus Procesos Reales
4.1. El OST como Escudo contra el "Mi Jefe Dijo"
Situación real: Tu jefe llega el lunes con una idea: "Los clientes necesitan una app móvil." Todos asienten. Nadie pregunta si es cierto.
Lo que hacías antes: Creabas un epic en Jira llamado "App Móvil" y empezabas a estimar.
Lo que harás ahora: Abres tu OST actual. Preguntas: "¿App Móvil resuelve alguna oportunidad de nuestro árbol? ¿Cuál?" Si no hay una oportunidad mapeada que "App Móvil" resuelva, entonces App Móvil no entra al backlog. O entra si mapeamos la oportunidad primero.
Instrucción: La próxima vez que alguien te pida una feature, no digas que no. Di: "Ayúdame a entender qué oportunidad estamos resolviendo." Si no pueden articularlo, es una solución en busca de un problema.
4.2. El Ciclo Semanal de Discovery
No necesitas 40 horas a la semana para hacer Discovery. Con 4 horas semanales estructuradas:
| Día | Actividad | Duración |
|---|---|---|
| Lunes | Revisar datos cuantitativos (analytics, soporte) | 30 min |
| Martes | 1 entrevista con usuario (15-20 min) | 30 min |
| Miércoles | Subir hallazgos a NotebookLM + preguntar patrones | 30 min |
| Jueves | Actualizar OST en Miro con nuevos hallazgos | 30 min |
| Viernes | Decidir: ¿qué oportunidad priorizamos la próxima semana? | 30 min |
Total: 2.5 horas semanales. Esto es menos tiempo del que pasas en una reunión de sincronización semanal.
4.3. Diagnóstico Rápido: ¿Estás Haciendo Discovery o Solo Reuniones?
Responde estas preguntas sobre tu proyecto actual:
- ¿Tus últimas 3 features salieron de entrevistas con usuarios o de reuniones internas?
- Entrevistas → Discovery real.
-
Reuniones internas → Estás construyendo lo que alguien asume sin validar.
-
¿Tienes un documento que mapee problemas (no soluciones) de tus usuarios?
- Sí, actualizado → Tienes un OST vivo.
-
No, o desactualizado → No tienes mapa de oportunidades.
-
¿Podrías defender tu priorización actual con datos de usuario, no con opiniones?
- Sí → Tus decisiones tienen respaldo.
-
No → Estás priorizando por política o intuición.
-
¿Cuándo fue la última vez que descartaste una feature porque una entrevista mostró que no resolvía un problema real?
- Hace menos de un mes → Estás haciendo Discovery correctamente.
- Nunca o no recuerdas → Nunca validaste una hipótesis.
4.4. Entregable del Módulo
Construye tu árbol de oportunidades para un problema real de tu trabajo actual (o simulado):
Pestaña 1 — El Árbol (Miro o FigJam): - Desired Outcome escrito en el nodo raíz (con línea base y meta numérica). - Mínimo 3 oportunidades identificadas (ideal 5+). - Cada oportunidad con al menos 1 solución propuesta. - Cada solución con al menos 1 experimento sugerido.
Pestaña 2 — Evidencia (NotebookLM o documento de texto): - Sube las fuentes que usaste para construir el árbol (transcripciones de entrevistas, datos de soporte, analytics). - Captura de pantalla de NotebookLM mostrando una pregunta que hiciste y su respuesta. - Explica (150 palabras máx) cómo la IA te ayudó a encontrar una oportunidad que no habías identificado solo.
Pestaña 3 — Priorización y Decisión: - Matriz de priorización de oportunidades (impacto × confianza ÷ esfuerzo). - La oportunidad ganadora y por qué. - El experimento concreto que harás la próxima semana para validar la solución elegida.
Formato de entrega: Link al tablero de Miro + link a la libreta de NotebookLM (o documento adjunto). Incluye un comentario de 3 líneas que resuma: "Voy a validar [oportunidad X] mediante [experimento Y] porque mi árbol mostró que es la oportunidad con mayor impacto y menor esfuerzo."
- Error: saltar de la idea a la solución sin pasar por oportunidades. Corrección: el OST existe para forzar la cadena outcome → oportunidad → solución → experimento; sin ella, es lista de deseos.
- Error: un outcome vago como "mejorar el producto". Corrección: el outcome es una métrica con dirección: "subir la retención a 30 días del 22% al 30%".
- Error: entrevistar usuarios solo cuando arranca un proyecto nuevo. Corrección: discovery es continuo: una cadencia semanal pequeña vale más que un estudio gigante anual.
- Error: tratar cada solicitud de feature como una oportunidad. Corrección: la solicitud es la solución que imaginó el usuario; pregunta por el problema que hay detrás.
- Error: no podar nunca el árbol. Corrección: las ramas sin evidencia se archivan; un OST que solo crece deja de orientar decisiones.
| Criterio | No Aprobado (0) | Aprobado (1) | Sobresaliente (2) |
|---|---|---|---|
| 1. El árbol distingue claramente oportunidades de soluciones | Las oportunidades están redactadas como soluciones ("hacer una app", "agregar botón") en lugar de problemas del usuario | La mayoría de las oportunidades están bien redactadas pero al menos 1 confunde problema con solución | Todas las oportunidades describen problemas/fricciones del usuario sin mezclar soluciones; cualquier persona puede leer el árbol y entender qué le duele al usuario |
| 2. La priorización está respaldada por datos, no por opinión | No hay matriz de priorización o los scores son arbitrarios sin justificación | Hay matriz con scores pero no hay evidencia de usuario (entrevistas, datos) que respalde los valores asignados | Hay matriz con scores, cada valor está justificado con citas de entrevistas o datos cuantitativos, y la oportunidad ganadora tiene un argumento claro de por qué es primero |
| 3. Hay un plan de experimentación para la próxima semana | No hay experimento definido o es demasiado grande ("construir el feature completo") | Hay un experimento definido pero es vago ("hablar con usuarios") sin criterio de éxito | Hay un experimento concreto, con criterio de éxito claro ("si 2 de 3 médicos dicen que el dashboard les ahorraría tiempo, pasamos a prototipado") y fecha definida |
Aprobación: 2 de 3 criterios en "Aprobado" o superior.
Para avanzar al Módulo 5: Ejecuta tu experimento esta semana. Así sea una conversación de 15 minutos con un usuario. Si el experimento invalida tu hipótesis (la oportunidad que creías prioritaria no duele tanto), actualiza tu árbol y reprioriza. Eso no es fracaso. Eso es Discovery funcionando.
Tras una entrevista real, arma un árbol con: 1 outcome medible, 2 oportunidades (problemas, no features) y 2 soluciones por oportunidad. Marca la oportunidad que atacarás primero y di por qué.
- El Feature Factory mide tickets cerrados; el Continuous Discovery mide problemas resueltos.
- El OST baja de un outcome medible a oportunidades, soluciones y experimentos.
- Distingue síntoma · oportunidad · solución: el usuario suele darte soluciones disfrazadas de necesidad.
- Ante una solución propuesta, pregunta qué problema resuelve: ahí está la oportunidad real.
Kit: Continuous Discovery
| Archivo | Descripción |
|---|---|
| ⬇ opportunity-solution-tree-template.md | Template del árbol de oportunidades/soluciones (OST canvas) en Markdown |