Proxy Product Owner: ¿por qué existe y cómo alcanzar un auténtico PO?
Tiempo de lectura: 5 minutos
En este artículo revisamos qué es un Proxy Product Owner, por qué suele aparecer este rol en las organizaciones que adoptan agilidad, y algunas propuestas para superarlo y conseguir un Product Owner completo.
¿Qué es un Proxy PO?
Un Proxy Product Owner (Proxy, en adelante) es un rol que actúa como intermediario entre quienes toman las decisiones sobre el producto y el equipo de desarrollo. Adopta parte de las responsabilidades habituales de un Product Owner (PO) — recoger las necesidades de los clientes, estructurar y priorizar el Backlog de Producto, negociar con el equipo su realización, validar cuándo el producto está listo para entregarse — pero es una versión incompleta.
Las principales carencias de un Proxy suelen ser: no es el dueño del producto, por lo que no toma las decisiones fundamentales ni suele responder por su resultado; no controla el presupuesto; a veces no define la visión ni la estrategia del producto; y no tiene la última palabra sobre qué forma parte del producto. Es una mejora respecto a no tener PO en absoluto, pero conduce a resultados muy mejorables respecto al valor entregado, especialmente en organizaciones complejas con múltiples actores interesados.
¿Por qué las organizaciones funcionales generan un Proxy Product Owner?
Las organizaciones funcionales (departamentales), que agrupan a sus miembros según el tipo de trabajo que realizan, son con diferencia el tipo más frecuente — herencia directa del Management Científico o Taylorismo. Suelen dividir a sus miembros entre "Negocio" e "Informática", con un responsable de cliente (Business Relationship Manager) que gestiona la demanda del negocio y un jefe de proyecto que lidera su realización.
Cuando estas organizaciones adoptan Scrum sin un buen entendimiento del rol de PO, es fácil identificarlo con alguien de informática que continúa la interlocución entre "Negocio" y el equipo — encaja de forma natural con el jefe de proyecto tradicional, que además no se ve a sí mismo ni como Developer ni como Scrum Master. Y si se plantea a los responsables de negocio, los PO ideales, que deben dedicarse a gestión detallada del backlog y los requisitos, es lógico que lo vean incompatible con sus responsabilidades actuales. Con estos ingredientes, el Proxy Product Owner aparece casi por inercia.
¿Cómo se supera el Proxy Product Owner?
Lo primero es que la organización y quienes la asesoran (Scrum Masters, Agile Coaches) entiendan bien el rol de Product Owner, y sobre todo asuman el rediseño organizativo que supone: integrar en Equipos Scrum autónomos a personas de "Negocio" (el PO) y a otros roles hoy repartidos entre distintos grupos de IT. Sin esto, la adopción de Scrum empieza con mal pie.
Lo segundo es entender que un Development Team auténtico debe ser autosuficiente, y por tanto se le puede delegar perfectamente el detalle de la gestión del backlog — su estructuración, la definición de los ítems, incluso los criterios de aceptación — mientras el Product Owner se mantiene informado y toma las decisiones que de verdad afectan al valor del producto.
Y lo tercero es encontrar un buen encaje para los jefes de proyecto tradicionales. Si son expertos en gestión de equipo, nadie mejor que ellos para entrar en el Development Team y ayudar a los demás a desarrollar esa capacidad — dejando claro desde el primer momento que su rol ya no es liderar el equipo, sino fomentar su autoorganización.
Si quieres profundizar en cómo se organiza un Product Owner según el tipo de producto que gestiona, sigue con ¿eres un Product Owner de tipo B2B o B2C?. El curso Professional Scrum Product Owner te ayuda a entender en profundidad qué implica asumir el rol completo, no solo una versión Proxy.