La gestión de producto se está partiendo en dos

La primera vez que me senté en el curso introductorio de Pragmatic Marketing, lo que me llamó la atención no fue ninguna casilla del marco en particular. Fue la forma. El Pragmatic Framework tiene 37 actividades repartidas en siete columnas, que arrancan en los problemas del mercado y el análisis de ganados y perdidos a la izquierda, y terminan en planes de lanzamiento, herramientas de ventas y entrenamiento del canal a la derecha. Hasta el nombre te decía para qué lado se inclinaba. La empresa pasó a llamarse Pragmatic Institute en 2019, pero el marco sigue siendo un mapa de marketing de producto con los requerimientos atornillados en la mitad.

Lo que el marco nunca tuvo fue una columna para la otra fuerza que jala al oficio: la que va hacia la ingeniería, la arquitectura y los sistemas sobre los que realmente corre el producto. Esa fuerza siempre estuvo ahí. He tenido la suerte de trabajar en los dos extremos, cargando un pipeline de ventas de un lado y peleando por la forma de las APIs y las entrañas del control plane del otro.

SIEMPRE he creído que la gestión de producto necesita un ancla. O te sientas en el extremo del marketing y cargas un número como un vendedor carga su cuota, de modo que tu trabajo queda amarrado directamente a los ingresos, o te sientas en el extremo de la ingeniería y respondes por el sistema en sí y por la experiencia de usarlo: cómo corre, cuánto cuesta, cómo se siente en las manos del usuario y qué pasa cuando falla. La profundidad en el dominio todavía importa en ese extremo, por ahora, pero su peso se está encogiendo, y ya llego a eso. El PM de la mitad, el que traduce entre clientes e ingenieros y escribe el documento que los conecta, siempre ha sido la posición más débil del espectro. La IA ya le está quitando esa silla.

Las dos anclas, antes de la IA

El ancla del marketing a gran escala se parece a Airbnb. La versión de internet es que Brian Chesky despidió a sus PMs en 2023. Su propia versión, en el podcast de Lenny ese noviembre, es más precisa: la gestión de producto de entrada se fusionó con el marketing de producto de salida; la gestión de programas pasó a program managers dedicados; el equipo quedó más pequeño y más senior. Eso es una empresa decidiendo que el ancla del PM es el mercado y el mensaje. Punto.

El ancla de la ingeniería a gran escala era más difícil de encontrar hace una década, pero existía. Gergely Orosz describió al ingeniero con mentalidad de producto en 2019 como la persona que cuestiona la especificación, propone la alternativa y termina siendo el socio más valioso del PM. PostHog fue más allá y contrató para eso: sus product engineers originan ideas, hablan con usuarios, despliegan a producción, son dueños del precio y hacen turno de soporte (cargan el buscapersonas), y el manual dice sin rodeos que los ingenieros lideran los equipos de producto. Linear funcionó con un solo PM. Ramp llegó a 100 millones de dólares de ARR con menos de cinco PMs y menos de cincuenta ingenieros, y solo contrata producto cuando queda claro que es el cuello de botella de la velocidad.

Nada de eso necesitó IA. Necesitó equipos pequeños y fundadores que se negaron a pagar por una capa de traducción.

Lo que cambia la IA

Traducir es exactamente lo que hacen los modelos. La especificación era la unidad de producción del PM porque una especificación salía más barata que el código. Eso se invirtió. Un prototipo que funciona hoy sale más barato que un documento bien escrito sobre ese prototipo, y el prototipo no necesita una reunión para que lo entiendan.

Los números se mueven rápido, así que no te enredes con los decimales. Mira la dirección. Mike Krieger dijo en junio de 2025 que alrededor del 90% del código de Claude lo estaba escribiendo Claude, y que el cuello de botella se había movido a decidir qué construir y a lograr que se integrara. Dos semanas después, Andrew Ng le contó a la AI Startup School de YC que uno de sus equipos propuso pasar de un PM por cada cuatro ingenieros a un PM por cada medio ingeniero, porque programar se había acelerado y las decisiones de producto no. Él no estaba seguro de que fuera buena idea. Yo tampoco, pero la dirección es la correcta.

Del lado de los PMs, la encuesta de diciembre de 2025 de Lenny Rachitsky a 1.750 personas encontró que los PMs usan la IA sobre todo para PRDs (21,5%) y prototipos (19,8%), y que el 44,4% nombra el prototipado como lo próximo que quiere hacer. El gasto cuenta la misma historia desde el otro lado: Cursor pasó un ritmo anual de 4.000 millones de dólares en junio de 2026 y Anthropic cerró su Serie H en mayo de 2026 con una valoración de 965.000 millones de dólares sobre un ritmo anual que ya pasaba los 47.000 millones, tres meses después de que Claude Code por sí solo superara los 2.500 millones. Hay una encuesta patrocinada por fondos de capital de riesgo que dice que los roles de "product builder" se multiplicaron por diez en un año mientras los roles tradicionales de PM cayeron un 30%. El mismo informe da por desaparecidos a los PMs en 2030. No creo que nadie haya pensado esa hasta el final. Esto es pura carreta de titular, pero apunta para el mismo lado que las encuestas serias.

