Ser Product Builder: 6 lecciones que he aprendido sobre el terreno

El término Product Builder está dando mucho que hablar. Entre lo que a veces se ve en las redes sociales y la realidad sobre el terreno, a veces hay una (gran) diferencia. O, al menos, eso es lo que constata Pierre Sur después de varios meses trabajando como Product Builder para una empresa del sector MedTech. Las limitaciones de los frameworks de código abierto, el "AI slop", la transformación de la organización… Pierre comparte seis lecciones concretas para entender qué realmente implica incorporar a un Product Builder en un proyecto.

El término Product Builder está muy de moda últimamente y cada uno lo interpreta un poco a su manera: para algunos es un PM que programa; para otros, un desarrollador que hace discovery con agentes; y para otros, simplemente una nueva forma de decir full-stack. Cuando empecé mi proyecto en una empresa MedTech, el cliente también quería su Product Builder. Para él, se trataba de alguien capaz de llevar un producto desde la idea hasta la producción, incorporando agentes de IA en el proceso. Aunque el briefing era claro al principio, varios meses después, casi todas mis certezas sobre lo que eso implicaba en la práctica habían cambiado.

Los frameworks del mercado terminan donde empiezan los problemas

Primera semana de trabajo, primer reflejo: ver qué había disponible. BMAD, OpenSpec, Speckit... El ecosistema de frameworks open source para trabajar con agentes de código ha explotado en los últimos meses. El problema es que todos terminan en el mismo punto: el código generado.

Pruebas, control de calidad, evaluación de riesgos, monitorización en producción: nada de eso está cubierto. Y, sin embargo, ahí es donde se decide todo cuando se trabaja en las instalaciones de un cliente con limitaciones reales. El backoffice en el que trabajaba exigía una trazabilidad completa con registro de auditoría, seudonimización por defecto y una gestión detallada de los permisos. Ningún framework del mercado aborda estos temas.

Aun así, probé BMAD durante una semana. Seis horas de configuración para generar un PRD genérico de calidad media. Para funcionalidades sencillas, está sobredimensionado, y para las críticas, no es suficiente. La relación esfuerzo/valor no compensaba.

En lugar de seguir buscando el framework adecuado, construimos nuestros propios componentes, adaptados a las restricciones del proyecto.

Ser Product Builder es ir de la idea a producción

La simplificación más habitual sobre el Product Builder es pensar que se trata de un PM que genera código rápidamente con un agente. Durante el proyecto, utilicé agentes mucho más allá de la generación de código: discovery, especificaciones, prototipado, desarrollo y QA. El objetivo es hacer mejor trabajo de Producto, más rápido y a lo largo de toda la cadena. Los agentes multiplican la capacidad de ejecución, pero la reflexión de Producto sigue recayendo por completo en el Product Builder.

Un ejemplo concreto: para una funcionalidad de gestión de usuarios, dirigí las entrevistas, redacté el PRD con un agente, puse en marcha el prototipo con un segundo agente, lo validé con cinco usuarios en una semana y, a continuación, pasé el relevo al equipo de desarrollo. Un único punto de decisión sobre el producto, desde la idea hasta la puesta en producción. El ahorro de tiempo es real, pero se debe a la continuidad de la cadena, no a la velocidad de generación del código.

Esta continuidad cambia algo fundamental en el día a día: el ciclo de feedback se acorta drásticamente. Cuando la misma persona lleva la intención del producto desde la primera entrevista hasta el prototipo probado, desaparecen los malentendidos que suelen colarse entre los eslabones de la cadena. Cada etapa sigue siendo necesaria; los agentes simplemente permiten que una sola persona se encargue de todas ellas.

Cuanto más rápido desarrollan los agentes, más importan las metodologías

Esta conclusión resulta contraintuitiva, y probablemente sea la lección más importante que he extraído de esta misión.

Cuanto más rápidos son los agentes de código, más determina la calidad del input el resultado. Unas especificaciones poco claras generan AI slop (código generado que funciona, pero que no sirve para nada) y unas prioridades mal planteadas dan lugar a funcionalidades inútiles entregadas en unas horas en lugar de unas semanas. El problema sigue siendo el mismo; simplemente llega más rápido. 

En cambio, cuando intenté generar una funcionalidad utilizando un PRD preciso (personas, jobs to be done, edge cases, historias de usuario procedentes de entrevistas reales), obtuve un prototipo utilizable desde la primera iteración. El ahorro de tiempo resultante es considerable.

El discovery, la investigación de usuarios y la priorización por valor siguen siendo válidas. Simplemente se vuelven más críticas porque la ejecución amplifica lo que se le aporta. Esa capacidad de juicio, ese "product taste" que permite distinguir un problema real de una necesidad falsa (lo que en Thiga denominamos craft), es precisamente lo que los agentes no aportan. Un buen enfoque multiplica su rendimiento cuando la ejecución es casi instantánea. En cambio, las consecuencias de un mal planteamiento llegan más rápido que antes.

La fuente de verdad debe estar cerca del código

En Thiga, hablamos del Sistema Operativo del Product Builder para describir el entorno de ejecución en el que opera a diario: el modelo de lenguaje, la interfaz conversacional, las conexiones MCP con los sistemas de la organización, las habilidades y la memoria. Durante el proyecto descubrí que la primera decisión estructural sobre este sistema operativo no es la elección del modelo o de la interfaz. Es la elección del lugar donde reside la fuente de verdad.

