Durante años, el rol del Product Owner (PO) ha sido presentado como uno de los pilares de Scrum y, por extensión, de la gran mayoría de iniciativas ágiles (nos guste o no) que aspiren a ser orientadas al valor. Sin embargo, la realidad de las organizaciones nos muestra una verdad incómoda: el PO tuvo un éxito marginal. Y cuando lo ha hecho, ha requerido de mucho esfuerzo.

No queremos convencer a nadie con este post. Queremos generar discusión y pensamiento, base siempre de la evolución. Pero la realidad dura la dejamos planteada como preguntas: ¿Qué nivel de éxito ha tenido el rol del PO? ¿Fue siempre muy idealizado?

Mientras tanto, roles como el del Business Analyst (BA o a veces llamado PO Proxy) —menos celebrados (y de plano criticados) por los ágilistas más dogmáticos — han ocupado silenciosamente y en la práctica de un mundo no ideal el espacio que la teoría le reservaba al PO, convirtiéndose en puentes pragmáticos entre la visión y la ejecución. En el mejor de los casos, no para quedarse, pero si para “abrir camino”.

El Product Owner según la Guía de Scrum

La Scrum Guide (Ken Schwaber y Jeff Sutherland, ed. 2020) define al PO como:

“El Product Owner es responsable de
maximizar el valor del producto resultante
del trabajo del equipo Scrum.”
—Scrum Guide, 2020

Sus responsabilidades, según este documento, incluyen:

• Gestionar efectivamente el Product Backlog.
• Comunicar claramente los ítems del backlog.
• Asegurar que el backlog sea visible, transparente y comprendido.
• Priorizar ítems que maximicen el valor.
• Asegurar que el equipo entienda adecuadamente los ítems del backlog.

Aunque suena simple, esta definición implica un conjunto de condiciones que rara vez se dan simultáneamente:

• Autoridad real.
• Criterio estratégico.
• Orientación a valor.
• Tiempo exclusivo.
• Presencia continua.

El Business Analyst según el BABOK

El Business Analysis Body of Knowledge (BABOK v3, IIBA, 2015) define al BA como:

“Un agente de cambio que trabaja para
identificar y definir las necesidades del negocio y
recomendar soluciones que entreguen
valor a las partes interesadas.”

Sus áreas de conocimiento incluyen:

• Elicitación y colaboración.
• Análisis de requerimientos y diseño.
• Estrategia y planificación.
• Evaluación de soluciones.
• Gestión del ciclo de vida de los requerimientos.

A diferencia del PO, el BA se define como un rol técnico-funcional, con una fuerte orientación a la trazabilidad, la estructuración de requerimientos y la conexión entre negocio y tecnología. No se exige que tenga autoridad total sobre el producto, sino que facilite decisiones informadas y consistentes.

Pero más que nada, representa un rol que las organizaciones en proceso de transformación, que tienen una mentalidad todavía anterior, pueden masticar y digerir sin tanta dificultad, ayudando a su éxito aunque sea temporal, de camino a otros paradigmas todavía en adopción…

¿Podríamos decir lo mismo del PO?. Difícil. El negocio en transformación, pensante todavía en proyectos y no en productos, nunca pudo colocar al PO en ningún lugar: no era jerárquico, no era un Project Manager… simplemente no lo entendieron. Ciertamente la guía de Scrum queda debiendo una declaración muy puntual de lo que es un “Producto” versus un proyecto, si es que va a hablar de “Product” Owner.

Los supuestos imposibles donde el PO no dió la talla.

En la práctica, el PO ha sido muchas veces:

• Un gerente funcional que “hereda” el rol, pero sin tiempo ni foco.
• Un proxy sin decisión real, que solo traduce pedidos.
• Un stakeholder sin conocimiento digital profundo.

Esto ocurre porque los supuestos del rol no encajan con la estructura organizacional heredada. Scrum pide que el PO sea la voz del negocio, pero la mayoría de las organizaciones aún no piensan en productos digitales como activos continuos; siguen operando en lógica de proyectos, donde el foco es cumplir alcance, plazo y presupuesto.

Ya lo sugerimos: la Guía de Scrum no lo resolvía todo

La Guía de Scrum, en su afán de ser minimalista, dejó fuera temas clave para la gestión de productos digitales:

• No habla de release planning.
• No aborda prácticas de descubrimiento.
• No incorpora experimentación validada.

Por eso, muchas organizaciones incorporaron prácticas de otros marcos como:

• Lean Startup (Eric Ries): ciclo de construir-medir-aprender.
• Extreme Programming (Kent Beck): historias de usuario, planificación por puntos de historia.

