Platform/Infrastructure Product Manager – o umiejętnościach i wyzwaniach w świecie AI

Jest gro feature'ów, które może nie są turbo seksowne, a turbo istotne. Szczerze, w sensie ciężko mi sobie wyobrazić bycie Platform Product Managerem, którąkolwiek z tych definicji jakby nie przyjmiemy, którą mówiliśmy, nie znając przynajmniej jakichś takich podstaw technologii. Chociażby jak weźmiemy sobie taką metrykę latency, Czyli gdzieś tam, jak szybko jesteśmy w stanie przesył danych w platformie przekazywań, czy weźmiemy sobie Spotify, czy weźmiemy sobie YouTube, banki wszystkie. My w Silonisie też mamy taką sytuację, że tak naprawdę często nasi klienci uzależniają swoje biznesy od tego, jak szybko będą dane przesyłane, powiedzmy z Source System, gdzie te dane są zasysane, czyli z SAP, Oracle, Salesforce.

Tomek z Product Academy i też właściwie od września zaczynam nową rolę, ale na razie nie zdradzam. Brzmi intrygująco. W startupie, jeszcze nie do końca publicznym, ale za jakiś czas pewnie będę trochę więcej o tym być może mówił. Więc w sumie to jest pierwsze miejsce, w którym mówię, że wracam gdzieś do headowania. Będzie gorąco. Fajnie, no to słuchajcie dzisiaj będziemy trochę rozmawiać sobie troszkę takiej mroczniejszej, nie jedni by powiedzieli, stronie product managementu albo bardziej takiej technicznej, czyli o tym kim są platform product managers albo infrastructure product managers. No właśnie, przygotowując się zastanawiałem się jaka jest różnica pomiędzy Platform Product Manager a Infrastructure Product Manager.

Ja przyznam szczerze, że personalnie spotkałem się z takimi sytuacjami w swoich rolach, że pracowałem dla produktu, który Platforma Infrastructure Product Manager o umiejętnościach Z osobami, które chcą znaleźć przejazd. To więc jest to gdzieś tam w pewien sposób produkt, którego celem jest budowanie wartości biznesowej przez efekt sieciowy. Z drugiej strony, chyba Wojtek, w twojej strony bliższe są tego produkty bardziej techniczne, które budujemy gdzieś tam dla wewnętrznych klientów, które wzmacniają tak naprawdę produkt przez infrastrukturę.

Jak wy to rozumiecie i kiedy pierwszy raz spotkaliście się w ogóle z takim pojęciem w waszej historii? Ja to rozumiem w ten sposób, że jeśli chodzi o platformę versus infrastrukturę, to może o tej drugiej łatwiej zacząć. Wydaje mi się, że Jako startup, duża organizacja chcemy dostarczać szybko. Czy wybierzemy sobie jakieś feature związane z AI czy inne, to chcemy mieć szybki time to market. Dla mnie infrastruktura to jest wszystko to, co związane z naszym Continuous Integration, Continuous Delivery i tym, jak te procesy mogą być szybsze, bardziej efektywne i też jakby komunikacja w jakiejś tam drabince stakeholderów, czyli nasz jakby bread and butter.

Natomiast platform to jest chyba taka rzecz, którą teraz bardziej robię, bliższa mojemu sercu, bo... Jest gro feature'ów, które może nie są turbo seksowne, a turbo istotne. Na przykład kwestie supportu różnych baz danych. Z punktu widzenia IBM'a, z punktu widzenia dużych jakby też price'owych klientów, to jakby to może być jakiś

Jakby deal breaker, czy masz, czy nie masz, jakby supportuje jakieś tam bazy. Więc ja to tak czuję, czyli infrastructure, odpowiadając sobie na pytanie, no dobra, no to co zrobić, żeby dostarczyć szybciej to oprogramowanie, Platform, czyli dla mnie wszystkie techniczne prerequisite, komponenty, które powodują, że nasz tech stack jest nowoczesny, dostarczamy szybkie, sprawne oprogramowanie.

