Product Manager de Tecnología e Innovación

Visión del rol

El Product Manager de Tecnología e Innovación es un arquitecto de soluciones con enfoque 100% de negocio. Forma parte del área de tecnología o sistemas; lo que lo distingue es que trabaja desde el negocio y el proceso, no desde el requerimiento técnico. Entiende un proceso desde el lugar donde ocurre, descubre qué aporta valor y qué es desperdicio, y diseña la solución que las unidades agénticas y el equipo técnico construyen.

Su trabajo no termina cuando la solución se entrega. Termina cuando se comprueba que la hipótesis de valor se cumplió en el proceso real.

En una frase: va al Gemba, descubre el valor, diseña la solución, orquesta la construcción y valida el resultado.

La IA desdibuja las fronteras

Antes de la IA, cada perfil del área de tecnología cubría una parte del camino entre el problema y la solución: uno analizaba, otro diseñaba, otro construía, otro probaba y otro implementaba. Las fronteras entre ellos eran fijas porque cada parte exigía mucho tiempo y una especialidad.

Con la IA y las unidades agénticas, construir soluciones tecnológicas de negocio es cada vez más rápido y eficiente, ya sea software, automatizaciones, agentes, robots o cobots. Eso cambia dos cosas:

• Cada persona puede cubrir más del camino. Un gerente de proyecto con agentes puede prototipar como un desarrollador. Un desarrollador con IA puede ir al Gemba, analizar el proceso y decidir qué construir. Nadie está obligado a cruzar su frontera, pero ya se puede.
• El valor se mueve hacia los extremos del camino: entender el proceso, decidir qué construir y comprobar que funcionó. Construir deja de ser la parte más escasa.

Este rol es el punto donde convergen esas trayectorias. Por eso se entiende mejor con una distinción:

Así, el rol es a la vez una ruta de carrera para quien quiera evolucionar hacia él y un rediseño gradual del área, que ocurre conforme la IA amplía a cada persona, no por una reorganización impuesta.

Perfiles de origen

Este rol no aparece de la nada. Es la evolución de perfiles que ya existen en el área de tecnología. Todos llegan al mismo rol con distinto punto de partida: cada uno trae una fortaleza y tiene algo que aprender.

Ninguno llega completo: cada uno trae una parte y la formación cubre el resto. Qué acredita, qué refuerza y qué tiene que desaprender cada perfil: Ruta de formación por perfil de origen.

Este documento es la referencia para definir el rol, seleccionar a quien lo ocupe y entrenarlo.

Por qué existe este rol

Este rol cubre un hueco concreto: nadie es dueño del "qué" y del "por qué" de una solución, de principio a fin. Hoy las solicitudes llegan de las direcciones como peticiones de sistema. Tecnología las construye y se mide por entregar. Nadie verifica si el proceso mejoró.

Con IA y unidades agénticas, construir soluciones tecnológicas de negocio es cada vez más rápido y eficiente: software, automatizaciones, agentes, robots o cobots. La restricción ya no es la capacidad de desarrollo. Es decidir bien qué construir y sobre qué proceso.

El rol combina tres perfiles conocidos, pero no es ninguno de ellos por separado:

Tampoco es Project Manager (administrador del proyecto). El Project Manager responde cómo y cuándo se entrega. Este rol responde qué se construye, para qué, y si funcionó.

Principios rectores

1. El Gemba antes que la solicitud. Ninguna solución se diseña desde la petición de un área. Se diseña después de observar el proceso donde ocurre, con las personas que lo ejecutan.
2. El valor se descubre, no se define. Nadie decide por decreto qué es valor. Se descubre en el Gemba, observando qué transforma el resultado que recibe el cliente del proceso. Ese cliente puede ser externo (el asegurado de una póliza, el comprador de una pieza manufacturada, el cliente de una tienda) o interno (otra área); ver Cliente. La prueba para reconocerlo: ¿el cliente externo pagaría por este paso? Después se acuerda con el dueño del proceso y queda registrado en la hipótesis. Todo lo demás es desperdicio o soporte necesario.
3. Primero eliminar, después automatizar. Automatizar un paso que no aporta valor solo produce desperdicio más rápido. El orden es eliminar, simplificar, estandarizar y luego automatizar.
4. Toda solución es una hipótesis. Cada iniciativa declara qué indicador del proceso va a cambiar, cuánto y en qué plazo. Si no se puede medir, no está lista para construirse.
5. Entregar no es terminar. El ciclo cierra cuando la hipótesis se valida o se descarta con datos del proceso real.
6. Negocio primero, tecnología como medio. El rol decide desde el proceso y el resultado. La tecnología se elige por lo que habilita, no por novedad. Automatizar o digitalizar no es valor en sí mismo: es un medio.
7. El usuario es actor del proceso, no destinatario. Quien ejecuta o recibe el proceso participa antes, durante y después del diseño: informa, valida, prueba y retroalimenta. Ver El usuario como actor del proceso.
8. Humano en el ciclo. Toda unidad agéntica que ejecuta o decide tiene un punto definido de supervisión humana y un responsable con nombre.

