Skills que aprenderás
Convocatorias
No hay convocatorias abiertas ahora mismo, pero no te pierdas la oportunidad: guarda este curso y te avisamos en cuanto se abra una convocatoria.
Recursos
No hay recursos disponibles todavía para esta convocatoria
Este módulo baja el rol de product manager de la teoría a la realidad del día a día: cómo funciona de verdad la semana de un PM, cómo se construye y se cuida un equipo, cómo se lidera sin tener autoridad formal y cómo es el salto profesional a un puesto de producto. Está dirigido a product managers en formación que ya dominan el discovery, la priorización y el go-to-market, y que ahora necesitan la capa relacional y operativa que hace que un equipo funcione y que un PM tenga impacto real. A lo largo de cuatro sesiones se trabajan las ceremonias Scrum y el papel del PM en cada una, el diseño de reuniones y la gestión del propio tiempo, la cultura y la salud de un equipo, la gestión de conflictos y la influencia sin autoridad, y la realidad de los distintos tipos de empresa junto con las claves para conseguir y empezar bien un primer puesto de producto. Al finalizar, el participante sabrá diagnosticar la salud de su equipo, resolver un conflicto y decir "no" con criterio, influir construyendo credibilidad, y leer el contexto de una empresa antes de entrar en ella.
Al finalizar el curso, el participante será capaz de:
El objetivo de cada ceremonia —Daily, Planning, Refinement, Review y Retro— y cómo juntas crean el ritmo de inspección y adaptación del equipo. Qué papel asume el PM en cada una: escucha en la Daily, trae prioridad y criterios en la Planning y el Refinement, conecta lo entregado con el objetivo en la Review, y aporta perspectiva de negocio y usuario en la Retro.
Lo que dice el manual frente a lo que pasa de verdad en la Planning, el Refinement, la Daily y la Retro. La user story como conversación escrita con el equipo técnico, no como ticket de backlog. Los fallos frecuentes: reportar puntuación y velocidad como si fueran un KPI de negocio, y dejar que una tarea "urgente" descarrile el sprint. Cómo el PM protege el sprint evaluando el impacto real antes de aceptar lo que entra.
Ser PM no es ir de ceremonia en ceremonia: los focos reales de una semana —discovery, stakeholders, roadmap, priorización, tech, métricas y 1:1s— entre emails, Slack, context switching y firefighting. El calendario como roadmap personal y los tres tipos de tiempo que hay que distinguir: profundo (deep work), colaborativo (reuniones) y reactivo (respuesta a interrupciones). Cómo recuperar el control de la agenda: proteger al equipo, no llenar el 100%, reducir el context switch y reservar tiempo para pensar.
Una reunión sin objetivo es una charla cara: el filtro de "¿esta reunión tiene que existir?" antes de convocar —objetivo en una frase, necesidad de decisión, personas correctas, agenda con tiempos y seguimiento posterior—. La anatomía de una reunión bien diseñada en sus tres momentos: antes (objetivo, agenda, contexto y roles), durante (facilitación, foco y parking lot) y después (resumen de decisiones, tareas y responsables).
Por qué la cultura de un equipo no es un detalle sino el contexto en el que se trabaja, dado que un PM no construye producto solo. Los pilares de un equipo sano según el Product Culture Canvas: claridad, seguridad psicológica, accountability, rituales, relaciones humanas, autonomía, foco y aprendizaje. La idea de que ningún equipo puntúa alto en todo y que lo importante es detectar qué está roto.
Los patrones que delatan a un equipo poco sano y cómo suenan en el día a día: la Feature Factory que lanza sin medir impacto, el PM Secretario que gestiona tickets sin decidir, el HiPPO donde manda quien tiene más poder, las retros de mentira que no cambian nada, las métricas de vanidad, el "todo es urgente" y la cultura del héroe que depende de personas concretas.
Las expectativas invisibles entre PM, Engineering Manager y Designer tienen que hacerse visibles para que un equipo funcione. Cómo construir un working agreement acordando expectativas concretas como punto de partida. El principio de que un equipo sin acuerdos explícitos los tiene igualmente, pero implícitos y mal.
El radar de diagnóstico de un equipo sano —confianza, comunicación, cadencia, ownership y motivación— y las señales de alarma de cada dimensión. El feedback 360 como forma de mantener el equipo sano sin evitar las conversaciones difíciles: el modelo Continue / Challenge / Try y la diferencia entre dar feedback sobre la persona ("eres un caos") y sobre el comportamiento ("las prioridades cambiaron sin explicación").
Los conflictos no se evitan, se gestionan: los tipos que todo PM afronta (ingeniería vs. negocio, stakeholders enfrentados, scope creep, disputas técnicas) y los cuatro movimientos para resolverlos —entender el interés de cada parte, hacer visibles los trade-offs, volver al objetivo común y acordar el siguiente paso—. Cómo decir "no" sin parecer el malo: convertirlo en un "ahora no", dar contexto antes del rechazo y ofrecer siempre una alternativa.
Decidir cuando no existe una opción perfecta, solo varias imperfectas: Build vs. Buy vs. Integrate como decisión estratégica y no tecnológica, la gestión de deuda técnica, cuándo matar una feature y qué hacer cuando el dato contradice el roadmap. El objetivo no es acertar la respuesta correcta, sino entender los trade-offs y defender una decisión con argumentos.
Influir sin autoridad formal como la habilidad más difícil y valiosa del PM: los cuatro pasos —entender los incentivos, alinear el problema, negociar los trade-offs y preservar la relación— y el framework de las 4 C de la credibilidad: contexto, claridad, confianza y consistencia. Lo que no funciona (insistir, empujar, ser el policía del roadmap) y cómo adaptar el idioma a cada interlocutor: stakeholders, tech, diseño y negocio.
El equipo ideal según Marty Cagan (empowered product team: problema en lugar de features, accountability del outcome, los tres riesgos cubiertos y discovery continuo) frente a la realidad de los tres tipos de equipo: delivery team, feature team y product team. Cómo detectar el product washing —empresas que dicen ser product-driven pero no lo son— y qué es y cuándo tiene sentido un marco como SAFe.
Cómo reencuadrar la experiencia previa en impacto y decisiones para el CV y LinkedIn, y preparar un pitch personal. Qué evalúan realmente las empresas en una entrevista de producto —cómo piensas, decides, trabajas y aprendes— y las preguntas que el candidato debe hacer para evaluar a la empresa. El stack real que abre un PM el primer día y el uso de la IA como apoyo, distinguiendo lo que resuelve bien de lo que sigue requiriendo criterio humano. Se cierra con un plan de acción a 30 días.
Ordenador con sistema operativo Windows, macOS o Linux.
Navegador web actualizado (Chrome, Firefox, Edge u otro).
Cuenta gratuita en Miro creada antes de la primera sesión. Se usa en los roleplays de expectativas y feedback 360, en el radar de salud del equipo y en los ejercicios de decisión. No requiere plan de pago.
Móvil o segunda pestaña del navegador disponible para usar Kahoot. No requiere cuenta ni instalación. Los códigos de acceso los facilita el profesor en el momento.
Zoom instalado y con cámara y micrófono funcionando. Descarga en zoom.us/download. El enlace de acceso a las sesiones está disponible en la plataforma.
→ PDE01 — Product Delivery, Agile y Product Teams (Intermedio, 16h)
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 técnicos de programación ni experiencia previa liderando equipos.