Product Owner w firmie produktowej z Bartoszem Lesnerem

Moja Kariera w IT: Product Owner w firmie produktowej z Bartoszem Lesnerem

Posted by wojtek on September 16, 2025 in Rozmowy · 32 mins read

Opis

W rozmowie z Bartoszem Lesnerem, Product Ownerem i Scrum Masterem, omawiamy kluczowe aspekty roli Product Ownera w firmach produktowych, w tym umiejętności, wyzwania oraz specyfika pracy w modelu SaaS. Bartosz dzieli się swoimi doświadczeniami, podkreślając znaczenie wiedzy technicznej, umiejętności miękkich oraz elastyczności w zarządzaniu produktem. Rozmowa dotyka również drogi do kariery w IT oraz mitów związanych z rolą Product Ownera.

Osoby

Transkrypcja

Transkrypcja jest generowana automatycznie

Bartosz (00:05) Rozumienie potrzeb klienta, rozumienie rynku, rozumienie tego jakie problemy produkt może rozwiązywać jest jakby podstawą, której nie można ruszyć, bo wtedy ten produkt może okazać się bezużyteczny.

Wojciech Nowicki (00:40) Zapraszam na siódmy odcinek podcastu Hospoda Tech. Dzisiaj pozostajemy w temacie mojej kariery w IT. A jeżeli IT, to nie tylko programiści. Są również ludzie, są również role w zespole, które sprawiają, że ci programiści wiedzą co mają robić. Firma wie jak tymi programistami zarządzać, no i wszystko działa płynnie. Dzisiaj o byciu product onerem w firmie produktowej porozmawiam z Bartkiem Lesnerem. Jak zawsze.

Transkrypcje, linki i wszelkie materiały do tego odcinka znajdziecie na hospoda.tech.pl, łamane na 7. Zachęcam również do subskrybowania podcastu. Jest już kilka osób, które słuchają mnie regularnie, ale wiadomo, fajnie gdyby to grono rosło. Teraz zapraszam już na dzisiejszy odcinek i życzę miłego słuchania.

Wojciech Nowicki (01:35) Moim gościem dzisiaj jest Bartosz Lesner, product owner, scrum master w filmie produktowej. Cześć Bartek.

Bartosz (01:41) Bitywaj.

Wojciech Nowicki (01:42) Na wstępie mamy dwa rodzaje firm software’owych można powiedzieć, no przynajmniej dwa. Produktowe, posiadające własny produkt i software house wykonujące zlecenia dla klientów różnego rodzaju zlecenia, tak czy to bardziej stałe, czy to zupełnie takie one off. Ty pracujesz w tej produktowej ze stałym produktem. Jak byś mógł krótko opisać właśnie charakterystykę pracy.

Bartosz (02:09) Posiadanie wewnętrznego klienta na pewno różni się wieloma aspektami. Oczywiście ta trudność zależy od tego, na jakim rynku działasz i jaki ten twój wewnętrzny klient jest. Ale mimo wszystko wydaje mi się, że w dłuższej perspektywie czasu jest to sytuacja łatwiejsza, bo można zbudować pewne relacje.

Poznaje się tych ludzi, ma się dużo większą szansę wpływu na ten produkt. Więc z mojej perspektywy praca w firmie posiadająca ten produkt jest przyjemniejsza, łatwiejsza i wydaje mi się, że w dłuższej perspektywie daje więcej satysfakcji.

Wojciech Nowicki (02:59) OK, mówisz, że jest łatwiejsza i można zbudować relacje i tak dalej. No to teraz ja tak troszeczkę z innego konta. No ale z drugiej strony dłużej żyjemy z ewentualnymi błędami naszych decyzji.

Bartosz (03:13) To prawda, ale mimo wszystko ta dłuższa perspektywa daje nam czas, oczywiście pewnie w wielu przypadkach tylko teoretycznie, na prawa tych błędów. Czy to zarówno w samym produkcie, czy to w procesach. Jeżeli mimo wszystko mamy czas na analizę tego, co się dzieje, to ten wpływ na produkt na pewno jest

większy.

Wojciech Nowicki (03:44) Ok to teraz tak przejdziemy bardziej do twojej osoby. A czym zajmuje się product owner tak ogólnie.

Bartosz (03:50) Cześć,

Wojciech Nowicki (03:50) Product Manager,

jak tu by cię nazywać.

