# Qué hace realmente un Product Owner

*Delivery · Fundamentos · 18 min · Curso: Product Ownership y delivery*

Mucha gente cree que el Product Owner es la persona que escribe tickets y los ordena en Jira. Esa es la parte visible y la menos importante. El trabajo de verdad es convertir una intención de negocio en trabajo que un equipo puede construir, probar y aprender de él, decidiendo por el camino qué entra, qué no, en qué orden y con qué riesgo. En esta lección verás qué hace un PO, en qué se diferencia de un PM, cómo cambia el papel según la empresa y qué decisiones son suyas y cuáles no.

## En 60 segundos

El Product Owner es quien convierte una intención de negocio en trabajo que un equipo puede construir, probar y aprender, y responde del valor de lo que se entrega. Importa porque sin ese trabajo los equipos entregan a tiempo cosas que no mueven nada y descubren el riesgo cuando ya es caro. La idea clave: el backlog es la herramienta, no el trabajo; el trabajo es decidir qué entra, qué no, en qué orden y cómo sabremos si funcionó.

## Al terminar sabrás

- Reescribir una petición de un stakeholder como problema, outcome, alcance con exclusiones y criterios de aceptación.
- Clasificar las decisiones de una semana entre decisiones de producto y de delivery, y señalar quién debe tomar cada una.
- Ordenar las historias de una apuesta por el riesgo que reducen, justificando la primera.

## Desde cero

El Product Owner es la persona que decide qué construye un equipo y en qué orden, para que lo entregado cree el máximo valor. Traduce lo que necesitan usuarios y negocio en trabajo concreto y comprueba después si sirvió.

Como quien dirige la cocina de un restaurante con carta cambiante: no cocina cada plato ni atiende cada mesa, pero decide qué se prepara hoy, con qué ingredientes, qué plato se quita si falta tiempo y prueba la salsa antes de que salga. Si solo apuntara las comandas, sería un camarero.

## El PO no es el administrador de Jira

Martes, diez de la mañana. Ventas entra en el canal del equipo: «un cliente grande necesita exportar las facturas a Excel, ¿lo podéis meter este sprint?». Media hora después ya hay un ticket que dice «Exportar facturas a Excel», asignado, estimado y metido en el sprint. Nadie ha preguntado para qué lo quiere el cliente, cuántos clientes más lo necesitan ni qué se deja de hacer a cambio. Quien creó ese ticket hizo de secretario, no de Product Owner.

El papel nace en Scrum. La Guía de Scrum (Ken Schwaber y Jeff Sutherland, versión de 2020) dice que el Product Owner es responsable de **maximizar el valor del producto** que resulta del trabajo del equipo, de definir y comunicar el objetivo de producto (product goal) y de que el product backlog, la lista ordenada de lo que se podría construir, sea transparente y se entienda. Fíjate en lo que no dice: no dice «escribir tickets», ni «estimar», ni «perseguir a los desarrolladores».

El backlog es una herramienta del PO, no su trabajo. Un backlog impecable que lleva al equipo a construir lo que nadie usa es un fracaso con buen formato.

> Si quitas a tu PO durante dos semanas y el equipo sigue construyendo lo mismo sin notar diferencia, el PO estaba administrando una cola, no tomando decisiones.

## PM y PO: dos sombreros, a veces una cabeza

La pregunta sale en cada entrevista y en cada reorganización: ¿un PM y un PO son lo mismo? Depende de la empresa, y discutir la etiqueta sirve de poco. Lo útil es separar dos tipos de trabajo que alguien tiene que hacer.

|  | Trabajo de producto (sombrero PM) | Trabajo de ownership (sombrero PO) |
| --- | --- | --- |
| Pregunta central | ¿Qué problema merece resolverse y por qué ganaríamos? | ¿Cómo convertimos esa apuesta en incrementos que funcionan y enseñan? |
| Horizonte | Trimestre, año, estrategia | Semanas, sprint, próxima entrega |
| Con quién pasa más tiempo | Clientes, negocio, dirección, datos | Equipo de desarrollo, diseño, QA, dependencias |
| Artefactos | Estrategia, roadmap por outcomes, business case | Backlog ordenado, historias, criterios, plan de release |
| Cómo falla | Estrategia bonita que nunca aterriza | Entrega puntual de cosas que no mueven nada |

En una startup estilo Holded (hipotético) de veinte personas, la misma persona lleva los dos sombreros. En una scale-up estilo Cabify (hipotético), el PM suele hacer de PO de su equipo durante media semana. En un banco que adoptó Scrum, el PO a menudo viene del negocio. Y con SAFe, un marco para escalar agile, un Product Manager decide la estrategia y varios Product Owners la bajan a cada equipo.

