El Product Manager ha muerto. Larga vida al Product Developer.

11 min de lectura

La especialización fue un parche, no una estrategia

Así funcionaba el viejo mundo. Una “persona de negocio” tenía una idea. Escribía un documento. Tal vez dibujaba mockups. Entregaba ese documento al “equipo técnico” y decía: construyan esto. Después esperaba. Semanas después llegaba algo. Equivocado, generalmente. Entonces escribía un documento más largo con más detalle. El equipo técnico construía eso también. También equivocado. Repetir hasta que el presupuesto se agote o todos se rindan.

Este flujo de trabajo creó familias enteras de roles. Product Managers que “son dueños del backlog.” Analistas de Negocio que “recopilan requerimientos.” Expertos en el Dominio que “conocen el negocio.” Diseñadores UX que “entienden a los usuarios.” Todos alimentando instrucciones a desarrolladores que aparentemente eran demasiado torpes para entender algo más allá de la sintaxis.

Esa línea de ensamblaje tenía sentido cuando convertir intención en software funcionando requería meses de escritura de código. La traducción era cara. Se necesitaban especialistas en cada punto de transferencia porque cada transferencia perdía información y alguien tenía que detectar la pérdida.

La IA eliminó los costos de traducción. Y con ellos, la justificación de la mayoría de esas transferencias.

Se acabó la entrega de mockups

Imagina al Product Manager clásico. Pasa tres semanas hablando con stakeholders, destilando requerimientos, armando un backlog en Jira, creando mockups en Figma, escribiendo criterios de aceptación. Agenda una reunión de “refinamiento”. Presenta los mockups al equipo. El equipo hace preguntas. El PM vuelve con los stakeholders por respuestas. Regresa el siguiente sprint. El ciclo se repite.

Toda la propuesta de valor de esa persona era ser el traductor entre “negocio” y “tecnología”. Existía porque los desarrolladores no podían darse el lujo de dedicar tiempo a entender el dominio. Cada hora que un desarrollador pasaba hablando con usuarios era una hora menos escribiendo código. Y escribir código era el cuello de botella.

Escribir código ya no es el cuello de botella.

Cuando un desarrollador puede describir un sistema a una IA y tener código funcionando en horas en vez de semanas, la economía se invierte. El cuello de botella ahora es entender el problema. Y el Product Manager nunca fue quien entendió el problema más profundamente. Los usuarios lo entendían. Los desarrolladores, una vez que hablaban con los usuarios, lo entendían suficientemente rápido.

La capa de traducción se convierte en lastre.

Expertos funcionales sin responsabilidad sobre el resultado

Los expertos funcionales tenían un arreglo similar. Conocían las reglas de negocio, las restricciones regulatorias, los casos especiales. Se sentaban en reuniones y explicaban cosas. Los desarrolladores tomaban notas. La mayor parte de los matices se perdía porque pasaba por dos o tres personas antes de llegar al código.

El experto que nunca entrega código tiene un problema fundamental: no tiene ciclo de retroalimentación. Describe lo que debería pasar, otra persona lo construye, y para cuando la brecha entre intención e implementación se hace visible, pasaron seis semanas y nadie recuerda la conversación original.

Un desarrollador que entiende el dominio no tiene ese problema. Escucha la regla de negocio, la codifica, la prueba, la entrega. El mismo día. El ciclo de retroalimentación dura horas, no meses.

“¡Pero los desarrolladores no pueden entender dominios de negocio complejos!” Esto lo escucho de gente que nunca lo intentó. Un desarrollador de software competente que pasa dos semanas inmerso en un dominio lo entiende lo suficiente para construir el software. No lo suficiente para dirigir el negocio. Pero sí para construir el software. Esa es la vara. Y la IA acelera la inmersión porque el desarrollador puede hacer preguntas, modelar escenarios y prototipar soluciones en tiempo real en vez de coordinar reuniones.

La integración vertical gana

El viejo modelo era especialización horizontal. Una persona conoce a los usuarios. Otra conoce el dominio. Otra diseña la interfaz. Otra escribe el backend. Otra maneja la infraestructura. Cinco personas, cinco transferencias, cinco oportunidades para perder información.

El nuevo modelo es integración vertical. Una persona (o un par compenetrado) que entiende el problema del usuario, diseña la solución, construye el sistema, lo prueba, lo despliega y lo monitorea en producción. No porque sea sobrehumana. Porque la IA se encarga de las partes que antes requerían especialistas separados por razones mecánicas. Porque el desarrollo de software es diseño, no línea de ensamblaje.

SpaceX lo descubrió con los cohetes. Cuando integras verticalmente, eliminas demoras en las transferencias y pérdida de información. La persona que toma la decisión de diseño es la persona que ve las consecuencias.