Bartosz (03:54) Podejrzewam, że to w bardzo dużym stopniu zmienia się z firmy na firmę, ale jakby podstawową funkcją, znaczy funkcją obowiązkami product ownera jest w bardzo dużym skrócie dbanie o sukces produktu. To jest bardzo dużym skrócie i to można bardzo mocno rozwijać, ale jakby to jest osoba, która

którym głównym zadaniem jest to, od samego początku, od poziomu planowania poprzez realizację wypuszczania tego produktu na rynek i potem jeszcze przy, znaczy nie przepraszam, potem już w trakcie działania tego produktu, dbanie o jego sukces, tak bym to nazwał.

Wojciech Nowicki (04:48) No okej istnieje taki podział wiedzy na wiedzę techniczną, produktową i wiedzę domenową. Gdzie jest ten, w jakim obszarze najbardziej realizuje się tutaj product only.

Bartosz (05:03) Wydaje mi się, że dobry product owner, tak żeby tę swoją funkcję spełniał w odpowiedni sposób, musi mieć wiedzę w każdym z tych obszarów. Ja nie mówię, że to musi być bardzo głęboka wiedza, ale rozmowa z ludźmi i tutaj mówię zarówno o biznesie, jak i o developerach.

jest dużo łatwiejsza, jeżeli rozumie się, co oni do Ciebie mówią.

Wojciech Nowicki (05:35) No oczywiście to jest pewne. Najlepiej byłoby powiedzmy sobie wiedzieć wszystko i być na 100 procent w każdym. No ale wiemy człowiek ma ograniczenia. Rozmawiamy tutaj o ogólnym przypadku i teraz jeżeli miałbyś nie wiem tą całość tą jedność podzielić jakoś procentowo. Gdzie jak powinna się według ciebie ta wiedza na przykład rozkładać.

Bartosz (06:04) Znaczy tak jak wspomniałem na początku dbamy o sukces produktu. Nie ma sukcesu produktu jeżeli nie rozumie się klienta i jego potrzeb. Więc tutaj na pewno duża część procentów nie chciałbym tutaj bo to tak troszkę trzeba by się bardzo głęboko zastanowić żeby takie procenty jakieś wyciągnąć ale wydaje mi się że także

Rozumienie potrzeb klienta, rozumienie rynku, rozumienie tego jakie problemy produkt może rozwiązywać jest jakby podstawą, której nie można ruszyć, bo wtedy ten produkt może okazać się bezużyteczny.

Potem tak naprawdę dochodzi już kwestia planowania, dochodzi kwestia realizacji zmian przy tej realizacji, więc to też są bardzo ważne aspekty, ale przy tej realizacji, czy to przy weryfikacji samej pracy deweloperów, jak i przy planowaniu trochę bardziej szczegółowo tej pracy, przy ustawianiu acceptance kriteriów, trzeba rozumieć też technologię.

Jeżeli chodzi o tę technologię, wydaje mi się, że można mieć trochę mniejsze pojęcie, ale bez żadnego pojęcia byłoby bardzo trudno tą pracę wykonać.

Wojciech Nowicki (07:28) Znaczy no tu się zgodzę tak jeżeli wchodzi się w dość specyficzną branżę, branżę technologiczną to te technologie mniej lub bardziej należy rozumieć i im lepiej się rozumie technologię to tym lepiej. Natomiast no OK bo product owner generalnie mi się wydaje że może zarządzać praktycznie każdym produktem bardziej zależy chyba od.

typu, czyli jeżeli mamy produkt SASowy, Software Assess Service, czyli generalnie rodzaj firmy, jakiej ty pracujesz, to tutaj jest takie pytanie, czy w tym momencie mógłbyś product onerem w dowolnej branży docelowej, ale produktu SASowego? Czy ci eksperci do MEN wystarczą ci do tego, żeby zarządzać dobrze produktem, żeby dbać o sukces produktu?

Bartosz (08:18) Tak, tylko tutaj zależałoby od tego jaką jakość dostarczają ci produkty, ci eksperci Domianowi. Zarządzanie jako takie wydaje mi się, że się nie zmieni bardziej, nie zmieni bardzo, ale mimo wszystko chwila czasu podejrzewam, że dla każdego człowieka potrzebna do zrozumienia takiego produktu.