Qué identifica en todo proceso

En cada Gemba, el rol identifica cinco elementos. Ver Elementos del proceso.

Los desperdicios que busca en el Gemba

El rol usa los ocho desperdicios de Lean (Muda), traducidos a procesos administrativos y digitales. Ver Los 8 desperdicios en procesos administrativos.

Responsabilidades y autoridad

El rol tiene cinco responsabilidades, cada una con una autoridad explícita. Sin la autoridad, la responsabilidad no se puede cumplir.

Qué controla y qué no

El rol necesita control para cumplir su responsabilidad. Controla el valor y el alcance. El plan lo controla el administrador del proyecto.

Tiempo fijo, alcance variable

Antes de construir, el rol decide con el dueño del proceso cuánto tiempo vale el problema. Ese tiempo es fijo. Si lo planeado no cabe, se recorta alcance empezando por lo que menos mueve el indicador. No se alarga la fecha por inercia. Ver Tiempo fijo, alcance variable.

Control de cambios de alcance

Todo cambio de alcance pasa por el mismo camino y queda en el Registro de cambios de alcance:

1. Se registra: qué se pide, quién lo pide y por qué.
2. Filtro de valor: ¿mueve el indicador de la línea base hacia la meta? Si no, no entra o se abre como iniciativa nueva.
3. Impacto en el plan: el administrador del proyecto evalúa qué le hace a tiempos y recursos.
4. Decisión: el Product Manager decide el alcance. Si hay que mover la fecha, lo aprueba el sponsor.
5. Se comunica a los involucrados.

Ver El Product Manager como Product Owner.

Las compuertas son sus hitos

El rol no controla avance por porcentaje de tareas. Controla por compuertas: seis puntos del ciclo donde otra persona confirma un entregable verificable. No se avanza sin él. Ver Compuertas.

Cuando el dueño del proceso no acepta el estado futuro

Dos reglas: el dueño del proceso decide sobre su proceso; el Product Manager decide qué se construye. Puede negarse a automatizar un estado futuro que conserva el desperdicio. El desacuerdo se resuelve con evidencia, en tres escalones con plazo acordado:

1. Volver juntos al Gemba con los datos del análisis.
2. Piloto acotado a tiempo fijo, planteado como hipótesis de valor: se prueba y se mide.
3. Decide el sponsor, con la iniciativa resumida en un A3.

Lo que no le corresponde

• Administrar cronograma, recursos y presupuesto del proyecto. Eso es del administrador del proyecto.
• Mover fechas. Lo deciden el administrador del proyecto y el sponsor.
• Ejecutar la puesta en producción, la capacitación y el soporte inicial. Eso es del encargado de implementación.
• Definir la arquitectura técnica detallada o escribir el código. Eso es de desarrollo y de las unidades agénticas.
• Revisar técnicamente lo que construyen agentes y desarrolladores. Eso es de desarrollo.
• Priorizar entre iniciativas. Es una decisión de portafolio de la dirección de tecnología.
• Ser dueño del proceso de negocio. El dueño del proceso sigue siendo la dirección responsable; este rol lo transforma con ella.

Ciclo de trabajo

Cada iniciativa recorre nueve etapas en tres bloques: entender el proceso (1–3), limpiarlo y comprometer un resultado (4–6), e innovar, construir y validar (7–9). La tecnología entra en la etapa 7, nunca antes.

Diagrama del ciclo

Las nueve etapas se leen de arriba hacia abajo. Cada flecha marcada con C es una compuerta: no se avanza sin que otra persona confirme. En la etapa 7 es donde se innova y donde entra la tecnología.

Detalle de cada compuerta: Compuertas.

Qué hace el rol en cada etapa

Compuertas

No toda etapa tiene compuerta formal. Hay compuerta donde otra persona tiene que confirmar el avance. En las demás etapas, el rol verifica su propia salida con el criterio de cierre del módulo correspondiente.

La hipótesis sigue siempre la misma forma:

Si eliminamos [desperdicio] y construimos [solución], el indicador [X] pasará de [línea base] a [meta] en [plazo], medido con [fuente de datos].

