Czym różni się tworzenie produktów opartych na AI — i dlaczego zespoły produktowe muszą się rozwijać

Galen Low: Czy proces tworzenia produktu, który ma natywne funkcje AI, rzeczywiście różni się aż tak bardzo od procesu tworzenia innych produktów, które mogą po prostu wykorzystywać istniejące technologie AI?

Jyothi Nookula: Tak. Kiedy tworzysz produkt natywnie oparty na AI, masz do czynienia z trzema rzeczami, które są inne. Po pierwsze, AI jest z natury nieprzewidywalna.

Galen Low: Co jest pierwszą rzeczą, którą robisz jako lider, gdy zauważasz, że członkowie zespołu mogą nie być na tym samym poziomie, jeśli chodzi o rozumienie, wykorzystywanie, a nawet samo akceptowanie nowych technologii, takich jak AI?

Jyothi Nookula: Rozdzielam problem na dwie odrębne kwestie. Pierwsza to kompetencje. Druga to nastawienie. Jeśli potraktujesz problem z nastawieniem jak problem z kompetencjami, tylko go pogorszysz.

Galen Low: Jakie są najważniejsze rzeczy, które menedżer produktu zainteresowany tworzeniem produktów opartych na AI powinien mieć w swoim CV lub portfolio, aby się wyróżnić?

Jyothi Nookula: Po pierwsze, dowody na to, że coś stworzył z wykorzystaniem AI, a nie tylko o tym mówił. Druga rzecz to...

Galen Low: Witajcie w podcaście The Digital Project Manager — programie, który pomaga liderom odpowiedzialnym za realizację projektów pracować mądrzej, dostarczać szybciej i lepiej przewodzić w epoce AI. Jestem Galen i co tydzień zagłębiamy się w strategie z życia wzięte, nowe narzędzia, sprawdzone metody oraz od czasu do czasu opowieść z pierwszej linii frontu projektu. Niezależnie od tego, czy kierujesz ogromnymi projektami transformacyjnymi, porządkujesz przepływy pracy oparte na AI, czy po prostu próbujesz utrzymać chaos pod kontrolą, jesteś we właściwym miejscu. Zaczynajmy.

Dziś rozmawiamy o przyszłości menedżera produktu, o tym, czego potrzeba do tworzenia produktów opartych na AI, o sposobach wykorzystywania AI do usprawniania procesu tworzenia i wydawania produktów oraz o tym, co liderzy zespołów mogą zrobić, gdy w ich zespołach produktowych występują nierówności w zakresie umiejętności i nastawienia wobec nowych technologii, takich jak AI.

Jest dziś ze mną w studiu Jyothi Nookula. Jyothi ma ponad 13 lat doświadczenia w rozwijaniu produktów i platform opartych na AI w firmach takich jak Netflix, Meta, Amazon AWS i Etsy. Ma również 12 patentów związanych z uczeniem maszynowym i pomogła ponad 1500 menedżerom produktu przejść do ról związanych z AI za pośrednictwem swojej firmy edukacyjnej Next Gen Product Manager.

Jyothi, bardzo dziękuję, że jesteś dziś ze mną.

Jyothi Nookula: Cześć wszystkim. Bardzo się cieszę, że mogę dziś tu być.

Galen Low: Ja również się cieszę i od kilku tygodni wyczekiwałem tego spotkania. Kiedy pierwszy raz rozmawialiśmy, a właściwie gdy przeglądałem Twój profil, pomyślałem: wow, Jyothi to prawdziwa potęga. W Twoim profilu jest mnóstwo marek i technologii, których można pozazdrościć.

Zawsze też bardzo cenię osoby, które próbują pomóc kolejnemu pokoleniu przedstawicieli dowolnego zawodu rozwijać się w coraz bardziej technologicznym, a teraz również zorientowanym na AI świecie. Kiedy później rozmawialiśmy, pomyślałem: wow, mamy ze sobą tak wiele wspólnego. Ja działam po stronie projektów, a Ty bardziej po stronie produktów. Bardzo się jednak cieszę, że możemy zagłębić się w to, jak wszystko się zmienia, oraz w niektóre rzeczy, których nauczyłaś się podczas swojej drogi przez świat produktów opartych na AI i uczeniu maszynowym.

Wiem, że po drodze prawdopodobnie zboczymy z tematu w kilka naprawdę interesujących i wartościowych obszarów, więc mam nadzieję, że tak się stanie. Ale menedżer projektu we mnie stworzył na dziś pewną mapę drogową. Na początek chciałem zadać jedno wielkie, palące pytanie — to niewygodne, ale pilne pytanie, na które, jak sądzę, wszyscy chcą znać odpowiedź.

Potem chciałbym spojrzeć na temat szerzej i porozmawiać o trzech rzeczach. Po pierwsze, chciałbym omówić identyfikowanie i zamykanie luk kompetencyjnych w zespołach produktowych, gdy tworzy się produkty wykorzystujące funkcje AI i uczenia maszynowego. Następnie chciałbym poznać przykłady sposobów, w jakie Wasze zespoły wykorzystywały narzędzia AI w procesie tworzenia produktów — podczas badań, analizy danych, projektowania, prac inżynieryjnych, testów z użytkownikami lub w jakimkolwiek innym obszarze.

Na koniec chciałbym porozmawiać o tym, jak wygląda przyszłość roli związanej z zarządzaniem produktem. Co musi znaleźć się w CV lub portfolio, aby kandydat był w ogóle brany pod uwagę na stanowiska w firmach takich jak Meta, AWS, Netflix, Etsy i innych znaczących markach stawiających na AI.

Jyothi Nookula: Uwielbiam to. Jestem zainteresowana. To obecnie najgorętszy temat. Naprawdę go uwielbiam.

Galen Low: Świetnie. Zacznijmy od tego wielkiego pytania. Chodzi oczywiście o AI. Masz ogromne doświadczenie we współpracy z zespołami produktowymi przy tworzeniu rozwiązań opartych na AI i uczeniu maszynowym dla gigantów takich jak Meta, Amazon, Etsy i Netflix. Czy proces tworzenia produktu, który ma natywne funkcje AI, rzeczywiście różni się aż tak bardzo od procesu tworzenia innych produktów, które mogą po prostu wykorzystywać istniejące technologie AI?