jest konieczna, Bo zarządzanie, ustawienie procesów tak, ale żeby mimo wszystko zacząć podejmować decyzje co do kierunków, żeby uczestniczyć w tworzeniu tej wizji, no to trzeba specyficznie produkt zrozumieć, tak? A jeżeli przechodzi się mimo wszystko z rynku na rynek i ona się różnią w jakiś sposób, różnią się ich klienci,

to trochę tego takiego przejściowego okresu właśnie na zrozumienie wydaje mi się, że jest potrzebne.

Wojciech Nowicki (09:23) Tutaj pojawia się jedno chyba z ciekawszych pytań ogólnie w zagadnieniu product ownera. Znowu można by prosto powiedzieć czym tak naprawdę zajmuje się product owner ale gdzie są rzeczywiście granice działania product ownera ponieważ według niektórych definicji czy niektórych podejść product owner jest troszeczkę bardziej jako człowiek zarządzający tym całym przepływem tego jak produkt jest tworzony ma współpracować ze stakeholderami.

ma ich ogarniać. innych podejściach product owner nie tylko powiedzmy sobie w tym pierwszym może można byłoby porównać to troszeczkę do dyrygenta orkiestry czyli generalnie zarządza wszystkim nadaje troszeczkę tego tego efektu końcowego tak to od niego oczywiście zależy. Natomiast w innym podejściu powiedziałbym że wpływ

na końcowy efekt jest dużo, dużo większy, czyli to jest nie tylko powiedzmy sobie ogarnianie tych wszystkich ludzi, bo też firmy mają różne podejście. Czasem w produkcji są wszyscy, praktycznie cały management, wszyscy tym żyją, a czasem jest to bardziej na barkach tej osoby. Jak ty widzisz tą rolę?

Bartosz (10:43) Znaczy tak, jeżeli chodzi o samą tą rolę to to pierwsze podejście jest na pewno konieczną podstawą. Tutaj się zgadzam z tym, ja tutaj może użyję trochę bardziej śmiesznego określenia, nie dyrygenta, jak dla mnie to jest taki człowiek, człowiek skrzyżowanie.

My odpowiadamy za łączenie wszystkich aspektów tego biznesu. Jeżeli chodzi o interesariuszy, to podejrzewam, że w większości przypadków w praktyce, w teorii na pewno my łączymy wszystkich ludzi tak, żeby osiągnąć później ten sukces. Tak jak wiemy, tych interesów jest wiele.

jest tyle opinii, tyle ile jest ludzi. Więc to jest jeden z bardziej trudnych aspektów naszej pracy. Ale to jest jakby podstawa, Bardzo trudna do zrealizowania i zajmująca bardzo dużo czasu. Ale wydaje mi się, że to w każdej firmie to musi być, tak? A to czy…

produkt owner ma więcej do powiedzenia, więcej do decydowania, no to to już zależy od tego jakie podejście ma firma, jak silną pozycję ma ten produkt owner i jak jak dobra jest ta wizja, którą on stara się, mówiąc prosto sprzedać,

Więc tu wydaje mi się, że na pewno nie byłbym w stanie powiedzieć, które z podejścia jest lepsze, bo to tak naprawdę trzeba by analizować case by case. Wydaje mi się mimo wszystko, że przy tak szybko rozwijającej, dynamicznej mimo wszystko sytuacji, jaką w sumie mamy na rynku cały czas,

wizja jako taka jest bardzo ważna, to jest moim zdaniem niemądre, żeby się zamykać na opinii innych ludzi, mimo wszystko 10 opinii może być niskiej jakości, nie mieć tak naprawdę żadnego przełożenia, ale może być jedna, która totalnie odwróci stolik i okaże się…

Albo nawet nie odwróci stolik, ale będzie naprawdę taką bardzo mocną, bardzo fajną wisienką na torcie, która po prostu zmieni się tak i przyłoży się na większy sukces.

Wojciech Nowicki (13:37) Ok, ja się spotkałem jeszcze z takimi ekstremalnymi przypadkami, bo tu fajnie o tym, że mówisz, że generalnie bycie product owner’em to jest w koniec końców ciężka praca i to nie jest tylko rysowanie sobie takiego tej wizji, którą byśmy chcieli zrobić i to ona ma się stać, no bo spotkałem się również z tymi, podejściami na zasadzie, że…

Product owner, czy product owner gdzieś tam wygloryfikowany na wyższy poziom jeszcze w hierarchiach, to troszeczkę jak jakiś taki, nie wiem, jak ten youtuber, czy TikToker, który tam na końcu zawsze soli mięso i on doprawia po prostu, lub ewentualnie przykład z naszego podwórka, który pewnie nie raz się pojawił każdemu w głowie, Nie lubię poniedziałku i pan dyrektor przedstawiający jeziorko.

