El vicepresidente de Producto de Amex afirma que la IA debe integrarse gradualmente en las organizaciones de producto: saltarse una sola capa te saldrá caro

Abishek (Abhi) Gandotra comenzó su carrera como ingeniero, pero pasó a trabajar en producto, llevándose consigo sus conocimientos técnicos. Actualmente es vicepresidente de Producto en American Express. También es el autor de El agente soberano.

Se reunió con nosotros para compartir lo que está aprendiendo mientras la IA difumina aún más las líneas entre la ingeniería y el producto. Esto es lo que nos contó.

De la ingeniería al producto

Soy Abhi Gandotra y dirijo la organización de producto de la plataforma bancaria en American Express. Comencé como ingeniero y pasé la primera década de mi carrera escribiendo código. Por eso, nunca he tratado la tecnología como una caja negra. Cuando algo no llega a producción, quiero saber por qué, en la capa en la que se produce el fallo.

Pasé a trabajar en producto porque me importaba menos construir las cosas correctamente y más construir las cosas adecuadas. En Green Dot, pasé más de una década desarrollando una plataforma de banca como servicio: la llevamos de una idea a superar los 1.000 millones de dólares en ingresos B2B entre más de 80 socios empresariales. Eso me enseñó algo que sigo creyendo: las plataformas triunfan cuando facilitan los problemas difíciles de otras personas. Ahora, en Amex, hago lo mismo con la infraestructura bancaria y de pagos, a una escala diferente y con el nivel normativo que ello conlleva.

Para mí, el momento de la IA no es solo publicidad. Ahora mismo estoy desarrollando productos con estas herramientas: creando agentes, poniendo en marcha un programa de formación en IA para toda mi organización y dirigiendo pequeños equipos que pasan de la idea al software funcional en cuestión de días. Mis instintos de ingeniero han vuelto por completo. La distancia entre «tengo una idea» y «está funcionando» nunca había sido tan corta. Esa es la parte que me entusiasma: no la publicidad, sino la velocidad.

Liderar el producto desde la capa de infraestructura

Como he dicho, dirijo la organización de producto de la plataforma bancaria en American Express: la plataforma de banca digital y pagos que sustenta nuestras experiencias de banca para consumidores y empresas. Es la capa de infraestructura: los raíles, las capacidades de cuentas y movimiento de dinero, y los controles que respaldan todos los elementos orientados al cliente.

Nuestros «usuarios» comprenden dos públicos distintos: los clientes finales, que experimentan el producto como sus servicios bancarios y de pagos, y los equipos internos de producto e ingeniería, que desarrollan sobre nuestra plataforma. El trabajo de plataforma exige atender simultáneamente a quienes desarrollan y a los usuarios finales; si optimizas solo para uno, el otro se resiente.

Operamos con la escala y el nivel normativo que se esperan de una institución financiera con más de cien años de historia, lo que significa que la fiabilidad y el cumplimiento normativo no son funcionalidades, sino requisitos básicos. Nuestro modelo de entrega combina producto e ingeniería internos con socios tecnológicos clave, por lo que, en gran medida, coordino: alineo las hojas de ruta internas con las capacidades externas y los controles que exigen nuestros equipos de riesgos y cumplimiento.

Cómo la IA traslada la creación de prototipos de la ingeniería al producto

El mayor cambio que hice fue dejar de tratar la creación de prototipos como una solicitud para ingeniería y convertirla en una capacidad de producto.

Hace un año, validar una idea nueva implicaba redactar un documento, añadirla a una lista de tareas pendientes y esperar semanas a que ingeniería tuviera capacidad para construir algo que los usuarios o socios pudieran evaluar. Ahora dirijo pequeños equipos que pasan del concepto al software funcional en cuestión de días, utilizando herramientas de programación basadas en IA para crear un prototipo funcional sobre un SDK real, no una maqueta interactiva. En una iniciativa reciente de integración de nóminas, un equipo pequeño creó y probó una integración funcional en el tiempo que antes necesitábamos para ponernos de acuerdo sobre los requisitos.

