Su cargo dice “Product Owner”. Pero cuando miras lo que hace en el día a día, lo que ves es otra cosa: escribe historias de usuario, las pasa a los developers y persigue que se terminen a tiempo.
No decide qué entra al producto. No decide a qué mercado apunta. No decide qué lo hace diferente ni cuánto debería costar. Esas decisiones las toma alguien más, en otro lugar, y le llegan como órdenes.
En más de 15 años trabajando con Scrum he visto cientos de Product Owners así: dueños de un producto sobre el que no tienen ningún poder de decisión. Y es, probablemente, la razón más silenciosa por la que tantos productos fracasan aunque “se haga Scrum”.
Por qué se inventó el Product Owner
La responsabilidad de Product Owner se creó en Scrum para resolver un problema muy concreto: la toma de decisiones en comité.
Cuando las decisiones sobre un producto las toma un grupo de personas, cada una con sus propias prioridades, todo se vuelve más lento. Cada cambio necesita una reunión, cada reunión necesita consenso y cada consenso diluye la visión del producto. Mientras tanto, el equipo espera.
Por eso la Guía de Scrum es tan clara en esto:
“El Product Owner es una persona, no un comité.”
“Para que los Product Owners tengan éxito, toda la organización debe respetar sus decisiones.”
Una persona, con autoridad real, que decide. Esa es la idea.
Lo que veo en la práctica
La realidad en muchas empresas es casi la opuesta. Tenemos Product Owners sin autoridad en la jerarquía de la empresa, que terminan siendo meros escritores de órdenes. Esas órdenes vienen de dos lugares:
- Desde arriba: gerentes o directores que deciden el producto y usan al PO como intermediario para bajar instrucciones al equipo.
- O, peor aún, desde abajo: analistas de negocio que conocen los tecnicismos, pero no la razón de negocio detrás de la creación del producto.
En ambos casos, el comité que Scrum quería eliminar sigue existiendo. Solo que ahora está escondido detrás de una persona que tiene el título, pero no la autoridad.
El Product Owner es el dueño del restaurante
La mejor forma que encontré de explicar este rol es con un restaurante.
El dueño de un buen restaurante sabe trazar la visión de su negocio. Decide dónde abrirlo, qué incluir en el menú, a qué tipo de cliente quiere atraer y cómo quiere que se le trate. Decide cuánto cobrar y qué hace a su restaurante distinto de los demás de la cuadra.
Pero él no cocina. Tampoco atiende las mesas.
Para eso tiene cocineros y meseros, que saben hacer su trabajo mucho mejor que él. Si el dueño se metiera en la cocina a decirle al chef cómo cortar la cebolla, el restaurante no funcionaría mejor; funcionaría peor, y nadie estaría pensando en el negocio.
Con el Product Owner pasa lo mismo. Su trabajo no es escribir historias ni decirles a los developers cómo hacer su trabajo. Su trabajo es tomar las decisiones estratégicas del producto:
- Alcance: qué entra al producto, qué no, y en qué orden.
- Mercado: para quién es el producto y qué problema le resuelve.
- Diferenciador: por qué alguien elegiría este producto y no otro.
- Costo: cuánto vale la pena invertir para obtener el valor esperado.
Por eso la Guía dice que el Product Owner es responsable de maximizar el valor del producto. No de maximizar la cantidad de historias escritas.
Los cuatro errores más comunes
1. Actuar como un project manager
Muchos Product Owners se ven a sí mismos como responsables de ejecutar un proyecto con tiempo, costo y alcance definidos. Su éxito se mide por “entregar lo que se pidió en la fecha comprometida”.
Pero un producto no es un proyecto. Un producto tiene un alcance evolutivo: se descubre, se prueba y se ajusta Sprint a Sprint según lo que aprendemos del mercado. Un PO que defiende un alcance fijo está defendiendo un plan, no un producto.
2. Compensar la falta de autoridad presionando al equipo
Este es uno de los patrones más dañinos que veo. El PO no tiene autoridad para decidir sobre el alcance, porque eso lo decide alguien más arriba. Entonces compensa ejerciendo la única autoridad que siente que tiene: la que tiene sobre los developers.
Les pide que hagan rápido, que terminen más historias, que se esfuercen más. Y muchas veces esas historias son funcionalidades que probablemente nadie va a usar. El equipo se quema construyendo rápido algo que no genera valor.
3. Reemplazar a los stakeholders en la Sprint Review
La Sprint Review existe para que el equipo inspeccione el resultado del Sprint junto con los interesados reales: clientes, usuarios, personas que sienten el problema. Ahí es donde el equipo aprende si va por buen camino.
Cuando el PO toma por completo ese lugar, cuando es él quien “aprueba” o “rechaza” el incremento en nombre de todos, el equipo pierde contacto con el mercado. Y un equipo que no ve a sus usuarios termina construyendo para el PO, no para el cliente.
4. Seguir escribiendo historias en lugar de mirar el mercado
Escribir historias es la parte más visible del trabajo del PO, y por eso muchos se quedan ahí. Es concreto, se puede medir, da sensación de avance.
Pero mientras el PO está escribiendo historias, nadie está mirando lo importante: ¿el problema sigue siendo relevante?, ¿qué está haciendo la competencia?, ¿cómo encaja nuestro producto en el mercado? Un PO con la cabeza en el backlog y no en el mercado es un dueño de restaurante que pasa el día en la cocina.
La responsabilidad más importante de las tres
He acompañado a decenas de Product Owners y puedo decirlo con conocimiento de causa: de las tres responsabilidades de Scrum, la de Product Owner es la más importante. Y también la más difícil, porque requiere cosas que no se aprenden en un manual:
- Capital político dentro de la organización.
- Una posición en la jerarquía que le dé credibilidad para tomar decisiones y que esas decisiones se respeten.
- Grandes habilidades de relacionamiento con los stakeholders, para involucrarlos de verdad en el desarrollo del producto y evitar que solo aparezcan al final para criticar.
Por eso, cuando una empresa nombra como Product Owner a alguien sin ninguna de estas tres cosas, no está ahorrando: está garantizando que el producto lo decida un comité invisible.
¿Tu Product Owner es realmente un Product Owner?
Cinco preguntas para saberlo:
- ¿Puede decidir qué entra y qué no entra al producto sin pedir permiso?
- ¿Sabe explicar para quién es el producto y qué lo hace diferente?
- ¿Tiene voz en cuánto se invierte en el producto?
- ¿Los stakeholders reales participan en las Sprint Reviews?
- ¿Pasa más tiempo pensando en el mercado que escribiendo historias?
Si la respuesta a la mayoría es “no”, tu empresa no tiene un Product Owner. Tiene un escritor de historias con un título que no le corresponde. Y la buena noticia es que eso se puede cambiar.
Aprende a ser el dueño del producto
En mi curso Certified Scrum Product Owner trabajamos justamente esto: cómo pasar de la mentalidad de proyecto a la de producto, cómo descubrir qué vale la pena construir, cómo involucrar a los stakeholders y cómo tomar decisiones estratégicas sobre el producto. Con la experiencia de haber acompañado a decenas de Product Owners en empresas reales.
👉 Conoce las próximas fechas del curso Certified Scrum Product Owner
Las citas de este artículo provienen de La Guía de Scrum (noviembre de 2020), de Ken Schwaber y Jeff Sutherland, publicada bajo licencia Creative Commons BY-SA 4.0.