Tutaj może bo na pewno chciałbym walczyć ze stereotypem, że a ten product owner to tam sobie tylko produkt ustawia. Tak naprawdę to ty musisz ustawić tych wszystkich ludzi wokół produktu.

Bartosz (14:43) Znaczy. Podejrzewam, że z perspektywy wielu ludzi może to tak wyglądać, ale mimo wszystko.

Ja uważam, że planowanie i wizja, czy ta część może pracy, to nie jest łatwe, ale to jest na pewno przyjemne, więc taką pracę się dużo chętnie wykonuje. A najcięższą częścią pracy produktownera, wydaje mi się właśnie jest taka…

jest komunikowanie się z innymi ludźmi, jest ta część komunikacyjna i właśnie zarządcze, bo tutaj pojawiają się jednostki, pojawia się konieczność odpowiedniego i innego podejścia, więc to jest ta, wydaje mi się, trudniejsza część, bo wymyślanie rzeczy, podejrzewam, że dla większości ludzi, znaczy ta wizja może być lepsza albo gorsza i te pomysły mogą być lepsze albo gorsze.

ale to jest ta łatwiejsza część.

Wojciech Nowicki (15:52) No tylko, że z drugiej strony tak jak sam fajnie to określiłeś, że ty dbasz o sukces produktu, to później z tego sukcesu jesteś rozliczany. Więc to tak trzeba dbać o to, żeby ta wizja miała miała sens. Okej wspomniałeś właśnie o tym, że wykonywanie tego później jeszcze. W twoim przypadku jesteś product tone’erem i pełnisz również funkcję Scrum Mastera. Jako, pracujesz w startupie wiadomo, tam trzeba czasem wiele

Bartosz (16:01) Top Round.

Wojciech Nowicki (16:21) funkcji łączyć ze sobą. To teraz porozmawiajmy rzeczywiście o tej szczególnej charakterystyce czy wyjątkowości pracy product ownera w firmie gdzie jest produkt SaaS wspomniałeś już o tym że dłużej możesz z tym wszystkim pracować ale to może zejdźmy tak troszeczkę do takiej do takiej praktyki jak to wygląda w praktyce z gram.

Kanban. No bo wiemy normalnie projekt ma początek koniec powinien być unikalny i wytworzyć jakiś efekt końcowy. U ciebie jest coś ciągłego. Czy są projekty tak naprawdę.

Bartosz (17:01) Tak dzielimy sobie pracę na projekty. Projekty jako takie dają wartość klientowi. To jest jakby podstawowe założenie naszych projektów. Często też też projekty jako takie powstają czy to z feedbacku klientów do poprzednich iteracji czy to po prostu z pomysłów.

Drugą jakby częścią przy kreowaniu, przy pomysłach jest oczywiście analiza rynku, podpatrywanie nie bezpośredniej konkurencji, ale po prostu trendów na rynku, czyli tak naprawdę adaptacja pomysłów na nasze podwórko. Więc mówiąc w skrócie, tak, my pracujemy w Scrumie. Tak jak podejrzewam każda firma, ten Scrum jest

nasz osobisty, więc nie jest totalnie by the book, ale w tej metodyce realizujemy po prostu projekt.

Wojciech Nowicki (18:11) No OK, czyli już wiemy pojawia się projekt zaczynacie go realizować. Nie wiem jest zapewne jakiś cykl tej realizacji. Jak na tyle na ile możesz nam powiedzieć jak to mniej więcej planuje.

Bartosz (18:26) Wszystko zaczyna się od pomysłu. Potem w pierwszej fazie ten pomysł jest analizowany przez biznes. Tutaj powstają pierwsze pytania. Już na tym etapie jesteśmy w stanie od tego pierwotnego pomysłu dobudowywać pewne rzeczy. Przy tej fazie, po jej zakończeniu już zaczynamy bardziej patrzeć na to od strony technicznej.

Po pierwsze, znaczy już tak naprawdę dużo wcześniej jesteśmy w stanie sobie odpowiedzieć, czy to jest możliwe do zrealizowania. Ale oczywiście jeżeli to już jest możliwe, jeżeli mamy zamkniętą tą pierwszą fazę, to zaczynamy rozrysowywać sobie flow. W jaki sposób po prostu ta funkcjonalność, ten feature ma działać. Z naszego doświadczenia wychodzi, że już