Esto cambió nuestra forma de tomar decisiones. Cuando puedes poner software funcional delante de un socio o una persona interesada en cuestión de días, la conversación deja de ser abstracta: debatís sobre algo real, con sus límites reales, en lugar de discutir sobre una presentación. Eso ha eliminado gran parte de la parálisis por análisis que antes consumía la fase inicial de nuestra hoja de ruta. Y, como los responsables de producto de mi equipo definen el alcance y crean los prototipos por sí mismos, el tiempo de ingeniería se dedica a lo que realmente lo necesita.

Ahora, la parte difícil no es construir. Es decidir qué merece la pena construir. El criterio y la priorización son los recursos escasos. Ese es el cambio en el que estoy más centrado como líder.

Un flujo de trabajo real para pasar de la idea al prototipo

Este es nuestro flujo de trabajo generalizado, desde la idea hasta el prototipo funcional, comprimido de semanas a días.

1. Definir el problema: Empieza siendo humano: una necesidad de un socio o una carencia que hemos detectado. Utilizo un asistente de IA como interlocutor para poner a prueba el planteamiento: ¿para quién es?, ¿cuál es el trabajo real que debe realizar? y ¿qué haría que no mereciera la pena desarrollarlo? Esto afina la pregunta antes de empezar a construir.
2. Sintetizar los datos de entrada: Dirigimos la IA hacia el material relevante —investigación, temas de soporte, panorama competitivo y contexto interno previo— y obtenemos una visión sintetizada en minutos en lugar de días. Una persona la revisa para identificar qué ha pasado por alto el modelo o a qué ha dado demasiado peso; la síntesis es un punto de partida, no el veredicto.
3. Construir un prototipo funcional: Este es el mayor cambio. En lugar de redactar una especificación y esperar a que haya capacidad de ingeniería, un equipo reducido utiliza herramientas de programación con IA para crear software funcional con una interfaz real; no una maqueta en la que se pueda hacer clic, sino algo que funciona. Días, no semanas.
4. Ponerlo delante de la gente: Presentamos pronto el prototipo funcional a las partes interesadas o a un socio. Como es real, los comentarios son genuinos: debatimos sobre el comportamiento y los casos límite, en lugar de reaccionar ante una presentación.
5. Decidir con criterio: Aquí la IA da un paso atrás. Si invertimos más, cómo encaja en la hoja de ruta y cuáles son las implicaciones en materia de controles y cumplimiento normativo: son decisiones humanas, con una responsabilidad clara desde el diseño.

Por qué debe cambiar el ámbito de responsabilidad del PM

Por eso, he estado redefiniendo activamente el ámbito de responsabilidad de los PM, los puntos de entrega entre producto e ingeniería y, fundamentalmente, el nivel de calidad exigido a los artefactos creados por los PM que llegan a producción.

En el momento en que un PM puede entregar un producto de principio a fin, hay que responder a nuevas preguntas que el modelo anterior nunca te obligaba a plantearte. ¿De qué es responsable ahora un PM que antes no lo era? ¿En qué punto debe seguir interviniendo el criterio de ingeniería para aprobar el trabajo y en cuál simplemente lo ralentiza? ¿Qué significa «listo para producción» cuando la persona que lo ha creado no es ingeniera?

Me centro en la coherencia, no en entregar más rápido porque sí. Dar a todo el mundo la capacidad de construir conlleva el riesgo de que cada persona cree su propia versión de todo, fragmentando la organización en silos capaces que no generan un efecto acumulativo. Por eso, el rediseño trata tanto de unos fundamentos compartidos y un estándar de calidad común como de dar más autonomía a los PM. Si se hace bien, los equipos avanzan mucho más rápido y construyen unos sobre el trabajo de otros, en lugar de trabajar al margen.

Por qué la IA debe generar opciones mientras las personas aplican su criterio

La IA destaca a la hora de generar opciones; las personas deben seguir asumiendo la responsabilidad del criterio, especialmente en la banca regulada.

Recurro a la IA para:

• Descubrimiento y síntesis: extraer información relevante de la investigación, los tickets de soporte, los comentarios de los socios y el panorama competitivo mucho más rápido de lo que una persona podría leerlo todo.
• Creación de prototipos y experimentación: poner en marcha software funcional para probar una idea en lugar de debatir sobre ella.
• El primer borrador de prácticamente todo: requisitos, análisis y estudios del mercado.

La IA nos lleva hasta un punto de partida creíble —algo que antes consumía la mayor parte de nuestro tiempo— en cuestión de minutos.

