Cuando la PMO y Producto chocan
En muchas organizaciones, la lógica de planificación anual y control de proyectos convive con equipos que intentan trabajar por producto, generando tensiones en la priorización y la toma de decisiones. Este artículo explora por qué ocurre el choque entre PMO y Producto y qué modelos híbridos están usando las empresas para equilibrar control y adaptabilidad.
Seguramente hemos escuchado hablar o leído sobre producto, priorización del valor o la autonomía en los equipos.
Luego ya cuando estamos en el trabajo, sea cliente o nosotros como parte de la organización, nos chocamos con la realidad…
El equipo SI que trabaja por sprints y ni que hablar, 100% de adaptación
Pero la organización está en otra sintonía ya que maneja planificación anual, presupuestos cerrados y cuando toma decisiones, NO siempre considera lo que pasa en el backlog.
Y aparecen situaciones que hemos vivido varios seguramente:
– Roadmaps comprometidos antes de empezar el desarrollo.
– Planes anuales cerrados que no pueden cambiar aunque cambie el contexto.
– Presupuestos aprobados por iniciativa, no por valor generado.
– Equipos que deben cumplir fechas definidas fuera del equipo.
– Backlogs que en teoría son ágiles, pero en la práctica ya vienen decididos.
– Product Owners que gestionan el detalle, pero no participan en las decisiones estratégicas.
El problema no es la PMO.
Y menos que Producto esté mal.
Muchas veces es el resultado natural de cómo están diseñadas las organizaciones grandes.
• Gobierno financiero centralizado.
• Planificación anual.
• Control por hitos.
• Reporting ejecutivo.
• Dependencias entre múltiples áreas.
Y cuando ese modelo convive con agilidad… aparece la tensión.
• Proyecto vs Producto.
• Plan vs Aprendizaje.
• Control vs Adaptación.
• Cumplimiento vs Valor.
No hay que elegir un lado de estos, no va por ahí, sino entender cómo evolucionar el sistema para que ambos puedan convivir sin bloquear la entrega de valor.
Primero explicaré de que va la PMO tradicional
La PMO suele dar control, previsibilidad y visibilidad sobre inversiones que muchas veces son muy grandes.
Por eso trabaja normalmente con:
• Planificación anual
• Presupuesto aprobado por iniciativa
• Alcance definido desde el inicio
• Fechas comprometidas
• Seguimiento por hitos
• Reporting ejecutivo
Desde este modelo, cambiar prioridades a mitad de año no es trivial, porque afecta a financiación, contratos, dependencias y compromisos con negocio.
El problema aparece cuando este modelo convive con equipos que intentan trabajar con lógica de producto.
Qué necesita el modelo de PRODUCTO
Cuando una organización trabaja realmente por producto, la lógica cambia.
No se parte de un plan cerrado, sino de una dirección estratégica que se va ajustando.
Se necesita:
• Aprendizaje continuo
• Priorización basada en valor
• Roadmap adaptable
• Discovery antes de comprometer alcance
• Iteración corta
• Feedback frecuente
En este contexto, comprometer todo el año desde el inicio suele ser arriesgado, porque el valor real muchas veces se descubre durante el camino.
Y ahí es donde empiezan los conflictos.
Donde chocan PMO y Producto
En la práctica, el choque no suele ser teórico, sino muy concreto.
La PMO necesita plan cerrado...........pero.............. Producto necesita margen para aprender.
La PMO necesita fechas.................pero.............. Producto necesita iterar.
La PMO mide cumplimiento...............pero.............. Producto mide impacto.
La PMO pide previsibilidad.............pero.............. Producto trabaja con incertidumbre.
“AQUÍ FALTA ALGO MAS”
Cuando ambos modelos conviven sin cambiar la gobernanza, aparecen síntomas muy claros:
• Backlog que en realidad no decide el equipo
• Roadmap impuesto desde arriba
• Discovery reducido o inexistente
• Product Owner sin poder real
• Equipos que ejecutan, pero no deciden
• Sensación constante de falta de foco
Y muchas veces el problema no es el equipo.
Es el sistema.
Antes de iniciar sobre los modelos a proponer, brindo un caso típico de presupuesto anual vs adaptabilidad a la incertidumbre
Cómo alinear presupuestos anuales cerrados con la necesidad de adaptarse continuamente.
Cuando la financiación está aprobada por iniciativa desde el inicio del año, cualquier cambio en prioridades implica volver a justificar inversión, mover partidas o renegociar compromisos.
En ese escenario, la adaptabilidad del equipo no depende solo del equipo, sino de cómo está diseñado el modelo de gobernanza financiera.
Algunas organizaciones están evolucionando hacia modelos donde el control se mantiene, pero la flexibilidad aumenta.
Por ejemplo, financiando productos o value streams en lugar de proyectos, revisando prioridades de forma periódica o separando la planificación financiera de la priorización del backlog. Esto a mayor detalle lo veremos líenas abajo en "Financiar capacidad, no solo entregables cerrados"
Se que no es un cambio sencillo, pero es uno de los puntos clave cuando PMO y Producto tienen que convivir.
Lo que pasa cuando no se ajusta el modelo
Cuando no se cambia la forma de gobernar, suelen aparecer modelos híbridos que funcionan a medias.
Doble gobierno.
Backlog formal y backlog real.
Roadmap público y roadmap interno.
Decisiones fuera del equipo.
Equipos ágiles dentro de estructuras rígidas.
Y eso genera frustración en todos lados.
La PMO siente que pierde control.
Producto siente que no puede priorizar.
El equipo siente que no decide nada.
Negocio siente que no ve resultados.
Modelos híbridos que están funcionando en empresas grandes
No existe una única forma de resolver el choque entre PMO y Producto.
De hecho, uno de los errores más comunes es intentar copiar un modelo completo de otra organización sin entender por qué funcionó allí y no necesariamente en otro contexto.
Lo que sí se ve en empresas grandes es que, cuando este conflicto se aborda bien, no se elimina de golpe la PMO ni se deja todo “a criterio del equipo”. Lo que ocurre es una evolución del sistema de gobierno. La organización mantiene control, visibilidad y disciplina financiera, pero cambia la forma en la que prioriza, financia y decide.
A continuación, explico algunos de los modelos o mecanismos híbridos que mejor están funcionando hoy en entornos enterprise.
1. PMO evolutiva: de controlar proyectos a facilitar flujo de valor
Qué cambia respecto a una PMO tradicional
Una PMO tradicional suele centrarse en:
• Cumplimiento de fechas
• Seguimiento de hitos
• Control presupuestario por iniciativa
• Reporting ejecutivo
• Gestión de desvíos contra un plan base
Una PMO evolutiva amplía esa mirada y empieza a incorporar también:
• Seguimiento de flujos y cuellos de botella
• Dependencias entre equipos
• Capacidad disponible vs demanda real
• Alineamiento estratégico
• Priorización entre iniciativas
• Métricas de outcome además de output
No abandona el control, pero deja de medir solo la ejecución del plan.
Para qué SÍ sirve
Este modelo suele funcionar bien cuando una organización no puede ni quiere eliminar la PMO, pero sí necesita que deje de ser un actor que rigidiza la entrega. Es especialmente útil en empresas grandes, reguladas o con alta complejidad operativa, donde la coordinación transversal sigue siendo necesaria.
Cuándo NO usarla
No basta si la organización sigue financiando todo como proyecto cerrado y además mantiene la decisión real fuera del entorno de Producto. En ese caso, la PMO puede cambiar el discurso, pero el sistema sigue funcionando igual.
Errores comunes
Uno de los errores más habituales es cambiar el discurso pero no cambiar el modelo real de decisión. Se empieza a hablar de flujo, valor o priorización continua, pero se siguen pidiendo planes cerrados, fechas comprometidas y reporting basado únicamente en cumplimiento.
Otro error frecuente es intentar que la PMO sea más flexible sin revisar cómo se financian las iniciativas. Si el presupuesto sigue aprobado por proyecto y con alcance fijo, la PMO tendrá que seguir controlando contra ese plan, aunque el lenguaje sea más ágil. También es común sobrecargar a la PMO con nuevos roles sin redefinir responsabilidades. Se le pide que coordine dependencias, mida valor, revise prioridades y facilite el flujo, pero sin darle capacidad real para influir en las decisiones estratégicas, lo que termina generando más burocracia en lugar de menos.
Un ejemplo real
Una empresa con varios equipos de desarrollo mantiene una PMO corporativa. Antes la PMO pedía cronogramas detallados a 12 meses. Después de su evolución, sigue reportando a dirección, pero empieza a trabajar con revisiones trimestrales, estado del flujo, dependencias críticas y riesgo sobre objetivos estratégicos, no solo sobre tareas completadas.
Riesgo habitual
El riesgo es llamarla “PMO ágil” pero seguir haciendo lo mismo de antes con otro lenguaje. Es decir, hablar de valor, flujo o priorización, pero seguir exigiendo planes cerrados, fechas inamovibles y reporting de cumplimiento como si nada hubiese cambiado.
2. Lean Portfolio Management: gobernar sin microgestionar
Qué problema intenta resolver
Muchas empresas tienen una desconexión fuerte entre:
• La estrategia corporativa
• Las inversiones aprobadas
• Las prioridades que ejecutan los equipos
Lean Portfolio Management intenta cerrar esa brecha, evitando que la planificación anual se convierta en un contrato rígido que bloquee el aprendizaje.
Para qué SÍ sirve
Es útil cuando la empresa tiene múltiples iniciativas compitiendo por recursos, necesita transparencia a nivel directivo y no puede dejar la priorización completamente descentralizada, pero al mismo tiempo quiere reducir el exceso de control por proyecto.
Funciona especialmente bien cuando hay varios productos, muchas dependencias o equipos trabajando sobre objetivos de negocio comunes.
Cuándo NO usarla
No sirve mucho implantarlo “por framework” si la organización todavía no tiene un mínimo de claridad estratégica, ni disciplina de priorización, ni madurez para revisar decisiones periódicamente. Sin eso, solo se convierte en una capa nueva de reuniones.
Errores comunes
Un error muy frecuente es implantar Lean Portfolio como si fuera solo una nueva estructura de reuniones o de comités, sin cambiar realmente cómo se toman las decisiones de inversión. Se mantiene la lógica tradicional, pero se añaden más capas de revisión, lo que termina ralentizando todavía más el sistema.
También ocurre que se intenta aplicar el modelo sin tener claridad estratégica suficiente. Si la organización no tiene objetivos bien definidos o cambia de prioridad constantemente por presión política, el portfolio se vuelve inestable y el modelo pierde credibilidad.
Otro error común es querer mantener el mismo nivel de detalle que en la gestión por proyecto. Lean Portfolio funciona mejor cuando la dirección decide a nivel estratégico, no cuando intenta controlar cada iniciativa como antes, solo que con otro nombre.
Un ejemplo real
Una compañía aprueba cada año 40 iniciativas con business case individual. El resultado: demasiadas cosas abiertas, poco foco y equipos saturados. Al evolucionar, agrupa la inversión en grandes líneas estratégicas revisadas trimestralmente, y la decisión ya no es solo “si el proyecto sigue vivo”, sino qué parte del portfolio merece más atención según valor, capacidad y aprendizaje reciente.
Riesgo habitual
Usarlo como una estructura bonita en PowerPoint, sin cambiar realmente quién decide y con qué criterios. Si la alta dirección sigue imponiendo prioridades por política o urgencia del momento sin revisar capacidad real, entonces el portfolio sigue siendo tradicional aunque use lenguaje lean.
3. Gobernanza por producto en lugar de por iniciativa
Qué cambia
Cuando se gobierna por iniciativa, la pregunta suele ser:
“¿Ya terminamos esto?”
Cuando se gobierna por producto, la pregunta cambia a:
“¿Este producto está generando el resultado que esperamos y qué conviene priorizar ahora?”
Ese cambio parece pequeño, pero transforma completamente la lógica de decisión.
Para qué SÍ sirve
Es útil cuando la organización tiene capacidades digitales o productos internos/externos que no se “terminan” realmente, sino que evolucionan. Plataformas, apps, canales digitales, productos de datos, ecosistemas internos, servicios core del negocio.
Cuándo NO usarla
No todas las iniciativas justifican una gobernanza por producto. Si hablamos de un cambio regulatorio puntual, una migración cerrada o una necesidad de cumplimiento con alcance muy definido y vida limitada, puede seguir teniendo sentido gestionarlo como iniciativa temporal.
Errores comunes
Un error habitual es llamar “producto” a algo que sigue gestionándose como proyecto. Se cambia el nombre del roadmap o del comité, pero se sigue aprobando alcance fijo, fecha fija y presupuesto fijo, lo que impide que el producto evolucione realmente.
También es frecuente definir productos demasiado pequeños o demasiado temporales, lo que obliga a volver constantemente a la lógica de iniciativa. Cuando el producto no tiene continuidad, la gobernanza por producto pierde sentido.
Otro problema común es no definir claramente quién tiene autoridad sobre el producto. Si negocio, PMO y dirección siguen tomando decisiones fuera del entorno del producto, el cambio se queda solo en la estructura, pero no en la forma real de decidir.
Un ejemplo real
En lugar de aprobar diez proyectos separados para ecommerce, checkout, catálogo, promociones y analytics, la empresa empieza a tratarlos como parte de un producto o dominio de negocio más amplio. Eso evita trocear artificialmente decisiones que en realidad están conectadas.
Riesgo habitual
Llamar “producto” a algo que en realidad sigue siendo un proyecto con otro nombre. Por ejemplo, cambiar el título del comité o del roadmap, pero seguir aprobando alcance fijo, fecha fija y presupuesto fijo como antes.
4. Funding por value streams: financiar capacidad, no solo entregables cerrados
Para qué SÍ sirve
Uno de los mayores bloqueos a la agilidad real aparece cuando cada ajuste de prioridad requiere reabrir el debate presupuestario. Si el dinero está atado a una lista cerrada de entregables, cualquier cambio se percibe como desviación. En cambio, si se financia una capacidad o un value stream, existe más margen para repriorizar dentro de ese marco.
Cuándo usarlo
Suele tener sentido en productos o dominios con demanda sostenida, backlog vivo y necesidad constante de adaptación. Por ejemplo:
• canal digital
• experiencia cliente
• pagos
• logística digital
• plataforma de datos
• onboarding de clientes
Cuándo NO usarla
No encaja igual de bien en trabajos muy puntuales, excepcionales o con vida corta, donde sí es razonable una financiación más acotada y temporal.
Errores comunes
Uno de los errores más comunes es pensar que financiar por value streams significa dejar de controlar el gasto. Cuando esto ocurre, la organización suele reaccionar volviendo al modelo de proyecto, porque percibe falta de visibilidad o de control.
También es habitual intentar aplicar funding por value stream sin cambiar el sistema de reporting. Si se sigue pidiendo justificar cada cambio como si fuera una iniciativa independiente, el modelo pierde sentido y vuelve la rigidez.
Otro error frecuente es definir value streams de forma artificial, sin que representen realmente flujos de valor estables. En esos casos, el presupuesto sigue fragmentado y la flexibilidad que se buscaba no aparece.
Un ejemplo real
En lugar de aprobar presupuesto para 14 proyectos separados del canal digital, la organización asigna un presupuesto anual a un value stream de “venta digital y experiencia cliente”.
Dentro de ese marco, se pueden mover prioridades entre mejora de conversión, performance, checkout, contenido o retención según el aprendizaje del trimestre.
Riesgo habitual
Pensar que funding por value stream significa ausencia de control. No es así. El control sigue existiendo, pero cambia de nivel. Ya no se controla tanto si el equipo ejecutó exactamente una lista cerrada, sino si el flujo financiado está generando valor, foco y aprendizaje suficiente.
5. Separar planificación financiera de priorización continua
Para qué SÍ sirve
Es especialmente útil en empresas que no pueden cambiar de un día para otro su ciclo presupuestario, pero sí quieren dar más margen a Producto y a los equipos para repriorizar dentro de límites acordados.
Cuándo NO usarla
No funciona si, aunque formalmente se diga que el backlog es flexible, en la práctica cualquier cambio genera un conflicto político, financiero o de reporting. Ahí la separación existe solo en teoría.
Errores comunes
El error más habitual es decir que el backlog es flexible, pero seguir exigiendo el mismo nivel de detalle que en una planificación cerrada. La organización mantiene el presupuesto anual, pero también quiere saber exactamente qué se entregará dentro de varios meses, lo que vuelve a generar rigidez.
Otro problema frecuente es que la separación exista solo en teoría. Formalmente se permite repriorizar, pero en la práctica cada cambio genera discusión financiera, política o de reporting, por lo que el equipo termina evitando cualquier ajuste.
También es común mantener dos sistemas en paralelo: uno para cumplir con la planificación anual y otro para trabajar de forma iterativa. Esto genera doble trabajo, confusión y sensación de falta de coherencia en la organización.
Un ejemplo real
La dirección aprueba que durante el año una determinada línea de producto tenga un equipo, un presupuesto y unos objetivos.
Pero no obliga a definir desde enero las épicas exactas de cada trimestre. El detalle se va revisando en ciclos más cortos, según feedback, datos y necesidades del mercado.
Riesgo habitual
Que la organización mantenga una planificación anual detallada “por si acaso” y además haga priorización continua encima. Resultado: doble trabajo, doble expectativa y sensación de contradicción permanente.
6. OKR para dirección estratégica y backlog para ejecución
Qué resuelve
Permite que la conversación ejecutiva no tenga que entrar al detalle del sprint ni a decidir cada historia de usuario. Y a la vez permite que el equipo no pierda conexión con resultados de negocio más amplios.
Para qué SÍ sirve
Funciona bien cuando hay cierta madurez en liderazgo y se quiere evitar que dirección baje a microgestionar entregables. También ayuda cuando el backlog ya estaba sobrecargado de peticiones sin un hilo estratégico claro.
Cuándo NO usarla
No aporta gran cosa si se implantan OKR como moda, sin métricas reales ni capacidad para tomar decisiones en función de resultados. En ese caso, los OKR se convierten en otro documento bonito sin impacto.
Errores comunes
Uno de los errores más frecuentes es convertir los OKR en una lista de tareas, en lugar de usarlos como dirección estratégica. Cuando los OKR bajan al nivel de detalle operativo, el equipo pierde margen para decidir cómo alcanzar el resultado.
También ocurre que se definen OKR sin métricas claras o sin capacidad real para cambiar decisiones en función de los resultados. En esos casos, los OKR se convierten en un documento más, sin impacto en la priorización.
Otro error habitual es mantener el roadmap completamente cerrado y al mismo tiempo introducir OKR. Si no hay espacio para adaptar el backlog, los OKR no sirven como guía, solo como un formalismo.
Un ejemplo real
Un objetivo estratégico puede ser mejorar conversión o reducir abandono en un canal digital. Ese objetivo y sus indicadores se definen a nivel de negocio. Luego el backlog va cambiando según los aprendizajes del equipo: mejoras de UX, pruebas A/B, cambios técnicos, ajustes de funnel, experimentos de pricing, etc. El OKR da dirección; el backlog da ejecución adaptable.
*Riesgo habitual
Usar los OKR como lista de tareas o como sustituto del roadmap. Los OKR no deberían decirle al equipo cada cosa que tiene que construir. Deberían marcar hacia dónde se quiere mover el resultado.
7. Diferenciar Product Manager y Product Owner
Qué problema resuelve
Evita cargar sobre el Product Owner una expectativa irreal: que al mismo tiempo gobierne la estrategia, pelee presupuesto, gestione stakeholders, priorice con el equipo y esté presente en todo el detalle operativo.
Para qué SÍ sirve
Tiene sentido cuando el producto tiene mucha complejidad de negocio, múltiples stakeholders, dependencia del portfolio o mucha carga de coordinación estratégica.
Cuándo NO usarla
En productos pequeños o equipos con menor complejidad, separar ambos roles puede ser innecesario e incluso burocrático.
Errores comunes
Un error muy común es crear ambos roles sin repartir realmente la autoridad. Se define un Product Manager y un Product Owner, pero las decisiones siguen tomándose fuera del producto, por lo que ninguno de los dos tiene capacidad real para priorizar.
También ocurre que se separan los roles sin aclarar responsabilidades, lo que genera solapamientos, conflictos o sensación de duplicidad dentro del equipo.
Otro problema frecuente es cargar todo el peso estratégico sobre el Product Manager sin darle tiempo ni contexto para hacerlo, o cargar todo el detalle sobre el Product Owner sin reducir las expectativas que antes tenía el rol único.
Cuando esto pasa, la estructura cambia, pero el problema de fondo sigue igual.
Un ejemplo real
El Product Manager trabaja con negocio, dirección, métricas de producto, visión y decisiones de inversión. El Product Owner aterriza eso con el equipo, mantiene el backlog sano, aclara prioridades inmediatas y facilita que la ejecución tenga foco. Ambos se necesitan, pero no hacen lo mismo.
Riesgo habitual
Crear dos roles sin repartir realmente la autoridad. A veces se pone un Product Manager y un Product Owner, pero ambos siguen esperando aprobación externa para casi todo. En ese caso, solo se añadió estructura, no capacidad real de decisión.
Entonces... ¿Cuál de estos modelos conviene elegir?
Para mi depende de muchos factores, no existe una receta mágica.
Depende de la cultura de la organización, nivel de madurez, el rubro de la industria, del nivel de regulación, de la estructura financiera y del tipo de productos que tenga la organización.
Pero no nos desanimemos, lo que SI o SI debemos de hacer cuando aparece este conflicto entre PMO y Producto es:
Revisar todo esto en la organización para ver como rediseñar la toma de decisiones de la organización:
• Quién prioriza realmente
• Quién aprueba la inversión
• Qué nivel de detalle necesita dirección
• Qué puede adaptarse y qué no
• Qué parte del trabajo es proyecto y qué parte es producto
• Qué métricas importan de verdad
Si eso no cambia, da igual cuántos rituales ágiles haga el equipo. El conflicto seguirá apareciendo.
Mi conclusión
El problema no es que la PMO exista.
Y tampoco que Producto quiera ser ágil.
El problema aparece cuando se intenta aplicar agilidad en el equipo sin cambiar la forma en la que la organización decide.
En las organizaciones, el reto no es elegir entre proyecto o producto.
El reto es rediseñar la gobernanza para que ambos puedan convivir sin bloquear la entrega de valor.
Y esa conversación, muchas veces, es más organizacional que técnica.
Gracias a todos los que llegaron hasta el final. Si tienen alguna sugerencia de lagún tópico que tocar, pueden dejarmelo como sugerencia aquí abajo.
Deja un comentario