Po tym flow tworzymy designy, mock-up czy też prototypy. Tutaj pomaga nam to na, bo już na tej fazie staramy się otrzymywać feedback od klientów, więc już tutaj jeszcze przed całą pracą jesteśmy w stanie pewne rzeczy dopracowywać, jeżeli ten feedback jest na przykład…

Nie mówię, negatywny, bo nigdy nie był negatywny, ale jeżeli pojawiają się jakieś pomysły od klientów, które mogą usprawnić. No i potem przechodzimy już do planowania szczegółowego i realizacji sprinter.

Wojciech Nowicki (20:07) OK, to tak na poziomie jednego jakiegoś case’a projektu, a teraz chciałbym zapytać bardziej high level, tak, no bo normalnie w przypadku software house’ów mamy zlecenia, tak, ty tutaj nazwałeś resztę firmy swoim klientem wewnętrznym, tak, czyli tu jest takie pytanie, czy…

Wy pracujecie rzeczywiście, bo normalnie w firmie pojawi się zlecenie, to się je realizuje. Jeżeli są jakieś zajęte zasoby, to planuje się i mówi się klientowi, dobra, za dwa miesiące mam wolny zespół. Tutaj może rzeczywiście pojawia się ta łatwość, ponieważ jesteś w stanie zarządzić tym wszystkim z dużo, masz szerszą perspektywę, może nie tyle dokładność, co szerszą perspektywę.

Bo z jednej strony klient jest bardzo blisko ciebie, ten klient jest zawsze ten sam. Masz zespół, którym zarządzasz, może więcej zespołów, no to tu już jest mniej ważne. I teraz tak, ale w przypadku jednak firmy Software as a Service, gdzie mamy swój produkt, no nawet jakby to był może produkt pudełkowy, to jest to produkt, musi być jakaś wizja, więc może jest jakaś roadmapa, może jest ten Northstar. Jak tutaj tym zarządzacie, jak to wygląda?

Bartosz (21:27) Jeżeli chodzi o planowanie, tak jak powiedziałeś, mamy pewne projekty do realizacji. Jeżeli okazuje się, ten plan, powiedzmy, że realizowany z kwartału na kwartał, nagle się zmienia, to to by świadczyło o tym, że ta wizja jest albo niesprecyzowana, albo na tyle słaba, że zmienia się z kwartału na kwartał.

Więc to już by było jeżeli nie jakieś czerwone światełko to pomarańczowe które by świadczyło że gdzieś tutaj trzeba by tą sprawę przemyśleć. Jeżeli chodzi o realizację no to pytanie jest tak naprawdę w jakim stopniu produkt owner faktycznie za tą wizję odpowiada bo jeżeli jest to.

Może nie jedno władztwo, ale decyzyjność sama i jego głos jest jakby najważniejszy. to tutaj to planowanie faktycznie jest dużo prostsze. Jeżeli mimo wszystko naciski są czy to z góry, czy to z boku i pojawiają się jakieś tematy, no to tutaj jest kwestia oceny tych tematów, no bo wszyscy wiemy, czasami zdarzają się

krytyczne rzeczy. Czasami pojawiają się też

bardzo ciekawe pomysły. No więc tutaj mimo wszystko trzeba się też wykazywać elastycznością i to też jest jakby wydaje mi się, że jedna z ważniejszych cech czy to przy zarządzaniu produktem, podejrzewam, że ogólnie przy zarządzaniu. Trzeba wszystkie rzeczy na bieżąco analizować i być gotowym te swoje plany też zmieniać.

Wojciech Nowicki (23:24) Okej,

no właśnie poruszyłeś tutaj…

Bartosz (23:25) Wszystko jest kwestia jakby

wartości, ocenę tej wartości na bieżąco.

Wojciech Nowicki (23:30) OK poruszyłeś dosyć tutaj ciekawe zagadnienie bo zwykle jeżeli znowu mamy ten software house, który stoi po drugiej stronie no to często ten software house nie zajmuje się już utrzymaniem tej aplikacji a może się zajmować może się nie zajmować może to robić inny zespół natomiast jeżeli software house jeżeli ten sam zespół zaczyna się już zajmować tą aplikacją w taki sposób ciągły no to