Dejo explícitamente en manos de las personas:

• La priorización y las decisiones sobre la hoja de ruta: la IA puede exponer las ventajas y desventajas, pero decidir qué construimos —y qué decidimos deliberadamente no construir— requiere criterio sobre la estrategia, la tolerancia al riesgo y nuestros clientes, aspectos que no estoy dispuesto a externalizar.
• Cualquier asunto relacionado con decisiones regulatorias o de riesgo: en nuestro mundo, «el modelo lo sugirió» no es una respuesta que se pueda dar a un regulador.
• Las decisiones difíciles con personas y partes interesadas: me refiero a interpretar el ambiente y gestionar prioridades enfrentadas entre los socios. Son aspectos irreductiblemente humanos.

Cómo la IA aporta rapidez y exceso de confianza

Reflexiones de Abhi

La lección fue que la IA reduce tan drásticamente el coste del primer 80 % que los equipos subestiman el 20 % restante, que es donde reside toda la dificultad del sector bancario. Ahora separamos explícitamente “parece terminado” de “está terminado,” y he establecido como norma que una demostración funcional es el comienzo de la conversación difícil, no el final de esta.

La ventaja más evidente es la rapidez al principio del ciclo de vida:

• Los ciclos de creación de prototipos que antes llevaban semanas ahora duran días, lo que significa que probamos más ideas y descartamos antes las que no funcionan, antes de que consuman capacidad real de ingeniería.
• Ahora mis PMs pueden completar la investigación, los comentarios del equipo de soporte y los análisis de la competencia en una fracción del tiempo, por lo que llegan mejor preparados a las conversaciones sobre priorización.
• Los PMs que antes no podían lanzar nada sin un ingeniero ahora pueden poner en marcha un prototipo funcional por sí mismos. Eso cambia la energía del equipo. La gente vuelve a sentirse más como creadora.

Pero aprendimos por las malas que el resultado de la IA transmite seguridad incluso cuando es incorrecto, y eso es peligroso en un entorno regulado. Al principio, un prototipo parecía lo bastante pulido como para generar una falsa confianza sobre lo cerca que estábamos de algo real. La demostración funcionaba, pero el 20 % difícil —los casos extremos, los controles y la lógica de cumplimiento— no se había abordado en absoluto.

La lección fue que la IA reduce tan drásticamente el coste del primer 80 % que los equipos subestiman el 20 % restante, que es donde reside toda la dificultad del sector bancario. Ahora separamos explícitamente "parece terminado" de "está terminado", y he establecido como norma que una demostración funcional es el comienzo de la conversación difícil, no el final de esta.

La brecha entre la demostración y el valor del producto

Existe una gran brecha entre la magia de una demostración y el valor duradero del producto. La IA destaca en el impresionante momento de pasar de cero a uno, pero decepciona sistemáticamente en el trabajo poco atractivo que impulsa un impacto sostenido.

Algunos ejemplos concretos:

• El «último kilómetro» en los flujos de trabajo regulados: La IA ofrece rápidamente un prototipo funcional, pero en la banca el valor no está en el recorrido ideal, sino en los controles, los registros de auditoría, la gestión de excepciones y la lógica de conciliación. La IA no ha acelerado de forma significativa esa parte. Esperaba que comprimiera todo el desarrollo; solo ha comprimido la primera mitad. La segunda mitad sigue siendo igual de difícil que siempre, y es donde reside la mayor parte del valor real del producto.
• La integración con la realidad de los sistemas heredados: Gran parte del valor de una plataforma proviene de lo bien que se integra con los sistemas existentes: API de socios, procesadores centrales y servicios internos con décadas de antigüedad. Las herramientas de IA destacan en entornos de desarrollo desde cero, pero se debilitan notablemente en cuanto se encuentran con nuestras limitaciones reales. El trabajo de integración desordenado y cargado de contexto que define la ingeniería de plataformas del mundo real es precisamente donde menos ayudan.
• La calidad de las decisiones en el nivel estratégico: Esperaba que la síntesis de la IA afinara nuestra priorización. Nos ha hecho más rápidos y estar mejor informados, pero no ha facilitado las decisiones difíciles, porque las decisiones difíciles nunca se debieron a la falta de información, sino a la convicción, las compensaciones y el apetito de riesgo. La IA nos dio más análisis; no nos dio más claridad. Fue útil corregir esa expectativa.

