El valor del código se está desplomando. Lo que ayer era un activo escaso y costoso en el ámbito digital se está convirtiendo en una commodity abundante, generada bajo demanda. En este nuevo paradigma, el Product Manager etendido como gestor deja paso al Product Builder, un perfil capaz de llevar un producto hasta producción con total autonomía. Pero, ¿cómo pasar del prototipo individual a la capacidad sin caer en el caos? Renaud Chevalier, CTO de Thiga, analiza cinco conceptos clave para comprender y afrontar este cambio.
Abres Claude Code y activas el Plan Mode. Claude empieza a hacerte preguntas: ¿qué problema queremos resolver?, ¿cómo mediremos el éxito?, ¿qué restricciones de negocio y técnicas existen? En unos pocos intercambios, se formaliza un pliego de condiciones, legible, que apruebas antes de que exista una sola línea de código.
Das tu visto bueno y Claude Code se pone manos a la obra. Orquesta la implementación en paralelo, consulta los servidores MCP para recuperar datos contextuales de los sistemas de la organización, realiza commits y reporta el progreso. Sigues el progreso y realizas ajustes si es necesario. Claude Code envía el código y abre una solicitud de incorporación de cambios (Pull Request). Los guardrails de la plataforma validan automáticamente el cumplimiento normativo, la seguridad y las pruebas. Realizas la fusión, consultas las métricas en tiempo real y vuelves a empezar.
De la especificación a producción, tú solo, en cuestión de horas. Sin planificación de sprints, sin un documento de requisitos (PRD) redactado para convencer al equipo de ingeniería, sin reuniones de priorización. Has analizado el problema, definido la solución, creado el producto y medido el resultado, todo ello en un mismo día.
Este escenario no tiene nada de ciencia ficción, ni tampoco es vibe coding. Es un enfoque estructurado, reproducible y trazable que practican hoy en día los profesionales del producto que han entendido cómo ha cambiado el mundo en el que trabajan. Lo vemos cada día tanto entre nuestros clientes como dentro de nuestros equipos.
La conclusión que comparten es la misma: los términos de la era anterior ya no se ajustan a lo que hacen. "Product Manager" describe a alguien que gestiona. "Sprint" describe una restricción de tiempo. "PRD" describe un documento de comunicación con el equipo técnico. Son términos que pertenecen a una realidad que ha cambiado. Y cuando el lenguaje deja de reflejar esa realidad, también perdemos la capacidad de comprenderla. Y lo que no se comprende, no se puede dirigir.
Este artículo propone cinco conceptos para comprender y liderar ese cambio.
El cambio de estado
En física, un cambio de estado nunca es progresivo. El agua a 99 °C y el agua a 101 °C no tienen las mismas propiedades. No hay una transición suave entre ambas, sino simplemente un umbral más allá del cual todo funciona de manera diferente.
El producto digital acaba de cruzar ese umbral. Durante más de veinte años, la práctica del producto ha funcionado en un marco estable, estructurado por una realidad sencilla: desarrollar software era caro. El código era un recurso escaso, y producirlo exigía competencias especializadas, tiempo y una larga cadena de intermediarios. Ese coste condicionaba todo lo demás: los roles, los rituales y la forma de trabajar.
Hoy ese coste se ha desplomado y el código se ha convertido en una commodity. Los sistemas siguen funcionando gracias a él, pero producirlo ha dejado de ser una limitación. El código empieza a parecerse a lo que fue la electricidad durante el siglo XX: una infraestructura invisible, accesible para cualquiera y cuyo valor ya nadie cuestiona por sí mismo. Nadie piensa en la electricidad cuando enciende una lámpara; simplemente enchufa el cable.
Si el código deja de ser el activo escaso, ¿qué es lo que adquiere valor en su lugar?
En primer lugar, los datos. El código generado al instante solo tiene sentido porque manipula, transforma y presenta información. Cuando escribir código deja de ser el problema, el verdadero activo diferencial pasa a ser la calidad de los datos sobre los que opera: su gobernanza, su accesibilidad, su actualización y su fiabilidad determinan mucho más el valor del producto que la sofisticación del propio código.
En segundo, el criterio. En un mundo en el que el código se parece cada vez más a la electricidad, lo que adquiere valor es la decisión de qué se conecta a la red. Si la ejecución es abundante, un error de dirección sale proporcionalmente más caro. Ya no hay fricción mecánica que frene las malas decisiones: ya no hay que esperar a que termine un sprint, ni estimaciones que obliguen a reflexionar antes de comprometerse. La decisión sobre qué se construye, por qué y para quién, eso es lo que se vuelve escaso y lo que realmente marca la diferencia.
Concepto n.º 1: el «Product Builder»
Este cambio de situación da lugar a un nuevo rol. La trayectoria se asemeja a la de DevOps: primero, una cultura y unas prácticas adoptadas por unos pocos equipos; después, un rol reconocido; y, por último, un título de puesto estandarizado en el mercado. El Product Builder se encuentra en la segunda etapa. Algunos PM ya desempeñan esta función sin ostentar el título, y algunas empresas ya contratan con este nombre.
Un Product Builder puede provenir del Product Management, del Diseño o del Desarrollo. Su origen importa menos que el cambio que ha experimentado su forma de trabajar: su relación con la ejecución. Es capaz de recorrer por sí solo toda la cadena de valor, desde la intención hasta la puesta en producción, sin depender del equipo de ingeniería para validar cada hipótesis.
El PM aporta el rigor de la discovery y la alineación con el negocio. El diseñador aporta la empatía con el usuario y la calidad de la experiencia. El desarrollador aporta el conocimiento técnico y la comprensión de la arquitectura. El Product Builder ideal reúne todas estas perspectivas; cuando no es así, sabe colaborar con cada uno de estos perfiles y aprovechar la IA para compensar aquello que no domina
Esta nueva relación con la ejecución transforma la práctica en profundidad.
En primer lugar, cambia la relación con los entregables. El Product Builder ya no se limita a describir una solución: la especifica y la demuestra. La especificación cocreada junto al agente sustituye al PRD redactado en solitario, y el entregable deja de ser un documento pensado para convencer al equipo técnico para convertirse en una demostración que alinea a las partes interesadas mediante la evidencia.
También cambia la relación con el tiempo. El sprint de dos semanas se reduce a unas pocas horas, y la iteración deja de ser un ritual con una cadencia fija para convertirse en un proceso continuo. Como cada paso queda registrado y validado por la plataforma, acelerar ya no implica sacrificar calidad; al contrario, puede reforzarla.
La relación con el equipo de ingeniería se reconfigura en función del grado de autonomía alcanzado. Al principio, el Product Builder crea el prototipo y el equipo de ingeniería se encarga de la producción. A medida que la plataforma madura, con sus guardrails, sus pruebas y su cumplimiento normativo automatizado, el Product Builder se adentra directamente en ámbitos cada vez más amplios, y el equipo de ingeniería se centra en la revisión del código y las decisiones de arquitectura. En las configuraciones más avanzadas, la única dependencia externa es el equipo de Platform Engineering, que actúa como proveedor de infraestructura compartida más que como un equipo de entrega.
La propia colaboración cambia de naturaleza. Dado que el Product Builder puede recorrer por sí solo la cadena de valor, la colaboración deja de ser una restricción estructural impuesta por el proceso (traspasos, ceremonias, dependencias cruzadas) y se convierte en un acto deliberado. Se colabora para acceder a datos que los agentes no cubren, para compartir aprendizajes que los datos por sí solos no revelan, para cuestionar los propios puntos ciegos y para mantener el vínculo humano, la confianza y la dinámica colectiva, algo que ningún agente puede generar por sí solo.
Para que todo esto sea posible hacen falta dos habilitadores fundamentales. El primero es un entorno de ejecución adaptado. El segundo, una infraestructura que abre la vía rápida hasta la producción.
¿Ya has integrado IA en tu producto? Descarga nuestro AI Product Canvas que recoge todas las preguntas que debes plantearte antes de lanzarte a un proyecto de IA.
Concepto n.º 2: el Operating System del Product Builder
El primer facilitador es el Operating System (OS) del Product Builder, su entorno de ejecución personal.
Chromebook ha demostrado que es posible ocultar el sistema operativo tradicional tras un navegador. El sistema operativo del Product Builder lleva esa idea un paso más allá: oculta toda la stack de desarrollo tras una interfaz conversacional. Se compone de cinco elementos.
El modelo de lenguaje
Es el motor de todo lo demás. La elección del modelo determina la calidad del razonamiento, el tamaño de la ventana de contexto, la velocidad de ejecución y el coste de uso.
Un agente consume muchas más llamadas que una conversación tradicional, y la diferencia de coste entre un modelo frontier (los más eficaces del mercado) y un modelo rápido puede alcanzar varios órdenes de magnitud.
La responsabilidad del Product Builder es calibrar: modelos frontier para tareas que requieren un alto nivel de criterio, como las especificaciones, la arquitectura o una decisión estructural; y modelos más económicos para tareas repetitivas y de alta frecuencia, como reformatear contenidos, ejecutar pruebas o generar documentación. Este equilibrio también plantea cuestiones de soberanía tecnológica (qué datos transitan por qué API, bajo qué jurisdicción) y de huella medioambiental, ya que cada inferencia consume energía y, a escala de una organización, esto se convierte en un reto de gobernanza colectiva.
La interfaz conversacional
En torno al modelo, la interfaz conversacional determina la forma en que el Product Builder expresa su intención. Hoy en día coexisten tres tipologías. La línea de comandos, minimalista y desprovista de cualquier distracción (Claude Code, Gemini CLI, Open Code). El IDE aumentado, donde la IA se integra en el entorno de desarrollo como una capa de asistencia (Cursor, Windsurf). Y el enfoque orientado al diseño, en el que el Product Builder describe o esboza lo que desea construir y la herramienta genera la interfaz sin mostrar el código (Lovable, Figma Make, v0, Bolt).
¿Cuál de estos enfoques terminará imponiéndose? Todavía es una incógnita. El gran reto de esta nueva generación de productos está, precisamente, en la experiencia de uso.
Los servidores MCP
Los servidores MCP (Model Context Protocol) constituyen el tercer elemento, y son los que anclan el sistema operativo en el mundo real. MCP es el protocolo abierto que conecta la interfaz conversacional con los sistemas de la organización: Jira, Figma, GitHub, bases de datos, API internas y herramientas de análisis.
Mientras el sistema operativo no esté conectado a los sistemas de la organización, su funcionamiento carece de sentido. El MCP cambia las reglas del juego: los datos circulan, se aplican las restricciones y el agente trabaja con datos reales en lugar de con abstracciones.
Las Skills
El siguiente componente son las Skills. Se trata de archivos (SKILL.md) cargados en el sistema operativo que codifican conocimientos especializados, activados automáticamente por el agente en cuanto reconoce su relevancia.
Un agente sin Skills es un generalista, competente pero sin memoria de cómo trabajan el Product Builder o su equipo. Las Skills le proporcionan comportamientos reproducibles: una forma de hacer una sesión de brainstorming, de depurar o de revisar el código, que aplica sin que haya que volver a explicárselas en cada sesión. Así es como el sistema operativo se adapta progresivamente al contexto y a los estándares de la organización.
La memoria
La memoria, por último, se basa en dos mecanismos. El contexto de sesión, volátil, que desaparece al cerrarla. Y la memoria persistente, lo que el Product Builder codifica deliberadamente en archivos que se cargan en cada sesión (CLAUDE.md, .cursorrules, AGENTS.md): estándares del equipo, decisiones anteriores, restricciones del contexto, complementados a través de MCP por sistemas de memoria externos.
En otras palabras, toda memoria que sobrevive entre sesiones responde siempre a una decisión deliberada. Los LLM no modifican su comportamiento de forma autónoma ni aprenden automáticamente a partir del uso.
Concepto n.º 3: la Plataforma
Si el sistema operativo proporciona al Product Builder la capacidad de ejecución, la plataforma, por su parte, transforma esa capacidad en una implementación controlada. Las barreras de la producción siguen ahí, pero se han desplazado de la competencia individual a la infraestructura compartida.
Ese es precisamente el papel del Platform Engineering: diseñar una Internal Developer Platform (IDP) que permita a los Product Builders desplegar en producción de forma autónoma y bajo un marco de control. El concepto no es nuevo. Sin embargo, la aparición del Product Builder cambia por completo su importancia. Sin una plataforma, esta nueva capacidad de ejecución queda reducida al ámbito individual, sin un camino fiable para llegar a producción. La plataforma es lo que permite pasar del prototipo al producto real.
La IDP funciona según un principio fundamental: los golden paths. Se trata de recorridos estandarizados y preconfigurados que encapsulan las buenas prácticas de la organización mediante automatizaciones disponibles en autoservicio. Seguir un golden path significa poder desplegar en producción sin necesidad de comprender todas las capas de infraestructura que existen por debajo. Exactamente igual que enchufamos un aparato eléctrico sin necesidad de entender cómo funciona toda la red eléctrica.
El sistema operativo interactúa con distintas capas de esta plataforma:
- El control de versiones. La gestión del código fuente, con sus ramas y sus Pull Requests, constituye la columna vertebral de la ejecución por parte de los agentes. Cuando los agentes generan código de forma continua, potencialmente en varias funcionalidades al mismo tiempo, la disciplina de las ramas se convierte en una condición para el funcionamiento, más allá de una simple convención del equipo. La pull request es el punto de unión entre el sistema operativo individual y la plataforma colectiva, el momento en el que se activan los guardrails y se verifica automáticamente el cumplimiento normativo. Con agentes capaces de abrir decenas de PR, la plataforma debe asumir la validación sistémica para que la revisión humana siga siendo específica y de gran valor.
- El acceso a los datos constituye una capa en sí misma. Quién tiene acceso a qué, con qué normas de calidad y qué trazabilidad: la fiabilidad de lo que produce el agente depende directamente de la calidad de los datos a los que está conectado, y cuando los datos no están bien gobernados, el agente puede ir muy rápido… Pero lo hará "mal".
- La infraestructura de ejecución (entornos de compilación, pipelines de CI/CD, sistemas de orquestación de contenedores) adquiere una nueva dimensión en un contexto agéntico. Los agentes pueden activar decenas de compilaciones en paralelo, en ramas aisladas, para funcionalidades simultáneas, y la infraestructura debe absorber esta paralelización sin que la reproducibilidad o la velocidad de ejecución se vean afectadas.
- Los guardrails codifican las normas de cumplimiento y seguridad directamente en la plataforma. En la práctica, el Product Builder avanza de forma autónoma, y es la plataforma la que garantiza que lo que llega a producción respete los estándares de la organización. Es la diferencia entre conducir por una autopista con quitamiedos y hacerlo por un camino de tierra.
- La monitorización y la observabilidad cierran el ciclo de aprendizaje. La monitorización señala que se produce un comportamiento inesperado, y la observabilidad permite remontarse a la causa analizando las señales del sistema. Ambos juntos proporcionan al Product Builder la información que necesita para iterar, porque desplegar en producción sin entender qué está ocurriendo después equivale a iterar completamente a ciegas.
Concepto n.º 4: el Product Operating Model de IA
Un Product Builder con un sistema operativo eficaz, conectado a una plataforma bien diseñada, es una unidad capaz y autónoma. Pero una organización no es un conjunto de unidades autónomas. Es (o debería ser) un sistema cuya inteligencia supera la suma de sus partes.
El Modelo Operativo de Producto es el marco organizativo que, hasta ahora, ha estructurado la forma en que los equipos de producto operan colectivamente, toman decisiones, aprovechan lo aprendido y mantienen la coherencia entre los sistemas operativos individuales que funcionan en paralelo. Con la IA de última generación, debe evolucionar para seguir siendo relevante.
Reto 1: decidir al ritmo de la ejecución
Cuando la ejecución se acelera, la toma de decisiones debe seguirle el ritmo. Cuando un Product Builder puede lanzar un producto en unas pocas horas, los rituales semanales de priorización pierden su función. La planificación de sprints partía de la base de que la ejecución era el cuello de botella: organizaba la cola ante un recurso escaso y obligaba, por necesidad, a priorizar antes de comprometerse.
Cuando ese recurso se vuelve abundante, la cola desaparece y, con ella, los puntos de pausa en los que se ejercía el juicio de forma natural. El riesgo es decidir demasiado despacio o decidir rápido y mal. El POM AI recrea deliberadamente estos puntos de reflexión: organiza de forma explícita qué forma parte del enfoque estratégico, qué se encuentra en fase de exploración controlada y qué está a la espera de su momento.
Reto 2: transformar el aprendizaje individual en capital colectivo
La capitalización del aprendizaje es un reto de otra índole. La puesta en común de herramientas, habilidades compartidas o conexiones MCP comunes es competencia de la plataforma. Pero, ¿cómo se convierte el aprendizaje individual en conocimiento colectivo? ¿Cómo pasar de «he validado esta hipótesis» a «la organización sabe que esta hipótesis está validada y actúa en consecuencia»? El Product Operating Model potenciado por IA estructura precisamente ese proceso de aprendizaje compartido mediante una memoria estratégica colectiva: hipótesis validadas, segmentos comprendidos, direcciones exploradas. Sin esta capa de conocimiento común, cada equipo acaba redescubriendo lo que los demás ya sabían.
Reto 3: gobernar sin limitar la autonomía
Cuando cada Product Builder dispone de un sistema operativo autónomo y de acceso directo a la producción, el control de accesos ya no es suficiente.
La gobernanza debe operar en dos niveles.
-
A nivel operativo: qué datos pueden consumir los sistemas operativos, qué ámbitos pueden cubrir los Product Builders por sí mismos, qué decisiones requieren una validación colectiva. La plataforma codifica estas reglas técnicamente, mientras que el POM AI las define a nivel organizativo.
-
A nivel estratégico: cuando cada célula es autónoma y ágil, el riesgo de desviación es proporcional a la velocidad de ejecución. El POM AI establece entonces un marco de convergencia compuesto por restricciones ligeras y explícitas, con una dirección compartida, límites claros y visibilidad recíproca.
Cuanto más descentralizada y rápida sea la ejecución, más explícito y ligero debe ser este marco de coherencia. Sin él, la autonomía distribuida se convierte en caos.
Reto 4: gestionar los datos como un activo estratégico
La gobernanza de los datos merece un tratamiento aparte. La plataforma controla el acceso técnico, pero ¿quién decide qué datos se recopilan, se mantienen y se comparten entre las unidades? Cuando cada Product Builder consume y produce datos a través de MCP de forma autónoma, sin gobernanza organizativa, los datos se duplican y pierden fiabilidad.
El POM AI define quién es el propietario de los productos de datos, cómo se establecen colectivamente los estándares de calidad y cómo los datos generados por una unidad se convierten en un activo accesible para las demás. Dado que los datos son el activo central de la nueva organización, su gobernanza es un reto organizativo antes que técnico. A esto se suma una cuestión de soberanía: cuando los sistemas operativos consumen datos a través de APIs alojadas fuera de la Unión Europea, la ubicación de los datos y la reversibilidad de las dependencias de los proveedores se convierten en cuestiones de gobernanza estratégica.
Reto 5: gobernar el coste y el impacto de la ejecución mediante agéntica
Cuando la ejecución se acelera, se acumulan dos costes fuera del campo de visión individual: el coste financiero y la huella de carbono asociada a cada inferencia. Un Product Builder puede ver las consecuencias de sus propias decisiones, pero una organización de Product Builders que operan en paralelo genera un consumo agregado que nadie controla si no se ha planificado la gobernanza. ¿Quién establece los presupuestos? ¿Qué modelos se aprueban para qué usos? ¿Quién se hace responsable de la huella colectiva? Se trata de cuestiones de gobernanza organizativa, no de cuestiones técnicas, y eso es precisamente lo que abordan el FinOps aplicado a la IA y el GreenOps. Sin esta capa, la aceleración de la ejecución se convierte en una inflación tanto financiera como medioambiental.
Concepto n.º 5: el Craft
Los cuatro conceptos anteriores describen aquello que está cambiando. El quinto aborda una cuestión distinta: ¿qué seguirá siendo irreductiblemente humano cuando todo lo anterior ya esté en marcha?
El término craft proviene del movimiento Software Craftsmanship: la convicción de que el desarrollo de software es un oficio cuyo dominio se construye con el tiempo y a través de la práctica. Aplicado al Product Builder, el craft se refiere a la misma idea extendida a la práctica del producto: todo aquello que se acumula con la experiencia y que ni los agentes ni la plataforma pueden reproducir.
Este craft se apoya en cuatro capacidades fundamentales.
Capacidad 1: El Product Taste
El Product Taste (el "buen gusto" en materia de producto, es decir, la capacidad de tomar buenas decisiones) es su manifestación más evidente. Distinguir un problema real de una necesidad falsa e intuir lo que va a ser importante para un usuario antes de que los datos lo confirmen es una inteligencia contextual que se forja a lo largo de los proyectos. El sistema operativo puede generar diez opciones, pero elegir la correcta por las razones adecuadas sigue siendo un acto de juicio humano.
Capacidad 2: la empatía profunda
La empatía profunda pertenece al mismo ámbito, aunque funcione de manera diferente. No nos referimos aquí a los perfiles de usuario segmentados ni a los comentarios analizados por un agente, sino a lo que se consigue al dedicarle tiempo al problema y comprender el contexto de uso que subyace al comportamiento observado. Los agentes sintetizan información; no comprenden a un ser humano en su singularidad.
Capacidad 3: la toma de decisiones en condiciones de incertidumbre
Tomar decisiones cuando los datos son incompletos, cuando los stakeholders discrepan o cuando el mercado envía señales contradictorias. El sistema operativo puede generar escenarios, cuantificar probabilidades y elaborar análisis. No puede asumir la responsabilidad de la elección ni las consecuencias organizativas de una decisión estructural.
Capacidad 4: el liderazgo narrativo
El liderazgo narrativo completa el panorama. Más que un simple ejercicio analítico, alinear una organización en torno a una visión de producto es un acto político y relacional que se basa en la confianza que unas personas depositan en otras, y esa confianza se construye con el tiempo y a lo largo de la relación.
Lo que la IA generativa transforma es el tiempo que el Product Builder puede dedicar a ejercer estas capacidades. Cuando el sistema operativo absorbe las tareas de alta frecuencia y bajo nivel de criterio, y la plataforma se encarga de la complejidad de la implementación, el criterio y la empatía pueden ocupar por fin el lugar central que deberían haber ocupado desde el principio.
Esta liberación no se produce de forma automática. Requiere un Product Operating Model que organice deliberadamente lo que asume el sistema operativo y lo que se reserva el ser humano; de lo contrario, la aceleración simplemente generará más tareas de bajo valor a un ritmo más elevado.
Los términos de la era anterior describían un mundo en el que construir software era caro. Ese mundo ya ha quedado atrás. Product Builder, Operating System, plataforma, POM-AI, Craft: estos cinco conceptos definen el marco en el que operarán las organizaciones de producto en los próximos años. La realidad ya ha cambiado de estado. El lenguaje, por su parte, apenas empieza a ponerse al día. Queda por ver qué organizaciones lo aprovecharán para construir su modelo.
La IA está transformando el panorama y, con él, el marco estratégico. Para aprovechar realmente las oportunidades que ofrece la IA, hay que ser capaz de decidir qué priorizar, cómo gestionarla y cómo involucrar a la organización. ¡Contacta con nuestro equipo para ver cómo podemos acompañarte!