staje się moim zdaniem troszeczkę zespołem produktowym. No ale to już w takim wybitnie zespole produktowym odpowiadacie za maintenance aplikacji, czyli to są nie tylko incydenty powiedzmy sobie, ale również bugi i również po jakieś tam drobne poprawki. Jak to wygląda, jak sobie z tym radzisz?

Bartosz (24:17) Znaczy tak, jeżeli chodzi o incydenty, to tutaj jakby nie ma wielkiego pola do popisu. Incydenty trzeba rozwiązywać i to jest największy priorytet, tak, bo oczywiście są też jakby poziomy zagrożenia, jeżeli chodzi o incydent. No ale tutaj, mimo wszystko staramy się je rozwiązywać jak najszybciej, no bo sama nazwa incydent wskazuje na krytyczność.

tego zdarzenia. Więc tutaj dla mnie incydent jest to takie zdarzenie, które w jakiś sposób uniemożliwia albo bardzo utrudnia pracę naszych klientów. Więc to jest jakby numer jeden na liście. Jeżeli chodzi o bugi, no to jest dość trudny temat, ponieważ w przypadku bugów też mamy jakby bardzo szeroką skalę ich krytyczności.

Więc to jest tak naprawdę case by case. Z mojej perspektywy i czym jakby dłużej pracuję, czym szybciej te bugi są rozwiązywane tym lepiej i to głównie tutaj chodzi też o te bugi, które przy developmencie są produkowane. Bo mimo wszystko potem wrócić do pewnych tematów jest dużo trudniej niż rozwiązywać je na bieżąco.

ale tu pojawia się problem taki, że jeżeli ma się napięty terminaż, to rozwiązywanie tych bugów może być problematyczne i tutaj komunikowanie tej potrzeby i swego rodzaju negocjacje, czy to z biznesem, czy to z innymi decydentami jest problematyczne.

Wojciech Nowicki (26:05) OK. Dzięki. Jako że jest to ogólnie odcinek nie tylko o omówieniu danych pozycji ale również o karierach w IT to takie pytanie jak to się stało że jesteś productem NER?

Bartosz (26:19) Moja droga w IT zaczęła się od pracy dewelopera.

Pisałem kod, mówiąc w skrócie kilka lat, ale mimo wszystko od pewnego momentu też została mi zaproponowana rola zarządcza, czyli tak naprawdę zaczęło się to od Scrum Mastera. Czy bardziej może nie zarządcza, bo Scrum Master nie odpowiada za takie ścisłe zarządzanie, tak jak my rozumiemy to pojęcie. No ale…

bardziej opiera się też na umiejętnościach miękkich planowaniu, pilnowaniu całego procesu. I tutaj też przy tej pracy dostrzegłem, że sobie z tym radzę, że dobrze mi to wychodzi, dostawałem pozytywny feedback i potem pojawiła się okazja przejścia już jakby w pełni od czysto technicznej pracy do bardziej właśnie zarządczej. Było to

swojego rodzaju wyzwania, chciałem się podjąć, bo byłem ciekawy jak to będzie wyglądać, jak sobie poradzę z tym i tak zaczęła się moja przygoda.

Wojciech Nowicki (27:35) Ok super dzięki to teraz takie trochę mentoringowa część tutaj dla słuchaczy. Jak zacząć karierę productonera jak w ogóle wejść w te buty.

Bartosz (27:47) To jest trudne pytanie, bo z jednej strony będzie moja odpowiedź kontrowersyjna, bo wydaje mi się, że na pewno łatwiej wejść w te buty, jeżeli ma się mimo wszystko jakiś background w IT. Ale podejrzewam, że jesteśmy w stanie spotkać wiele osób, które zaczynały swoją przygodę z tą pozycją…

nie mając za dużo do czynienia i poradziły sobie świetnie i naprawdę skutecznie tą rolę wykonują, tą pracę. Ale mimo wszystko przejście na pewno jest łatwiejsze, jeżeli ma się jakieś obycie po prostu na tym rynku.

Wojciech Nowicki (28:35) OK, ale to tylko na rynku powiedzmy sobie, czy tutaj tak jak w twoim przypadku to doświadczenie twarde techniczne.

Bartosz (28:44) To twarde techniczne doświadczenie daje bardzo dużo, ponieważ daje też perspektywę człowieka. jest tak, jak porównywałoby się, z głowy mógłbym to porównać do wojska. Jeżeli wydaje się pewne rozkazy żołnierzowi i nie wie się tak naprawdę, jak to wygląda na polu walki.