Userpilot lo dijo en mayo de 2026: el PM generalista se está partiendo en un Builder-PM y un Integrator-PM, con el integrador deslizándose hacia el marketing de producto y la mitad encogiéndose. Esa es la bifurcación, y son las mismas dos direcciones que vi en la forma del marco de Pragmatic la primera vez que me senté en ese salón: las columnas del mercado de un lado, el trabajo de ingeniería que nunca tuvo columna del otro. Marty Cagan le puso a la mitad el nombre de teatro de gestión de producto hace dos años: PMs que en realidad son project managers, corriendo standups y escribiendo tickets. Esa es la parte del trabajo que un modelo hace primero y sin quejarse.

Adónde se va el foso

El conocimiento se está volviendo abundante, y los fosos construidos sobre él se están yendo con él. Dos casos de fuera del software hacen el punto mejor que cualquiera de adentro. En septiembre, el fundador de una empresa de pedales publicó Firmware freedom, señalando que los modelos de amplificador son de código abierto, las bibliotecas de capturas son gratis, y un ESP32-P4 de 4 dólares ya corre dos modelos de tamaño completo a la vez y le gana a los chips DSP propietarios, así que la única parte cerrada de un pedal de guitarra es el firmware, y sigue cerrada porque es lo único que queda por cerrar. El Klon fue un foso durante veinte años porque el circuito venía cubierto de resina. Ya nadie cubre nada con resina. En abril, investigadores de Calif le dieron a Codex un punto de apoyo en el navegador de un televisor Samsung, junto con el árbol de código fuente correspondiente. Encontró un driver del kernel que le permitía al espacio de usuario mapear memoria física, barrió la RAM buscando la estructura de credenciales del navegador, la puso en ceros y abrió un shell de root. Los humanos lo guiaron con prompts cortos.

La ingeniería inversa siempre fue posible. Los clones del Klon existían mucho antes de que alguien dijera la palabra agente. Lo que cambió es que el costo de hacerla cayó a más o menos el precio de los tokens, y el piso de habilidad cayó con él. Un modelo hoy le explica cualquier sistema a cualquiera. Así que saber cómo funciona un sistema tampoco es un ancla; tiene fecha de vencimiento. El foso se mueve hacia lo que sigue siendo caro de copiar cuando el conocimiento es gratis, y en software eso son dos cosas. De un lado, distribución y confianza: todavía tienes que poner la cosa frente al comprador y lograr que te crea. Del otro, operación y costo: todavía tienes que correrla, más barato que el de al lado, sin que se caiga. Ya argumenté que el token es el kilovatio hora. El foso nunca fue la física de la electricidad. Es ser dueño de la red eléctrica.

Durante el último año les he tirado un experimento mental informal a un montón de líderes de la industria, y apareció un patrón. Dale al CEO cinco puntos para repartir entre las primitivas de su negocio: su ventaja o alpha, sus operaciones, su adquisición de clientes con retención y servicio incluidos, y el sustrato sobre el que corre el negocio, sea una nube, una línea de producción o una flota de camiones. La mayoría le carga la mano al alpha. La mayoría pone más o menos medio punto en el sustrato. El medio punto es sensato. Todo el argumento de venta de una nube o de un fabricante por contrato es que te permite subinvertir en sustrato; ese es el trato, no un error. Pero míralo desde el lado del proveedor. Gasta cuatro de sus cinco puntos exactamente en lo que sus clientes gastan medio punto. La relación es codependiente y asimétrica, y los términos de verdad no están en el SLA. Son lo que sea que el proveedor no alcance a comprar suficiente este año.

De ahí salen dos cosas. El alpha es sobre todo conocimiento, lo que significa que los puntos gastados ahí compran menos cada trimestre mientras el medio punto en sustrato compra más. Esa repartición tenía sentido cuando el conocimiento era escaso. Y el medio punto está a punto de dejar de ser medio punto, porque el alpha ahora corre sobre inferencia. Un CEO que cree que está gastando en su ventaja está gastando parte de eso en tokens, aceleradores y la red que los conecta, que es la red eléctrica. Se está reequilibrando hacia el sustrato sin haberlo decidido, y nadie de su lado de la mesa está mirando ese renglón.

Pon las cuatro primitivas sobre el espectro del PM y la partición ya está dibujada. Adquisición, retención y servicio es el ancla del marketing. Operaciones y sustrato son dos puntos separados, y los dos pertenecen al extremo de la ingeniería. El alpha es la mitad, y el PM de la mitad no tenía ninguna de las dos cosas duraderas; tenía conocimiento del cliente y conocimiento del sistema, y los dos acaban de volverse baratos.

Lo que realmente le pertenece a un product engineer