Ja nie wiem, czy mam jakąś taką silną tutaj spojrzenie na to. Wydaje mi się, że w ogóle takie platform, product, teams są albo rozumiane, tak jak ty Marcin mówisz, z jednej strony po prostu budujące platformę dla różnych użytkowników końcowych, ale nie wiem, czy to wtedy nie jest po prostu taki marketplace bardziej. Czasem nazywa się też platformę dla innych, bo jest po prostu platforma techniczna, więc jakby użytkownikami końcowymi są, nie wiem, inni deweloperzy. Niektórzy tak to nazywają. Ale chyba taką popularną rzeczą, która ostatnio sprawiła, że zaczęły pojawiać się platform Teams i platform product managerowe, to jest chyba Team Topologies. I tam jest w tych topologii zespołów po prostu wykształcona jeden z typów zespołów jako platform właśnie Team.

I tutaj ja się posłużę ich definicją. Oni mówią, że to jest zespół, który buduje i utrzymuje wewnętrzną platformę dla innych zespołów produktowych, Stream Aligned Teams, czyli jakby tych, które pracują pewnie na konkretnych outcome'ach, które są związane z danym streamem prac. To są te zespoły, natomiast bardzo często one pracują nad jednym produktem i potrzebny jest ktoś, kto trochę spija, spaja, daje im serwisy jakieś takie core'owe, które umożliwiają to, że te zespoły między sobą się ze sobą nie gryzą na przykład. No i to widzę jakby w ogłoszeniach o pracę. Jeśli ktoś pisze często o Platform Product Manager, że szuka, to bardziej chyba tego typu osoby, która właśnie za tego typu platformy odpowiadała.

Ja się bliżej spotkałem w ogóle z tym pojęciem i właśnie takim patrzeniem na to, jak coachowałem właśnie Platform Product Managera, który przyszedł do mnie i właśnie mnie pyta, Tomek, powiedz mi, jak sprawić, żebym był Platform Product Managerem, bo byłem, w sumie był tym Platform Product Managerem, ale nie był tak nazwanym. I to było takie ciekawe, bo bardzo mocno się zagłębiłem w ogóle w ten temat wtedy. I rzeczywiście okazało się, że jest sporo osób, które pracują właśnie na takich stanowiskach, nie? Budujących platformy wewnątrz. Właściwie takie core produktu, które dzięki temu, że jest tym corem, daje usługi tym Stream Align. No i to jest teraz mocno promowane w wielu większych organizacjach, żeby mieć taki zespół platformowy do tego. Ja nie wiem, nie mam silnych spojrzeń, czy to rzeczywiście super działa.

Wydaje się sensowne. Infrastructure bardzo widziałbym, bardziej widziałbym, no w niektórych być może firmach właśnie ten platform to będzie infrastructure, ale w tym, co ja się spotkałem, to jest właśnie to bardziej to, co Wojtek mówił, nie? Czyli tacy, którzy pomagają w tym, żeby no dostarczać po prostu software szybciej. W moich jakichś tam scale-upowych środowiskach to są często były zespoły po prostu DevOpsowe, które po prostu pozwalały, żeby zespoły deweloperskie szybciej dostarczały gdzieś kod. Natomiast w ogłoszeniach bardziej spotykam się z tą pierwszą jakby taką koncepcją. Na pewno jest tak, że to jest też bardziej techniczna rola i ta rola PMA się różni od takich... Jeśli myślisz sobie, że będziesz robił jakiś feature discovery i interview z klientami, to możesz się przeliczyć, możesz ich robić zdecydowanie mniej w takiej roli.

Ja właśnie Tak traktuję zespoły bardziej właśnie te platformowe, to co mówisz, bo ja na przykład byłem PM-em platformy, tak, Sentium Automate Platforma, my to tak nazywaliśmy, dla enterprise'owych klientów i to rzeczywiście była platforma, ale teraz czy ta moja praca była jakaś zupełnie inna niż typowego Product Managera, którym wcześniej byłem? Od strony takiej produktowej niespecjalnie. To był po prostu bardziej techniczny produkt, a nie tak, że udostępnialiśmy innym zespołom jakieś dedykowane usługi. Jak widzę to, gdzie trochę się różni to, to wtedy, kiedy tę platformę nazwałbym korową częścią produktu albo jakąś platformą wewnątrz organizacji, która udostępnia rzeczy innym zespołom.

