Durante 13 módulos construiste herramientas. Aprendiste a diagnosticar industrias, a orquestar Discovery, a escribir specs inmunes a la ambigüedad, a priorizar con algoritmos, a scrapear datos con Python, a automatizar flujos con n8n, y a construir dashboards que siempre están actualizados.
Ahora llega el momento de la verdad.
Este no es un examen teórico. No hay preguntas de opción múltiple. No hay "define qué es SDD".
Esto es un simulacro de Quarterly Business Review. Vas a recibir una crisis. Una crisis realista, con fecha y hora, que exige que tomes decisiones en minutos, no en semanas.
Un cambio regulatorio de la FDA acaba de anunciarse. Tu producto de HealthTech tiene un plazo para adaptarse o deja de operar legalmente.
Tu trabajo: en 5 horas, construir un portafolio que demuestre que puedes navegar esta crisis. No solo desde lo estratégico —sino desde lo operativo. Con un spec actualizado, un backlog re-priorizado por Cost of Delay, una automatización que mitigue el trabajo manual que generará esta crisis, y un dashboard que le muestre al comité ejecutivo que tienes el control.
Al final, vas a presentar tu portafolio ante un panel. No vas a leer diapositivas. Vas a mostrar decisiones. Y el panel —PMs seniors— va a evaluar no lo que sabes, sino lo que harías.
Este es el módulo donde dejas de ser un PM que mueve tickets y empiezas a ser un Product Operator.
Vamos.
El panel no evalúa lo que sabes, sino lo que harías. No hay una sola respuesta correcta: hay decisiones bien justificadas con datos y decisiones que no.
Contexto (3 minutos de lectura)
Eres el PM de MediTrack, una plataforma SaaS de gestión de ensayos clínicos utilizada por 45 hospitales en Estados Unidos y 12 en Latinoamérica. Tu plataforma maneja:
- Reclutamiento y seguimiento de pacientes en ensayos clínicos.
- Gestión de documentos de consentimiento informado.
- Reportes de eventos adversos.
- Facturación y cumplimiento regulatorio.
La Crisis
Acaba de publicarse la regulación FDA 2026-124. Entra en vigor en 90 días, pero las auditorías comienzan en 60 días.
Resumen ejecutivo:
- Todos los consentimientos informados deben incluir un formato digital firmado con biometría facial o hash de blockchain (a elegir por el proveedor).
- Los reportes de eventos adversos deben enviarse a la FDA en tiempo real (antes eran 24 horas).
- El paciente debe poder descargar su historial completo de participación en el ensayo en formato interoperable (FHIR).
- Los datos de los pacientes latinoamericanos deben cumplir con la nueva resolución de protección de datos transfronterizos (efecto inmediato).
Implicaciones:
- Si no cumplimos, los hospitales no pueden usar nuestra plataforma para nuevos ensayos a partir del día 60.
- El equipo de cumplimiento estima que el requerimiento #4 (datos transfronterizos) requiere re-arquitectura de almacenamiento.
- El requerimiento #2 (reportes en tiempo real) implica cambiar la arquitectura de eventos.
Necesito tu plan de acción para el viernes a las 5 PM. Formato QBR: Spec + Backlog priorizado + Automatización + Dashboard.
El comité ejecutivo quiere ver que tenemos control de la situación.
Si no cumples a tiempo, los 45 hospitales de EE. UU. no pueden usar la plataforma para nuevos ensayos a partir del día 60. No es un riesgo abstracto: es la pérdida directa de los contratos que sostienen el producto.
Los 4 requerimientos — elige uno como prioridad #1:
1 abogado + 1 oficial de privacidad + 0 recursos técnicos. Todo el trabajo técnico recae en tu equipo de producto. No puedes delegar la implementación.
32 historias existentes + 4 requerimientos regulatorios nuevos = 36 historias a priorizar. Este sprint ya tiene 5 historias comprometidas con clientes no regulatorios — necesitas decidir qué sacrificas.
- Lee los 4 requerimientos y decide cuál priorizas como #1 según su Cost of Delay.
- Escribe el Spec (PR/FAQ) de ese requerimiento — es el entregable que desbloquea los demás.
- Con el Spec listo, reprioriza el backlog completo (32 + 4 historias) usando Cost of Delay.
- Identifica el cuello de botella de automatización y elige la herramienta (M8, M9 o M10).
- Construye el Dashboard de crisis en Looker Studio (M13) que muestra el avance al comité.
El entregable de este módulo es un portafolio de 4 piezas que responden a la crisis y que luego presentarás en vivo ante el panel. Cada pieza demuestra una competencia distinta del curso; juntas demuestran que eres un Product Operator, no un PM que mueve tickets. Ligado al kit m14-qbr.
Entregable 1: Spec Document adaptado a la crisis
Crea un PR/FAQ completo (Módulo 3) para UNO de los 4 requerimientos regulatorios. Eliges cuál — pero debe ser el que priorices como #1 en tu backlog.
El spec debe incluir:
- Press Release ficticio (¿cómo se anuncia esta feature al mercado?).
- FAQ externas (¿qué preguntarán los hospitales?).
- FAQ internas (técnicas, legales, de negocio).
- Criterios de aceptación medibles.
- La sección "Lo que NO está incluido" (tan importante como lo que sí).
#1 (biometría) → muestra una comparación de proveedores.
#2 (tiempo real) → define la arquitectura de eventos.
#3 (FHIR) → referencia el estándar FHIR R4.
#4 (datos transfronterizos) → incluye un plan de Discovery, porque la regulación es ambigua.
Entregable 2: Backlog re-priorizado con Cost of Delay
Toma el backlog actual (32 historias) + los 4 nuevos requerimientos regulatorios y re-prioriza todo usando Cost of Delay como algoritmo principal, con RICE como criterio secundario.
Crea un Google Sheet (Módulo 5) con:
- Las 36 historias (32 existentes + 4 regulatorias).
- Cost of Delay estimado para cada una ($/semana).
- RICE Score (como secundario).
- Orden final priorizado.
- Una columna "Decisión" que clasifique cada historia en una de las 4 categorías.
La matriz de decisión del backlog:
Reglas de negocio para el Cost of Delay:
| Tipo de historia | Cost of Delay | Implicación |
|---|---|---|
| Regulatoria (no cumplir) | $540,000/mes + 2%/sem | Máxima urgencia: bloquea ingresos |
| Comprometida con cliente | $8,000 USD/semana | Ingreso real en juego |
| No comprometida | $0 directo | Candidata a congelar o cancelar |
Entregable 3: Automatización propuesta
La crisis va a generar una avalancha de trabajo manual: los hospitales van a solicitar cambios en sus configuraciones, los pacientes van a pedir descargas de historial, el equipo de cumplimiento va a necesitar reportes diarios.
Diseña una automatización (Módulos 8, 9 o 10 — eliges la herramienta) que mitigue al menos UNO de estos picos de trabajo manual.
El entregable de automatización debe incluir:
- Código o JSON del workflow funcionando.
- Diagrama lógico del flujo (Miro, diagrama en texto o captura del canvas).
- Explicación de: qué problema resuelve, cuánto tiempo manual ahorra por semana, y cómo asegura resiliencia (¿qué pasa si falla?).
Entregable 4: Dashboard de seguimiento de la crisis
Crea un dashboard en Looker Studio (Módulo 13) que el comité ejecutivo pueda abrir en cualquier momento para ver el estado de la respuesta a la crisis.
Métricas que debe mostrar:
- Días restantes para el cumplimiento: cuenta regresiva.
- % de requerimientos regulatorios completados: 0% → 100%.
- Throughput del equipo: ¿vamos al ritmo necesario?
- Lead Time de las historias regulatorias: ¿están tardando más de lo esperado?
- Riesgo de no cumplir a tiempo: semáforo verde/amarillo/rojo según el ritmo actual vs. la fecha límite.
Opcional, pero suma puntos:
- Conexión a BigQuery (datos vivos).
- Filtro por tipo de requerimiento regulatorio.
- Alertas (si el riesgo pasa a rojo, el dashboard lo muestra).
El viernes a las 5 PM presentas tu portafolio ante el "comité ejecutivo" (el instructor y/o un panel de PMs seniors).
Formato:
- Duración: 15 minutos de presentación + 10 minutos de preguntas.
- Sin diapositivas: compartes pantalla y muestras los entregables en vivo:
- Tu spec (link al documento).
- Tu backlog priorizado (link al sheet).
- Tu automatización (código, workflow o diagrama).
- Tu dashboard (link a Looker Studio).
No leas el spec ni recites las diapositivas. Explica las decisiones: por qué priorizaste así, qué sacrificaste y qué harías distinto con más tiempo.
Lo que el panel va a evaluar — 4 decisiones:
No se espera que elijas "el correcto" (no hay una sola respuesta). Se espera que justifiques por qué tu prioridad es la correcta basándote en Cost of Delay y riesgo.
Muestra qué historias congelaste o cancelaste y por qué. La crisis requiere sacrificios: el panel quiere ver que puedes hacerlos.
No se espera que automatices todo. Se espera que identifiques el cuello de botella más crítico y lo resuelvas.
El comité ejecutivo no quiere ver todas las métricas. Quiere ver las que importan para esta crisis.
- Error: presentar el QBR con capturas estáticas del dashboard. Corrección: el panel debe estar vivo: el panel directivo va a pedir filtrar en vivo, y una imagen no filtra.
- Error: defender las 4 decisiones con narrativa en vez de datos. Corrección: cada decisión (AHORA/DESPUÉS/CONGELAR/CANCELAR) cita su evidencia: CoD, NPS, throughput, riesgo regulatorio.
- Error: esconder la decisión de CANCELAR para no dar malas noticias. Corrección: un panel respeta más una cancelación bien justificada que un "todo va bien" sin sustento.
- Error: llegar sin ensayar los 10 minutos de presentación. Corrección: cronometra el recorrido completo al menos dos veces: el QBR castiga la improvisación.
- Error: entregar los 4 entregables como archivos sueltos. Corrección: arma el portafolio integrado con índice y enlaces cruzados: la coherencia entre piezas es parte de la evaluación.
| Criterio | 1 (No Aprobado) | 2 (Insuficiente) | 3 (Aprobado) | 4 (Sobresaliente) | 5 (Product Operator) |
|---|---|---|---|---|---|
| Spec (20%) — Claridad y completitud del PR/FAQ | Spec incompleto, ambigüedades críticas sin resolver, no cubre casos regulatorios | Spec completo pero genérico, no aborda las particularidades técnicas del requerimiento elegido | Spec completo, criterios de aceptación medibles, incluye "Lo que NO está incluido" | Spec con comparación de alternativas (ej. proveedores de biometría), FAQs que anticipan preguntas reales de hospitales | Spec que podría ser entregado a un LLM para generar código sin ambigüedad, incluye análisis de riesgos regulatorios |
| Backlog (25%) — Priorización basada en Cost of Delay | No usa Cost of Delay, priorización intuitiva, no hay historias congeladas o canceladas | Usa Cost of Delay pero los cálculos son incorrectos o no reflejan la urgencia regulatoria | Cost of Delay calculado correctamente, backlog priorizado, hay historias congeladas con justificación | Backlog con 4 categorías (ahora/después/congelar/cancelar), cada decisión justificada por Cost of Delay y capacidad del equipo | Backlog paramétrico que se reordena automáticamente al cambiar supuestos, análisis de sensibilidad incluido |
| Automatización (25%) — Pertinencia y calidad técnica | No hay automatización, o el código no funciona, o no resuelve un problema real de la crisis | Automatización existe pero es frágil (sin manejo de errores), o resuelve un problema menor no crítico | Automatización funciona, resuelve un cuello de botella identificado, incluye manejo de errores básico | Automatización con código limpio, diagrama lógico, y estimación de horas ahorradas por semana | Automatización resiliente (reintentos, logging, alertas si falla), código reusable, documentación para que otro PM lo entienda |
| Dashboard (15%) — Claridad y utilidad ejecutiva | Dashboard desconectado de la crisis, métricas irrelevantes, sin filtros | Dashboard muestra métricas correctas pero sin contexto (no hay semáforo, no hay referencia de qué es "bueno") | Dashboard con las 3 métricas clave (días restantes, % completado, throughput), filtro de fechas funcionando | Dashboard con semáforo de riesgo, alertas visuales, y al menos un valor de referencia por métrica | Dashboard conectado a datos vivos, actualización automática, y diseñado para que el comité ejecutivo tome decisiones sin ayuda del PM |
| Presentación QBR (15%) — Claridad y toma de decisiones | Presentación desorganizada, lee los documentos, no puede defender las decisiones | Presenta los entregables pero no logra priorizar la información (quiere mostrar todo y abruma) | Presentación estructurada: contexto → decisiones → demostración, responde preguntas del panel | Presentación enfocada en decisiones difíciles (qué sacrificó y por qué), demuestra los entregables en vivo | Presentación que un VP de Producto presentaría al CEO: clara, basada en datos, con acciones concretas y dueños asignados |
Puntaje total: Suma de 5 criterios, cada uno de 1 a 5. Máximo: 25 puntos.
| Rango | Resultado |
|---|---|
| 20-25 | Product Operator — Listo para liderar transformaciones operativas |
| 15-19 | PM Proficiente — Domina las herramientas, necesita integrarlas mejor en crisis |
| 10-14 | PM en Formación — Conceptos claros, ejecución necesita práctica |
| 5-9 | No aprueba — Debe repetir módulos clave (3, 5, 8-10) |
- 📄 Spec
- PR/FAQ completo del requerimiento regulatorio priorizado.
- Criterios de aceptación medibles.
- Sección "Lo que NO está incluido".
- (Opcional) Comparación de alternativas.
- 📊 Backlog
- Google Sheet con las 36 historias (32 existentes + 4 regulatorias).
- Cost of Delay calculado para cada historia.
- Columna "Decisión" (AHORA / DESPUÉS / CONGELAR / CANCELAR).
- Ordenamiento automático por prioridad.
- Justificación de las historias congeladas o canceladas.
- ⚙ Automatización
- Código o workflow funcionando (Python, Apps Script o n8n).
- Diagrama lógico del flujo.
- Explicación del cuello de botella que resuelve.
- Estimación de horas ahorradas por semana.
- Manejo de errores (¿qué pasa si falla?).
- 📈 Dashboard
- Looker Studio con 3+ métricas clave.
- Filtro de fechas funcionando.
- Semáforo de riesgo.
- Conexión a datos vivos (o simulados con actualización automática).
- 🎤 Presentación
- Duración: 15 min + 10 min de preguntas.
- Sin slides: solo los entregables en vivo.
- Enfocada en decisiones difíciles, no en features bonitas.
Has llegado al final. No al final del aprendizaje —al final del inicio.
Este curso no te dio respuestas. Te dio herramientas. La diferencia entre un PM que mueve tickets y un Product Operator es que el primero espera instrucciones y el segundo construye los sistemas que generan las instrucciones.
- Un framework para diagnosticar cualquier industria en minutos (Módulo 1).
- Un sistema para no construir cosas que nadie pidió (Módulos 2, 4).
- Una máquina de especificaciones que ni un humano ni una IA pueden malinterpretar (Módulo 3).
- Un backlog que prioriza solo, sin política (Módulo 5).
- Un radar de mercado que nunca duerme (Módulo 6).
- Una terminal que te da acceso directo al servidor (Módulo 7).
- Un scraper que hace en segundos lo que antes tomaba horas (Módulo 8).
- Un asistente en Google que trabaja 24/7 (Módulo 9).
- Un orquestador visual que conecta todo sin pagar por tarea (Módulo 10).
- Un analista que lee 50 documentos en segundos (Módulo 11).
- Un sistema de información que cualquier persona puede navegar (Módulo 12).
- Un dashboard que siempre está actualizado (Módulo 13).
- Y una crisis que sobreviviste (Módulo 14).
Todo esto lo construiste tú. Sin pedirle permisos a ingeniería. Sin pagar suscripciones caras. Sin esperar a que alguien más lo hiciera por ti.
Ahora ve y construye los sistemas que mueven los tickets por ti.
Kit: QBR — Caso Integrador
| Archivo | Descripción |
|---|---|
| ⬇ rubrica-panel.md | Rúbrica del panel de evaluación del QBR |