Por qué la integración de la IA debe ser una progresión paso a paso

No se pueden saltar las capas inferiores. El instinto con la IA —especialmente con los modelos capaces de hoy— es ir directamente al estado final impresionante: el sistema autónomo, el agente que actúa por su cuenta. Aprendí que hay que llegar hasta ahí paso a paso. Intentar tomar un atajo sale caro.

Ahora lo concibo como una progresión de madurez. La capacidad de la IA en cualquier contexto operativo serio avanza por etapas: primero la productividad (hacer más rápido el trabajo existente), después la eficiencia (automatizar los pasos rutinarios), luego la inteligencia (obtener conocimientos más profundos y apoyo para la toma de decisiones) y solo después la autonomía (sistemas que actúan por su cuenta). Cada capa depende de la que tiene debajo. No se puede implementar un agente fiable en una plataforma que todavía no puede observarse a sí misma, mostrar su propia configuración o explicar por qué ha tomado una decisión. La autonomía sin observabilidad no es sofisticación: es un riesgo que no se puede ver.

Si me hubiera dado cuenta de esto antes, habría evitado la tentación de prometer demasiado sobre la parte superior de la pila antes de que la inferior estuviera consolidada. La demostración más ambiciosa te atrae fácilmente porque entusiasma a todo el mundo. Pero una capacidad autónoma llamativa asentada sobre unos cimientos inmaduros falla de maneras difíciles de diagnosticar y erosiona rápidamente la confianza; y la confianza, una vez gastada en un sistema que actuó de forma incorrecta, es costosa de reconstruir.

Por eso, le diría a cualquiera que lance su primer producto impulsado por IA: sé honesto sobre la capa en la que estás, ofrece valor real en esa capa y deja que las capacidades de orden superior se ganen su lugar. La secuenciación lo es todo.

Cómo pueden los CPO optimizar la escasez adecuada

En general, mi consejo es dejar de optimizar la escasez equivocada.

Durante la mayor parte de nuestras carreras, el cuello de botella era la producción: conseguir que se construyeran las cosas. Así que lo organizábamos todo en torno al rendimiento: listas de tareas pendientes, planificación de la capacidad y lanzamientos más rápidos. La IA simplemente ha eliminado ese cuello de botella. El coste de generar una opción, un prototipo, un borrador o un análisis se aproxima a cero. Y cuando desaparece una restricción, otra nueva pasa a ser lo importante.

El nuevo recurso escaso es el criterio: saber qué merece la pena construir, a qué decir que no, cómo es algo «bueno» y qué está haciendo mal silenciosamente la salida aparentemente segura de la IA. Así que mi consejo tiene tres partes:

1. Invierte tu dividendo de IA en criterio, no solo en velocidad: La cuestión de avanzar más rápido no es lanzar más cosas, sino conseguir más oportunidades para poder ser más selectivo. Si la IA simplemente hace que construyas más rápidamente las cosas equivocadas, has empeorado el problema en lugar de mejorarlo.
2. Mantente cerca del oficio: Los líderes que tendrán dificultades son los que tratan esto como una decisión de herramientas de otra persona. Construye algo tú mismo. No puedes liderar a un equipo durante un cambio sobre el que solo has leído; tus instintos estarán calibrados para un mundo que ya no existe.
3. Afina tus conocimientos sobre tu sector en lugar de volverlos más vagos: Ahora todo el mundo tiene acceso a la misma IA de propósito general. Tu ventaja no es el modelo, sino el conocimiento específico y adquirido con esfuerzo sobre tus clientes, tu realidad normativa y tu negocio. La IA convierte lo genérico en una mercancía y hace que lo específico sea más valioso. Apuesta por lo que te pertenece.

Este momento recompensa más el buen criterio y la convicción que la información y el esfuerzo. Resulta incómodo, porque controlas el esfuerzo y debes desarrollar el criterio. Pero los líderes que lo interioricen pronto serán los que acumulen ventajas.

Sigue su trabajo

Puedes seguir el trabajo de Abhi Gandotra en LinkedIn y en su sitio web. También puedes echar un vistazo a su libro, El agente soberano.

¡Próximamente habrá más entrevistas con expertos en The CPO Club!