Publiqué una frase simple en LinkedIn: el puesto de Product Owner ya me parecía una aberración organizativa, y en la era de la IA se vuelve francamente difícil de defender.

66.000 impresiones y unos cuarenta comentarios después, constato dos cosas. La primera es que he tocado un nervio. La segunda es que la mitad de los desacuerdos giran en torno a un malentendido que quiero deshacer ahora mismo.

No buscaba la polémica — me da igual el número de visualizaciones. Y sobre todo: tenía exactamente esta posición antes de la IA. Mencionar la IA cristalizó las reacciones, pero no es el fundamento de mi argumento. Es su acelerador.

El post original y todos los intercambios están aquí. Este artículo es mi respuesta construida a quienes se tomaron el tiempo de contradecirme.

Lo que no digo

No digo que la IA vaya a sustituir a los Product Owners.

Me respondieron, con razón, que una IA no entiende un mercado, no anticipa una necesidad, no defiende una visión ante un sponsor, no sostiene un NO GO y no rinde cuentas seis meses más tarde. Estoy de acuerdo. Del todo.

Tampoco digo que la gente que lleva "PO" en la tarjeta de visita no sirva para nada. Conozco a algunos excelentes. Lo que critico es la división, no a las personas que la sufren.

Lo que sí digo: el producto es lo que está en producción

Una especificación describe una intención. Un PRD describe un objetivo, unas reglas esperadas, unos escenarios. Una maqueta describe una interfaz deseada.

Pero entre esa intención y la producción siempre pasa algo. Desarrollé este punto en La pregunta de producto debe partir del código fuente:

Se hacen concesiones. Se ajustan detalles. Aparecen casos límite. Se toman decisiones durante el desarrollo. Hay restricciones técnicas que obligan a modificar ligeramente el comportamiento. Hay conversaciones dentro de una pull request o una merge request. Los arbitrajes no siempre vuelven a la documentación inicial.

[...] la spec no es la verdad del producto. Es una aproximación útil en un momento dado. La verdad es lo que está funcionando.

No es grave. Es incluso normal: un producto vivo no se construye como un documento congelado.

Pero esto tiene una consecuencia que nos negamos a mirar de frente. Si la verdad del producto se fabrica entre la intención y la producción, entonces la persona que se queda aguas arriba de la producción no trabaja sobre el producto. Trabaja sobre una intención. Nunca ve los arbitrajes que, en realidad, definen lo que el cliente va a vivir.

El cliente no ve tu discovery. No ve tu framework de priorización, ni tu preciosa roadmap. Ve lo que sale a producción. Y la calidad de un producto está en una acumulación de pequeños detalles — y esos detalles solo los ves si lo acompañas hasta el final.

De ahí mi convicción: quien piensa el producto tiene que ser quien lo entrega y quien lo acompaña después de la entrega. Una sola y misma persona. Ownership completo.

La aberración no es el contenido del puesto, es lo que revela su existencia

Lo que hace indefendible el puesto de PO a mis ojos no es, por tanto, lo que un PO hace en su día a día. Es que una organización haya considerado útil separar la parte "noble" — pensar el producto — de la parte que se delega: llevar el backlog, mantener la relación con los desarrolladores, vigilar la puesta en producción.

Esto es taylorismo aplicado al producto.

Y esta película ya la hemos visto.

Hubo una época con analistas por un lado y programadores por otro. Unos pensaban, los otros producían código a destajo. Esa división desapareció. Hoy hay desarrolladores que cogen un problema de punta a punta: la arquitectura, el código, la seguridad, la entrega, el seguimiento. Incluso hay cada vez menos arquitectos separados del resto del equipo.

Nadie echa de menos a los analistas-programadores. Nadie defiende la idea de que se hacía mejor software cuando la reflexión y la ejecución vivían en dos cabezas distintas.

No veo ninguna razón para que el producto se libre de ese movimiento.

Me aplico la regla que impongo a los desarrolladores

Hay un argumento que tengo que afrontar antes que todos los demás, porque me concierne directamente.

Escribí en La calidad pertenece a quienes entregan una regla que considero no negociable del lado del desarrollo:

La regla más sana es simple: quien crea el bug lo corrige.

No porque haya que castigar. No porque haya que humillar. Porque la responsabilidad de corregir debe quedar pegada a la responsabilidad de producir.

Y más adelante:

En la mayoría de los casos, si un desarrollador ha creado el defecto, debe corregirlo. Aunque haya pasado a un tema importante. Aunque altere la planificación. Aunque frene la siguiente feature.

La calidad consume capacidad. Esconderla no la vuelve gratis.