no to te decyzje mogą być totalnie, czy tam rozkazy mogą być irracjonalne. A jeżeli są irracjonalne, to są jakby w większości przypadków skazane na porażkę. Tutaj jeżeli tak naprawdę robiło się to, czyli tworzyło się jakiś produkt, te decyzje wydają mi się bardziej osadzone w rzeczywistości.

i dzięki temu będą miały lepsze skutki.

Wojciech Nowicki (29:42) Z jednej strony tak, ale mi teraz przyszło na myśl, żeby tutaj troszeczkę to skontrować taką anegdotą, że dajmy coś komuś kto nie wie, że się nie da tego zrobić. Czyli generalnie czy możemy też założyć, że zbytnie osadzenie technologiczne takiego product ownera może go troszeczkę ciągnąć w dół, bo będzie myślał, że to jest trudne do zrobienia, a tak naprawdę.

Tu trzeba myśleć o użytkownikach, reprezentować koniec końców ich interesy, bo dbanie o sukces produktu, no chyba można przełożyć właśnie o nadbanie o interes użytkownika końcowych.

Bartosz (30:22) Czyli jak najbardziej. Podstawą tego problemu jest takie, czy osoba się boi wyzwań, czy się nie boi wyzwań. Bo to, że coś jest trudne, to nie znaczy, że się tego nie da zrobić. To jest kwestia odpowiedniego rozplanowania tego projektu. I tutaj mimo wszystko ten background też daje pewną przewagę, bo człowiek jest bardziej świadomy tej trudności.

A co do anegdoty to tak osoby, które miałyby mniejsze albo żadne pojęcie mogą osiągnąć taki sukces tylko wydaje mi się, w dłuższej perspektywie, znaczy że on jest mimo wszystko krótkoterminowy, tak, że to się może udać raz, dwa, ale po jakimś czasie w taki czy nie inny sposób coś po prostu może nie wejść, tak.

Wojciech Nowicki (31:19) Ok rozumiem. No to teraz jeszcze tak troszeczkę drążąc w temacie tego jak zacząć karierę wyobraź sobie kogoś nie wiem po maturze w tej chwili. Oczywiście nie przekreślając nie wiem czy tą maturę trzeba mieć w dzisiejszych czasach do tego bo nie wiem czy w IT dalej patrzy się tylko na umiejętności czy czy czy czy wraca się do patrzenia również na skończone studia w takich przypadkach więc właśnie.

Pytanie w jakim kierunku iść, żeby zostać product owner i generalnie co można jeszcze robić po byciu product owner, gdzie ta kariera może pójść dalej.

Bartosz (31:59) Znaczy tak, jeżeli chodzi o to, jeżeli miałbym dać radę osobie, która zastanawia się czy chciałaby zostać produktownerem, to jakby pierwszą rzeczą, którą taka osoba musi spełniać, to jest mimo wszystko umiejętność komunikowania się, Jeżeli…

to sprawia tej osobie trudność. Jeżeli to nie jest w miarę naturalne i jest problematyczne, to bardziej radziłbym mimo wszystko takie osoby zostać przy ściśle technicznych aspektach naszej pracy. Także to jest taki podstawowy wymóg, bez którego spełnienia, raczej wydaje mi się, że nie ma sensu.

brać pod uwagę takie ścieżki kariery. Więc jest to swojego rodzaju paradoks, że dużo łatwiej jest, jeżeli ma się background techniczny, ale mimo wszystko te umiejętności miękkie też muszą być na odpowiednim wysokim poziomie, bo po prostu taka osoba nie będzie skuteczna. Bo od pewnego momentu te umiejętności miękkie stają się ważniejsze.

Jeżeli chodzi o ścieżkę i kolejne kroki, które można podjąć, to…

To też podejrzewam zależy od firmy, której się pracuje i też pytanie jest czy ta ścieżka ma być wewnątrz tej firmy czy na zewnątrz. Jeżeli chodzi o ścieżkę w samej firmie, to tutaj wydaje mi się, że to jest bardzo szeroki wachlarz, bo co by nie powiedzieć taka osoba zna ten produkt, zna ten rynek, jest w pewnym, znaczy nie w pewnym sposób, tylko jest ekspertem po prostu od tego produktu.

