Wiceprezes ds. produktu w Amex mówi, że sztuczna inteligencja musi być stopniowo integrowana z organizacjami produktowymi — pominięcie jednego etapu będzie cię kosztować

Abishek (Abhi) Gandotra rozpoczął karierę jako inżynier, ale przeszedł do obszaru produktu, zabierając ze sobą wiedzę techniczną. Obecnie jest wiceprezesem ds. produktu w American Express. Jest także autorem książki Suwerenny agent.

Dołączył do nas, aby podzielić się tym, czego uczy się w czasie, gdy sztuczna inteligencja jeszcze bardziej zaciera granice między inżynierią a produktem. Oto, co nam powiedział.

Od inżynierii do produktu

Nazywam się Abhi Gandotra i kieruję organizacją produktową Platformy bankowej w American Express. Zaczynałem jako inżynier, spędzając pierwszą dekadę kariery na pisaniu kodu. W związku z tym nigdy nie traktowałem technologii jak czarnej skrzynki. Kiedy coś nie trafia na rynek, chcę wiedzieć dlaczego — na poziomie, na którym dochodzi do awarii.

Przeszedłem do obszaru produktu, ponieważ mniej zależało mi na tym, aby budować rzeczy właściwie, a bardziej na tym, aby budować właściwe rzeczy. W Green Dot przez ponad dekadę tworzyłem platformę bankowości jako usługi — przekształciliśmy ją z pomysłu w rozwiązanie generujące ponad 1 mld USD przychodów B2B w ramach współpracy z ponad 80 partnerami korporacyjnymi. To nauczyło mnie czegoś, w co nadal wierzę: platformy wygrywają wtedy, gdy ułatwiają innym rozwiązywanie trudnych problemów. Teraz w Amex robię to samo dla infrastruktury bankowej i płatniczej, na inną skalę i przy towarzyszącym jej poziomie wymogów regulacyjnych.

Moment związany ze sztuczną inteligencją nie jest dla mnie jedynie szumem medialnym. Już teraz dostarczam rozwiązania z wykorzystaniem tych narzędzi — tworzę agentów, uruchamiam program podnoszenia kompetencji w zakresie AI w całej mojej organizacji i prowadzę małe zespoły, które przechodzą od pomysłu do działającego oprogramowania w ciągu kilku dni. Moje inżynierskie instynkty powróciły w pełni. Przepaść między „mam pomysł” a „to działa” nigdy nie była tak mała. To właśnie uważam za ekscytujące — nie szum medialny, lecz tempo.

Zarządzanie produktem z poziomu warstwy infrastruktury

Jak wspomniałem, kieruję organizacją produktową Platformy bankowej w American Express — cyfrową platformą bankową i płatniczą, na której opierają się nasze doświadczenia bankowe klientów indywidualnych i biznesowych. To warstwa infrastruktury: mechanizmy umożliwiające realizację transakcji, funkcje obsługi rachunków i przepływu pieniędzy oraz mechanizmy kontrolne wspierające wszystkie elementy skierowane do klientów.

Nasi „użytkownicy” dzielą się na dwie odrębne grupy: klientów końcowych, którzy korzystają z produktu jako z usług bankowych i płatniczych, oraz wewnętrzne zespoły produktowe i inżynieryjne, które tworzą rozwiązania na naszej platformie. Praca nad platformą wymaga jednoczesnej obsługi osób budujących rozwiązania i użytkowników końcowych — jeśli optymalizujesz działania tylko pod kątem jednej z tych grup, druga na tym cierpi.

Działamy na skalę i przy poziomie wymogów regulacyjnych oczekiwanych od ponadstuletniej instytucji finansowej, co oznacza, że niezawodność i zgodność z przepisami nie są dodatkowymi funkcjami, lecz absolutną podstawą. Nasz model dostarczania rozwiązań łączy wewnętrzne zespoły produktowe i inżynieryjne z kluczowymi partnerami technologicznymi, dlatego w dużej mierze pełnię funkcję koordynatora — uzgadniam wewnętrzne plany rozwoju z zewnętrznymi możliwościami oraz mechanizmami kontrolnymi wymaganymi przez nasze zespoły ds. ryzyka i zgodności.