Ninguno de esos modelos es «el correcto». El que falla es el que deja huecos: un PO sin acceso a clientes ni a datos que solo puede ordenar una lista cerrada, o un PM que decide en una diapositiva y desaparece hasta la demo.

> En entrevista, no recites la Guía de Scrum. Cuenta cómo era el reparto donde trabajaste, qué hueco dejaba y cómo lo cubriste.

## El trabajo central: de intención a trabajo ejecutable

Cualquier petición llega como una intención difusa: «exportar a Excel», «mejorar el onboarding», «lo que pidió el CEO». El PO la convierte en algo que un equipo puede construir el lunes sin adivinar, sin saltar a la solución antes de entender el problema. Cada paso que te saltas reaparece más tarde como retrabajo o como una discusión en QA.

1. **Aclarar la intención.** ¿Quién lo pide, qué intenta conseguir y qué pasa si no lo hacemos? «Exportar a Excel» suele significar «mi gestoría necesita los datos en su programa de contabilidad». Eso cambia la solución.
2. **Atarla a un outcome.** El outcome es el cambio de comportamiento o de negocio que buscamos (menos horas de cierre mensual, menos bajas en el segundo mes), no la feature.
3. **Recortar el alcance.** Qué entra en la primera versión y, sobre todo, qué no. Un alcance sin una lista de exclusiones no es un alcance.
4. **Partir en incrementos.** Trozos que funcionan de punta a punta y se pueden enseñar a un usuario, no capas técnicas (primero la base de datos, luego la API, luego la pantalla).
5. **Escribir criterios de aceptación.** Las condiciones observables para dar algo por bueno, incluidos errores, permisos y casos límite.
6. **Mapear dependencias.** Otro equipo, un proveedor, un permiso legal, un dato que no existe todavía.
7. **Secuenciar por riesgo.** Primero lo que más incertidumbre quita, no lo más fácil ni lo más vistoso.
8. **Cerrar el bucle de feedback.** Decidir antes cómo sabremos si funcionó y cuándo lo miraremos.

## Decisiones de producto y decisiones de delivery

Un PO toma decenas de decisiones por semana. La habilidad que separa a uno bueno de uno mediocre es distinguir dos familias y saber quién manda en cada una.

| Situación | ¿Producto o delivery? | Quién decide | Por qué importa |
| --- | --- | --- | --- |
| Quitar el estado de error de la exportación para llegar al viernes | Producto, aunque parezca técnica | PO, con el equipo | Cambia lo que vive el usuario cuando algo falla |
| Usar una librería u otra para generar el fichero | Delivery | Equipo de desarrollo | No cambia la experiencia; el PO solo pide que no comprometa plazos ni calidad |
| Lanzar primero a gestorías y luego a autónomos | Producto | PO | Decide de quién aprendes primero y a quién expones al riesgo |
| Partir la historia en dos para que quepa en el sprint | Las dos | PO y equipo juntos | El corte técnico tiene que dejar algo útil para el usuario en cada parte |
| Retrasar una semana por una dependencia de otro equipo | Delivery con impacto de producto | Equipo informa, PO decide qué se comunica y qué se reordena | Afecta a promesas con clientes |

La trampa más común es la decisión de producto disfrazada de técnica. «Lo dejamos sin paginación, que es más rápido» parece un atajo, pero si un cliente con 4.000 facturas se queda con la pantalla colgada, alguien acaba de decidir la experiencia de tu mejor cliente sin saberlo. Ante cada recorte, el PO pregunta «¿qué notará el usuario?».

La trampa inversa también existe: el PO que opina sobre cómo construir. Si el equipo prefiere generar el fichero en el servidor, esa decisión es suya. Tu trabajo es fijar el resultado (que 4.000 filas salgan en menos de diez segundos) y dejarles el cómo.

## Reducir riesgo antes de que sea caro

Marty Cagan, en *Inspired* (segunda edición, 2017), resume los riesgos de cualquier idea en cuatro: de **valor** (¿lo querrán?), de **usabilidad** (¿sabrán usarlo?), de **viabilidad técnica** (¿podemos construirlo?) y de **viabilidad de negocio** (¿encaja con legal, finanzas, ventas?). Un PO de verdad ordena el trabajo para atacar primero el riesgo que más daño haría si resultara cierto.

En la práctica, la primera historia de una apuesta rara vez es la más fácil. Si nadie sabe si las gestorías aceptan nuestro fichero, lo primero es mandar uno hecho a mano a tres gestorías. Si lo importan, construyes; si no, te has ahorrado un sprint.