Jyothi Nookula: To świetne pytanie, ponieważ dotyka sedna tego, co obecnie naprawdę zmienia się w tworzeniu produktów. Uczciwa odpowiedź brzmi: zasadniczo tak, ale niekoniecznie w sposób, w jaki ludzie to sobie wyobrażają. Już tłumaczę. Kiedy tworzysz produkt natywnie oparty na AI, masz do czynienia z trzema rzeczami, które różnią się od tradycyjnego oprogramowania, a nawet od produktów, które tylko integrują się z AI za pomocą interfejsu API.

Po pierwsze, AI jest z natury nieprzewidywalna. W tradycyjnym tworzeniu produktów piszesz deterministyczny kod: jeśli wydarzy się to, zrób tamto. Jeśli kliknę ten przycisk, przejdź do następnego ekranu. Za każdym razem, gdy klikam ten przycisk, dzieje się dokładnie to samo. W przypadku produktów natywnie opartych na AI pracujesz jednak z systemami probabilistycznymi, więc funkcja AI może działać inaczej za każdym razem, gdy zostanie uruchomiona.

Oznacza to, że cały proces zapewniania jakości, obsługa przypadków brzegowych oraz gwarancje niezawodności muszą zostać całkowicie przemyślane na nowo. Nie testujesz już tylko tego, czy coś działa. Sprawdzasz, czy działa wystarczająco dobrze i czy za każdym razem działa w sposób spójny w całym rozkładzie możliwych rezultatów.

To pierwsza fundamentalna różnica: nieprzewidywalność, czyli różnica między systemem deterministycznym a probabilistycznym. Druga polega na tym, że budujesz produkty na zmiennym gruncie, ponieważ bazowe modele rozwijają się w sposób, którego nie możesz kontrolować. Na przykład nowy model może zmienić swoje zachowanie.

Nie musi to być zmiana powodująca niezgodność, ale może nieznacznie zmienić sposób działania, rozszerzyć możliwości lub wprowadzić nowe tryby błędów. Dziś takie zmiany mogą nastąpić z dnia na dzień, w tempie, w jakim rozwija się technologia. W przeciwieństwie do tradycyjnych zależności, w których można kontrolować wersje powodujących niezgodność zmian i dokumentować aktualizacje,

aktualizacje modeli zachodzą szybciej, niż jesteśmy w stanie za nimi nadążyć. Trzecia rzecz — i to bardzo ważna — polega na tym, że trzeba zmienić miary sukcesu. Nie możesz już po prostu sprawdzać, czy funkcja wykonała się prawidłowo. Musisz mierzyć takie rzeczy jak: czy wynik był użyteczny? Nie tylko czy został wygenerowany, ale czy rzeczywiście był przydatny?

Czy odpowiadał intencji użytkownika? Czy pasował do pytania, które zadał użytkownik? Jak w ogóle definiujesz jakość w swoim przypadku użycia? W efekcie potrzebujesz znacznie ściślejszych pętli informacji zwrotnej z użytkownikami i musisz wbudować mechanizmy oceny bezpośrednio w proces tworzenia produktu. To bardzo różni się od sposobu, w jaki tworzy się tradycyjne produkty.

To są trzy najważniejsze różnice. Produkty, które tylko korzystają z istniejącej AI — na przykład dodają integrację z ChatGPT — nadal mogą być traktowane jak tradycyjne integracje. Nadal masz miary sukcesu i rzeczy, które trzeba monitorować, a także oceny, o których trzeba pamiętać.

W takim przypadku istnieje jednak pewien kontrakt. Kiedy natomiast od początku budujesz produkt natywnie oparty na AI, sytuacja wygląda zupełnie inaczej. Wtedy te trzy elementy w jeszcze większym stopniu wpływają na proces tworzenia produktu.

Galen Low: To zabawne, bo zanim zadałem to pytanie, myślałem: zadam je, a ona pewnie odpowie, że jest mniej więcej tak samo, tylko z kilkoma drobnymi różnicami. A to naprawdę zmienia zasady gry.

Bardzo podoba mi się to, co powiedziałaś o mierzeniu intencji i o stronie pomiarowej. Pochodzę ze świata projektów, gdzie mamy dokument wymagań. Wszystko jest binarne: tak albo nie. Czy produkt robi to, co zapisano w specyfikacji funkcjonalnej? Potem pojawia się jednak cała ta niejednoznaczność. Po pierwsze dlatego, że wynik jest probabilistyczny i nie będzie za każdym razem taki sam.

Po drugie dlatego, że bazowa architektura jest pod pewnymi względami czarną skrzynką i sama rozwija się każdego dnia szybciej, niż ludzie są w stanie to zrozumieć. To naprawdę bardzo różni się od sposobu, w jaki przez ostatnie lata tworzono większość produktów cyfrowych. Ale ma sens.

Masz ponad dekadę doświadczenia w pracy z uczeniem maszynowym i AI. Wiele osób dopiero zaczyna, a AI jest dla nich nowością od mniej więcej dwóch lat. ChatGPT uchylił wieko i pokazał, w jaki sposób można wykorzystywać AI, ale AI od dawna znajduje się w oprogramowaniu i produktach cyfrowych.

Myślę o tym, że skoro pracowałaś przy Netflixie, funkcja rekomendacji wygląda tak prosto, choć prawdopodobnie wcale taka nie jest. Ten algorytm, uczenie maszynowe, przetwarzanie danych w tle — to nie jest tylko kwestia tego, że wszystko w Netfliksie ma przypisaną określoną taksonomię. To nie są zwykłe powiązane linki na stronie.

Chodzi o zachowanie i intencje użytkownika, a bardzo łatwo się pomylić. Łatwo niemal nigdy nie dowiedzieć się, jak bardzo się pomyliliśmy, dopóki ktoś nie napisze: „Mój Netflix zawsze się myli, bo obejrzałem ten jeden film, a teraz poleca mi 18 sezonów Barneya”.

Jyothi Nookula: To samo cały czas dzieje się w przypadku rolek na Instagramie i TikToku. Oglądam jeden film, na którym ktoś jeździ na nartach, a chwilę później jestem zalewana filmami o narciarstwie.