Jak AI przenosi prototypowanie z inżynierii do produktu

Największa zmiana, jaką wprowadziłem, polegała na tym, że przestałem traktować prototypowanie jako żądanie ze strony inżynierii i uczyniłem z niego zdolność produktową.

Rok temu sprawdzenie nowego pomysłu oznaczało napisanie opisu, dodanie go do backlogu i czekanie tygodniami, aż inżynierowie znajdą czas na zbudowanie czegoś, co użytkownicy lub partnerzy mogliby ocenić. Teraz prowadzę małe zespoły, które przechodzą od koncepcji do działającego oprogramowania w ciągu kilku dni — wykorzystując narzędzia AI do programowania, aby stworzyć funkcjonalny prototyp oparty na rzeczywistym SDK, a nie klikalną makietę. W ramach jednej z ostatnich inicjatyw, dotyczącej integracji płacowej, niewielki zespół zbudował i przetestował działającą integrację w czasie, który wcześniej zajmowało samo uzgadnianie wymagań.

Zmieniło to sposób, w jaki podejmujemy decyzje. Kiedy możesz zaprezentować partnerowi lub interesariuszowi działające oprogramowanie w ciągu kilku dni, rozmowa przestaje być abstrakcyjna — dyskutujesz o czymś rzeczywistym, z rzeczywistymi ograniczeniami, zamiast spierać się o prezentację. W dużej mierze wyeliminowało to paraliż analityczny, który wcześniej pochłaniał początkową część naszego planu rozwoju. A ponieważ menedżerowie produktu w moim zespole samodzielnie określają zakres i tworzą prototypy, czas inżynierów jest przeznaczany na to, co naprawdę go wymaga.

Teraz trudność nie polega na budowaniu. Chodzi o ocenę, co warto zbudować. Wyczucie i ustalanie priorytetów to ograniczone zasoby. To właśnie na tej zmianie koncentruję się najbardziej jako lider.

Praktyczny proces przechodzenia od pomysłu do prototypu

Oto nasz uogólniony przepływ pracy — od pomysłu do działającego prototypu — skrócony z tygodni do dni.

1. Zdefiniowanie problemu: Zaczyna się od człowieka — od potrzeby partnera lub luki, którą zauważyliśmy. Korzystam z asystenta AI jako partnera do myślenia, aby poddać ramy problemu próbie: dla kogo to jest, jakie zadanie ma faktycznie zostać wykonane i co sprawiłoby, że nie warto tego budować? Dzięki temu doprecyzowujemy pytanie, zanim rozpoczniemy pracę.
2. Synteza danych wejściowych: Wskazujemy AI odpowiednie materiały — wyniki badań, tematy zgłaszane do pomocy technicznej, otoczenie konkurencyjne i wcześniejszy kontekst wewnętrzny — i w ciągu kilku minut otrzymujemy syntetyczny obraz zamiast czekać na niego całymi dniami. Człowiek weryfikuje wynik, aby wskazać to, co model pominął lub nadmiernie uwypuklił; synteza jest punktem wyjścia, a nie ostatecznym werdyktem.
3. Budowa działającego prototypu: To największa zmiana. Zamiast pisać specyfikację i czekać na dostępność zespołu inżynieryjnego, mały zespół wykorzystuje narzędzia AI do programowania, aby stworzyć funkcjonalne oprogramowanie z prawdziwym interfejsem — nie klikalną makietę, lecz coś, co działa. Dni, a nie tygodnie.
4. Przedstawienie go ludziom: Na wczesnym etapie prezentujemy działający prototyp interesariuszom lub partnerowi. Ponieważ jest prawdziwy, informacje zwrotne są autentyczne — dyskutujemy o zachowaniu i przypadkach brzegowych, a nie reagujemy na prezentację.
5. Podjęcie decyzji na podstawie oceny sytuacji: W tym momencie AI wycofuje się na dalszy plan. To, czy będziemy dalej inwestować, jak rozwiązanie wpisuje się w plan rozwoju oraz jakie są konsekwencje w zakresie kontroli i zgodności — to decyzje podejmowane przez ludzi, z jasno określoną odpowiedzialnością już na etapie projektowania.

Dlaczego zakres odpowiedzialności PM musi się zmienić

