Product Delivery, Agile y Product Teams

Este módulo responde a una de las preguntas más frecuentes de quienes empiezan en producto: ¿cómo se trabaja de verdad en un equipo Agile y cómo se decide qué construir? Arranca desde lo más concreto —cómo se organiza un equipo, quién hace qué y cómo son las reuniones reales de un sprint— y va subiendo en abstracción hasta las herramientas de decisión que usan los PMs profesionales para priorizar, planificar y comunicar su trabajo.

La primera parte del módulo cubre el funcionamiento real de un equipo de producto Agile: el trío de PM, Designer y Engineering Manager, las ceremonias del sprint y la entrega incremental. La segunda parte introduce las herramientas de decisión: el Opportunity Solution Tree para estructurar oportunidades a partir de datos de usuario, el Opportunity Scoring Matrix para priorizarlas y RICE para elegir qué construir primero. La tercera parte cierra el ciclo bajando al backlog: épicas, feature slicing, user stories con sus criterios de aceptación, Definition of Done y MoSCoW.

Cada sesión combina un bloque teórico con un taller aplicado en Miro donde cada equipo trabaja sobre su propio producto. Al final del módulo, los equipos tienen un roadmap priorizado y un backlog real con user stories listas para ejecutar.

Al finalizar el curso, el participante será capaz de:

• Entender cómo funciona un equipo de producto Agile en la práctica y cuál es el papel real del PM dentro de él.
• Identificar los roles del trío de producto —PM, Designer y Engineering Manager— y cómo se coordinan en discovery y en delivery.
• Aplicar el Opportunity Solution Tree para convertir insights de usuario en un mapa estructurado de oportunidades ligadas a un outcome.
• Priorizar oportunidades con el Opportunity Scoring Matrix y soluciones con RICE, usando criterios objetivos y datos reales.
• Construir un roadmap de outcomes en formato Now/Next/Later y aprender a defenderlo ante la presión de stakeholders.
• Descomponer una épica en user stories bien escritas, con Acceptance Criteria en Gherkin y una Definition of Done clara.
• Distinguir cuándo el problema de un equipo es de discovery, de delivery o de estrategia, y saber qué hacer en cada caso.

1. Agile en el mundo real Qué significa trabajar en Agile más allá de los frameworks y la terminología. La diferencia entre hacer Agile y ser Agile. Por qué los equipos construyen lo incorrecto y cuál es el papel del PM para que el proceso tenga sentido. Visión comparada de los principales marcos de trabajo: Scrum, Kanban, SAFe y Dual Track.

2. El trío de producto Cómo se organiza un equipo de producto moderno alrededor de tres roles: PM, Designer y Engineering Manager. Qué pertenece a cada uno, dónde se solapan las responsabilidades y cómo se coordinan en discovery y en delivery. El modelo del Ownership del Timeframe como herramienta práctica para gestionar esa coordinación sin que nadie quede sin dueño.

3. Ceremonias del sprint Las cinco ceremonias de Scrum —planning, daily, review, retro y refinement— explicadas desde el punto de vista del PM: para qué sirve cada una, cómo facilitar las que te toca liderar y qué señales indican que una ceremonia ha dejado de aportar valor. Los antipatrones más frecuentes en equipos reales.

4. MVP y entrega incremental Qué es un MVP y qué no es. El concepto de entrega incremental a través del ejemplo de la farola: no se trata de construir menos, sino de identificar cuál es la hipótesis más importante a validar primero. Casos reales de primeras versiones de productos que hoy son grandes plataformas.

5. Dual Track Agile Por qué discovery y delivery no son fases separadas sino dos carriles paralelos. Los dos riesgos opuestos: el analysis paralysis —demasiado discovery sin lanzar nada— y el building blind —construir sin entender el problema—. Cómo mantener el equilibrio y qué señales indican que el equipo se ha desviado hacia alguno de los dos extremos.

6. Opportunity Solution Tree (OST) El framework de Teresa Torres para convertir los insights de usuario en decisiones de producto estructuradas. Cómo construir el árbol partiendo de un outcome, mapear oportunidades reales —fricciones del usuario, no features— y generar soluciones solo cuando el espacio del problema está bien entendido. La diferencia entre una oportunidad y una solución, y por qué confundirlas es el error más frecuente en discovery.

7. Opportunity Scoring Matrix (OSM) Cómo pasar del OST a una decisión concreta sobre qué oportunidad atacar primero. Los cuatro criterios del OSM —severidad, frecuencia, alineación estratégica y evidencia— y cómo puntuarlos para cada oportunidad del árbol. Cómo usar el OSM para defender una priorización ante presión externa y qué hacer cuando el score contradice la intuición del equipo.

8. RICE — priorización de soluciones El framework RICE —Reach, Impact, Confidence, Effort— para priorizar qué solución o feature construir primero dentro de una oportunidad ya elegida. La diferencia entre el OSM, que elige el problema, y RICE, que elige la solución. Cómo evitar los sesgos más frecuentes al puntuar y cómo usar el resultado como herramienta de conversación con stakeholders y con el equipo.

9. Roadmap de outcomes Qué es un roadmap y qué no debería ser. La diferencia entre un roadmap de outputs —lista de features con fechas— y un roadmap de outcomes —mapa de apuestas orientadas a resultados—. El formato Now/Next/Later como alternativa a los roadmaps por fechas: qué va en cada horizonte y cómo gestionar la incertidumbre sin prometer lo que no puedes cumplir.

10. Épicas y feature slicing Cómo pasar de una oportunidad priorizada a una épica de trabajo concreto. Qué es el feature slicing y por qué el corte vertical —cada slice entregable y con valor por sí solo— es la técnica más útil para reducir el riesgo de un sprint. Las cuatro técnicas principales de corte y cuándo aplicar cada una.

11. User Stories, Acceptance Criteria y Definition of Done Qué es una user story y en qué se diferencia de una feature o una tarea técnica. El formato Como [usuario], quiero [acción] para [beneficio] y los errores más frecuentes al escribirlo. Los Acceptance Criteria en formato Gherkin (GIVEN / WHEN / THEN) como contrato entre el PM y el equipo. La Definition of Done como acuerdo del equipo sobre qué significa "terminado" para cualquier entrega.

12. MoSCoW y la relación PM–equipo técnico El método MoSCoW —Must Have, Should Have, Could Have, Won't Have— para priorizar user stories dentro de un sprint. Cómo y cuándo usarlo frente a otros frameworks de priorización. El refinement como ceremonia donde el PM y el equipo técnico alinean el qué y el cómo antes de que empiece el sprint, y por qué la calidad de esa conversación determina la calidad de la entrega.

• Cuenta gratuita en Miro creada antes de la primera sesión — se usa en todos los talleres para construir el OST, el OSM, el roadmap y el backlog; no requiere plan de pago
• Móvil o segunda pestaña del navegador disponible para Mentimeter — sin cuenta ni instalación; los códigos de acceso los facilita la profesora al inicio de cada sesión
• Zoom instalado con cámara y micrófono funcionando — el enlace de acceso a las sesiones está disponible en la plataforma

Este curso forma parte del micro-certificado de Product Management. Se asume que el participante ha completado los módulos previos del programa. No se requieren conocimientos previos de UX ni de análisis de datos.