Cuando el Product Owner no puede decidir de verdad
La Guía de Scrum es tajante sobre el Product Owner: es una sola persona, responsable de maximizar el valor del producto, que es dueña del Product Backlog y de su ordenamiento. Para que eso signifique algo, la organización debe respetar las decisiones que toma el Product Owner. Cuando no lo hace —cuando el cargo existe pero la autoridad no—, Scrum conserva las ceremonias y pierde el sentido. En 2022, con presupuestos apretados por la inflación y equipos repartidos entre la casa y la oficina, un Product Owner incapaz de decidir se convertía pronto en la pieza más lenta de todo el sistema.
La mayoría de las fallas siguen unos pocos patrones recurrentes. Vale la pena nombrarlos, porque cada uno tiene una corrección concreta.
Dónde se quiebra la autoridad del Product Owner
El testaferro sin mandato. Se da el cargo a alguien con poca experiencia, pero cada decisión real vuelve a un comité directivo o a un alto directivo. Los Desarrolladores esperan, el backlog se atasca y el valor se erosiona. La corrección: dar el rol a alguien en quien la organización confíe para decidir, o delegar de verdad la autoridad en quien ostenta el cargo.
El backlog por comité. Cuando varios interesados insisten en que sus elementos vayan primero, el ordenamiento se vuelve teatro de negociación. La Guía de Scrum es clara: una sola persona decide el orden. Recoja opiniones ampliamente, pero la secuencia final corresponde únicamente al Product Owner.
El escribiente, no quien decide. Algunos Product Owners solo trasladan solicitudes y redactan tickets. Eso es administración, no propiedad del producto. El rol existe para arbitrar el valor: decir no, posponer, elegir. Si nunca dicen no, no están siendo dueños del producto.
Ausente cuando importa. Un Product Owner que se salta la Planificación del Sprint, ignora la Revisión del Sprint o resulta inaccesible durante el Sprint obliga a los Desarrolladores a adivinar. Las conjeturas se convierten en retrabajo. El rol exige disponibilidad real, no una aparición en el calendario.
Sin un Objetivo del Producto claro. Sin un Objetivo del Producto contra el cual ordenar, el backlog se vuelve una lista de deseos y la priorización se torna arbitraria. El Product Owner fija y comunica ese objetivo para que cada decisión de orden tenga un punto de referencia.
Recuperar a un Product Owner que pueda decidir
La solución rara vez es una mejor persona; suele ser un mandato más claro y la disciplina organizacional para honrarlo. La dirección debe respaldar en público las decisiones del Product Owner, incluso las impopulares, y resistir el impulso de anularlas desde arriba en mitad del Sprint.
Nombre un solo Product Owner por producto y otórguele derechos de decisión reales y visibles.
Deje que los interesados influyan en el backlog a través del Product Owner, no rodeándolo.
Fije un Objetivo del Producto para que cada decisión de prioridad se remonte a algo concreto.
Proteja el tiempo del Product Owner para que esté presente y accesible durante todo el Sprint.
Haga que la dirección defienda las decisiones del Product Owner en lugar de revertirlas en silencio.
Una buena verificación: en el último mes, ¿a qué dijo no este Product Owner? Si la respuesta es nada, la autoridad es decorativa. La verdadera propiedad del producto se manifiesta en arbitrajes deliberados que a algunos disgustan, porque elegir qué construir siempre implica elegir qué no construir, y alguien tiene que asumir esa decisión y respaldarla.
Si sus Product Owners tienen el cargo pero no la autoridad, la asesoría en ejecución de programas y proyectos de XNM puede ayudarle a establecer el mandato y la gobernanza que les permitan decidir de verdad.