Las dependencias son la otra fuente de riesgo, y conviene clasificarlas porque cada tipo se trata distinto:

| Tipo de dependencia | Ejemplo | Qué hace el PO |
| --- | --- | --- |
| De datos | No sabemos qué formato usa cada programa contable | Pedir muestras reales antes de diseñar |
| De capacidad técnica | El servicio de facturas no expone los impuestos desglosados | Hablar con el equipo dueño y acordar fecha o alternativa |
| Comercial | Ventas ya prometió fecha a un cliente | Separar la promesa del cliente de la versión que de verdad aprende |
| Legal o de confianza | Datos fiscales saliendo de la plataforma | Revisión de privacidad antes de construir, no después |

Para cada dependencia, apunta tres cosas: la fecha en que necesitas la respuesta, qué harías si no llega y quién es el dueño al otro lado. Una dependencia sin fecha de decisión es una sorpresa programada.

## Feedback y alineación: el trabajo que no se ve en el tablero

La mitad del tiempo de un buen PO no aparece en ningún ticket. Es hablar con Ventas para entender qué prometieron, con Soporte para saber qué se rompe y con datos para ver si lo del sprint pasado se usa. No es «comunicar más»: es construir un modelo compartido del problema, para que cuando digas que no, el otro entienda por qué.

Decir que no es parte del puesto. La forma madura no es un no seco, sino un «sí, si quitamos esto» o un «no ahora, y esto es lo que nos haría cambiar de opinión». Cada petición nueva compite con algo que ya está en el backlog; el PO hace visible esa competencia en lugar de absorberla en silencio.

Y el feedback no se queda en la demo. Un incremento entregado es una pregunta al mercado; si el PO no mira la respuesta (uso, tickets, comentarios de los primeros clientes), el equipo entrega a ciegas, por muy rápido que vaya.

> Una costumbre que funciona: un registro de decisiones con una línea por entrada (fecha, qué, por qué, qué nos haría cambiar). Dentro de tres meses tendrás la respuesta a «¿por qué no hay PDF?» en diez segundos.

## Ejemplo trabajado: la exportación que pidió Ventas

**Ejemplo: Un software de facturación estilo Holded (hipotético). Datos hipotéticos.**

**La petición.** Ventas pide «exportar facturas a Excel» para cerrar un cliente de 40 usuarios. El PO no lo mete en el sprint; pide quince minutos con la comercial y con dos clientes.

**Lo que descubre.** El cliente no quiere Excel: su gestoría pierde unas seis horas al mes copiando facturas a su programa contable. Soporte tiene 120 tickets del trimestre con la palabra «gestoría». El problema es de muchos.

**El outcome.** Reducir el tiempo de cierre mensual de las cuentas con gestoría externa, medido con una encuesta corta y con los tickets de soporte relacionados.

**El alcance de la primera versión.** Exportar las facturas emitidas de un mes en el formato de los dos programas contables más usados por los clientes. Fuera: facturas recibidas, exportación automática programada, otros formatos.

**El primer riesgo.** ¿Importan las gestorías nuestro fichero sin tocarlo? Antes de construir nada, el equipo genera tres ficheros a mano y se los manda a tres gestorías. Dos los importan; la tercera falla por el desglose del IVA. Esa historia sube al principio del backlog.

**El resultado del refinement.** Tres historias pequeñas con sus criterios (incluidas 4.000 facturas y las rectificativas), una dependencia con fecha con el equipo de impuestos y una regla de revisión por uso.

**El elemento del backlog para la misma petición, en un software de facturación estilo Holded (hipotético), escrito por dos PO distintos.**

Versión débil: **«Exportar facturas a Excel»**

**Descripción:** el cliente X necesita exportar facturas a Excel. Urgente, lo pide Ventas.

**Estimación:** 8 puntos.

**Criterios:** que se puedan exportar las facturas.

Versión fuerte: **«Exportación mensual de facturas emitidas para la gestoría (v1)»**

**Problema:** las cuentas con gestoría externa pierden horas copiando facturas a su programa contable (120 tickets en el trimestre, datos hipotéticos).

**Outcome:** menos tiempo de cierre mensual; se mira el uso a las cuatro semanas.

**Alcance v1:** facturas emitidas de un mes, dos formatos contables. **Fuera:** recibidas, exportación programada, PDF.

**Criterios clave:** el fichero se importa sin cambios en los dos programas; las rectificativas salen con signo negativo; con 4.000 facturas tarda menos de diez segundos; solo pueden exportar los perfiles con permiso de facturación.

**Dependencia:** desglose de IVA del equipo de impuestos, respuesta el día 12.