Si las especificaciones están en Notion, las decisiones en Confluence y las historias de usuario en Jira, los agentes navegan a ciegas en cada iteración. Es un problema que descubrí ya en las primeras semanas y que exigió un cambio en la arquitectura de la información incluso antes de hablar de funcionalidades.

Coocamos GitLab en el centro. Todo lo que proporcionamos como información a los agentes se encuentra en el repositorio, versionado: PRD, kit de diseño y especificaciones técnicas. Notion se mantiene para la documentación de carácter humano, y el flujo siempre va de GitLab a Notion, nunca al revés.

La regla que aplicamos es sencilla: en GitLab solo entra aquello que sirve como input para un agente. Las transcripciones de las entrevistas, por ejemplo, permanecen en Notion. Son material humano, no contexto para el agente. Esta distinción puede parecer anecdótica, pero estructura todo el workflow en el día a día.

Incluso nos planteamos eliminar Jira por completo. Si los agentes leen directamente los PRD desde el repositorio, las historias de usuario escritas en una herramienta de ticketing independiente dejan de aportar demasiado valor. Cuando un desarrollador lanza un agente para implementar una funcionalidad, este recupera automáticamente el PRD y las especificaciones técnicas desde el repositorio. Todo el contexto está ahí, actualizado, sin que nadie haya tenido que copiar y pegar nada.

En solitario o en equipo: el modelo se adapta

La fantasía del Product Builder autónomo que lo hace todo por sí solo de la A a la Z resulta tentadora. La realidad del proyecto me ha enseñado que el modelo adecuado depende de dos variables: la criticidad y la complejidad del producto.

En el backoffice de esta scale-up de MedTech (sistema heredado y crítico), el equipo estaba formado por un PM y dos desarrolladores con experiencia en IA. El código tiene diez años, la fiabilidad prima sobre la velocidad y las competencias de desarrollo siguen siendo imprescindibles. Un Product Builder integrado en un equipo pequeño, con menos desarrolladores que antes, pero con desarrolladores al fin y al cabo, es el equilibrio adecuado para este tipo de contexto.

En una herramienta interna de generación de datos de demostración para el departamento de ventas (proyecto nuevo, no crítico), un Product Builder en solitario lanzó una aplicación con Supabase + N8N en pocos días. El nivel de fiabilidad exigido es bajo, el código parte de cero y los usuarios finales son internos: en este caso, el sistema autónomo funciona bien.

Que el Product Builder actúe en solitario en cualquier circunstancia sigue siendo una quimera. El modelo que funciona en la práctica es el del punto de decisión central del producto rodeado de un equipo dimensionado en función del contexto. La verdadera pregunta que hay que hacerse en cada caso es: ¿cuántas competencias complementarias necesita a su alrededor en este proyecto concreto?

La adopción no se impone

Conceder acceso a Claude y organizar formaciones es un requisito previo y puede ayudar a que las cosas avancen... pero no genera adopción por sí solo.

Lo que realmente funciona es la demostración y el mentoring directo, aplicado a los problemas reales del equipo. Cuando una funcionalidad entra en desarrollo, incorporamos a un desarrollador de otro equipo implicado en la iniciativa y trabajamos con él. Le enseñamos a utilizar Claude Code y los agentes que hemos desarrollado y avanzamos juntos en la funcionalidad. Él adquiere competencias a partir de un caso concreto y nosotros obtenemos feedback para seguir iterando sobre nuestro framework.

Esta forma de transmitir conocimiento a través de la práctica ha conseguido resultados que ninguna formación descendente habría podido alcanzar, porque la competencia se integra en el trabajo cotidiano del desarrollador, aplicada a sus problemas reales. Es algo que también tenemos previsto hacer más adelante con los PM: el mismo principio de acompañamiento aplicado a una discovery potenciada por agentes.

El Product Builder funciona en proyectos reales, con clientes reales, en productos reales. Ya no es una proyección: hay consultores que trabajan así a diario. Pero la versión que produce resultados se parece poco a la narrativa habitual del PM aumentado que hace vibe coding entre dos sprints. Abarca las herramientas, las metodologías, las fuentes de verdad y los mecanismos de equipo.

Lo que esta misión me ha confirmado es que un Product Builder con un buen sistema operativo no basta. El sistema operativo estructura la ejecución individual y dota al Product Builder de su capacidad de actuar. Pero cada punto abordado en este artículo remite a cuestiones que trascienden al individuo: ¿dónde reside la fuente de verdad y quién decide sobre ella? ¿Cómo se transmite el craft de un consultor al resto del equipo? ¿Qué configuración de equipo necesitamos para cada nivel de criticidad?

Estas cuestiones forman parte de lo que en Thiga denominamos el Modelo Operativo de Producto (POM) adaptado a la IA. El POM-IA es el marco organizativo que articula el sistema operativo (OS) del Product Builder, la plataforma que garantiza el camino hacia la producción y las normas colectivas que permiten que varios Product Builders operen en paralelo sin que la autonomía derive en caos. Este marco debe abarcar todo el ciclo de desarrollo del producto y debe ser específico para el contexto de cada organización. Los componentes ya existen. Ensamblarlos proyecto a proyecto, organización a organización, es probablemente la parte más interesante del trabajo que queda por hacer.