Galen Low: Myślę, że traktujemy to jako coś oczywistego. Łatwo byłoby uznać — ja sam mógłbym tak pomyśleć — że to dość łagodne i proste. Ten sam trik, ten sam zestaw umiejętności. Kiedy jednak naprawdę rozłożysz to na czynniki pierwsze, okazuje się, że wcale tak nie jest. Zastanawiałem się, czy moglibyśmy nieco oddalić perspektywę, ponieważ poza imponującym doświadczeniem w kierowaniu produktami cyfrowymi dla marek takich jak Amazon, Meta, Netflix i Etsy jesteś także założycielką Next Gen Product Manager. Firma oferuje między innymi pięciotygodniowy program edukacyjny pomagający przejść od tradycyjnego zarządzania produktem do zarządzania produktami opartymi na AI.

Sam fakt, że taki kurs istnieje, mówi mi, że nie wszystkie konwencjonalne umiejętności związane z zarządzaniem produktem wystarczają obecnie. Potrzebne jest nowe, bardziej przyszłościowe nastawienie i nowe umiejętności. W swojej karierze mogłaś dobierać zespoły, ale rozsądnie można założyć, że nie wszyscy ich członkowie mieli dokładnie te same kompetencje i nastawienie wobec AI oraz innych nowych technologii. Co jest więc pierwszą rzeczą, którą robisz jako liderka, gdy zauważasz, że członkowie zespołu mogą nie być na tym samym poziomie pod względem rozumienia, wykorzystywania, a nawet akceptowania nowych technologii, takich jak AI?

Jyothi Nookula: To bardzo praktyczne, prawdziwe wyzwanie, z którym często miałam i nadal mam do czynienia. Byłam liderką ludzi zarządzającą zespołami różnej wielkości — od trzech, przez pięć, dziesięć i dwanaście osób. Przeszłam przez cały ten zakres. Widzę, że luka w umiejętnościach i luce komfortu związana z AI jest większa niż w przypadku jakiejkolwiek innej technologii lub zmiany w mojej karierze.

Pierwszą rzeczą, którą robię w takiej sytuacji, jest rozdzielenie problemu na dwie odrębne kwestie. Pierwsza to kompetencje — ludzie nie wiedzą, jak skutecznie pracować z AI. Druga to nastawienie — ludzie są sceptyczni, opierają się zmianie albo odczuwają niepokój.

Trzeba zdiagnozować, z którym z tych problemów masz do czynienia. Być może występują oba jednocześnie. Ważne jest jednak rozpoznanie, który problem próbujesz rozwiązać, ponieważ jeśli potraktujesz problem z nastawieniem jak problem z kompetencjami, tylko go pogorszysz. W przypadku luk kompetencyjnych pierwszym krokiem jest stworzenie wspólnego kontekstu poprzez działanie, a nie naukę.

Taką samą zasadę uczę swoich studentów podczas pięciotygodniowego kursu zarządzania produktami opartymi na AI. Uczą się poprzez działanie, a nie tylko przez słuchanie. Nie lubię wysyłać ludzi na szkolenia ani prosić ich o oglądanie samouczków. Zamiast tego od razu włączam AI do naszych rzeczywistych przepływów pracy i skupiam się na praktycznych rezultatach.

Chodzi o integrowanie Claude'a lub GPT z procesami pisania podsumowań retrospektyw sprintów, syntezy tematów, prowadzenia pogłębionych badań czy tworzenia podsumowań badań użytkowników — o coś, dzięki czemu ludzie widzą, że narzędzie wykonuje za nich prawdziwą pracę, a nie postrzegają go jako zastępstwo dla siebie. Po około dwóch tygodniach pytam uczestników spotkania: „Opowiedzcie o czymś, co AI pomogła wam zrobić szybciej” albo „Powiedzcie o spostrzeżeniu, którego nie zauważylibyście bez AI”. Te wspólne doświadczenia stają się podstawą wspólnego budowania kompetencji.

W przypadku problemów z nastawieniem, czyli oporem lub lękiem, najlepszym sposobem jest rozpoczęcie od ciekawości, a nie od entuzjastycznego przekonywania. Podczas spotkań jeden na jeden pytam zazwyczaj: „Co tak naprawdę jest tutaj Twoją obawą?”. Potem milknę i słucham. Zwykle w takich rozmowach pojawia się coś uzasadnionego. Ludzie mówią: „Mam wrażenie, że to umniejszy wartości mojego fachu”.

Albo: „Nie ufam wynikom, bo nie potrafię ich w pełni zweryfikować”, czy też: „Mam wrażenie, że zostaję w tyle, a wszystko mnie przytłacza”. To są prawdziwe obawy. Nauczyłam się, że nie można wyprowadzić kogoś ze strachu za pomocą samej logiki. Można natomiast uznać ten lęk, znormalizować go, a następnie pokazać tej osobie drogę naprzód.

Jeśli ktoś martwi się, że jego fach straci na wartości, pokazuję mu, jak AI może zająć się podstawową konstrukcją pracy, a człowiek może skupić się na wymagających niuansów i wysokiej oceny zadaniach, na które wcześniej nie miał czasu. Jeśli ktoś martwi się weryfikacją, mówię: „Dobrze, zbudujmy razem ramy oceny”. W ten sposób ta osoba staje się ekspertem w zapewnianiu jakości AI.

Kolejną rzeczą, która działa bardzo dobrze, jest szybkie identyfikowanie osób pełniących funkcję pomostu. W każdym zespole są ludzie, którzy naturalnie interesują się AI, stale eksperymentują i wprowadzają innowacje. Są praktyczni i osiągają rezultaty.

Daję im wyraźne przyzwolenie na dzielenie się tym, co działa. W nieformalny sposób, na przykład podczas codziennych spotkań, można organizować krótkie sesje dzielenia się wiedzą. Tworzy to naukę od rówieśników, ponieważ gdy ludzie widzą, że ich współpracownik korzysta z danego rozwiązania i osiąga wyniki, chętniej sami je wypróbują niż wtedy, gdy lider mówi im z góry: „Idźcie i zróbcie to”.

