El PO no es una profesión, es una función — y la IA no lo cambia, lo acelera

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 está volviendo francamente difícil de defender.

66 000 impresiones y unos cuarenta comentarios después, hay dos cosas claras. La primera es que toqué un nervio. La segunda es que la mitad de los desacuerdos se apoyan en un malentendido que quiero aclarar ya.

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 el acelerador.

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

Lo que no estoy diciendo

No estoy diciendo 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 estoy diciendo que la gente que lleva "PO" en su tarjeta no sirva para nada. Conozco a personas excelentes en ese papel. Critico el reparto, no a quienes lo sufren.

Lo que 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. Un mockup 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 compromisos. Se ajustan detalles. Aparecen casos límite. Se toman decisiones durante el desarrollo. Las restricciones técnicas obligan a modificar ligeramente el comportamiento. Se producen intercambios en una pull request o una merge request. Los arbitrajes no siempre suben a la documentación inicial.

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

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

Pero 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 quien se queda antes 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 bonita 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 acompañas hasta el final.

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

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

Lo que hace indefendible el puesto de PO a mis ojos no es lo que un PO hace a diario. Es el hecho de que una organización haya considerado útil separar la parte "noble" — pensar el producto — de la parte que se delega: seguir el backlog, sostener la relación con los desarrolladores, vigilar el paso a producción.

Eso es taylorismo aplicado al producto.

Y ya hemos visto esta película.

Hubo una época con analistas de un lado y programadores del otro. Unos pensaban, los otros producían código al metro. Ese reparto 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 producíamos 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 escape a ese movimiento.

Me impongo la regla que impongo a los desarrolladores

Hay un argumento que debo afrontar antes que todos los demás, porque me señala directamente.

En La calidad pertenece a quienes entregan dejé una regla que considero no negociable del lado de la ingeniería:

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

No para castigar. [...] Sino porque la responsabilidad de corrección debe permanecer ligada a la responsabilidad de producción.

Y más adelante:

En la mayoría de los casos, si un desarrollador creó el defecto, debe corregirlo. Aunque haya pasado a un tema importante. Aunque eso perturbe el planning. Aunque ralentice la siguiente feature.

La calidad consume capacidad. Ocultarlo no la hace gratuita.

Estaría en mala posición exigiendo eso a los desarrolladores y eximiéndome a mí mismo.

Un PM que concibe y luego confía a un PO la tarea de llevar la cosa hasta producción hace exactamente lo que reprocho al desarrollador que entrega y pasa al tema siguiente. 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 estaba torcido. El ciclo no se cierra.

Y es ese ciclo 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 un mal PO"

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

Mi respuesta es constante: eso se llama Product Manager. Acabas de describir 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 el mercado contrata. Me reprocharon 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. Y es mayoritario.

Y ahí hay un punto que nadie planteó en los comentarios.

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

El argumento más usado para defender el rol es el del backlog: el PO maximiza el valor del producto manteniéndolo, refinándolo y priorizándolo.

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

Un item de backlog sirve hasta la entrega. Después, pierde gran 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 suele diferir 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 a menudo herramientas de tarjetas. Procesadores de texto mejorados. [...] Pueden ser útiles para coordinar la acción. Pero son muy débiles 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 mantenerlo?

Se puede fundar una función sobre un artefacto consumible. 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 cuenta, y he aquí por qué

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 haces, no cómo te llamas.

En principio, estoy de acuerdo. Hice project management en una época en la que no sabía que aquello tuviera 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 de arbitraje 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 demandas no han sido atendidas.

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

Cortar la responsabilidad de producto en dos es el mismo reflejo aplicado al organigrama. Permite tener a alguien que carga con la consecuencia sin haber tenido la elección, y a alguien que tuvo la elección sin cargar con la consecuencia.

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

Dónde entra de verdad la IA

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

El reparto pensador / ejecutor tenía una justificación económica. El trabajo de traducción, documentación, redacción y maquetación costaba mucho tiempo. Lo bastante caro para crear un puesto dedicado a absorber esa capa operacional.

Durante mucho tiempo el PM fue una centralita: recoger necesidades, reformular, producir documentos, aclarar tickets, ordenar, coordinar, priorizar, seguir, reclamar, 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 corazón del oficio, solo su fontanería.

Ese coste se está hundiendo.

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

Ahí es donde mi desacuerdo original 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 en torno a 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 pretenderé lo contrario.

Pero en 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 subtítulos, artículos en cuatro o cinco idiomas, los posts, los briefs sobre las ventajas y los puntos a destacar, el trabajo es descomunal. La IA me permite hacer cosas para las que simplemente no tenía tiempo. No era el cuello de botella de la decisión. Pero sí era un muro.

Yo veo la IA como un excelente asistente personal. Recoge mi reflexión, se traga las fuentes, hace el trabajo ingrato. Pero quien comprende con finura, quien elige, quien asume el riesgo y quien rinde cuentas 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 todo o morimos", esa elección pertenece a quienes fundaron la empresa. Una IA puede analizar la opción. No puede asumirla.

Dónde quienes me contradijeron me hicieron avanzar

Tres cosas que me llevo 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. Renombrar 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 tech lead me describió su equipo, sobre un software de salud regulado con una codebase legacy: no suprimieron el puesto, lo redefinieron. El desarrollador sostiene parte de la visión de producto, el PO diseña. Las personas se quedan, el rol cambia. Probablemente sea más justo que mi formulación inicial, y merece decirse: lo que se vuelve indefendible es la correa de transmisión, no las personas.

El verdadero peligro 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 el pretexto 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. Aquí, los desarrolladores entrevistan a los clientes directamente desde hace varios meses. Y hace unos días subí mi primera pull request en nuestro producto principal.

Sobre el conocimiento del negocio, por último, corrijo una idea recibida: no es propiedad del PO. Lo he encontrado en CSM que venían del terreno, en gente de soporte. Puede estar en cualquier parte — y debe estar en el PM. En mi ámbito devoro libros y vídeos de mantenimiento industrial. Me exijo ser excelente en el negocio, o no tengo nada que arbitrar.

Dónde no me muevo

Me dijeron 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 los pasos a 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.

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 no se delega la responsabilidad de lo que uno ha concebido.

La IA no hace verdadero ese argumento.

Lo hace imposible de esquivar.

Para saber más

La calidad pertenece a quienes entregan El backlog no es un vertedero: es una herramienta de acción La pregunta de producto debe partir del código fuente