Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Idea principal
Cuando producir y mantener documentos, tickets e informes absorbe la mayoría de las jornadas de un Product Manager, esa producción acaba definiendo el puesto: se contrata por ella, se evalúa por ella, se describe en las ofertas de empleo. No porque se haya juzgado esencial, sino porque ocupaba el sitio.
El coste actúa aquí como una prueba engañosa: lo que es pesado parece importante. Una tarea que ocupa seis horas por semana se convierte en objeto de reporting, en competencia exhibida, en identidad profesional.
La demostración se hace al revés, y es brutal: cuando el coste de esa capa se hunde, se descubre que no era la profesión. Nada más ha cambiado — ni el producto, ni el mercado, ni lo que de verdad se esperaba del rol.
El mecanismo no se detiene en la definición de un puesto existente: fabrica otros nuevos. Cuando la capa se vuelve lo bastante pesada, se le dedica una denominación — Product Owner — y una descripción de puesto construida en torno a la transmisión de información. El puesto hereda entonces la misma suerte que la definición: se justificaba por un coste, y se vuelve difícil de defender cuando ese coste cae.
Capa aportada por "El PO no es una profesión, es una función" (2026-08-03).
Capa aportada por "PM, desarrolladores e IA: los roles se difuminan, las responsabilidades permanecen" (2026-08-01). El mecanismo actúa también dentro de una profesión, sobre lo que distinguía a sus practicantes entre sí. Escribir una especificación correcta, producir un primer análisis de datos, montar un benchmark, redactar una release note, hacer una maqueta aceptable, sintetizar entrevistas: esas producciones diferenciaban a los Product Managers entre sí mientras seguían siendo costosas. Cuando se vuelven accesibles, no abandonan la profesión — pasan de ser un signo distintivo a ser el nivel mínimo, y quienes tenían su valor en esa ejecución intermedia lo pierden sin que nada del producto ni del mercado haya cambiado.
Por qué es importante
Esto explica por qué una automatización se vive como una amenaza identitaria en lugar de como una ganancia: no retira solo horas, retira aquello en lo que la competencia era visible.
Y da una prueba retrospectiva útil: lo que desaparece sin que nadie intente restablecerlo no era el núcleo de la profesión.
Matices y límites
El hundimiento del coste no demuestra por sí solo que la capa fuera accesoria. Algunas tareas pesadas lo son porque realmente son decisivas, y automatizarlas degrada silenciosamente el resultado.
Y una capa accesoria puede tener efectos secundarios reales: redactar una especificación a mano obliga a leerla, y ese rodeo desaparece con la tarea ingrata.
Preguntas abiertas
- ¿Cómo distinguir, antes de automatizarla, una tarea pesada y accesoria de una tarea pesada porque es decisiva?