Ostatnia rzecz może być nieco kontrowersyjna: szybko ustalam, że biegłość w korzystaniu z AI staje się podstawowym oczekiwaniem. Jestem empatyczna wobec krzywej uczenia się i bardzo cierpliwa wobec procesu, ale jasno komunikuję kierunek: to nie jest opcjonalne. Tak jak wszyscy musieliśmy nauczyć się zwinnych procesów, analityki czy projektowania z myślą o użytkowniku, tak teraz jest to część naszej pracy.

Odkryłam, że połączenie dużego wsparcia z wysokimi standardami i jasno określonymi oczekiwaniami zmniejsza niepokój. Zespoły, które najbardziej się zmagają, to te, w których liderzy nie precyzują oczekiwań i jednocześnie nie zapewniają realnego wsparcia. Wtedy pojawia się frustracja i poczucie bezradności.

Celem nie jest doprowadzenie wszystkich natychmiast do tego samego poziomu. Celem jest sprawienie, aby wszyscy zmierzali w tym samym kierunku, mając poczucie bezpieczeństwa psychologicznego i dostęp do praktycznych narzędzi.

Galen Low: Bardzo mi się to podoba. Po pierwsze, uwielbiam rozdzielenie kompetencji i nastawienia. Cieszę się, że poszłaś w tę stronę. Kiedy tego słuchałem, pomyślałem, że to niemal połączenie zarządzania zmianą i budowania zespołu w czasie rzeczywistym.

Mamy tendencję do myślenia o zarządzaniu zmianą jak o czymś, co robi się raz, gdy wdrażana jest duża zmiana. To niemal jednorazowa inicjatywa. Ty opisujesz coś, co przypomina codzienne zarządzanie zmianą w zespole. Jak powiedziałaś, chodzi o wsparcie, a nie o komunikat „naucz się tego sam, bo musisz”. Buduje to zbiorowe kompetencje i wspólne nastawienie zespołu, ponieważ proces jest bardziej płaski, oddolny i klarowny. To nie jest presja grupy, lecz wsparcie rówieśników.

Dzielimy się wiedzą i informacjami. Bardzo podoba mi się również to, co powiedziałaś o uzasadnionych obawach związanych z AI: poczuciu, że zostaje się w tyle, braku czasu na wykonywanie zadań czy poczuciu, że AI umniejsza wartość naszego fachu. Prawdopodobnie nie ma lepszego sposobu, aby znaleźć drogę naprzód, niż zobaczyć, jak współpracownicy radzą sobie z tym w praktyce na co dzień, a nie tylko w teorii.

Robicie to razem. Naprawdę bardzo mi się to podoba. Jestem wielkim zwolennikiem nauki poprzez działanie, więc cieszę się, że jest to również część Twojej metody nauczania. Szczególnie przemówiła do mnie kwestia jasności. Masz wysokie standardy i oczekiwania, ale zapewniasz wsparcie, a to właśnie jasność pozwala nam iść naprzód.

Decyzja, czy AI to tylko przejściowy trend, który można zignorować, czy też stanie się czymś tak normalnym jak pisanie na klawiaturze, została już podjęta — przynajmniej organizacyjnie, przez wiele osób, z którymi pracowałaś. Nie można ignorować AI, więc musimy ruszyć w tym kierunku, ale trzeba robić to razem.

Jyothi Nookula: Tak.

Galen Low: Wspomniałaś o małych eksperymentach i pilotażach, które pozwalają ludziom praktycznie pracować z AI, aby budować kompetencje i pewność siebie. Wyobrażam sobie, że możliwości są bardzo szerokie, podobnie jak obszary, w których można wykorzystywać AI podczas tworzenia produktów, które same w sobie są produktami opartymi na AI.

Czy mogłabyś podać przykłady innych sposobów, w jakie Wasze zespoły wykorzystywały AI podczas projektowania i tworzenia produktów?

Jyothi Nookula: Mogę podać konkretne przykłady z całego cyklu życia tworzenia produktu.

Galen Low: Świetnie.

Jyothi Nookula: Zacznijmy od odkrywania i badań. Chodzi o wykorzystanie AI do znacznego przyspieszenia generowania spostrzeżeń. Zwykle prowadzimy wiele badań użytkowników, na przykład 15–20 rozmów. Zamiast poświęcać tydzień na identyfikowanie tematów, przekazujemy transkrypcje do Claude'a i prosimy go o wskazanie wzorców, sprzeczności oraz przypadków brzegowych.

Kluczowe jest jednak to, że nie można bezkrytycznie przyjmować samego wyniku. Nadal omawiamy go z badaczem, który go weryfikuje, podważa i dopracowuje. Człowiek pozostaje bardzo ważnym elementem procesu. AI dostarcza mocny pierwszy szkic w ciągu godziny zamiast tygodnia, a badacz może poświęcić czas na wymagającą oceny pracę: zdecydować, które spostrzeżenia rzeczywiście mają znaczenie, które podważają nasze założenia i co powinniśmy zbadać dalej. Badacz użytkowników i menedżer produktu mogą wspólnie identyfikować wzorce.

To samo dotyczy zgłoszeń do działu wsparcia. Jeśli produkt jest już dostępny na rynku, liczba zgłoszeń jest zawsze ogromna. Zamiast ręcznie analizować każde zgłoszenie, aby znaleźć wzorce, analizujemy tysiące rozmów z klientami, żeby ustalić, jakie są ich problemy, jak duże są te problemy i jak wielu użytkowników dotyczą.

AI ujawnia te wzorce w sposób, który byłby niemożliwy ręcznie ze względu na ogromną liczbę informacji napływających kanałami wsparcia. Menedżer produktu widzi teraz wyniki badań użytkowników oraz wzorce w zgłoszeniach i może świadomiej ustalić, co należy naprawić w pierwszej kolejności oraz które funkcje powinny zostać uwzględnione w planach rozwoju.

AI eliminuje również pracę rutynową w dokumentacji i komunikacji. Widzieliśmy osoby wykorzystujące AI do pisania dokumentów wymagań produktu, podsumowywania przeglądów wydruków, a nawet tworzenia aktualizacji dla interesariuszy.

Są to zadania, w których AI może przygotować dobry pierwszy szkic. Jeden z moich menedżerów produktu powiedział: „Kiedyś spędzałem 30% czasu na pisaniu dokumentacji, a teraz spędzam 30% czasu na jej edytowaniu i dopracowywaniu”. To znacznie bardziej wartościowe, ponieważ zaczynasz od dobrego punktu wyjścia.

