{"id":512,"date":"2026-01-28T04:53:00","date_gmt":"2026-01-28T09:53:00","guid":{"rendered":"https:\/\/andressalcedo.com\/blog\/?p=512"},"modified":"2026-01-28T17:19:15","modified_gmt":"2026-01-28T22:19:15","slug":"la-era-del-product-builder","status":"publish","type":"post","link":"https:\/\/andressalcedo.com\/blog\/la-era-del-product-builder\/","title":{"rendered":"La era del Product Builder"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Hace unos meses fue muy popular el debate (por no llamarlo de otra manera) de si Agile est\u00e1 muerto<\/em>. Y, honestamente, siempre me ha parecido un tema irrelevante en el que no pienso perder mi tiempo. Pero s\u00ed reconozco que detr\u00e1s de esto hay un s\u00edntoma: el debate \u2014m\u00e1s all\u00e1 del morbo que produce en los detractores de Agile sentir que \u201cten\u00edan raz\u00f3n\u201d\u2014 evidencia una realidad que vale la pena analizar. No es tanto si Agile muri\u00f3 o no, sino que algo cambi\u00f3<\/strong>. Y es precisamente de esto de lo que quiero hablar en este art\u00edculo.<\/p>\n\n\n\n

Agile naci\u00f3 como respuesta a problemas muy espec\u00edficos de la ingenier\u00eda de software de los 90: entregas que se demoraban una eternidad, requisitos que envejec\u00edan antes de salir, handoffs<\/em> interminables y un negocio que solo ve\u00eda valor al final del proyecto. Para ese tipo de problemas, Agile funcion\u00f3\u2026 y si hoy alguien sigue teniendo esos mismos problemas, Agile le seguir\u00e1 funcionando.<\/p>\n\n\n\n

Lo que cambi\u00f3 fue el mundo alrededor. Estamos en 2026. Si como humanidad sigui\u00e9ramos atrapados en los problemas de 1990, algo estar\u00eda muy mal. En estos 30 a\u00f1os pasamos por todo tipo de revoluciones: masificaci\u00f3n de internet, computaci\u00f3n personal, smartphones, apps m\u00f3viles, wearables<\/em>, IoT, cloud computing<\/em>, blockchain, NFTs, machine learning<\/em>\u2026 hasta una pandemia tuvimos en el medio. Y ahora estamos viviendo la que promete ser una de las disrupciones m\u00e1s grandes: modelos generativos de lenguaje y, por supuesto, agentes de IA. La ingenier\u00eda de software cambi\u00f3 \u2014y con ella cambi\u00f3 el tipo de problemas<\/em> que hay que resolver.<\/p>\n\n\n\n

Entonces, para m\u00ed, la conversaci\u00f3n no es \u201cAgile sirve o no sirve\u201d. La conversaci\u00f3n es: qu\u00e9 desaf\u00edos tenemos hoy para construir productos digitales, y con qu\u00e9 los vamos a sortear<\/strong>.<\/p>\n\n\n\n

Si hacemos un viaje r\u00e1pido en el tiempo, se ve bastante claro c\u00f3mo hemos ido llegando a este punto.<\/p>\n\n\n\n

La era del \u201cScrum Team\u201d cl\u00e1sico<\/strong><\/h3>\n\n\n\n

En el Pleistoceno (seg\u00fan los arque\u00f3logos), durante varios a\u00f1os existi\u00f3 un est\u00e1ndar de equipo de desarrollo de producto: Product Owner, Scrum Master y developers<\/em>. A eso le llamaban Scrum Team<\/em> o, tambi\u00e9n, el mal llamado squad<\/em> (algunos incluso le dec\u00edan \u201cc\u00e9lulas\u201d). A nivel organizacional emergi\u00f3 el t\u00e9rmino \u201ctribus\u201d para referirse a agrupaciones de squads<\/em>.<\/p>\n\n\n\n

Luego vino un momento en el que construir productos digitales se volvi\u00f3 tan complejo que nos fuimos al otro extremo: equipos hiperfragmentados.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

UX Writer, UI Designer, UX Researcher, frontend Angular, frontend React, mobile developer<\/em>, backend Spring Boot, DBA, DevOps, tester, business analyst\u2026 y as\u00ed. Ten\u00eda sentido: cada especialidad exist\u00eda porque hab\u00eda tal nivel de complejidad que ameritaba asumir el costo de esos roles.<\/p>\n\n\n\n

En esa \u00e9poca, el Scrum Master ten\u00eda una raz\u00f3n de ser muy concreta: ayudar a que un equipo entregara con ritmo, remover impedimentos y crear un sistema de mejora continua. Cuando la productividad era un problema real, ese rol brillaba. El Scrum Master aportaba valor impulsando la cohesi\u00f3n de equipos hiperfragmentados para que fueran m\u00e1s all\u00e1 de sus silos y se convirtieran en equipos multifuncionales, donde un hiperespecialista evolucionara hacia un tipo de profesional capaz de aportar al equipo en roles m\u00e1s all\u00e1 de su hiperespecialidad.<\/p>\n\n\n\n

Llega la era del \u201cfull stack\u201d<\/strong><\/h3>\n\n\n\n

Despu\u00e9s empez\u00f3 a pasar algo interesante: apareci\u00f3 con fuerza el t\u00e9rmino full stack<\/em>.<\/p>\n\n\n\n

Antes, hablar de un \u201cdeveloper full stack\u201d (un desarrollador lo suficientemente competente para trabajar en frontend y backend) era casi hablar de un unicornio. Pero con el tiempo fueron apareciendo herramientas cada vez mejores \u2014y ahora, con IA\u2014 que facilitaron la aparici\u00f3n de estos perfiles sin necesidad de ser el m\u00e1ximo experto en cada una de estas disciplinas. Empez\u00f3 a bastar con conocer los fundamentos del desarrollo front<\/em> y back<\/em>, mientras que la necesidad de profundidad en temas espec\u00edficos se cubr\u00eda con estas herramientas emergentes.<\/p>\n\n\n\n

Y mientras aparec\u00edan los primeros espec\u00edmenes de developers full stack<\/em>, sucedieron otros cambios que redujeron a\u00fan m\u00e1s la multiespecialidad dentro de los squads<\/em>: muchos equipos empezaron a prescindir del rol de tester. Aclaro: prescindir del cargo, no de la responsabilidad. Porque testear es igual o m\u00e1s importante que antes\u2026 solo que una parte relevante de ese trabajo se absorbi\u00f3 con tecnolog\u00eda (automatizaci\u00f3n, pipelines<\/em>, testing asistido, etc.). Algo similar empez\u00f3 a ocurrir con otras especialidades: de repente, el UX designer pod\u00eda cubrir tambi\u00e9n necesidades de UX writing, UI design y research, con mucho m\u00e1s alcance que antes.<\/p>\n\n\n\n

Entonces, los developers, en lugar de invertir su tiempo en profundizar su especialidad al extremo, empezaron a dedicarse a adquirir habilidades adyacentes y aparecieron profesionales en forma de Pi (\u03c0) o en forma de \u201cM\u201d. Esto significa que los profesionales ahora pod\u00edan representar m\u00faltiples especialidades con la calidad necesaria para generar valor.<\/p>\n\n\n\n

Este tipo de evoluci\u00f3n profesional era el estado deseado que promov\u00eda el Scrum Master cuando buscaba productividad y el desarrollo de equipos multifuncionales. Pero, a medida que se produc\u00eda esta evoluci\u00f3n, el aporte requerido del Scrum Master fue disminuyendo.<\/p>\n\n\n\n

Si hoy en d\u00eda eres un hiperespecialista, d\u00e9jame decirte que eres un esp\u00e9cimen en v\u00eda de extinci\u00f3n. Un humano nunca va a competir como especialista contra una m\u00e1quina. El otro d\u00eda escuchaba a Guillermo Rauch decir algo que me hizo clic: si eres buen\u00edsimo calculando n\u00fameros en la cabeza\u2026 igual vas a perder contra una calculadora [1]. Y esa analog\u00eda aplica perfecto para entender lo que ha pasado con los hiperespecialistas.<\/p>\n\n\n\n

Aparece el meteorito LLM y la IA empieza a borrar fronteras de verdad<\/strong><\/h3>\n\n\n\n

Con la aparici\u00f3n de los modelos generativos de lenguaje y la IA ag\u00e9ntica, estamos presenciando un punto de inflexi\u00f3n en el mundo del desarrollo de productos. Las fronteras tradicionales entre roles como Product Owner, dise\u00f1ador y desarrollador se est\u00e1n desdibujando. Varias fuerzas convergen para impulsar este cambio:<\/p>\n\n\n\n