Un product engineer tiene el derecho de decidir qué se construye y cómo se construye en la capa que importa: la forma de la API, el modelo de datos, la frontera entre tenants, los modos de falla, la experiencia de usuario. Eso es un trabajo distinto al de un PM que hace vibe coding de una demo o un ingeniero al que le entregaron el roadmap. Hace el descubrimiento, habla con la gente que lo usa, toma la decisión de arquitectura, construye la primera versión que funciona, escribe las evaluaciones que prueban que hace lo que dice, conoce su costo y su latencia por solicitud, y lo lleva a operación. La distancia entre una demo y algo que sobrevive al tráfico de producción es donde vive el valor, porque es la parte en la que los modelos todavía se equivocan y la parte por la que un cliente realmente paga.

El insumo caro del software solía ser el código. Ahora es la decisión, y la verificación de la decisión. Jeremy Freeman, de Allstacks, recopiló las proporciones históricas y pronostica una compresión hacia un PM por cada tres o cuatro ingenieros. Creo que se queda corto. Cada traspaso entre un PM, un diseñador y un ingeniero era un impuesto que pagábamos porque ninguna persona sola podía sostener el problema completo. Cuando una sola persona puede, el impuesto desaparece, junto con la nómina que lo cobraba. Hay un costo del otro lado de ese libro contable y el panel de Denver de Jenny Wanger en octubre lo nombró: la IA es de un solo jugador, así que todo el mundo construye solo, y un PM quemó 30 horas en un prototipo que ignoró el sistema de diseño. El product engineer también es la respuesta a eso. Solo puedes construir solo, sin peligro, si estás anclado en el sistema y no parado al lado.

Las habilidades son las que los ingenieros de infraestructura siempre han tenido y a los PMs siempre les han permitido saltarse. Leer un documento de diseño y saber dónde vive el estado y qué se rompe bajo carga. Conocer tu dominio lo suficiente como para que la respuesta equivocada y segura del modelo te salte a la vista, mientras eso todavía cuente para algo. Escribir una evaluación antes de escribir una funcionalidad. Sacar tus propios números con SQL en vez de pedir un dashboard. Tratar el costo y la latencia por solicitud como métricas de producto, no como el SLO de otro. Leer cada pull request aunque lo haya escrito el agente. Las herramientas salen de las habilidades: una terminal y un flujo de git que domines, una de las herramientas de programación agéntica, un arnés de evaluaciones, la pila de observabilidad que usan tus ingenieros, acceso directo al almacén de datos, un clúster local o un sandbox que puedas romper, y el protocolo que use tu empresa para conectar agentes a sus sistemas internos. Nada de eso es exótico. Es el kit estándar de un ingeniero senior, y el punto es que ahora una persona de producto tiene que cargarlo.

Los contraargumentos

Uno de los contraargumentos es el de Roman Pichler, de abril de 2026: los PMs que construyen descuidan la estrategia, acumulan deuda técnica y se queman, así que construir debería seguir siendo una actividad secundaria. Ant Murphy suma los números: unas 42.000 vacantes de PM abiertas en LinkedIn a comienzos de 2026, más o menos el doble del año anterior, y el 59% de los encuestados nombrando la estrategia y el criterio de negocio como las habilidades que importan. Felipe Barreiros argumenta que los dos roles no son rivales y que el trabajo de coordinación del PM crece con la escala.

Donde me tropiezo es que cada una de esas defensas describe un ancla. Estrategia, criterio de negocio y coordinación entre equipos son el extremo del marketing del espectro con otra etiqueta encima. Si ese es tu trabajo, carga el número. Lo que ninguna defiende es la posición de la mitad, y esa es la posición para la que todavía están escritas la mayoría de las vacantes. Las 42.000 vacantes te dicen que la demanda del título subió. No te dicen cuántos de esos trabajos van a existir tal como están escritos dentro de tres años.

No estoy diciendo que el extremo de la ingeniería sea mejor ni más noble. Alguien tiene que ser dueño de los ingresos y del mensaje, y la gente que lo hace bien es escasa. Simplemente no es para donde voy, y tampoco es para donde deberían ir la mayoría de los PMs con los que trabajo. Su valor está en responder por cómo corre el sistema.

Qué mirar

Tres señales van a decirte si esto es una partición de verdad o una moda que se queda dentro del valle. Mira la proporción de PMs a ingenieros en las vacantes de empresas con más de 1.000 ingenieros; Ramp y Linear lo probaron a escala de startup y la pregunta es si sobrevive a la empresa grande. Mira si aparecen vacantes de PM que exijan commits en el repositorio en vez del habitual "se valora perfil técnico". Y mira a Pragmatic Institute. El día que el marco tenga una columna para construir es el día en que el lado del marketing reconoce que el lado de la ingeniería existe.

Ya escogí mi bando. Es el que queda cerca del metal, sobre la infraestructura que hay debajo de todo esto, incluidos los modelos. El metal es valioso porque es difícil de operar, difícil de pagar y difícil de reemplazar, y entenderlo dejó de ser la parte difícil. Treinta años después de que alguien dibujara el espectro, te toca escoger un extremo.