Ok, no to gdzieś tam mamy już pewien fundament tej dyskusji, czyli wiemy, że jest to bardziej taka strona techniczna tych produktów, który umożliwia tak naprawdę lepszy efekt biznesowy dla zespołów, które są bardziej wyeksponowane frontem do klienta, że tak powiem. No ale wciąż gdzieś taki platform albo Infrastructure Product Manager jednak ma takiego swojego użytkownika, który musi zadawać konkretne pytania. I zakładajmy, że może to być właśnie czy to ten techniczny deweloper, któremu chcemy usprawnić infrastrukturę, aby była ona jeszcze bardziej skalowalna, aby była jeszcze bardziej niezawodna, albo może CTO danej firmy. Jak to było w waszych przykładach, Tomek albo Wojtek, jak pracowaliście właśnie przy produktach?

Wchodząc w tę rolę bardziej technicznego produktu albo feature'u, co było dla was ważne, jak zadawaliście pytania tym osobom? W przypadku tak typowo platformy wewnętrznej, to użytkownikiem końcowym był deweloper albo zespół obok, który był i to było dosyć ciekawe. Z jednej strony fajne, bo masz użytkowników przy sobie w organizacji i bardzo łatwo możesz ich znaleźć. Czasem te platformy były skalowane na inne zespoły oczywiście. Nie zawsze to musiała być platforma używana przez deweloperów wewnętrznych, czasem oczywiście na zewnątrz. Natomiast jeśli to było wewnętrznie, to łatwo było znaleźć tego użytkownika i łatwo było z nim rozmawiać, więc takie discovery mogło być dużo bardziej jakościowe w takiej sytuacji i bardziej skierowane na to, że nie mam problemu z pozyskaniem użytkownika do testów, do tego, żeby z nim rozmawiać, do tego, żeby z nim współpracować.

Może nie zaskoczony, ale rzeczywiście to było takie fajne w tej pracy. No i trzecia sprawa, żeby z nimi rozmawiać, no to jednak trochę tych technologii trzeba było znać i bardzo ciężko byłoby pewnie rozmawiać jakby z takim użytkownikiem na tylko poziomie takim biznesowym, powiedzmy. Trzeba było być trochę technologicznie obeznanym. Dla mnie to było tyle fajne, że gdzieś tam jestem po informatyce, przez chwilę byłem programistą, To ułatwiało, nie, te rozmowy. I szczerze, w sensie ciężko mi sobie wyobrazić bycie Platform Product Managerem, którąkolwiek z tych definicji jakby nie przyjmiemy, którą mówiliśmy, nie znając przynajmniej jakichś takich podstaw technologii. Nie trzeba być oczywiście od razu inżynierem, dużo można teraz się, nie wiem, nauczyć dzięki temu, że pogadam sobie z czatem GPT.

Ale te koncepty podstawowe trzeba gdzieś rozumieć i mówię szczerze rozumieć, jakby nie tylko wiedzieć, ale rozumieć właśnie jak działają. Dodając do tego, co Tomas powiedziałeś, to z mojego doświadczenia w Zendesku to wyglądało tak, że masz n różnych zespołów, które Czasami mają jakby konfliktujące cele czy konfliktujące jakieś priorytety, więc jakby jako pewnie PM musisz zrozumieć, Jakby ich priorytety i no co z tego wynika i zrozumieć tam jak powiedziałeś o tym rozumieniu technologii i zrozumieć co z tego wynika właśnie dla technologii, dla platformy, dla

Podobał mi się ten odcinek. No więc tak, ci stakeholderzy są może łatwiej dostępni, ale często tych celów jest dużo, są konfliktujące i twoim zadaniem jest jakby dobrze zrozumieć, okej, no to co one znaczą technologicznie dla platformy i czy my chcemy taki trade-off płacić na przykład. No to co mówicie jest ciekawe, bo zastanawiam się tylko, ja ze swojego doświadczenia też wiem, że

