Tu equipo de Producto entrega. Los releases salen. Las features se implementan. La velocidad parece buena.
Y sin embargo cuando te tomás dos semanas de vacaciones, algo pasa. Las decisiones se frenan. Los PMs juntan preguntas para cuando vuelvas. Las prioridades que se tienen que mover se quedan donde estaban. Volvés y tenés que descomprimir tres semanas de definiciones acumuladas.
Si esa imagen te resulta familiar, tenés un equipo que ejecuta pero no participa en definir qué construir. Y a diferencia de los problemas de proceso, esto no se ve hasta que crece la empresa.
Cómo se nota la diferencia
Hay un patrón que aparece en los equipos donde la definición está concentrada en una sola persona.
Las reuniones de roadmap son monólogos disfrazados de conversación. Vos presentás lo que viene, el equipo asiente, hace preguntas tácticas, y vuelve a su trabajo. Nadie cuestiona el orden. Nadie propone descartar algo. Nadie dice "esto va a ser un problema".
Cuando aparece un pedido nuevo (de Ventas, del CEO, de un cliente), el PM lo escucha, lo escribe, te lo trae. No filtra. No propone. No descarta.
Las propuestas que el equipo trae suelen ser tácticas. "¿Podemos cambiar el orden de estas dos features?". "¿Podemos pedir ayuda a otro equipo para esto?". Casi nunca propuestas estratégicas tipo "esto no deberíamos hacerlo nunca" o "creo que estamos resolviendo el problema equivocado".
Y cuando algo sale mal (un release con bugs, un feature que nadie usa, una métrica que no se mueve), la respuesta del equipo es operativa. "Vamos a mejorar el QA". "Vamos a iterar el flujo". Casi nunca "creo que esto se aprobó sin entender bien el problema".
Todos esos son síntomas del mismo dolor de fondo. El equipo opera como feature team. Recibe un roadmap con fechas y mide por entregables. Lo que el negocio necesita en muchos casos es un product team empoderado, que reciba un problema y tenga autonomía para validar, definir y medir por impacto.
Por qué tu equipo está en modo feature team
Hay tres razones que aparecen en casi todos los casos.
La primera es cómo se contrató. Si el último ciclo de hiring buscó "PMs que muevan el roadmap", entrevistaste para ejecución. Los PMs que entraron son los que más fácilmente se convierten en buenos coordinadores. La gente con perfil más fuerte de definición probablemente no llegó a la oferta o la rechazó porque el rol no le sumaba.
La segunda es el espacio para equivocarse. Si cada vez que un PM propone algo y vos no estás de acuerdo, la conversación termina con vos imponiendo, el equipo aprende rápido. La propuesta segura es traerte el problema, no la solución. Cuando aprenden eso, dejan de proponer.
La tercera es la falta de lenguaje compartido. Discovery, validación, hipótesis, métricas que importan. Si cada PM tiene su propio marco para hablar de estas cosas, las conversaciones se vuelven imposibles. Sin lenguaje común no hay debate. Y sin debate, las decisiones se toman donde haya consenso fácil, que es donde vos hablás.
Lo que cambia cuando el equipo decide
El cambio más visible no se ve en el equipo. Se ve en vos. Pasás de definir a editar. Pasás de presentar el roadmap a desafiar el roadmap que trae el equipo. Pasás de aprobar features a discutir el orden en que se quieren resolver problemas.
A nivel de output, las decisiones se distribuyen y los tiempos bajan. El equipo deja de necesitarte para mover cosas que antes pasaban por tu escritorio. Las apuestas mejoran porque están más cerca del usuario y los datos.
Y a nivel cultural, el equipo se vuelve responsable. Cuando algo sale mal, no espera tu diagnóstico. Investiga, presenta hipótesis y propone qué hacer distinto la próxima vez.
Cómo se empieza
Los tres frentes hay que trabajarlos en paralelo, pero hay un orden de impacto.
Lo primero es construir lenguaje compartido. Si el equipo no tiene un marco común para hablar de discovery o de impacto, ningún cambio de proceso va a tomar. Esto se construye con formación conjunta del equipo. La individual deja a cada PM con su propio marco y no resuelve.
Lo segundo es hacer explícito qué tipos de decisiones puede tomar un PM sin consultar, cuáles consulta pero decide, y cuáles necesitan tu visto bueno. Si eso no está escrito, todo va por defecto a vos.
Lo tercero es cambiar las preguntas que vos hacés. Cuando te traen un problema, en lugar de resolverlo, preguntar "¿qué harías vos?". Si la respuesta es buena, dejarlos avanzar. Si necesita ajustes, trabajar juntos para mejorarla. Pero la decisión final tiene que volver al equipo.
Esto último es lo más difícil porque pelea contra el instinto de quien creó la operación. Es más rápido decidir vos. Pero el costo de seguir decidiendo vos es que el equipo nunca crece.
El punto
Si tu equipo entrega pero las definiciones siguen pasando por tu escritorio, sos el cuello de botella. Vas a serlo hasta que cambies dos cosas: el lenguaje compartido con el que el equipo discute, y el marco de decisiones que rige cuándo te consultan y cuándo no.
Lo primero requiere formación conjunta. Lo segundo requiere conversación, disciplina y aguante.
ProductPrepa for Business es un programa de mentoría grupal pensado para equipos de Producto que necesitan construir este lenguaje compartido. El temario se arma a partir de una conversación previa con vos para entender qué está faltando. Podés escribirme a nicoproducto@hey.com con el asunto "ProductPrepa for Business" para arrancar.
Abrazo de Producto, NicoProducto