El principio 3 aplica aquí: muchas iniciativas se resuelven en la etapa 5, con un cambio de proceso y sin construir nada. Aun así pasan por la hipótesis y la validación: saltan de la etapa 6 a la 9.

Tres dimensiones del diseño

Toda solución se evalúa en tres dimensiones. El valor es el eje: una solución fácil de usar y fácil de construir que no mueve el indicador no se construye.

La pregunta que guía el diseño: ¿cuál es la solución más simple que mueve el indicador?

Tres tipos de métricas en una iniciativa

Ver Indicador.

El usuario como actor del proceso

El usuario participa en todo el ciclo, no solo al final. Así se evita diseñar desde supuestos internos o decisiones jerárquicas sin evidencia.

Relación con otros roles

El Product Manager decide qué y por qué; los demás roles deciden cómo y cuándo, cada uno en su terreno.

Matriz RACI

R = responsable de ejecutar, A = aprueba y rinde cuentas, C = consultado, I = informado.

Mover fecha: aprueba el sponsor de la iniciativa. Estado futuro: el Product Manager lo propone con lo descubierto en el Gemba y el dueño del proceso lo acuerda.

Funciones que no se combinan

La matriz RACI asigna funciones, no personas. Con IA, una misma persona puede cubrir varias funciones, y eso está bien. Pero algunas funciones sirven de control de otras y no se juntan en la misma persona dentro de una misma iniciativa:

Cómo se orquestan las unidades agénticas

El Product Manager no programa agentes, pero sí define su trabajo. Por cada unidad agéntica que participe en la solución especifica tres cosas:

• Qué tarea del proceso ejecuta o qué parte de la solución construye.
• Con qué información y con qué límites opera. Las políticas del proceso se trasladan a esos límites.
• Quién revisa su resultado y en qué punto interviene una persona.

Competencias requeridas

El perfil es de negocio con fluidez técnica, no un técnico que aprende negocio. Las competencias se agrupan en seis dominios, con el nivel esperado al terminar el entrenamiento.

Competencias de liderazgo

• Decir que no a una solicitud y explicar por qué desde el valor.
• Sostener el alcance frente a la presión y controlar sus cambios.
• Identificar involucrados y anticipar la resistencia al cambio.
• Facilitar sesiones con operación y con dirección, en el lenguaje de cada una.
• Negociar el estado futuro con dueños de proceso que no reportan a él.
• Tomar decisiones con información incompleta y corregirlas con datos.
• Liderar por influencia, no por posición: como el value stream manager de Lean o el chief engineer de Toyota, no manda a la gente; convence con el flujo, los datos y el Gemba.
• Crear confianza para que la gente proponga, muestre sus atajos y reporte errores: preguntar más de lo que ordena y tratar el error honesto como aprendizaje, no como falta (Seguridad psicológica).

Métricas de éxito del rol

El rol se mide por el valor validado en los procesos, no por el número de entregas. Las metas numéricas se fijan después de medir la primera línea base.

Una hipótesis descartada con datos no cuenta como fracaso del rol. Un fracaso es construir algo que nadie mide.

Artefactos que produce

Cada etapa del ciclo deja al menos un artefacto. En conjunto forman el expediente de la iniciativa.

Ruta de formación

La formación se aprende haciendo: cada fase termina con una iniciativa real, no con un examen. La duración es una propuesta que se ajusta según el perfil de la persona.

Las fases marcan el orden; los módulos de capacitación son el contenido:

Design Thinking no es un módulo aparte: cada módulo trabaja su parte (empatizar en 2–3, definir en 4–6, idear y prototipar en 7, evaluar en 9).

Cada persona adapta la ruta a su punto de partida: acredita lo que ya domina y refuerza lo que le falta. Después evoluciona en el rol en tres niveles: acompañado, supervisado y autónomo. Pasa a autónomo quien lleva una segunda iniciativa de forma autónoma y presenta su reporte de validación ante dirección. Diagnóstico de entrada, ficha por perfil y criterios de formación: Ruta de formación por perfil de origen.

Riesgos y decisiones abiertas

Se decide al poner en marcha el rol

No se resuelven mientras se diseña el rol. Se definen con la primera persona en el puesto y la primera iniciativa. Esta tabla sirve como guía para esa decisión:

Referencias: PMI (gobierno de portafolio), Lean Enterprise Institute (value stream manager, hoshin kanri), RAPID de Bain (un solo decisor por decisión).

Relacionado

• Metodología de transformación de procesos
• Cómo conducir un Gemba
• El Product Manager como Product Owner
• Design Thinking para el Product Manager
• Elementos del proceso
• El usuario como actor del proceso
• MOC Product Manager