Łatwo jest rozmawiać też z tymi technicznymi osobami, które są często skore właśnie do dzielenia się kontekstem na temat swoich problemów, ale koniec końców gdzieś tam zawsze stoimy przed tym zadaniem jakiejś takiej priorytetyzacji tego, który z tych problemów technicznych jest istotny mniej lub bardziej. Ja właśnie patrzę sobie na ostatni post, który wrzuciła właśnie Melissa Perry, Czyli jedna z takich influencerek powiedzmy w świecie product managementu. Kilka dni temu właśnie w poście napisała, że jedną z największych takich gap w organizacjach dzisiaj są właśnie bardzo doświadczeni product platform PMI, którzy z jednej strony są w stanie zrozumieć te cele biznesowe,

Zanim odpowiem, to jeszcze nawiązując do tego postu. Wydaje mi się, że taką kompetencją, która ona mówi o bardzo doświadczonych PM-ach i to też może jest jakiś ciekawy wątek, bo Myślę, że jest mała szansa, żeby być jakimś takim dobrym platform PM-em na początku swojej kariery, bo wymaga to pewnego doświadczenia i pewnego takiego bullshit detectoru właśnie związanego z doświadczeniem, związanego z jakąś A jeśli chodzi o jakiś taki framework priortyzacji, o który pytasz,

Są jeszcze dalej niż u tradycyjnego PM-a, nie? Już u nas jakby ciężko przełożyć to bardzo często na taki impact biznesowy, czy coś przyniesie nam konkretny przychód, jakiś ROI, zwrot z tej inwestycji, nie? Bo wpływ mamy tak naprawdę na zachowanie użytkowników. A tam jest jeszcze dalej bardzo często, bo jest jeszcze ten krok wcześniejszy. I to, co ja gdzieś obserwuję, to że To jest jedno z największych wyzwań Platform PM-ów, czyli żeby udowadniać, którą inicjatywą warto było się zająć. I jest to dużo proste po tej stronie kosztowej, czyli żeby pokazywać, że obniżymy czymś koszty. I to może nie chcę powiedzieć, że jest proste, ale dużo prostsze. W wielu inicjatywach da się pokazać, że jak coś zrobimy trochę inaczej, to zaoszczędzimy nasze sprzęcie na przykład.

Jak zrobimy rzecz Y, to zaoszczędzimy np. jakieś zespoły będą potrzebowały mniej czasu na wytwarzanie jakiejś części oprogramowania. I to jest jeszcze w stanie tak w miarę pokazać. Gorzej jest po tej drugiej stronie P&L, w tej części takiej profitowej. Może, trzeba sobie powiedzieć jasno, że jakby to, jesteśmy w stanie to liczyć tylko tą częścią L PNL-a, nie? Nie wiem, ale znam wielu Platform Product Managerów, którzy bardzo mają z tym duże wyzwanie, o, tak bym powiedział, czyli pokazywaniem tego profitu i to też wiąże się potem z kolejną rzeczą. Że kiedy przychodzi do trudnej sytuacji w firmie i zaczynamy coś ciąć, no to niestety jakby tu jest to centrum takie bardzo mocno pokazywane kosztowe i czy my rzeczywiście tego platform PM-a i zespoły platformowe, czy my rzeczywiście potrzebujemy.

No i znam kilku, kilka osób, które właśnie na tym dosyć mocno ucierpiały, nie? Że to niestety były pierwsze zespoły do odstrzału, no bo no wy tu generujecie koszty, ewentualnie trochę ograniczacie koszty. Z drugiej strony, jeśli pokazać ograniczenie kosztów, to może być fajne w takim momencie, ale jeśli nawet tego nie jesteśmy w stanie, to jest bardzo trudne. I to jest, wydaje mi się, jedno z największych wyzwań. Pokazywanie pozytywnego wpływu na organizację. No właśnie, są takie produkty, jak właśnie weźmiemy pod uwagę, chociażby jak weźmiemy sobie taką metrykę latency. Czyli gdzieś tam, jak szybko jesteśmy w stanie przesył danych w platformie przekazywań, czy weźmiemy sobie Spotify, czy weźmiemy sobie YouTube, banki wszystkie. My w Silonisie też mamy taką sytuację, że tak naprawdę często nasi klienci uzależniają swoje biznesy od tego, jak szybko będą dane przesyłane, powiedzmy z Source System, gdzie te dane są zasysane, czyli z SAP, Oracle, Salesforce.