Wykorzystujemy też AI, aby zwiększyć dostępność dokumentacji. Ktoś może zapytać: „Co ustaliliśmy w sprawie przeprojektowania procesu płatności?” i otrzymać odpowiedź opracowaną na podstawie trzech różnych wątków na Slacku, spotkań i dokumentu wymagań produktu. AI pomaga więc również uczynić dokumentację łatwiej dostępną.

W całym cyklu życia tworzenia produktu — od eksperymentowania, przez dokumentację, aż po współpracę z zespołem inżynieryjnym — widzimy zmiany. Początkowo jako menedżerowie produktu byliśmy właścicielami i autorami dokumentów wymagań produktu. Dokumenty te nie znikają. Nadal będą istnieć, ale pojawia się nowy element: prototyp.

Po co przekazywać tylko listę historyjek użytkownika, skoro można wypróbować rozwiązanie i stworzyć jego prototyp? Można uzyskać prosty obraz dopasowania produktu do rynku i przekazać prototyp zespołowi inżynieryjnemu jako pomysł. Nowy sposób tworzenia dokumentu wymagań produktu polega na tym, że zawiera on wizję, mechanizmy oceny, opis tego, jak i kiedy rozwiązanie powinno działać, a także definicję dobrego i złego wyniku.

Jednocześnie mamy prototyp opisujący interakcję, możliwość korzystania z rozwiązania i sposób, w jaki produkt powinien zostać wyobrażony. Widzimy to w całym cyklu życia tworzenia produktu.

Galen Low: Cieszę się, że o tym wspomniałaś, bo jeszcze w zeszłym tygodniu rozmawiałem z kilkoma osobami zajmującymi się produktami i zastanawialiśmy się, czy dokument wymagań produktu umarł.

Kiedy rozmawiałem o tym z jedną z tych osób, powiedziała, że nie, ponieważ nadal trzeba mieć te przemyślenia i muszą być one dobre. Zbudowała małą aplikację, która pomaga generować dobre pomysły oraz uzasadnienie dopasowania produktu do rynku, a także określać, jakie funkcje powinien mieć produkt i które z nich są najważniejsze.

Potem łączymy to z prototypowaniem. Nadal musi istnieć wizja. AI sama nie wygeneruje wszystkich kreatywnych odpowiedzi i nie będzie to wystarczające. Nadal potrzebujesz strategicznej wizji tego, co produkt robi, jak odpowiada na potrzeby użytkowników i jak wprowadzamy go na rynek.

Podoba mi się jednak pomysł, że zmienia się charakter pracy. Znam wielu menedżerów produktu i rzeczywiście ich praca jest mocno związana z dokumentacją. To nawet stało się supermocą, ponieważ teraz większość czasu spędzają na jej edytowaniu. Dokumentacja i tak była częścią procesu, co oznacza, że można na jej podstawie uczyć AI.

Inaczej wygląda sytuacja w przypadku osób, które wcześniej niczego nie zapisywały. Teraz muszą zacząć dokumentować pracę, aby w ogóle móc czerpać z tego korzyści. W pewnym sensie menedżerowie produktu są więc do przodu. Uwielbiam pomysł maszyn tworzących pierwsze szkice. Mam jednak pytanie. W świecie projektów wiele osób mówi: „Świetnie, AI nadaje się do pierwszego szkicu”.

Czy Wasze zespoły korzystają tylko z tego pierwszego szkicu, a potem przechodzą do kolejnych etapów procesu? Czy też przekazują informacje zwrotne z powrotem do systemu, aby udoskonalać narzędzie i otrzymywać coraz lepsze pierwsze szkice na podstawie edytowanych wersji?

Jyothi Nookula: Nazywamy to podejściem jednorazowym. Ludzie zakładają, że praca z AI polega na jednorazowym przekazaniu jej informacji, otrzymaniu raportu i rozpoczęciu działania. Rzadko tak to wygląda. Zwykle otrzymujesz mocny pierwszy szkic, a następnie dodajesz własne przemyślenia i prosisz AI o krytykę, wskazanie obszarów do poprawy oraz dopracowanie.

Potem AI przedstawia swoje uwagi, a Ty możesz powiedzieć: „Ten fragment ma sens, ale z tym drugim się nie zgadzam”. To przypomina współpracę z partnerem, z którym możesz stale dopracowywać rozwiązanie, aż naprawdę dobrze ocenisz efekt końcowy. Jeśli traktujesz systemy AI jako sposób na przekazanie informacji, uzyskanie jednej odpowiedzi i natychmiastowe jej wykorzystanie, rzadko działa to dobrze.

Największą wartość widzę wtedy, gdy pracujesz iteracyjnie, przechodzisz przez kolejne wersje i je ulepszasz. Dlatego mówimy, że łatwo nauczyć kogoś, jak coś zrobić, ale bardzo trudno nauczyć go dobrego smaku. Smak nadal jest czymś, za co musi odpowiadać menedżer produktu.

Galen Low: Podoba mi się ten „smak”. Czy wiele osób myśli: „Dobrze, teraz 30% mojej pracy to nie tylko edytowanie dokumentacji, ale także rozmawianie z robotem”? Rola menedżera produktu jest przecież bardzo ludzka. Prowadzisz rozmowy i badania z użytkownikami. Oczywiście masz ogromne ilości danych, z którymi nie masz indywidualnej relacji, więc AI może bardzo pomóc.

Czy zauważasz jednak utratę ludzkiego wymiaru zarządzania produktem? Jedną z obaw może być myśl: „Spędzam większość czasu na rozmowach z robotem i uczeniu robota, a to nie jest takie samo jak rozmowa z człowiekiem”.

Jyothi Nookula: Nie wiem, czy chodzi aż tak bardzo o rozmowę z robotem. Jeśli rzeczywiście tylko Ty i system AI rozmawiacie ze sobą, to sytuacja wygląda inaczej.

Nadal musisz jednak przekonywać interesariuszy i rozmawiać z zespołem inżynieryjnym. Menedżerowie produktu znajdują się w centrum, w którym łączą różne zespoły. W pewnym sensie AI przypomina pomocnego asystenta, z którym można przeprowadzać burze mózgów. Widziałam, jak moi menedżerowie produktu, liderzy i współpracownicy z tego korzystają.