Z tego powodu aktywnie na nowo definiuję zakres odpowiedzialności PM, punkty przekazania pracy między zespołami produktu i inżynierii oraz — co najważniejsze — standard jakości artefaktów tworzonych przez PM i wdrażanych na produkcję.

Gdy PM może dostarczyć rozwiązanie kompleksowo, od początku do końca, trzeba odpowiedzieć na nowe pytania, których stary model nigdy nie wymuszał. Za co PM odpowiada teraz, choć wcześniej nie odpowiadał? W których miejscach ocena zespołu inżynieryjnego nadal musi wyznaczać bramkę dla pracy, a gdzie jedynie ją spowalnia? Co oznacza „gotowe do wdrożenia na produkcję”, gdy osoba, która coś zbudowała, nie jest inżynierem?

Skupiam się na spójności, a nie na szybszym dostarczaniu za wszelką cenę. Przyznanie wszystkim możliwości budowania stwarza ryzyko, że każdy zacznie tworzyć własną wersję wszystkiego, fragmentując organizację na kompetentne silosy, które nie wzmacniają się wzajemnie. Dlatego przeprojektowanie dotyczy w równym stopniu wspólnych fundamentów i wspólnego standardu jakości, co uwolnienia potencjału PM. Jeśli zostanie przeprowadzone właściwie, zespoły działają zdecydowanie szybciej i budują na bazie swoich rozwiązań, zamiast pracować obok siebie.

Dlaczego AI powinno generować opcje, a ludzie stosować własną ocenę

AI doskonale sprawdza się w generowaniu opcji; ludzie nadal muszą odpowiadać za ocenę sytuacji, szczególnie w bankowości regulowanej.

Polegam na AI w zakresie:

• Odkrywania i syntezy: wydobywania istotnych informacji z badań, zgłoszeń do pomocy technicznej, opinii partnerów i otoczenia konkurencyjnego znacznie szybciej, niż człowiek jest w stanie przeczytać wszystkie te materiały.
• Tworzenia prototypów i eksperymentowania: szybkiego uruchamiania działającego oprogramowania w celu przetestowania pomysłu zamiast debatowania nad nim.
• Pierwszej wersji niemal wszystkiego: wymagań, analiz i przeglądów rynku.

AI pomaga nam w ciągu kilku minut dotrzeć do wiarygodnego punktu wyjścia — czegoś, co wcześniej zajmowało większość naszego czasu.

Wyraźnie pozostawiam po stronie ludzi:

• Ustalanie priorytetów i decyzję dotyczącą planu rozwoju: AI może przedstawić kompromisy, ale decyzja o tym, co zbudujemy — i czego celowo nie zbudujemy — wymaga oceny strategii, apetytu na ryzyko i potrzeb naszych klientów, której nie zamierzam zlecać na zewnątrz.
• Wszystko, co dotyczy decyzji regulacyjnych lub związanych z ryzykiem: w naszym świecie „model tak zasugerował” nie jest odpowiedzią, której można udzielić organowi regulacyjnemu.
• Trudne decyzje dotyczące ludzi i interesariuszy: mam na myśli odczytywanie atmosfery, poruszanie się między sprzecznymi priorytetami partnerów. Tego nie da się sprowadzić wyłącznie do działań maszynowych.

Jak AI zapewnia zarówno szybkość, jak i nadmierną pewność siebie

Myśli Abhiego

Lekcja polegała na tym, że AI tak drastycznie obniża koszt pierwszych 80%, że zespoły nie doceniają pozostałych 20%, czyli tej części, w której kryją się wszystkie trudności związane z bankowością. Teraz wyraźnie oddzielamy “wygląda na ukończone” od “jest ukończone,” a ja ustanowiłem zasadę, że działające demo jest początkiem trudnej rozmowy, a nie jej końcem.

Najwyraźniejszą korzyścią jest szybkość na początku cyklu życia:

• Cykle prototypowania, które wcześniej trwały tygodnie, teraz zajmują dni, co oznacza, że testujemy więcej pomysłów i wcześniej odrzucamy te złe — zanim pochłoną rzeczywiste moce przerobowe zespołu inżynieryjnego.
• Moi menedżerowie produktu przechodzą teraz przez badania, opinie działu wsparcia i analizy konkurencji w ułamku wcześniejszego czasu, dzięki czemu są lepiej przygotowani do rozmów o ustalaniu priorytetów.
• Menedżerowie produktu, którzy wcześniej nie mogli dostarczyć niczego bez pomocy inżyniera, mogą teraz samodzielnie stworzyć działający prototyp. To zmienia energię w zespole. Ludzie znów czują się bardziej jak twórcy.

Jednak przekonaliśmy się na własnej skórze, że AI generuje odpowiedzi z dużą pewnością siebie, nawet gdy są błędne, a w regulowanym środowisku jest to niebezpieczne. Na początku prototyp wyglądał na tyle dopracowanie, że stworzył fałszywe przekonanie o tym, jak blisko jesteśmy stworzenia czegoś rzeczywistego. Demo działało, ale trudne 20% — przypadki brzegowe, mechanizmy kontroli i logika zgodności z przepisami — pozostało całkowicie nierozwiązane.

Lekcja polegała na tym, że AI tak drastycznie obniża koszt pierwszych 80%, że zespoły nie doceniają pozostałych 20%, czyli tej części, w której kryją się wszystkie trudności związane z bankowością. Teraz wyraźnie oddzielamy "wygląda na ukończone" od "jest ukończone", a ja ustanowiłem zasadę, że działające demo jest początkiem trudnej rozmowy, a nie jej końcem.

Przepaść między demem a wartością produktu

Między magią dema a trwałą wartością produktu istnieje duża przepaść. AI świetnie radzi sobie z imponującym przejściem od zera do jednego, ale konsekwentnie rozczarowuje w przypadku mało efektownej pracy, która zapewnia długotrwały wpływ.

Kilka konkretów:

• „Ostatni etap” w regulowanych procesach: AI szybko dostarcza działający prototyp, ale w bankowości wartość nie tkwi w pomyślnej ścieżce — lecz w mechanizmach kontroli, śladach audytowych, obsłudze wyjątków i logice uzgadniania. AI nie przyspieszyło znacząco tej części. Oczekiwałem, że skróci cały proces budowy; skróciło tylko jego pierwszą połowę. Druga połowa pozostaje równie trudna jak wcześniej i to właśnie w niej kryje się większość rzeczywistej wartości produktu.
• Integracja ze spuścizną istniejących systemów: Duża część wartości platformy wynika z tego, jak sprawnie integruje się ona z istniejącymi systemami — interfejsami API partnerów, głównymi systemami przetwarzającymi i wewnętrznymi usługami rozwijanymi od dziesięcioleci. Narzędzia AI świetnie sprawdzają się w nowych środowiskach, ale wyraźnie słabną, gdy napotykają nasze rzeczywiste ograniczenia. Złożona, wymagająca szerokiego kontekstu praca integracyjna, która definiuje inżynierię platform w świecie rzeczywistym, jest dokładnie tym obszarem, w którym pomagają najmniej.
• Jakość decyzji na poziomie strategii: Miałem nadzieję, że synteza AI usprawni ustalanie naszych priorytetów. Dzięki niej działamy szybciej i mamy lepsze informacje, ale nie ułatwiła podejmowania trudnych decyzji — ponieważ trudne decyzje nigdy nie wynikały z braku informacji; dotyczyły przekonania, kompromisów i apetytu na ryzyko. AI dostarczyło nam więcej analiz, ale nie zapewniło większej jasności. To było przydatne skorygowanie oczekiwań.

Dlaczego integracja AI powinna przebiegać etapami

Nie można pominąć niższych warstw. Naturalnym odruchem w przypadku AI — zwłaszcza dzisiejszych, zaawansowanych modeli — jest od razu sięgać po imponujący stan docelowy: autonomiczny system, agenta działającego samodzielnie. Nauczyłem się, że trzeba na to zasłużyć. Próba pójścia na skróty ma swoją cenę.