To jest taka anegdotka statystyczna o mierzeniu średniej. Załóżmy, że mamy mecz piłki nożnej I liczymy sobie średnią przychodu tam jakiegoś tam widza i wychodzi nam, że każdy tam ma, nie wiem, 7 tysięcy złotych na to na przykład. I wchodzi na stadion, na nasz stadion piłkarski Bill Gates, no i okazuje się, że wszyscy jesteśmy milionerami na stadionie, statystycznie przynajmniej. No więc tak, więc to jest też ciekawe z punktu widzenia platform PMA, co się dzieje, jak właśnie na taki stadion, na taką infrastrukturę wejdzie taki outlier, taki uber, no i jakie są konsekwencje tego, więc

To są ciekawe case, ale które pojawiają się jakby w pewnym rozmiarze. No tak, w pewnej skali i w pewnym też jakby przemyśleniu jaką właśnie, wrócimy do tej topologii, jaką topologię zespołów chcemy mieć w organizacji, bo to jest wszystko plusy i minusy. Możemy iść w stronę zespołu jednego wielkiego produktowego, który czuwa nad całym produktem. Możemy iść w stronę platform team i tych właśnie streamowych zespołów. To też jest spoko, ale z drugiej strony buduje właśnie to takie dużą zależność od tego platform teamu, czy to dobrze, czy źle. Ma to swoje plusy i minusy, nie? Pozwala na przykład zmniejszyć zależności między poszczególnymi zespołami tymi streamowymi i z drugiej strony trochę sprawia, że każdy z tych zespołów może za chwilę będzie iść w swoją stronę, nie?

Bo to byłby gigantyczny koszt. No i jakby będąc PM-em muszę być tego a świadomy, a b podejmować świadome decyzje razem z zespołem jakby w tym kontekście. Więc to będzie miało w przypadku produkt managerów zajmujących się AI-em, to będzie miało bardzo, ma i będzie miało bardzo duże moim zdaniem znaczenie. No i to się mocno wiąże jakby z tym platform PM-em, bo w sumie te rzeczy machine learningowe, AI-owe są pewną platformą jakby z której gdzieś korzystasz, nie? I to myślę, że będzie w tą stronę... Tak to trochę wygląda. W którą stronę to będzie szło? Wyjmujemy oczywiście jakąś tam szklaną kulę, ale ja osobiście uważam, że będzie chyba coraz mniej przestrzeni w najbliższych latach na takich generycznych

Więc wydaje mi, że w tą stronę będzie trochę zmierzać. Trochę takiej strony specjalizacji i platforma lub AI będzie, znaczy AI pewnie docelowo wszyscy będą musieli trochę z tego umieść, natomiast na pewno będzie też taka specjalizacja jeszcze lepszego wykorzystania właśnie modeli, tak jak teraz jest platformy. W sensie taki platform PM, tylko tutaj będzie dodatkowo, być może platformy PM-owie to przejmą, że jeszcze jakby ten klocek związany z AI, jak to lepiej jakby wykorzystać, żeby Wewnątrz organizacji lepiej to wykorzystywać, żeby, nie wiem, robić to takie developer experience, czy to u nas wewnątrz organizacji związane z AI, czy gdzieś na zewnątrz, jeśli tworzymy platformę zewnętrzną. Mega ciekawe to, co mówisz, bo dokładnie mieliśmy podobny właśnie use case teraz ostatnio, w którym ewaluujemy właśnie, czy warto wykorzystywać AI do tego, co chcemy, czy nie. No i te dyskusje na temat kosztów potencjalnych versus korzyści, to jest po prostu coś niesamowitego.