Po prostu rozmawiają z AI, aby wygenerować pomysły. To mniej robotyczne, a bardziej przypomina wykorzystanie narzędzia jako sposobu na rozpoczęcie pracy i uporządkowanie myśli. Masz jednego towarzysza, z którym możesz porozmawiać o każdej porze, 24 godziny na dobę, 7 dni w tygodniu.

Galen Low: Przyjmijmy rolę adwokata diabła. Pracowałaś w miejscach, w których jestem niemal pewien, że ktoś przyszedł do Ciebie i powiedział: „Jyothi, dlaczego po prostu nie zautomatyzujemy tego procesu?”.

Dlaczego człowiek musi uczestniczyć w tym procesie? Czy nie moglibyśmy pobrać wszystkich zgłoszeń do działu wsparcia, przepuścić ich przez agenta, pozwolić mu ustalić priorytety nowych funkcji, stworzyć te funkcje i wydać je bez udziału człowieka? Nie musisz mówić, czy rzeczywiście Ci się to przydarzyło, ale możesz.

Moje pytanie brzmi: jak przeciwstawiasz się podejściu stawiającemu technologię przed człowiekiem, zamiast podejściu skoncentrowanemu najpierw na człowieku lub użytkowniku? Zwłaszcza na poziomie, na którym pracowałaś — w dużych przedsiębiorstwach technologicznych, gdzie istnieje presja, by powiedzieć: „Nie moglibyśmy po prostu użyć tej technologii, a dopiero później ustalić, co z nią zrobić?”.

Jak przeciwstawiasz się takiemu podejściu i uzasadniasz potrzebę udziału człowieka w procesie?

Jyothi Nookula: Często się z tym spotykam, także podczas konsultowania wielu firm i w rozmowach ze studentami, którzy mówią: „Jestem w takiej sytuacji. Co mam zrobić?”. To obecnie niemal choroba. Wszyscy chcą zaczynać od AI i, niezależnie od tego, czy jest to dobre, czy złe, mam wrażenie, że zapominamy o użytkownikach i ich problemach, a zaczynamy od technologii. To bardzo sprzeczne z intuicją.

Najtrudniejsze jest to, że naprawdę trudno się temu przeciwstawić, ponieważ bodźce instytucjonalne kierują wszystkich w niewłaściwą stronę. Mamy menedżerów, którzy przeczytali te same trzy artykuły o tym, że AI ma egzystencjalne znaczenie. Inwestorzy podczas każdej rozmowy dotyczącej wyników pytają o strategię AI.

Inżynierowie są autentycznie podekscytowani — widać to podczas hackathonów. Presja, aby zrobić coś z AI, jest ogromna. Ja jednak wracam do podstawowych zasad tworzenia produktów: zaczynamy od użytkownika i problemu, a nie od algorytmu. W swoich zajęciach zawsze mówię: najpierw użytkownicy, potem algorytmy.

Kiedy ktoś przychodzi podekscytowany i mówi: „Pojawiła się nowa funkcja AI — wielomodalność, głos czy cokolwiek innego”, nie wygrasz, mówiąc „nie”. Zamiast tego przeformułowuję pytanie: „To bardzo interesująca technologia. Jaki problem próbujemy za jej pomocą rozwiązać?”.

Proszę tę osobę o opisanie problemu — nie w sposób konfrontacyjny, lecz poprzez wspólne prześledzenie dnia użytkownika. Gdzie mieści się ta funkcja? Co użytkownicy próbują dziś zrobić? Jaka jest alternatywa, jeśli tego rozwiązania nie będzie?

Zwykle dzieje się jedna z trzech rzeczy. Po pierwsze, ludzie odkrywają, że jest to rozwiązanie szukające problemu. Entuzjazm naturalnie wygasa, ponieważ nie potrafią wskazać przekonującej potrzeby użytkownika. Nie jest potrzebna żadna konfrontacja.

Po drugie, mogą odkryć, że problem jest prawdziwy, ale technologia AI nie jest najlepszym rozwiązaniem. Być może lepiej rozwiązać go poprzez lepszy interfejs użytkownika, lepsze wdrożenie, naprawę innego zepsutego procesu albo prostszą, deterministyczną technologię. Wtedy okazuje się, że AI byłaby przesadą.

Trzecia możliwość — najlepsza — polega na znalezieniu prawdziwego problemu, w którym AI rzeczywiście otwiera nowe możliwości. Wtedy pojawia się prawdziwa innowacja. W Amazonie słynnie stosujemy proces pracy od końca. Pisze się informację prasową.

Proszę menedżerów produktu i współpracowników, z którymi pracuję, aby napisali informację prasową dla tego produktu. Muszą opisać wpływ produktu i dodać przykładową opinię użytkownika. Trudno udawać, że coś jest niesamowite, gdy przechodzisz przez takie ćwiczenie. Bardzo pomaga mi to prowadzić te rozmowy.

Czasami decyzja pochodzi jednak z góry, na przykład od dyrektora technicznego, i trudno iść do niego i się z nim spierać. W takich przypadkach nauczyłam się przeformułowywać sytuację: „Dobrze, skoro mamy to zrobić, zróbmy to przynajmniej w użyteczny sposób”. Znajdźmy i rozwiążmy prawdziwy problem, zamiast walczyć z konkretnym przypadkiem użycia.

Mówię wtedy: „To świetny pomysł, ale istnieje inny problem, w którym ta technologia może być naprawdę użyteczna. Mamy dane i przypadek użycia. Zwrot z inwestycji jest jasny”. Pracuję nad wszystkimi propozycjami i mówię: „Tak, wykorzystajmy tę technologię, ale ten problem jest pilniejszy niż tamten”.

To kilka technik, które sprawdziły się u mnie na początku kariery. Kiedyś myślałam, że moim zadaniem jest chronienie wizji produktu przed rozproszeniem. Teraz rozumiem, że moim zadaniem jest kierowanie energią: wykorzystywanie entuzjazmu wobec nowych technologii i kierowanie go we właściwą stronę, ku rezultatom, które naprawdę mają znaczenie.