Este es el Software Product Developer en forma de T. Experiencia profunda en diseño de sistemas y disciplina de desarrollo. Conocimiento suficientemente amplio para hablar con usuarios, entender restricciones regulatorias, diseñar interfaces, gestionar infraestructura. La IA llena los vacíos. No necesitas memorizar configuraciones YAML de Kubernetes. Necesitas entender por qué tu estrategia de despliegue importa y dejar que la IA escriba los manifiestos.

Qué desaparece

Siendo concretos.

El Product Manager que escribe elementos de trabajo. Si tu contribución es traducir deseos de stakeholders en historias de Jira, la IA lo hace más rápido y con menos pérdida de información. El desarrollador habla directamente con el stakeholder, esboza la solución con asistencia de IA y la entrega. Tu rol de intermediario desapareció.

El Analista de Negocio que documenta requerimientos. Los documentos de requerimientos siempre fueron un pobre sustituto de la conversación. Ahora la conversación ocurre en tiempo real entre la persona que tiene el problema y la persona que entrega la solución. El documento no necesita existir.

El Diseñador UX que entrega mockups. Un desarrollador con IA puede prototipar una interfaz en minutos, mostrarla a usuarios, iterar en tiempo real. La “entrega de diseño” era una ceremonia de un mundo donde construir un prototipo era caro. Ya no lo es.

El Experto Funcional que solo asesora. Conocimiento del dominio sin autoridad de implementación es consultoría. El Product Developer absorbe suficiente conocimiento funcional para construir lo correcto y valida con los usuarios reales del dominio.

El Scrum Master que facilita. Cuando un equipo de dos o tres Product Developers entrega diariamente, no hay nada que facilitar. No hay Sprint Planning porque no hay sprints. No hay retrospectivas porque la retroalimentación es continua. No hay standups porque el equipo es lo suficientemente pequeño para simplemente hablar. Como el ciclo de vida de los frameworks nos mostró, estos roles fueron productos de la industria de frameworks. Los equipos pequeños que entregan sin ceremonias siempre superaron a los departamentos cargados de procesos.

Qué sobrevive

No el Product Manager. Las actividades.

Hablar con usuarios, entender dinámicas de mercado, evaluar si el software resuelve problemas reales. Esas cosas no desaparecen. Se convierten en lo que hace cada desarrollador del equipo. No queda nadie para “gestionar” el producto porque no hay nada que gestionar. Hay decisiones que tomar, y las personas que las toman son las mismas que escriben el código.

Eric Ries lo entendió bien hace quince años con Lean Startup. Construir-medir-aprender. Entregar algo pequeño. Observar qué hacen realmente los usuarios. Ajustar. Entregar de nuevo. El problema nunca fue la idea. El problema era que “construir” tomaba seis meses y requería una carrera de relevos de 40 personas desde el PM al BA al diseñador al desarrollador al QA a operaciones. Así que “medir” llegaba demasiado tarde y “aprender” quedaba enterrado bajo el backlog del siguiente sprint.

La IA redujo “construir” a horas. Ahora construir-medir-aprender se ejecuta diariamente. Un Product Developer entrega una funcionalidad por la mañana, observa los datos de uso por la tarde y decide por la noche si iterar, expandir o descartar. Sin comité de roadmap. Sin teatro trimestral de priorización. Solo un ciclo ajustado entre código y realidad.

¿El experto funcional que puede sentarse con un desarrollador y responder preguntas en tiempo real mientras este construye? Esencial. Pero integrado, no en su propio departamento. No escribe documentos. Demuestra flujos de trabajo, explica casos especiales, valida comportamiento. El desarrollador codifica lo que aprende inmediatamente.

¿Y los diseñadores? En teoría, alguien que pueda prototipar, probar con usuarios e iterar el mismo día es valioso. En la práctica, la mayoría de los diseñadores no darán ese salto. Se niegan a aprender CSS. Se aferran a Figma y entregan mockups perfectos en píxeles de cosas que no funcionan en un navegador. Tratan la web como un lienzo en vez de un medio con sus propias restricciones. Esa terquedad es una decisión que termina carreras. Un Product Developer con buen gusto, sentido de la usabilidad y una IA generando variaciones de diseño en segundos producirá mejores resultados que un diseñador que dibuja imágenes y las lanza por encima del muro. El buen sentido de UX no es un don raro. Es una habilidad que los desarrolladores curiosos aprenden rápido, sobre todo cuando la IA se encarga de la experimentación visual.