**Regla de revisión:** si en un mes lo usa menos del 15 % de las cuentas con gestoría, paramos antes de añadir formatos.

Qué cambia de una a otra:

- La débil describe una solución pedida por un cliente; la fuerte describe un problema de muchos y una apuesta concreta para resolverlo.
- La débil no dice qué queda fuera, así que el alcance crecerá en mitad del sprint; la fuerte lo cierra por escrito.
- La débil no tiene forma de saber si funcionó; la fuerte decide de antemano qué mirará y qué hará con el dato.

## Cómo lo piensan los referentes

**El PO de Scrum es un product manager ágil** (Roman Pichler, *Product Manager vs. Product Owner*, 2017, https://www.romanpichler.com/blog/product-manager-vs-product-owner/)

Pichler sostiene que el papel de PO que define Scrum (maximizar el valor del producto) es trabajo de producto de punta a punta: visión, estrategia y táctica. La idea del PO como rol puramente táctico viene, según él, de que Scrum no es un marco de product management y de cómo SAFe partió la propiedad del producto en dos papeles. Su recomendación es no llamar «owner» a quien solo tiene la parte táctica, porque genera expectativas falsas.

Cuándo no usarlo: En organizaciones grandes, con decenas de equipos sobre una misma plataforma, es razonable separar la estrategia de la bajada a cada equipo. Lo que no conviene es hacerlo sin decir quién decide qué.

**Equipos de producto frente a equipos de features** (Marty Cagan, *Product vs Feature Teams (SVPG)*, 2019, https://www.svpg.com/product-vs-feature-teams/)

Cagan distingue entre equipos que reciben una lista de features y la entregan, y equipos a los que se les da un problema y responden por el resultado. En los primeros, el «PO» acaba siendo un gestor de backlog. En los segundos, la persona de producto responde del valor y de la viabilidad, y por eso necesita contacto directo con clientes y datos.

Cuándo no usarlo: Hay trabajo que es de verdad una lista cerrada (un cambio regulatorio con fecha, una migración obligada). Ahí empujar por autonomía de descubrimiento es perder tiempo; el valor del PO está en secuenciar bien y proteger la calidad.

## En el trabajo real

- **El refinement semanal**, donde el PO trae problemas aclarados y el equipo los parte, pregunta y estima. Si llega con tickets cerrados, es un dictado.
- **La sprint planning**, donde defiende un objetivo de sprint y negocia alcance con la capacidad real del equipo.
- **El registro de decisiones y la página del problema** (un PRD corto), que son la memoria del producto.
- **Las conversaciones uno a uno con Ventas, Soporte y dirección**, donde se gana la autoridad para decir que no.

## Errores comunes

- **Ser el traductor de peticiones.** Copiar lo que pide Ventas a un ticket sin preguntar por el problema.
- **Confundir backlog largo con backlog bueno.** Trescientos elementos que nadie mirará son ruido; mejor treinta ordenados y el resto archivado.
- **Recortar sin preguntar qué notará el usuario.** Los estados de error y los permisos son lo primero que se cae y lo primero que llega a soporte.
- **Secuenciar por facilidad.** Hacer primero lo cómodo y dejar el riesgo grande para el final, cuando ya no queda margen.
- **Decidir el cómo.** Imponer soluciones técnicas en lugar de definir el resultado esperado.
- **Dar por terminado lo que se entregó.** Sin mirar uso ni feedback, el equipo no aprende nada de lo que construyó.

## Junior, senior y VP: qué cambia

|  | Junior | Senior | VP o Head |
| --- | --- | --- | --- |
| Ante una petición | La convierte en ticket | La convierte en problema, outcome y alcance | Ve si encaja en la estrategia o la delata |
| Backlog | Lo mantiene limpio | Lo ordena por valor y riesgo, y lo explica | Revisa si el reparto de equipos refleja las prioridades |
| Riesgo | Lo descubre en QA | Lo ataca en la primera historia | Diseña rituales para que salga pronto en todos los equipos |
| Decir que no | Le cuesta y lo evita | Lo hace con alternativas y datos | Protege a los equipos de peticiones sin estrategia |

## Cómo aparece en entrevistas

Pregunta tipo: «Ventas te pide una feature para cerrar un cliente grande y el sprint ya está lleno. ¿Qué haces?».

- **Qué buscan:** que no digas ni «la meto» ni «no» de entrada. Que preguntes por el problema, mires si es de uno o de muchos clientes, hagas visible qué se deja de hacer y propongas la versión más pequeña útil.
- **La repregunta habitual:** «el CEO insiste en que entre ya». Quieren oír cómo pones el coste sobre la mesa (qué sale del sprint, qué riesgo asumes) sin convertirlo en un pulso.

## Cómo practicarlo

Coge la última petición que te llegó por chat y reescríbela con la estructura del contraste: problema, outcome, alcance, fuera, criterios, dependencias y regla de revisión. Después haz el ejercicio del sprint sobrecargado en el Product Gym y el caso del sprint de 35 puntos.

## Puntos clave

- El PO responde del valor de lo que construye el equipo; el backlog es su herramienta, no su trabajo.
- PM y PO son dos tipos de trabajo; lo que importa es que alguien cubra los dos y que esté claro quién decide qué.
- Toda petición recorre la misma cadena: intención, outcome, alcance, incrementos, criterios, dependencias, secuencia y feedback.
- Muchas decisiones técnicas en apariencia son de producto: ante cada recorte, pregunta qué notará el usuario.
- Secuencia por riesgo: la primera historia de una apuesta es la que más incertidumbre quita, no la más fácil.

## Comprueba lo aprendido

**Un desarrollador propone dejar fuera los mensajes de error de la exportación para llegar al viernes. ¿Es una decisión técnica que debe tomar él?**

No. Parece técnica, pero cambia lo que vive el usuario cuando algo falla, así que es de producto. El PO la toma con el equipo: quizá se acepta un mensaje genérico en la v1, pero dejar al usuario sin saber que la exportación falló no.

**Tienes tres historias para una apuesta: la pantalla de exportación, la generación del fichero y comprobar si las gestorías aceptan el formato. ¿Cuál va primero y por qué?**

Comprobar el formato con gestorías reales, aunque sea con ficheros hechos a mano. Es el riesgo de valor que, si resulta cierto, invalida todo lo demás. Las otras dos son más previsibles y pueden esperar a esa respuesta.

**En tu empresa hay un PM que decide el roadmap y tú eres PO de un equipo. Te llega una lista cerrada de features sin contexto. ¿Qué haces?**

No la ordeno a ciegas. Pido el problema y el outcome detrás de cada una, acuerdo con el PM qué decisiones puedo tomar yo (alcance, secuencia, cortes) y señalo los huecos. Si el reparto deja al PO sin acceso a clientes ni datos, lo hago visible como riesgo.

## Glosario

- **Product Owner (PO)** (responsable de producto del equipo): Persona que responde del valor de lo que construye un equipo y ordena su trabajo.
- **Product backlog** (pila de producto): Lista ordenada de lo que el equipo podría construir, con lo más valioso arriba.
- **Product goal** (objetivo de producto): El resultado a medio plazo hacia el que trabaja el equipo durante varios sprints.
- **Outcome** (resultado): Cambio de comportamiento o de negocio que buscas, distinto de la feature que entregas.
- **Scope** (alcance): Lo que entra en una versión y, por escrito, lo que queda fuera.
- **Dependency** (dependencia): Algo fuera del control del equipo que condiciona cuándo o cómo puede entregar.
- **SAFe** (Scaled Agile Framework): Marco para coordinar muchos equipos ágiles; separa Product Manager y Product Owner.

## Fuentes

- [La Guía de Scrum](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf), Ken Schwaber y Jeff Sutherland, 2020 (ES)
- [Product Manager vs. Product Owner](https://www.romanpichler.com/blog/product-manager-vs-product-owner/), Roman Pichler, 2017 (EN)
- [Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/), Marty Cagan (SVPG), 2019 (EN)
- [INSPIRED: How to Create Tech Products Customers Love (2.ª edición)](https://www.svpg.com/books/inspired-how-to-create-tech-products-customers-love-2nd-edition/), Marty Cagan, 2017 (EN)

## Relacionado

- [35 puntos para un sprint de 20](https://productcasa.pro/app/gym/sprint-sobrecargado)
- [35 puntos de presión para un equipo que cierra 20](https://productcasa.pro/app/casos/sprint-35-puntos)
- [Cómo funciona un sprint de verdad](https://productcasa.pro/app/aprender/sprint-de-verdad)
- [User stories y criterios de aceptación](https://productcasa.pro/app/aprender/user-stories-criterios)
- [Priorización y sequencing](https://productcasa.pro/app/aprender/prioritization-sequencing)
- [PRD compacto](https://productcasa.pro/app/templates/prd-compacto)
- [La fecha comprometida está en riesgo](https://productcasa.pro/app/gym/execution-slip)

---
> Fuente: https://productcasa.pro/app/aprender/product-owner-de-verdad · ProductCasa, formación en product management en castellano · Actualizado: 2026-10-14