Problemem nie jest sam entuzjazm, lecz to, jak skierować go w sposób pomocny dla użytkowników. Zawsze wracam więc do podstawowych zasad tworzenia produktów: myśl o użytkowniku i jego problemie, zamiast zaczynać od technologii. Nie zaczynasz przecież od powiedzenia: „Otworzyłem dziś dokument Word. Co powinienem napisać?”.

Galen Low: Gdzie jest Clippy, kiedy go potrzebujemy? To była prawdziwa lekcja polityki produktowej w pigułce. Twoja perspektywa na tę rolę jest bardzo użyteczna. Znam wielu ludzi zajmujących się produktami i jako osoba od projektów również to rozumiem. Czujesz się strażnikiem i obrońcą, osobą, która ma powiedzieć „nie”, wskazać ryzyka i dopilnować, abyśmy utrzymali pierwotny kierunek.

Bardzo podoba mi się jednak pomysł kierowania energią, ponieważ może to prowadzić do dobrych rzeczy. Zainteresowała mnie Twoja trzecia kwestia: skoro już to robimy, postarajmy się przynajmniej, aby było użyteczne. To perspektywa, którą rzadko słyszę, ale jest odświeżająca i zgodna z tym, jak znam funkcjonowanie firm. Czasami, niezależnie od skali, nie masz wyboru.

Nie zawsze musi chodzić o zdobycie pisemnego potwierdzenia decyzji po to, by później powiedzieć „a nie mówiłem”. Podejście może być konstruktywne. Energia może przynieść korzyści. Pochodzę ze środowiska projektowania skoncentrowanego na człowieku, więc zawsze cieszę się, gdy ludzie wracają w rozmowie do użytkownika i jego korzyści.

To bardzo użyteczna zmiana perspektywy: spokojnie zapytać, jaki problem próbujemy rozwiązać, i zachęcić innych do takiego myślenia. To podejście jest też współpracujące. Zamiast defensywnego szukania sposobu na powiedzenie „nie” i zakulisowej polityki, można wspólnie przeanalizować sytuację i znaleźć najlepszy rezultat.

Skoro mówimy o rezultatach, kradnę pomysł z informacją prasową. To w ogromnym stopniu odpowiada pracy od końca, ale prowadzi ją jeszcze dalej — aż do informacji prasowej. To doskonały sposób na opisanie tego, co zrobiliśmy, dlaczego to zrobiliśmy i jaki był wpływ. To świetne narzędzie, aby kierować myślenie ku rezultatowi, a nie tylko ku wydaniu produktu.

Nie chodzi tylko o przyjmowanie poleceń i wykonywanie pracy, ale o wyobrażenie sobie, do jakiego rezultatu zmierzamy. Co to zrobi dla ludzi? Z czego będziemy dumni, gdy skończymy? To naprawdę świetne.

Jyothi Nookula: Uwielbiam koncepcję informacji prasowej. Korzystałam z niej przez wiele lat po odejściu z AWS i nadal stosuję ją w swojej pracy. Zmienia perspektywę.

Galen Low: Bardzo mi się podoba. To niezwykle użyteczne.

Może zakończmy rozmowę, rozmawiając trochę o przyszłości. Wydaje mi się, że przez całą tę rozmowę było widać, iż obszar zarządzania produktem mocno się zmienia. Zmieniają się same produkty, narzędzia i metody, a także oczekiwania dotyczące rozumienia technologii, biznesu i strategii realizacji.

Jakie trzy lub cztery najważniejsze rzeczy powinien mieć w CV lub portfolio menedżer produktu zainteresowany tworzeniem produktów opartych na AI, aby się wyróżnić?

Jyothi Nookula: Dziękuję za to pytanie, ponieważ jest bardzo praktyczne. Szczerze mówiąc, to, czego szukam w CV, zmieniło się diametralnie w ciągu ostatnich dwóch lat.

Pierwszą rzeczą są dowody na stworzenie czegoś z wykorzystaniem AI, a nie tylko mówienie o tym. Jako menedżerka rekrutująca lub rekruter mamy konkretne stanowisko do obsadzenia, a nie miejsce na badania. Chcę zobaczyć, że rzeczywiście wydałeś funkcję lub produkt natywnie oparty na AI.

Nie chodzi o stwierdzenie: „Pracowałem w zespole, który korzystał z AI” albo „Wspierałem strategię”. Chcę wiedzieć: jaki problem rozwiązywał ten produkt, co dokładnie robiła AI, jak ocenialiście jej działanie i jakie wnioski Was zaskoczyły?

W przypadku osób, które nie wydały jeszcze produktu opartego na AI, mówię: zbudujcie coś samodzielnie. Twórzcie projekty poboczne. Powtarzam to również na zajęciach, gdzie realizujemy wiele projektów praktycznych. Uczestnicy wychodzą z pełnym zestawem materiałów do portfolio.

Mówię im jednak, żeby nie traktowali tych prac wyłącznie jako projektów. Trzeba przekształcić je w produkty. Nie można skończyć pracy, zamknąć laptopa i odejść. Należy pokazać produkt znajomym i społeczności, pozwolić im z niego korzystać, poprosić o informacje zwrotne, a następnie ulepszyć produkt na ich podstawie.

Można dodać integrację ze Stripe i pobierać opłatę w wysokości 1 dolara lub 50 centów. Kwota nie ma znaczenia — ważne, aby produkt zaczął generować przychody, jeśli taki jest jego model. Należy przekształcić go w produkt możliwie najbardziej zbliżony do rzeczywistego. To wywrze na CV znacznie większe wrażenie niż samo stwierdzenie: „Pracowałem nad projektem AI”.

Trzeba tworzyć produkty — w pracy albo poza nią. Drugą ważną rzeczą jest pokazanie biegłości technicznej. Nie musisz być inżynierem uczenia maszynowego. Nie oczekuję, że będziesz programować. Chcę jednak zobaczyć dowody na to, że potrafisz prowadzić wiarygodne rozmowy z inżynierami o działaniu tych systemów.

W CV może to oznaczać opis wykorzystanych ram oceny, sposobu prowadzenia testów i kompromisów, które udało Ci się rozwiązać — na przykład między opóźnieniem a jakością, kosztem a możliwościami albo różnych typów modeli i architektur, z którymi pracowałeś.