El hilo conductor: todos los que sobreviven trabajan dentro del ciclo de desarrollo de producto, no al lado. Y la “gestión de producto” se disuelve de un rol a una disciplina compartida. Cada desarrollador del equipo habla con usuarios. Cada desarrollador lee métricas de producción. Cada desarrollador toma decisiones de producto. Eso no es caos. Es construir-medir-aprender sin intermediario.

El Product Developer en forma de T

Este perfil reemplaza cinco roles separados.

Habilidades profundas: Arquitectura de sistemas. Estrategia de pruebas. Despliegue y observabilidad. Fundamentos de seguridad. La capacidad de leer código, razonar sobre modos de fallo y verificar que la salida de la IA realmente funciona. No negociable. El fin de la programación no significó el fin del desarrollo. Significó el fin de la escritura mecánica. Y llamemos las cosas por su nombre: desarrollo, no ingeniería. Los ingenieros aplican reglas establecidas. Un ingeniero civil sigue códigos de construcción. Un desarrollador de software crea algo que no existía antes, toma decisiones bajo incertidumbre y asume responsabilidad por resultados que nadie puede predecir desde una especificación. Eso es desarrollo. La palabra importa.

Habilidades amplias: Comprensión del dominio. Empatía con el usuario. Sentido básico de diseño. Comunicación con stakeholders. Conciencia regulatoria donde sea relevante. Comprensión del modelo de negocio. No se necesita un MBA. Se necesita suficiente alfabetización de negocio para saber si lo que estás construyendo importa.

Habilidades aumentadas por IA: Configuración de infraestructura. Prototipado de interfaces. Análisis de datos. Documentación. Generación de código repetitivo. Armado de pruebas. Todo lo que antes requería un especialista por complejidad mecánica, no conceptual.

Los humanos deciden qué construir, cómo estructurarlo, si funciona. La IA produce el código, las pruebas, la documentación, la configuración. El juicio queda en el humano. El volumen va a la máquina.

Por qué las organizaciones se resisten

Porque amenaza cantidades de personal, presupuestos y territorios.

Un VP de Producto con 15 Product Managers no va a ofrecerse voluntariamente a decir que 12 de esos roles podrían absorberse en equipos de desarrollo. Un Jefe de Análisis de Negocio con 8 analistas no va a sugerir disolver el departamento. Una Dirección de UX con un equipo de 20 diseñadores no va a admitir que 15 de ellos hacen trabajo que la IA más un Product Developer manejan mejor.

Las organizaciones optimizan la eficiencia a través de la especialización. Ese es el modelo de fábrica. Funciona cuando la restricción es el rendimiento de producción. Falla cuando la restricción es la comprensión y la toma de decisiones.

Construir productos en la era de la IA requiere equipos pequeños que se muevan rápido y decidan bien. Cada persona en la sala debería ser capaz de entregar. Si el trabajo de alguien es solo describir qué se debe construir sin ninguna capacidad para construirlo, esa persona es un cuello de botella, no un habilitador.

La verdad incómoda

Esto no es una predicción. Ya está pasando en cada empresa donde los desarrolladores usan GitHub Copilot, Claude Code o herramientas similares en serio.

Un desarrollador que usa bien la IA puede absorber trabajo que antes requería tres o cuatro roles de apoyo. No porque esos roles fueran innecesarios en el viejo modelo. Eran necesarios. La traducción era genuinamente difícil. Las transferencias eran genuinamente caras. La especialización era genuinamente eficiente cuando escribir código era el cuello de botella. Y no, la IA no reemplaza al desarrollador. Lo intentamos cada década desde 1969. Fracasa cada vez.

Pero el cuello de botella se movió. La IA se convirtió en un compañero de pensamiento, no solo un asistente de escritura. El desarrollador que la usa bien no solo programa más rápido. Entiende más rápido. Prototipa más rápido. Valida más rápido. Entrega más rápido.

La pregunta no es si esta transición ocurre. Es si tu organización se adapta o queda superada por un equipo de tres personas que entrega más valor en una semana que tu departamento de 40 personas en un trimestre.

Cómo llegar

Deja de contratar para roles de transferencia. Empieza a contratar para roles de integración.

Deja de preguntar “¿quién escribe los requerimientos?” Empieza a preguntar “¿quién entiende el problema lo suficiente para entregar la solución?”

Deja de separar “negocio” y “técnico.” El Product Developer es ambos.

Invierte en desarrolladores curiosos sobre dominios funcionales, no solo sobre tecnología. Invierte en expertos funcionales dispuestos a trabajar junto a desarrolladores, no solo a escribir documentos. Invierte en diseñadores que prototipan con código, no solo con Figma.

Termina con la línea de ensamblaje. Construye equipos integrados. Entrega a diario. Mide resultados. Todo lo demás es lastre.

El Product Manager ha muerto. Larga vida al Product Developer.