Ayer tuve la oportunidad de asistir a LPCxMAD, un pequeño evento en Madrid organizado por Thiga, que es una versión más local y relajada de La Product Conf. Allí coincidí con algunos de los sospechosos habituales, pero lo que más disfruté fue reencontrarme con @CarlosTheSailor, quien además era uno de los ponentes. Siempre tan generoso, Carlos vino desde Barcelona, haciendo malabares con su agenda, sólo para esto. Es de esas personas que, simplemente con su ejemplo, ya están construyendo comunidad.
Su charla se me hizo cortísima, pero aun así logró dejar dos mensajes muy potentes: “Atentos al cargo cult (las prácticas que hacemos por inercia) también en desarrollo de producto” y “El producto no es un fin, sino un medio: lo importante es el impacto en el negocio” (o como él prefiere decir: #NoProducts 💃). NOTA: El emoji es clave; forma parte del mensaje. 🙂 No voy a desarrollar estas ideas para no hacerle más “spoiler” del que ya le he hecho, por si tiene previsto llevar esta charla a otros eventos.
Pero lo mejor estaba aún por venir. Efectivamente: la conversación post-evento aka “las cervezas”. En ella surgieron dos debates muy interesantes que se fueron entrelazando. Por un lado, la reacción alérgica del mercado hacia todo lo que suena a Agile. Y por otro, cómo las empresas están ahora enfocándose más en desarrollar capacidades reales de desarrollo ágil de producto digital. Sobre el primero, me lo voy a guardar porque llevo tiempo preparando un artículo al respecto y, además, no quiero mezclar temas. Este artículo se inspira en el segundo: los retos y oportunidades que presenta la necesidad de desarrollar producto con mayor agilidad.
El cargo cult en el desarrollo de producto
En la mesa tuvimos un animado debate sobre cuál es la diferencia que hacemos entre Product Owner y Product Manager. Claro, aquí surge la eterna discusión de si “el mercado” está entendiendo bien qué es lo que compra.
Esta dinámica no es nueva. Un concepto (llámale X, pero no el de Elon 😉 ) se desarrolla en un ambiente muy experimental para dar respuesta a una necesidad ⇒ demuestra que funciona ⇒ se empieza a adoptar con éxito ⇒ se populariza ⇒ se populariza aún más, tanto que mucha gente lo adopta aunque no haya entendido exactamente qué es ni para qué sirve exactamente 😱. En ese punto, la solución original empieza a difuminarse: quienes la demandan ya no tienen claro qué están pidiendo, y quienes la ofrecen tampoco entienden bien qué están entregando. El resultado es que el concepto X pierde su significado original y se convierte en un término genérico, sin la capacidad de generar el impacto que inicialmente tuvo.
En el mundo empresarial, este fenómeno es más común de lo que parece, y supone un riesgo importante: la falta de comprensión profunda puede llevar a adoptar soluciones “de moda” sin obtener los resultados esperados. Carlos, durante su charla, hablaba con gran acierto del cargo cult como uno de los fenómenos que impulsa esta dinámica. Por eso es crucial que las empresas no sólo adopten lo que está en tendencia, sino que se aseguren de entenderlo y aplicarlo de forma estratégica para sus necesidades reales, no sólo porque “así lo hace todo el mundo”.
La confusión en el rol del Product Owner
Product Owner (PO) es un rol que aparece originalmente en el marco ágil Scrum, con la misión específica de ser la persona responsable de maximizar el valor que entrega el equipo de desarrollo. Un/a PO gestiona el backlog del producto, priorizando las historias de usuario y asegurando que el equipo trabaje en lo más importante para el negocio. Sin embargo, con el tiempo, este rol ha sufrido una serie de distorsiones a medida que ha sido adoptado por diferentes empresas y en diferentes contextos.
Parte de esa confusión se debe a la existencia previa de roles similares en las organizaciones que iban adoptando Scrum, como el Project Manager o el Business Analyst. Al ser Scrum el marco ágil más ampliamente adoptado, al menos nominalmente, las “adaptaciones” han sido muchas y muy diversas. El problema principal es que, en muchas empresas, al adoptar el marco ágil, no se ha cambiado realmente la manera de trabajar. Lo que hacen es un simple cambio de nombre: p.ej. el Project Manager pasa a llamarse Product Owner, pero las responsabilidades y el enfoque del trabajo permanecen prácticamente iguales. En lugar de ejercer una visión estratégica sobre lo que se está construyendo, el PO es a menudo relegado a tareas más administrativas u operativas (como escribir las historias de usuario en Jira), sin tener un impacto significativo en la dirección del producto.
Además, el PO no siempre gestiona realmente un “producto” en el sentido más estricto de la palabra. A veces, su función se limita a la gestión de un backlog asociado a un proyecto, una mejora interna o una iniciativa puntual, lo que diluye la visión de producto que originalmente estaba destinada a este rol. Este enfoque limitado convierte al PO en un simple facilitador del flujo de trabajo, sin espacio para influir en las decisiones estratégicas del producto, lo que impide que se convierta en un verdadero enlace entre el equipo de desarrollo y el negocio.
El choque entre Product Owner y Product Manager
Estas distorsiones generan una gran confusión, tanto en las responsabilidades del PO como en su colaboración con otras figuras clave dentro de la organización, especialmente con el Product Manager (PM), con quien, a menudo, se producen choques de competencias. Mientras que el PM tiene la responsabilidad de definir la visión y la estrategia de producto a nivel más amplio, el PO, en teoría, debería estar enfocado en priorizar el backlog y asegurar que el equipo de desarrollo trabaje en lo más importante. Sin embargo, en la práctica, estas fronteras no están siempre claras.
Uno de los principales puntos de fricción es la priorización. El PM puede tener una visión más amplia y estratégica, queriendo desarrollar nuevas funcionalidades o productos que respondan al feedback que recibe del mercado, mientras que el PO puede estar más preocupado por las entregas inmediatas y el cumplimiento de plazos más operativos. Esto puede llevar a conflictos, especialmente cuando ambos roles intentan priorizar el trabajo del equipo en función de sus propias agendas.
Otro punto de tensión es la gestión del producto. En algunas organizaciones, el PO es visto como la persona que “posee” el backlog del equipo, pero sin una verdadera autoridad sobre la dirección estratégica del producto. Mientras tanto, el PM se encarga de guiar esa dirección, pero con poco o ningún control sobre la implementación diaria y la toma de decisiones operativas. Esto puede crear un vacío de poder, donde ninguna de las dos figuras tiene el control total ni la visión completa del producto.
Además, la confusión sobre las competencias de cada rol se agrava cuando las empresas no han definido claramente las responsabilidades de cada uno. En algunos casos, los Product Managers se ven obligados a entrar en detalles operativos, mientras que los Product Owners tienen que tomar decisiones estratégicas sin el contexto necesario, lo que desdibuja sus funciones y genera frustración en ambos lados.
Este choque de roles no solo dificulta la colaboración entre ambos, sino que también afecta negativamente al equipo de desarrollo, que recibe señales diferentes sobre qué priorizar y cómo avanzar. La falta de claridad en la definición de estos roles es uno de los mayores obstáculos para que las organizaciones puedan desarrollar productos de manera ágil y alineada con sus objetivos de negocio.
El desarrollo ágil de producto es una necesidad estratégica
El desarrollo ágil de producto no es sólo un conjunto de prácticas, roles, procesos o herramientas, sino una forma de trabajo enfocada en la entrega continua de valor y en la capacidad de adaptación rápida. En lugar de planificar todo el desarrollo de un producto de principio a fin, como se hace en metodologías tradicionales, el enfoque ágil fragmenta ese desarrollo en pequeños ciclos o iteraciones, en los cuales el equipo se enfoca para entrega versiones funcionales del producto en intervalos cortos. Esto último es lo que llamamos desarrollo iterativo e incremental. Cada una de estas versiones, una vez puestas en producción, nos permite incorporar feedback directo de los usuarios y stakeholders, lo que permite ajustar el rumbo a medida que el producto evoluciona, reduciendo la incertidumbre y asegurando que el producto final realmente resuelva los problemas de los usuarios y cumpla con los objetivos del negocio.
Lo que hace del desarrollo ágil una necesidad es su capacidad para generar aprendizaje continuo. Cada entrega no sólo añade funcionalidad, sino que permite obtener datos reales sobre el comportamiento de los usuarios y el impacto del propio producto. Podemos así tomar decisiones informadas y corregir el rumbo antes de que los errores vayan a más. En un entorno cambiante, la capacidad de aprender y adaptarse más rápido que la competencia se convierte en una ventaja estratégica
Además, fomenta una cultura de responsabilidad compartida. Todos, desde desarrolladores hasta PMs, participan activamente en la toma de decisiones, creando una red de inteligencia colectiva que permite establecer las prioridades con mayor precisión.
Finalmente, el desarrollo ágil es esencial para gestionar la complejidad inherente en la creación de productos digitales hoy en día. Acepta la incertidumbre y se adapta a ella. Para ello, ofrece una forma de trabajo que evoluciona junto al producto, integrando cambios de mercado, nuevas oportunidades tecnológicas y, sobre todo, el feedback continuo de los usuarios, ofreciendo así una respuesta eficaz a los desafíos actuales.
¿Puede un Product Manager ignorar la agilidad en la actualidad?
En un mercado cada vez más dinámico y competitivo, la agilidad se ha convertido en un requisito inevitable para el desarrollo de productos. Los ciclos de vida de los productos son más cortos, las expectativas de los clientes cambian rápidamente, y la competencia puede ser feroz. En este contexto, las empresas que no son capaces de adaptarse rápidamente quedan obsoletas. Es por eso que todo PM debería estar alineado con este enfoque ágil, no sólo para que el trabajo de los equipos se coordine de una manera eficaz, sino también para asegurar que la estrategia de producto evolucione junto con el entorno empresarial.
Un PM ágil no puede trabajar aislado. Debe ser capaz de coordinarse de manera efectiva con los POs, quienes, aunque están más centrados en las tareas operativas, juegan un rol crucial en la entrega de valor. El PM debe asegurarse de que los POs entiendan la estrategia de producto, estén alineados con los objetivos de la empresa y puedan traducir esa visión en un backlog bien priorizado. Este alineamiento entre estrategia y ejecución es clave para evitar esfuerzos mal dirigidos y maximizar el impacto del producto en el negocio.
Además, la agilidad en el desarrollo de productos implica una colaboración estrecha con otros stakeholders, como los equipos de ventas, marketing o finanzas. El PM tiene que garantizar que todos los departamentos entiendan la dirección del producto y sus implicaciones para la empresa. Y viceversa, debe ser sensible y escuchar sus necesidades, porque también son importantes para el éxito de todos. Hay que crear consenso y asegurar que el producto está alineado con los objetivos más amplios de la compañía.
Por último, un PM ágil también debe ser capaz de proponer cambios estructurales cuando sea necesario. A menudo, la verdadera agilidad no puede lograrse sin ajustar la estructura organizativa o los procedimientos que siguen los diferentes equipos. Esto puede implicar la creación de equipos multidisciplinares, la adopción de nuevas herramientas, o incluso la revisión de los procesos de toma de decisiones dentro de la empresa. El PM debería tener la visión y la capacidad de impulsar estos cambios para que la agilidad permee y llegue a toda la organización.
Por supuesto, esto es muy bonito. En una pizarra seguro que queda fenomenal pero en la práctica luego todo es mucho más borroso. Hay empresas muy pequeñas donde quien hace de PO también hace de PM e incluso también de CEO. O justo todo lo contrario, empresas tan, tan grandes, y con productos tan sumamente complejos (por las razones que sean) que necesitan muchas más capas para que la carga cognitiva correspondiente a cada rol sea mínimamente abordable.
¿Es hora de ayudar a los Product Owners a dar el salto a Product Managers?
A lo largo de este artículo, hemos explorado cómo la agilidad en el desarrollo de productos es esencial y cómo las líneas entre los roles de Product Owner (PO) y Product Manager (PM) a menudo se desdibujan. Esta realidad plantea un desafío, pero también una oportunidad: capacitar a los POs para que asuman roles más estratégicos como PMs ágiles.
Durante “las cervezas” discutimos precisamente este punto. Muchos POs sienten que podrían aportar más al negocio si tuvieran las herramientas y el conocimiento para influir en la estrategia del producto. Al mismo tiempo, el propio Carlos explicaba que muchas de las empresas con las que tiene contacto necesitan profesionales que puedan navegar entre la visión estratégica y la ejecución táctica.
Por eso, estoy considerando desarrollar una formación específica que ayude a los POs a dar este salto. Pero antes de avanzar, quiero asegurarme de que esta iniciativa realmente responde a tus necesidades y desafíos.
Te invito a participar en un breve cuestionario donde podrás compartir tus experiencias y expectativas. Tu feedback será muy valioso para diseñar un programa que verdaderamente aporte valor y ayude en el desarrollo profesional de quien lo reciba.
Además, si crees que este tema puede ser relevante para otros roles en tu red, agradecería mucho que compartieras este artículo o el formulario para ayudarme a llegar a quienes más podrían beneficiarse. Tu participación puede marcar la diferencia, no sólo impulsando el crecimiento profesional de quienes desean enfrentar este desafío, sino también ayudando a las empresas a adaptarse mejor, definir roles más claros y fomentar una cultura ágil que les permita prosperar. Por supuesto, me comprometo a publicar los resultados del cuestionario.
P.S. He tenido serias dudas sobre cómo referirme a los roles con un lenguaje inclusivo. Siempre que he podido me he referido a ellos como “el rol de” o “la persona que hace de”, sin embargo, en muchas ocasiones (en parte por inercia y en parte para evitar la repetición) he tenido que recurrir a expresiones como “el PO” o “un/a PO”. Son bienvenidas todas las sugerencias que me puedan ayudar a mejorar este blog en el futuro.
ACTUALIZACIÓN (29/Sep/2024): Me comenta @vgaltes en este tweet que me estoy refiriendo a los “roles responsables de producto” y que no incluyo al equipo de desarrollo al completo (de hecho, tampoco menciono a especialistas en UX/UI ni en QA), lo cual da pie a pensar que, de alguna manera, el equipo tiene un rol subsidiario. Aunque ya hablé sobre esto hace tiempo en este artículo titulado “Roles vs jerarquía“, me gustaría corregirlo aquí para que se entienda que mi intención al hablar de “roles de producto” era referirme sólo a aquellos individuos encargados de la definición y priorización del producto y que, además, rinden cuentas sobre ello. Además, Vicenç también alerta de cómo se complica la cosa en organizaciones grandes. Me temo que ahí no puedo hacer más que sumarme a la alerta y, si acaso, ofrecerme a ayudar con una posible reorganización.
LA FOTO: Publicada en el LinkedIn de La Product Conf Madrid, recoge el momento de la presentación de Carlos en el que reflexiona sobre el exceso de foco en el producto y que resume en el hashtag #NoProducts 💃