Znaczenie ma język. Jeśli w CV napiszesz: „Wykorzystywałem AI do poprawy doświadczenia użytkownika”, nie powie mi to niczego. Jeśli napiszesz: „Zbudowaliśmy architekturę RAG, aby ograniczyć halucynacje w odpowiedziach działu obsługi klienta, zwiększając dokładność z X do Y”, będę wiedzieć, co stworzyłeś.

Zwykle sprawdzam, czy potrafisz wyjaśnić inżynierowi, dlaczego w danym przypadku użycia powinniśmy zastosować technikę A zamiast techniki B. Czy potrafisz również wyjaśnić interesariuszowi biznesowemu, dlaczego ta decyzja techniczna ma znaczenie i jak wpływa na wyniki biznesowe?

Jako menedżer produktu znajdujesz się na styku tych obszarów. Twoją główną rolą jest tłumaczenie możliwości technicznych na wyniki i wartość biznesową, a następnie przekładanie tego z powrotem na ramy techniczne. To właśnie taki menedżer produktu AI osiąga najlepsze wyniki.

Ostatnią, ale nie mniej ważną rzeczą jest doświadczenie w radzeniu sobie z niejednoznacznością i szybką iteracją. Produkty oparte na AI są inne. Modele są aktualizowane, a możliwości ewoluują, dlatego trzeba czuć się swobodnie w warunkach niepewności. Powinno to być widoczne w CV.

Jeśli napiszesz, że wprowadzałeś produkty od zera w szybko zmieniającym się środowisku, pokażesz, że potrafisz działać w warunkach niejednoznaczności. Ważne jest również nastawienie na eksperymentowanie: szybkie prototypowanie, testowanie i uczenie się. Dotyczy to także projektów pobocznych, które przekształciłeś w produkty.

To kilka umiejętności, które mogą wyróżnić kandydatów. Nie szukam natomiast zupy z modnych słów. Nie potrzebuję stwierdzeń typu: „Wykorzystywałem AI i uczenie maszynowe do tworzenia synergii i optymalizacji”. To nic mi nie mówi. Same certyfikaty z sześciu różnych kursów ani deklarowanie pasji do AI również nie wystarczą.

Jeśli miałabym wskazać jeden wzorzec, byłaby to szybkość uczenia się. Jak szybko potrafisz działać? Jak głęboko wchodzisz w kwestie techniczne? Czy rozumiesz, jak te systemy współpracują?

Jeśli chcesz wejść do obszaru zarządzania produktami opartymi na AI, ale nie masz bezpośredniego doświadczenia, możesz je stworzyć. Możesz coś zbudować. Nikt Ci tego nie zabrania. Jeśli w Twojej pracy nie ma okazji do pracy z AI, możesz stworzyć coś samodzielnie.

Możesz również pisać o tym, czego uczysz się podczas budowania. Gdy zaczniesz tworzyć, pojawi się wiele wyzwań. Możesz współtworzyć, przygotowywać studia przypadków produktów AI, które podziwiasz, analizować je i zastanawiać się, jak można je ulepszyć.

Bariera wejścia jest dziś bardzo niska. Nie trzeba mieć ogromnych zasobów, aby zbudować własny pomysł. W branży również niewiele osób ma dziesięć lat doświadczenia w AI, więc wszyscy wspólnie próbują zrozumieć, jak to działa.

Najbardziej wyróżniają się osoby, które rzeczywiście wykonują pracę potrzebną do zrozumienia tematu, zamiast czekać na pozwolenie.

Galen Low: To był bardzo dobry opis dylematu, który z pewnością słyszysz cały czas: „Jestem menedżerem produktu, nie powinno się ode mnie oczekiwać programowania”. Istnieje jednak warstwa pośrednia i bardzo dobrze ją wyjaśniłaś. Nie, być może nie musisz programować, ale musisz znać słownictwo potrzebne do tłumaczenia między potrzebami biznesowymi i użytkowników a konsekwencjami technicznymi.

Musisz też mieć nastawienie osoby budującej, rozumieć technologię na tyle, aby wiedzieć, gdzie pojawią się tarcia i co może pójść źle. Nie wystarczy powiedzieć: „Robiłem to, co mi kazano, pracując w dużej firmie technologicznej X, więc jestem dobrym kandydatem”. Jako menedżer rekrutujący nie wiesz wtedy, czy kandydat potrafi poruszać się w warunkach niejednoznaczności, rozumie użytkownika i mówi językiem zespołów interdyscyplinarnych, z którymi będzie pracować.

Wiesz tylko, że pracował w dużej firmie na określonym stanowisku. Mógł po prostu podążać za kimś innym, nie wykazując się odwagą, śmiałością ani szybkością uczenia się. Nie wiadomo, czy ma otwartość i energię potrzebne do zaangażowania się w ten obszar i wykorzystania go do rozwijania własnego fachu, zamiast uznania, że to problem kogoś innego.

Jyothi Nookula: Dlatego mówię: nie czekaj na pozwolenie, po prostu działaj. Bariera wejścia jest dziś bardzo niska.

Galen Low: Jyothi, bardzo dziękuję za poświęcony mi czas. To była świetna rozmowa. Zanim się pożegnamy, gdzie można dowiedzieć się o Tobie więcej?

Jyothi Nookula: Można znaleźć mnie na LinkedIn pod nazwiskiem Jyothi Nookula. Można też odwiedzić stronę nextgenproductmanager.com, gdzie opisuję kursy dotyczące zarządzania produktami opartymi na AI, agentowej AI oraz programu PM Accelerator.

Galen Low: Wspaniale. Umieszczę również te linki w notatkach do odcinka dla osób słuchających oraz w opisie dla osób oglądających. Jyothi, jeszcze raz bardzo dziękuję.

Jyothi Nookula: Bardzo dziękuję. Świetnie się bawiłam.

Galen Low: Dobrze, to wszystko w dzisiejszym odcinku podcastu The Digital Project Manager. Jeśli podobała Ci się ta rozmowa, zasubskrybuj podcast w miejscu, w którym go słuchasz. Jeśli chcesz poznać jeszcze więcej praktycznych spostrzeżeń, studiów przypadków i przewodników, odwiedź thedigitalprojectmanager.com. Do usłyszenia następnym razem. Dziękuję za słuchanie.