Więc tutaj ścieżka w górę jako taka wydaje mi się otwarta. Jeżeli chodzi o jakby przechodzenie między firmami, to tutaj też to doświadczenie, które się nabyło, jeśli chodzi o zarządzanie zarówno samym produktem, jak i procesami przy realizacji projektów, jak i w pewnym stopniu zarządzanie ludźmi, no to tutaj też czy to potem przechodzenie do

project managementu, czy to przechodzenie do już bezpośrednio do zarządzania ludźmi. Po takich doświadczeniach, bo co by nie powiedzieć taka osoba zajmuje się po trochę wszystkim, to daje też duże możliwości tak. I odnalezienie się w lekko innej roli nie powinno sprawiać problemów.

Wojciech Nowicki (34:53) OK to teraz już takie ostatnie pytanie. Jeden mit o byciu product onerem lub o firmach software as a service który chciałby się obalić na sam koniec.

Bartosz (35:08) To trudne pytanie.

Wydaje mi się, że to może nie od czego zaczęliśmy, ale postrzeganie tej roli właśnie jako tej, która…

wnosi takie czasami nieważne szczegóły, jest dość krzywdzące, bo mimo wszystko te osoby uczestniczą w tworzeniu tego produktu od początku do końca. Praca wymaga elastyczności, wymaga ciągłego podejmowania decyzji, zarządzania oczekiwaniami, rozwiązywania jakichś mniejszych czy większych konfliktów. Więc to wydaje mi się krzywdzące, ale…

Tak, my odpowiadamy za sukces produktu, ale co by nie powiedzieć, to przy tej pracy takie bezpośrednie sukcesy to są też sukcesy innych ludzi. Wydaje mi się, to postrzeganie tej roli, takiego, tak jak powiedziałem, to skrzyżowanie, jest takie pojęcie w sporcie drużynowym, które się nazywa

GluGuy, czyli łączący wszystko. Wydaje mi się, że warto by było postrzegać tę rolę właśnie przez ten pryzmat.

Wojciech Nowicki (36:26) czyli taki cichy bohater sukcesu.

Bartosz (36:30) Słasz w tym stylu,

Wojciech Nowicki (36:31) Super. Dziękuję ci bardzo za rozmowę.

Bartosz (36:34) Dzięki bardzo.

Wojciech Nowicki (36:35) I mam nadzieję, że jeszcze do usłyszenia.

Wojciech Nowicki (36:43) Mam nadzieję, że udało mi się przekazać wam coś wartościowego. Mam nadzieję, że po dzisiejszym odcinku rola product ownera, zwłaszcza product ownera w firmie produktowej będzie trochę mniej enigmatyczna dla niektórych. Że lepiej już rozumiecie czym tak naprawdę ta osoba się zajmuje.

i że nie jest to tak jak być może niektórym, podobnie jak mi, wydawało się, że jest to osoba, która rzeczywiście sama ustala pewne rzeczy, ale jest to bardziej ta osoba skrzyżowanie, której mówił Bartek. Przypominam, że transkrypcję odcinka znajdziecie na Hospoda Łamane na Tech, tak, siedem od numeru tego odcinka. A co za tydzień? Za tydzień pozostajemy w temacie karier w IT.

Za tydzień porozmawiamy sobie o aplikacjach mobilnych i o byciu programistą mobilnym. Nie zabraknie też wielu takich dygresji o AI i o tym, jak ta branża w tej chwili się zmienia i czy te kariery wyglądają tak, jak wyglądały 10 lat temu. Jeśli jesteś ciekawy, ciekawa tego, co będzie dalej, zasubskrybuj podcast w aplikacji, której mnie słuchasz. Wiecie, podcasty wychodzą regularnie, ale fajniej mieć taką przypominankę.

Zostaw komentarz, wystaw ocenę, daj lajka. Jest nas coraz więcej, znaczy no was jest coraz więcej, chociaż ta grupa wiadomo na samym początku rośnie dosyć powoli. Fajnie byłoby, gdyby poza tymi subskrypcjami był jeszcze jakiś taki bardziej aktywny feedback od was. Wiedziałbym też na przykład z komentarzy czego oczekujecie, co się podobało, co się nie podobało, co powinienem poprawić. Przypominam, że…

Znajdziecie mnie również na Facebooku, znaczy nie mnie, a podcast. Znajdziecie podcast na Facebooku, na Xie czy BlueSky App. A teraz dziękuję już za dzisiaj i do usłyszenia.