Teraz postrzegam to jako proces dojrzewania. Możliwości AI w każdym poważnym kontekście operacyjnym rozwijają się etapami — najpierw produktywność (przyspieszanie istniejącej pracy), następnie efektywność (automatyzowanie rutynowych czynności), potem inteligencja (głębszy wgląd i wsparcie decyzji), a dopiero na końcu autonomia (systemy działające samodzielnie). Każda warstwa zależy od tej znajdującej się pod nią. Nie można wdrożyć niezawodnego agenta na platformie, która nie potrafi jeszcze obserwować samej siebie, ujawniać własnej konfiguracji ani wyjaśniać, dlaczego podjęła daną decyzję. Autonomia bez obserwowalności nie jest wyrafinowaniem — to ryzyko, którego nie można dostrzec.

Gdybym wcześniej to zrozumiał, uniknąłbym pokusy obiecywania zbyt wiele na szczycie stosu, zanim fundament nie był solidny. Najbardziej ambitne demo z łatwością cię wciąga, ponieważ ekscytuje wszystkich. Jednak efektowna funkcja autonomiczna oparta na niedojrzałym fundamencie psuje się w trudny do zdiagnozowania sposób i szybko podkopuje zaufanie — a zaufanie, gdy system raz zawiedzie i zadziała nieprawidłowo, trudno i kosztownie odbudować.

Dlatego powiedziałbym każdemu, kto wprowadza na rynek swój pierwszy produkt oparty na AI: uczciwie określ, na której warstwie jesteś, dostarcz rzeczywistą wartość na tym poziomie i pozwól, by bardziej zaawansowane możliwości zasłużyły na swoje miejsce. Cała gra polega na właściwym ustaleniu kolejności.

Jak CPO mogą optymalizować działania pod kątem właściwego ograniczenia

Ogólnie rzecz biorąc, radzę przestać optymalizować działania pod kątem niewłaściwego ograniczenia.

Przez większość naszej kariery wąskim gardłem była produkcja — tworzenie rzeczy. Dlatego organizowaliśmy wszystko wokół przepustowości: zaległości, planowania wydajności i szybszego dostarczania. AI po prostu usunęła to wąskie gardło. Koszt wygenerowania opcji, prototypu, wersji roboczej czy analizy zbliża się do zera. A gdy jedno ograniczenie znika, nowe staje się tym, co ma znaczenie.

Nowym ograniczonym zasobem jest osąd — wiedza o tym, co warto zbudować, czemu należy powiedzieć „nie”, jak wygląda coś „dobrego” oraz co AI po cichu robi źle, mimo że przedstawia swoje wyniki z pewnością siebie. Dlatego moja rada składa się z trzech części:

1. Przeznacz dywidendę z AI na osąd, a nie tylko na szybkość: Celem szybszego działania nie jest dostarczanie większej liczby rzeczy — chodzi o zwiększenie liczby prób, aby móc dokonywać bardziej selektywnego wyboru. Jeśli AI sprawia tylko, że szybciej tworzysz więcej niewłaściwych rzeczy, pogarszasz problem, zamiast go rozwiązywać.
2. Pozostań blisko rzemiosła: Z trudnościami zmierzą się liderzy, którzy uznają, że jest to decyzja dotycząca narzędzi podejmowana przez kogoś innego. Zbuduj coś samodzielnie. Nie możesz poprowadzić zespołu przez zmianę, o której tylko czytałeś — twoje instynkty będą dostrojone do świata, który już nie istnieje.
3. Zdobywaj coraz głębszą wiedzę o swojej dziedzinie, zamiast ją uogólniać: Wszyscy mają teraz dostęp do tej samej sztucznej inteligencji ogólnego przeznaczenia. Twoją przewagą nie jest model — jest nią szczegółowa, ciężko zdobyta wiedza o klientach, realiach regulacyjnych i działalności firmy. AI ujednolica to, co ogólne, i zwiększa wartość tego, co szczegółowe. Wykorzystaj to, co jest twoje.

Ten moment premiuje wyczucie i przekonanie bardziej niż informacje i wysiłek. To niewygodne, ponieważ masz wpływ na wysiłek, a wyczucie musisz dopiero rozwinąć. Jednak liderzy, którzy wcześnie to zrozumieją, będą tymi, którzy osiągną efekt kumulacji.

Bądź na bieżąco

Możesz śledzić działalność Abhiego Gandotry na LinkedInie oraz na jego stronie internetowej. Możesz też sięgnąć po jego książkę Suwerenny agent.

Na The CPO Club czekają kolejne wywiady z ekspertami!