No estaría bien exigir esto a los desarrolladores y eximirme a mí mismo.

Un PM que diseña y luego confía a un PO la tarea de llevar la cosa hasta producción hace exactamente lo que le reprocho al desarrollador que entrega y pasa al siguiente tema. Externaliza el coste de lo que ha producido. Nunca ve dónde su comprensión era insuficiente, dónde la formulación era ambigua, dónde el arbitraje cojeaba. El bucle no se cierra.

Y es ese bucle el que crea calidad.

La calidad no se delega a posteriori. Ni del lado del código, ni del lado del producto.

"Estás describiendo a un mal PO"

Es la objeción más frecuente, y me llegó de varias personas distintas: el papel de un PO es entender la necesidad, definir las funcionalidades desde el punto de vista del cliente, sostener una visión, arbitrar prioridades contradictorias, maximizar el valor.

Mi respuesta es siempre la misma: eso se llama Product Manager. Acabas de describirme mi profesión.

Si tu definición de PO se solapa con mi definición de PM, entonces estamos de acuerdo en el fondo y discutimos por una palabra.

El problema es que no es eso lo que contrata el mercado. Me han reprochado describir un PO que no existe. Abre las ofertas de empleo: alimentar el backlog, redactar las user stories, hacer de interfaz entre el negocio y los devs, dinamizar las ceremonias. Ese PO está en todas partes. Es incluso mayoritario.

Y ahí hay un punto que nadie señaló en los comentarios.

No se puede fundar una profesión en un artefacto desechable

El argumento más usado para defender el rol es el del backlog: el PO maximiza el valor del producto llevando, refinando y priorizando el backlog.

Solo que esa base ya la demolí en otro sitio, sin hablar de IA ni una sola vez. En El backlog no es un vertedero:

Un ítem de backlog sirve hasta la entrega. Después pierde buena parte de su valor.

Los tickets se desincronizan. Las specs se desincronizan. Los arbitrajes cambian durante la realización. El comportamiento final en producción difiere a menudo de lo que se había escrito al principio.

[...] El backlog no es una fuente de verdad. Es un soporte temporal de coordinación.

Y sobre todo, ya no es el lugar donde se piensa el producto:

Herramientas como Jira, Notion o sus equivalentes siguen siendo, muchas veces, herramientas de tarjetas. Procesadores de texto mejorados. [...] Pueden ser útiles para coordinar la acción. Pero son muy flojas para construir una reflexión de producto.

[...] El ticket ya no es el lugar donde se piensa. Es el lugar donde se empuja el resultado de un pensamiento ya estructurado.

Entonces, si el backlog no es ni la memoria del producto, ni el cerebro del producto, ni un activo duradero — ¿cómo se funda una profesión en su mantenimiento?

En un artefacto consumible se puede fundar una función. Una profesión, no.

Fíjate en que este argumento no tiene nada que ver con la IA. Ya era cierto en 2020.

El nombre importa, y por esto

Me objetaron que PO es un rol dentro de un marco metodológico, mientras que PM es una profesión. Que lo importante es lo que uno hace, no cómo se llama.

En principio, estoy de acuerdo. Hubo una época en la que hice project management sin saber que eso tenía nombre. Lo que uno hace cuenta más que la etiqueta.

Pero el título fabrica el mandato.

En los hechos, los PO tienen menos ownership y menos autonomía. Cuando eres PM, eres owner de tu scope, punto. Varias personas lo formularon mejor que yo en los comentarios: el título de PO ha servido muchas veces para compartimentar la responsabilidad de producto sin dar el mandato de decisión.

Un PO sin mandato para arbitrar no es un rol. Es una posición incómoda.

Y ahí reconozco un mecanismo que ya describí en Por qué las organizaciones prefieren las decisiones blandas:

Una decisión clara hace visible la responsabilidad. Expone a quien arbitra. Da pie a la crítica. Obliga a asumir que ciertas peticiones no se han aceptado.

Una decisión blanda distribuye esa responsabilidad. La diluye entre los participantes, las reuniones, los documentos, las formulaciones prudentes, las validaciones sucesivas.

Partir en dos la responsabilidad de producto es el mismo reflejo aplicado al organigrama. Permite tener a alguien que carga con la consecuencia sin haber podido elegir, y a alguien que eligió sin cargar con la consecuencia.

El mecanismo es cómodo. Es también la razón por la que ya nadie es realmente responsable de nada.

Dónde entra la IA de verdad

Mi argumento sobre la IA no es "va a sustituir a los PO". Es más mecánico que eso.

La división entre quien piensa y quien ejecuta tenía una justificación económica. El trabajo de traducir, documentar, redactar, dar formato costaba caro en tiempo. Lo bastante caro como para crear un puesto dedicado a absorber esa capa operacional.

