Cómo onboardear a un nuevo PM en tu equipo
El onboarding de un nuevo Product Manager determina en gran medida cuánto tiempo tardará en ser productivo y si se integrará bien en el equipo. Esta guía ofrece un proceso de 90 días que funciona.
El onboarding de un Product Manager nuevo es una de las inversiones de más alto retorno que puede hacer un equipo de producto. Y también una de las que con más frecuencia se deja a la improvisación.
El resultado de un onboarding mal diseñado: el nuevo PM tarda meses en ser productivo, comete errores por falta de contexto que generan fricciones con el equipo, y quizá toma decisiones tempranas que hay que deshacer porque no entendía bien las restricciones del sistema o de la organización.
El resultado de un onboarding bien diseñado: el nuevo PM aporta valor en semanas, genera confianza con el equipo más rápido, y las primeras semanas de trabajo construyen una base sólida en lugar de acumular malentendidos que hay que resolver después.
Lo que el nuevo PM necesita entender en los primeros 90 días
No todo con la misma urgencia. Hay contexto que es urgente (el sprint actual, los stakeholders clave, el sistema de trabajo del equipo) y contexto que puede esperar hasta que la base esté asentada (la historia completa del producto, los detalles técnicos de la arquitectura, el contexto competitivo completo).
Un onboarding efectivo distingue entre esos planos y los aborda en el orden correcto.
Los tres primeros días: orientación básica
El objetivo de los primeros días no es que el nuevo PM entienda el producto. Es que entienda el contexto suficiente para no hacer preguntas básicas que generarían fricción.
Accesos y herramientas. El nuevo PM tiene que tener acceso a todas las herramientas el primer día: el sistema de gestión de tareas, las herramientas de diseño, el repositorio de documentación, las herramientas de analytics, los canales de comunicación del equipo. No en el segundo día. El primero.
Estructura del equipo. Quién hace qué, cómo se comunican, cuáles son las reuniones regulares y para qué sirve cada una.
El producto en uso. No la documentación del producto. El producto en uso real. El nuevo PM tiene que usar el producto como usuario antes de empezar a entenderlo como PM.
El contexto del sprint actual. Qué está haciendo el equipo ahora mismo y por qué. No para que el nuevo PM tome decisiones de inmediato, sino para que tenga el contexto suficiente para no interrumpir el trabajo en curso con preguntas inoportunas.
La primera semana: escuchar más que hablar
El nuevo PM tiene que dedicar la primera semana principalmente a escuchar.
Reuniones de contexto con stakeholders clave. No para empezar a trabajar, sino para entender las perspectivas de cada área. Cómo ven el producto desde ventas, desde soporte, desde tecnología. Qué expectativas tienen del rol de PM. Qué frustraciones tienen del proceso actual.
Revisión del backlog existente. No para cuestionarlo de inmediato, sino para entender qué está ahí y por qué. La historia del backlog refleja la historia de las decisiones del equipo.
Lectura de la documentación de producto existente. Roadmaps anteriores, documentos de decisión, resultados de research, specs de funcionalidades clave. No para absorberlo todo, sino para hacerse una imagen del estado del arte.
Conversaciones con el equipo técnico y de diseño. Entender las restricciones técnicas actuales y las deudas técnicas conocidas. Entender el estado del sistema de diseño y los principios que guían las decisiones de UX.
El primer mes: generar el primer aprendizaje propio
A partir de la segunda semana, el nuevo PM tiene que empezar a generar su propio conocimiento sobre el producto, los usuarios y el contexto.
Entrevistas con usuarios. Al menos 5-8 entrevistas con usuarios actuales del producto. No para hacer discovery de inmediato, sino para escuchar directamente a los usuarios y calibrar la comprensión que se tiene del problema que el producto resuelve.
Análisis de los datos de uso. Exploración de las métricas clave del producto: dónde están los puntos de abandono, qué funcionalidades tienen mayor engagement, cómo se comportan los distintos segmentos de usuarios.
Primeras contribuciones al trabajo del sprint. No tomando decisiones estratégicas de inmediato, sino participando en el refinamiento, haciendo preguntas que revelan su proceso de aprendizaje, y añadiendo criterios de aceptación o contexto a historias que ya están en proceso.
Los 90 días: la primera evaluación estratégica
Al final del tercer mes, el nuevo PM debería ser capaz de hacer su primera aportación estratégica propia: un análisis de una oportunidad de producto, una propuesta de prioridades para el siguiente ciclo, o una revisión fundamentada del roadmap actual.
Esa aportación es el test real del onboarding. No porque el nuevo PM tenga que haberlo resuelto todo, sino porque demuestra que tiene suficiente contexto para opinar con criterio propio sobre el producto.
Lo que el equipo tiene que hacer para que funcione
El onboarding no es responsabilidad solo del nuevo PM. El equipo tiene que poner de su parte.
Asignar un “buddy” de onboarding. Una persona del equipo (no el manager directo) que sirva de referencia para las preguntas del día a día. Las preguntas que el nuevo PM no se atrevería a hacer en una reunión, las hace al buddy.
Documentar lo que está implícito. Muchos equipos tienen convenciones, decisiones y contexto que está en la cabeza de los miembros del equipo pero no está escrito en ningún sitio. El onboarding de alguien nuevo es el momento para identificar y documentar esas cosas.
Dar feedback explícito y temprano. El nuevo PM no sabe si sus contribuciones son del tipo que el equipo espera hasta que alguien se lo dice. Un feedback semanal breve y específico en los primeros meses acelera el ajuste.
Tener paciencia con el ciclo de aprendizaje. Los primeros meses del nuevo PM van a tener preguntas que el equipo considera básicas, perspectivas que parecen ingenuas, y decisiones que habrían sido distintas con más contexto. Eso es normal. El contexto se adquiere con el tiempo, no de forma instantánea.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.