Aplaudimos a quienes lo vieron así: la Guía de Scrum necesitaba complementos! Y en ese sentido es bueno que haya sido “minimalista”, para no volverse un mamotreto teórico inmenso que hubiese ahi si desafiado a la mentalidad ágil, como si lo hicieron otras propuestas. Las organizaciones que decidieron complementar Scrum, o inclusive interpretarlo y extenderlo, tomaron el camino correcto, más allá de si tuvieron éxito en el intento.

Otras en cambio, haciendo esa incorporación en buena fé, lastimosamente cayeron nuevamente en la mentalidad de control: en vez de entenderlas como complementos conceptuales, se volvieron recetas rígidas, con un sesgo hacia la eficiencia operativa, más que hacia la entrega de valor validado.

El resultado: se medía la velocidad del equipo por puntos entregados, no por aprendizajes obtenidos ni valor generado. Y el PO se convirtió en un “administrador de backlog” más que en un “guardián del propósito”.

Y si, otras —organizaciones, personas y hasta agilistas — simplemente quisieron ejecutar el libro al pie de la letra. Esas definitivamente no entendieron nada.

¿Y si el BA fue siempre el puente que necesitábamos, mientras pensemos en proyectos?

Consultoras como Thoughtworks adoptaron desde temprano una visión más flexible. Lo mencionamos con claridad como un buen ejemplo, no solo porque lo vimos entregar resultados tangibles, sino porque personifica justamente lo que la agilidad siempre propuso en su esencia: que respetando ciertos valores y principios, tengamos la inteligencia suficiente para plantear nuestras propias interpretaciones en los contextos reales y en cada momento de la evolución de las organizaciones.

Para ellos, el BA no reemplazaba al PO, pero sí resolvía el vacío operativo que la organización no podía llenar de inmediato:

• Tenía tiempo dedicado.
• Participaba en la conversación de descubrimiento.
• Conocía al usuario y al equipo técnico.
• Mantenía vivo el backlog y organizaba releases viables.

Consultoras como Accenture, IBM, Cognizant y Capgemini han usado variaciones del rol de BA (a veces con nombres como Functional Analyst o Digital Analyst) para mantener la conversación fluida entre stakeholders, equipos y soluciones, en especial en contextos regulados o legacy, donde el PO ideal era inviable. No puedo hablar por ellos, porque ciertamente al no usar la mentalidad correcta, como todo, esta idea puede deformarse solamente para monetizar. Triste pero cierto.

En la era de los codebots, el “qué” importará más que el “cómo”

Como presentamos en nuestro post sobre Synthetic Teams, hoy se proyecta un futuro en el que buena parte del desarrollo será asistido o incluso ejecutado por IA. No lo digo como un deseo, ni siquiera se si estamos de acuerdo con esto, es simplemente el poder del capital el que se terminará imponiendo. El dejar de aceptar esa realidad, nos pone nuevamente en plano teórico e idealista que ya ha hecho demasiado daño a la agilidad.

En este escenario, la necesidad de tener claridad sobre qué se construye y por qué será más crítica que nunca. Mientras algunos temen la automatización del rol técnico, pocos se dan cuenta de que:

• El valor diferencial no estará en el código, sino en la decisión estratégica del backlog.
• El análisis de valor, de hipótesis y de impacto sigue siendo profundamente humano.

Y ahí, el BA preparado para pensar en producto, y el PO liberado de tareas operativas, pueden convertirse en una dupla potente para liderar esta transición. Por lo menos no se ven tan reemplazables como ya las consultoras opinan sobre los desarrolladores. Y de paso podrían aprovechar y evolucionar el nombre del PO a un “Product Strategist” dándole la autoridad y el enfoque que siempre debió tener.

Cómo avanzar: menos ideal, más real

Es momento de abandonar el purismo. El PO no fracasó porque la idea fuera mala, sino porque el contexto no maduró a la velocidad necesaria.

En vez de seguir esperando el PO ideal, quizás debemos construirlo progresivamente, apoyándonos en roles como el BA, que —lejos de ser una herejía— pueden ser la base sobre la cual esa visión se vuelva realidad.

En Itera lo hemos visto una y otra vez: las organizaciones que abrazan la agilidad con criterio (y no con dogma) logran más avances reales, sostenibles y valiosos.

¿Quieres conversar sobre cómo diseñar una estructura de roles que funcione realmente en tu contexto, sin sacrificar la visión de producto?

Hablemos. En Itera tenemos la experiencia exitosa y real para acompañarte a encontrar ese punto de equilibrio entre la teoría y la práctica, entre la visión y la entrega.