Durante mucho tiempo, el PM fue el centro neurálgico: recoger necesidades, reformular, producir documentos, aclarar tickets, poner orden, coordinar, priorizar, hacer seguimiento, insistir, documentar otra vez. Una parte de la profesión consistía en compensar las fricciones de la organización. Acabamos aceptando como normal una masa de tareas que no eran el núcleo de la profesión, solo su capa operacional.

Ese coste se derrumba.

Y cuando desaparece la justificación económica de una división del trabajo, la división del trabajo no sobrevive mucho tiempo.

Ahí es donde mi desacuerdo inicial y la IA se encuentran. La IA no crea el problema: quita la última excusa práctica que teníamos para convivir con él. Ya no se puede decir "sí, en teoría el PM debería acompañar hasta producción, pero en la práctica no tiene tiempo".

Así que seguir contratando hoy con una descripción de puesto construida alrededor de la transmisión de información es optimizar un circuito ya obsoleto.

El matiz sobre la redacción

Me respondieron: "la redacción nunca ha sido el cuello de botella de la profesión".

Sobre el arbitraje, es cierto. Decidir nunca ha sido un problema de redacción, y no voy a sostener lo contrario.

Pero en un sentido amplio, no estoy de acuerdo. Soy el único PM de toda la empresa. Cuando hay que producir un vídeo en quince idiomas con los subtítulos, artículos en cuatro o cinco idiomas, los posts, los briefs sobre las ventajas y los puntos a destacar — es un trabajo descomunal. La IA me permite hacer cosas que sencillamente no tenía tiempo de hacer. No era el cuello de botella de la decisión. Pero era un muro, y bien real.

A la IA la veo como un excelente secretario particular. Recoge mi reflexión, se traga las fuentes, hace el trabajo ingrato. Pero quien entiende con finura, quien elige, quien corre el riesgo y quien lo asume es el PM. No la IA.

Y hay una cosa que nunca hará: la apuesta.

Si eres una startup y la pregunta es "vamos a por todas o morimos", esa elección pertenece a quienes fundaron la empresa. Una IA puede analizar la opción. No puede asumirla.

En qué me hicieron avanzar mis contradictores

Tres cosas me quedo del debate.

El mandato cuenta más que el título. Varias personas recentraron el tema ahí, y tienen razón. Un PM encerrado en lo operativo y en la gestión de urgencias, sin margen para definir una estrategia de producto, estará ocupado sin producir nada útil. Cambiarle el nombre a los puestos no arregla nada si el mandato no acompaña. Mi insistencia en el vocabulario no debe tapar eso.

Se puede repensar el puesto en lugar de suprimirlo. Un lead técnico me describió su equipo, en un software sanitario regulado con una codebase legacy: no suprimieron el puesto, lo redefinieron. El desarrollador sostiene una parte de la visión de producto, el PO diseña. Las personas se quedan, el rol cambia. Probablemente es más justo que mi formulación inicial, y merece decirse: lo que se vuelve indefendible es la correa de transmisión, no la gente.

El peligro real es la capa de aislamiento. El problema no es que exista un PO. Es cuando se convierte en la capa que corta a los desarrolladores de la necesidad real — con la excusa de que los devs no tendrían que entender el negocio, solo ejecutar specs. Eso la IA lo va a volver aún más insostenible. En mi empresa, los desarrolladores entrevistan a los clientes directamente desde hace varios meses. Y hace unos días subí mi primera pull request a nuestro producto principal.

Sobre el conocimiento del negocio, por último, corrijo un tópico: no es propiedad del PO. Lo he encontrado en CSM que venían del terreno, en gente de soporte. Puede estar en todas partes — y tiene que estar en el PM. En mi campo, me trago libros y vídeos de mantenimiento industrial. Tengo la obligación de ser excelente en el negocio, si no, no tengo nada que arbitrar.

En qué no me muevo

Me han dicho que el PO que describo es probablemente el que yo fui. Es posible.

Y añado algo más incómodo de admitir: es muy cómodo librarse del backlog, del seguimiento de los devs, de las puestas en producción. El PM tiene un interés objetivo en que el puesto de PO exista. Nos quedamos con la parte que se cuenta bien en una reunión y delegamos la que cuesta.

Precisamente por eso desconfío de ello.

Separar a quienes piensan de quienes ejecutan es una aberración. No porque llegue la IA. Porque el producto es lo que está en producción — y porque no se delega la responsabilidad de lo que uno ha diseñado.

La IA no hace que este argumento sea verdadero.

Lo hace imposible de esquivar.