El terremoto organizativo: cómo el Product Builder redefine los roles de PM, desarrollador y diseñador
Erik Perrier, Senior Manager y Head of Product en Converteo, acompaña a las direcciones de producto y tecnología en su transformación en la era de la inteligencia artificial. Especialista en el diseño de soluciones agénticas y en la industrialización de los métodos de desarrollo, impulsa el desarrollo de competencias de los equipos para que evolucionen hacia el rol de Product Builder.
Puntos clave
- Invertir la lógica del cuello de botella: deja de intentar resolver únicamente la falta de capacidad de desarrollo. La abundancia de código generado por IA desplaza la principal limitación hacia la definición del problema y la alineación estratégica. Refuerza el tiempo dedicado al descubrimiento de las necesidades de los usuarios.
- Reorientar al desarrollador hacia la robustez: no pidas a los ingenieros que escriban todo el código desde cero. Delega el prototipado rápido en los perfiles de producto y centra a los equipos técnicos en la arquitectura, la seguridad y la industrialización a escala.
- Clarificar las responsabilidades para evitar tensiones: no impongas una evolución forzada de las competencias que genere estrés latente entre los colaboradores. Diferencia las trayectorias profesionales de los perfiles orientados al desarrollo técnico y las de los especialistas en investigación de usuarios.
El cuello de botella se desplaza de la ingeniería al producto
Durante años, el modelo organizativo dominante situaba a la ingeniería en el centro de las limitaciones de velocidad. La estructura clásica asociaba un Product Manager (PM) con varios desarrolladores, que a menudo veían ralentizado su trabajo por la deuda técnica y eran incapaces de seguir el ritmo de las ideas surgidas durante la fase de descubrimiento de producto (discovery).
La aparición de las herramientas de generación de código y de la práctica del vibe coding ha invertido por completo esta relación de fuerzas. Los desarrolladores han multiplicado su velocidad a la hora de producir componentes de aplicaciones. Ahora, la cuestión estratégica ya no consiste en saber si la empresa dispone de capacidad técnica para probar una funcionalidad, sino en determinar con precisión qué hipótesis merece la pena validar.
ANTES (Ingeniería bajo presión):
HOY (Producto bajo presión):
La capacidad para producir artefactos funcionales se ha acelerado, por lo que la escasez se ha desplazado hacia la calidad de la definición del problema, la priorización y la alineación de las partes interesadas. Antes, el tiempo necesario para el desarrollo permitía afinar la visión de producto sobre la marcha. Como ese margen temporal se ha reducido, los responsables de producto deben reservar tiempo para la investigación y la alineación con la dirección, evitando así desarrollar muy rápidamente funcionalidades que nadie necesita.
La recomposición de los tres pilares profesionales del producto
El aumento de la capacidad de desarrollo está reorganizando las responsabilidades cotidianas de la gestión de producto, la ingeniería de software y el diseño de interfaces.
-
1. El Product Manager: del pliego de requisitos al papel de orquestador
El rol del Product Manager evoluciona para incorporar la capacidad de llevar una idea hasta un prototipo funcional que pueda probarse en condiciones reales. Ya no se limita a redactar especificaciones textuales o crear maquetas estáticas, sino que entrega artefactos conectados directamente a datos o interfaces de prueba.
Sin embargo, el valor fundamental del PM no reside en el simple dominio de las herramientas de generación de código. La capacidad de construir prototipos se está convirtiendo en una competencia cada vez más accesible. El verdadero valor añadido se desplaza hacia el criterio de producto: comprender en profundidad un sector de actividad, dominar los procesos de negocio de los usuarios y saber seleccionar los problemas que realmente merece la pena resolver.
Ámbito de responsabilidad del Product Manager:
-
2. El desarrollador: de escribir código a diseñar la arquitectura del sistema
La idea de que las herramientas de IA sustituirán a los ingenieros no se corresponde con la realidad sobre el terreno. El desarrollador no desaparece: cambia la naturaleza de sus intervenciones. Al delegar parte de la escritura inicial del código y del prototipado rápido en los perfiles de producto, el ingeniero se libera de tareas de ejecución repetitivas.
Su función se centra ahora en los retos más complejos: diseñar arquitecturas robustas, gestionar la deuda técnica, proteger los flujos de datos y escalar las soluciones (scaling). Se convierte en el garante de los estándares de ingeniería y define las reglas de desarrollo dentro de las cuales los perfiles híbridos pueden crear prototipos de forma segura.
3. El diseñador: de la ejecución gráfica al diseño del comportamiento
Al automatizar las tareas de ejecución visual —como ajustar componentes en herramientas de diseño o implementar sistemas de diseño—, la IA libera tiempo para los diseñadores de interfaces (UI) y de experiencia de usuario (UX).
El diseñador reorienta su trabajo hacia la exploración profunda de los usos y la investigación de usuarios. En un contexto en el que las interfaces conversacionales y los agentes autónomos adquieren protagonismo, la profesión evoluciona desde la creación de pantallas visuales hacia el diseño del comportamiento de los agentes, con el objetivo de orquestar cómo interactúa el sistema con el usuario mediante el lenguaje natural.
| Rol | Ámbito tradicional | Nuevo enfoque estratégico |
|---|---|---|
| Product Manager | Redacción de especificaciones, wireframes y coordinación | Definición de necesidades de negocio, orquestación de iniciativas y prototipado rápido |
| Desarrollador | Escritura manual de todo el código y entrega | Arquitectura del sistema, seguridad, integración a escala y gobernanza |
| Diseñador | Ejecución gráfica, adaptación de pantallas y sistemas de diseño | Investigación de usuarios, comprensión de los usos y diseño del comportamiento |
La expansión de la capacidad de desarrollo más allá del equipo de producto
En las organizaciones se observa un fenómeno importante: la capacidad de diseñar prototipos funcionales ya no se limita a los equipos de producto y tecnología. En las áreas comerciales, de marketing, operaciones o atención al cliente, profesionales sin formación informática están creando sus propias herramientas para resolver problemas operativos.
Esta autonomía aporta una gran capacidad de respuesta a los equipos de negocio, pero también genera desorden organizativo. Cuando varios departamentos desarrollan simultáneamente sus propias soluciones —por ejemplo, cuando los equipos de comercio electrónico, logística y atención al cliente crean agentes conversacionales en paralelo—, la propiedad del producto y la coherencia de la experiencia global se difuminan.
El papel del equipo de producto se transforma entonces para incorporar funciones de arbitraje y orquestación. El Product Manager debe:
- Analizar los prototipos desarrollados espontáneamente por los equipos de negocio.
- Evaluar su alineación con la estrategia global de la empresa.
- Filtrar e integrar las mejores iniciativas en el sistema de información principal.
- Rechazar la mayoría de los proyectos paralelos para preservar la coherencia del ecosistema de aplicaciones.
Gestionar la tensión entre la velocidad del prototipado y la robustez técnica
La aparición de prototipos generados por perfiles que no son desarrolladores suele despertar reticencias entre los ingenieros de software. Las críticas se centran principalmente en la calidad del código generado por IA, que a menudo se considera frágil, mal estructurado y propenso a generar deuda técnica a largo plazo.
Esta tensión refleja un choque legítimo entre dos culturas: la exigencia de rapidez para validar una necesidad y la exigencia de estabilidad para mantener un sistema de información.
Proceso de transferencia recomendado:
Fase de Validación
Prototipado y Uso
→
Fase de Industrialización
Seguridad y Escalabilidad
Para resolver este punto de fricción, la organización debe establecer un protocolo de transferencia claro:
- El prototipo como herramienta de definición: el código generado por IA durante las pruebas sirve únicamente para validar el uso empresarial y la experiencia de usuario. Está concebido para desecharse o reestructurarse.
- Un entorno de pruebas aislado (sandbox): el departamento de TI proporciona un entorno técnico seguro que permite probar prototipos conectados a datos ficticios o aislados, sin poner en riesgo los sistemas de producción.
- Una revisión de arquitectura: una sesión formal de transferencia sustituye a los rituales tradicionales de redacción de especificaciones. El prototipo se presenta a los ingenieros, que deciden si debe industrializarse y reescriben el código de acuerdo con los estándares de la empresa.
Acompañar a las personas y evitar el riesgo de culpabilización
La rápida evolución de los métodos de trabajo genera un riesgo sociológico dentro de los equipos. La posibilidad técnica de producir más deprisa puede convertirse en una exigencia implícita de dominar todas las herramientas, provocando un estrés latente entre los colaboradores que temen que su perfil profesional quede obsoleto.
El reto de la dirección consiste en evitar que el dominio de las herramientas de desarrollo se convierta en un criterio de evaluación que genere culpabilidad. No todas las personas de un equipo de producto tienen que convertirse en perfiles técnicos híbridos.
Las organizaciones más eficaces adoptan una gestión diferenciada de las competencias:
- Perfiles Builder: orientados al prototipado rápido, el uso de API y la experimentación técnica.
- Perfiles Discovery y Strategy: especialistas en investigación de usuarios, análisis de negocio, coordinación estratégica y gestión del cambio.
Ambos perfiles son estrictamente complementarios. Reafirmar el valor del análisis del comportamiento y de la investigación de usuarios permite tranquilizar a los equipos y construir una organización equilibrada.
