W branży IT (choć podobno nie tylko) występuje odwieczny problem nieustannej walki między biznesem a technologią. Jak świat długi i szeroki, tak deweloperzy uważają biznes za niekompetentnych głupków, którzy nie wiedzą czego chcą, a biznes z pogardą traktuje deweloperów, dla których każda „prosta” rzecz jest problemem 😉
Pomiędzy tymi dwoma światami, razem z liderem stoi nasz dzisiejszy gość – Senior Product Owner – Jarosław Burda, z którym przez ostatnie 7 lat zrobiliśmy z sukcesem wiele projektów dla największego ekosystemu eCommerce w Europie centralno-wschodniej.
Jarek opowie o tym, jak wygląda praca na pograniczu biznesu i technologii, jak skutecznie dbać o relacje w pracy oraz jak wykorzystać potencjał żywych ludzi w dobie AI – bo jak się okazuje, ludzie mają większy potencjał niż może Ci się wydawać 😉
Gość odcinka:
Jarosław Burda – Senior Product Owner, współpracujący z Krzyśkiem i Pawłem od ponad 7 lat.
Karierę rozpoczął jako programista, ale jego rosnące zainteresowanie zadaniami biznesowymi skłoniło go do eksplorowania ról takich jak analityk systemowy i kierownik projektu. Ostatecznie odnalazł swoją pasję w zarządzaniu produktem.
Co istotne, Jarek ma również doświadczenie jako nerd menedżer, co daje mu cenną perspektywę na potrzeby i trudności zespołów deweloperskich.
Z tego odcinka dowiesz się:
- Co tak naprawdę robi Product Owner?
- Dlaczego jako lider, potrzebujesz mieć partnera w postaci Product Ownera?
- Jak zmotywować zespół deweloperski do pracy?
- Po co Product Ownerowi zespół deweloperski, skoro może wygenerować kod samemu przy użyciu AI?
- Czy AI zastąpi programistów?
- Do czego narzędzia AI się dziś świetnie sprawdzają i gdzie warto z nich korzystać?
i wiele więcej 🙂
🚨 Potrzebujesz pomocy w pracy lidera?🚨
Zostały ostatnie miejsca na współpracę z nami!
Wypełnij formularz na stronie https://nerd.management/konsultacje
i dogadamy szczegóły!
Agenda:
00:00 – Intro
00:58 – Wprowadzenie
02:06 – Wywiad z Jarosławem Burdą
03:11 – Jak sprawić by zespół developerski wziął odpowiedzialność za efekty swojej pracy?
06:09 – Jaką metodologie pracy najlepiej przyjść w zespole?
08:11 – Jak PO może pracować z zespołem deweloperskim?
09:38 – Jak zmotywować zespół do pracy?
13:34 – Czy każdy członek zespołu musi się angażować w produkt?
16:53 – Co dziś PO może zrobić sam?
21:40 – Czy AI zastąpi programistów?
24:30 – Jaki jest dziś największy problem w firmach?
31:24 – Jak skutecznie pracować z Product Ownerem?
33:49 – Podsumowanie
Wersja do słuchania
Linki
Książki
- Książka: Transformed: Moving to the Product Operating Model – Marty Cagan
- Książka: Empowered – Marty Cagan
- Po co zespołom deweloperskim jest PO? – Shreyas Doshi on X about Product Manager role
Jak zespoły deweloperskie mogą angażować się w pracę nad produktem:
- SVPG ‘The Product Operating Model: An Introduction’
- Marty Cagan – Product vs Feature Teams
- Lenny’s Newsletter – Improve strategy, influence, and decision-making by understanding your brain – Evan LaPointe (founder of CORE Sciences)
Czy AI zastąpi Product Ownera?
- AgileByExample 2024: Craig Larman – AI & HR
- Lenny’s Newsletter – Building Lovable: $10M ARR in 60 days with 15 people – Anton Osika (CEO and co-founder)
- Andrej Karpathy’s thread on X (2023) – The hottest new programming language is English
- Andrej Karpathy’s thread on X (2025) about vibe coding
Czy Product Owner będzie potrzebował zespołów deweloperskich?
- Birgitta Böckeler – The role of developer skills in agentic coding
- Sichu Zhang – How much faster can coding assistants really make software delivery?
Transkrypcja odcinka
[00:00:58.06] – Krzysztof
Cześć, witamy w Nerd Management. tutaj Krzysztof Rakowski…
[00:01:01.11] – Paweł
…i Paweł Rekowski.
[00:01:02.21] – Krzysztof
Dzisiaj mamy jeden z tych odcinków, które bardzo lubimy, czyli wywiady z gośćmi, spotkania z gośćmi. A dzisiaj naszym gościem jest osoba wyjątkowa dla nas osobiście, bo jest to osoba, z którą pracujemy już bardzo, bardzo, bardzo długo. Paweł, kto jest Twoim gościem?
[00:01:18.21] – Paweł
Moim gościem dzisiaj jest Jarosław Burda, Senior Product Owner w eMAG, z którym pracowałem przez ponad sześć i pół roku. To była świetna współpraca i bardzo Jarka cenię jako specjalistę, eksperta Product Ownera z takim prawdziwym zacięciem. Jarek jest osobą, która ma background techniczny. Zaczynał pracę jako developer, był analitykiem z różnych pieców chleb jadł, aż finalnie jego pasja skierowała go w stronę zarządzania produktem. Miał też epizody, kiedy zarządzał ludźmi, więc ma perspektywę bardzo szeroką od strony zarządzania procesem, projektem, zespołami. I rozmawiamy o tym, w jaki sposób to, co się obecnie dzieje z technologią, z AI, może wpłynąć na pracę i Product Ownera i zespołów developerskich i jak razem wypracować wspólne rozwiązania, aby nam się żyło lepiej.
[00:02:04.09] – Krzysztof
Bardzo soczysty wywiad. Oglądajcie.
[00:02:06.23] – Paweł
Cześć Jarek. Miło Cię widzieć.
[00:02:08.08] – Jarosław
Cześć, Paweł.
[00:02:09.05] – Paweł
Dzięki wielkie, że przyjąłeś zaproszenie do podcastu Nerd Management. Powiedz, nam taką rzecz, bo ty jesteś Product Ownerem z krwi i kości, jesteś Senior Product Ownerem, jak już mówiliśmy z Krzyśkiem i od strony lidera, lidera zespołu, lidera technicznego. Powiedz mi, po co tak naprawdę jest Product Owner?
[00:02:26.20] – Jarosław
Niektórzy myślą w ten sposób, że jak jest jakiś problem, to warto mieć jakąś osobę, która w pełni odpowiada za ten problem, za rozwiązanie tego problemu. No, ja właśnie jestem takim product ownerem, który bierze odpowiedzialność za rozwiązanie jakiegoś problemu.
[00:02:40.15] – Paweł
Jak to z Twojego doświadczenia jest, jeżeli chodzi o zespoły developerskie? No bo to jest część taka projektowa, produktowa, w zależności od firmy, bo to też jest różnie. Jak to z twojego doświadczenia wygląda, jeśli chodzi o współpracę z deweloperami? Bo mi się wydaje, tak z mojego doświadczenia, że to jest różnie, że z odpowiedzialnością u deweloperów to jednak jest nie do końca tak, jak ludzie by chcieli w biznesie. A z drugiej strony deweloperzy myślą, że ten biznes to są głąby i w ogóle oni niczego nie rozumieją. Jako product owner stoisz pośrodku. I teraz jak ty sobie z tym radzisz? Jak te światy połączyć?
[00:03:11.21] – Jarosław
Po pierwsze to jest taka kwestia, żeby zbudować jakąś taką synergię i współodpowiedzialność za ten problem, który się rozwiązuje. Tak na koniec dnia, tak jak wcześniej powiedziałem, ten problem jest na barkach Product Ownera. Natomiast ten zespół techniczny jest od tego, żeby przede wszystkim wspierać te rozwiązania od strony technicznej. Zespół techniczny odpowiada za rozwiązanie techniczne tego problemu, natomiast z perspektywy Product Ownera jest niezwykle istotne, żeby ten zespół też zaangażować po to, żeby on użyczył swoich umysłów w tej całej podróży związanej z tym problemem, produktem, rozwiązaniem.
[00:03:49.06] – Jarosław
Bo ta historia zaczyna się od tego, że problem został w jakiś sposób wstępnie zdefiniowany. Może jakieś objawy tego problemu zostały zauważone i te objawy, ten problem został przydzielony do rozwiązania temu Product Ownerowi. Albo Product Owner wręcz sam zauważył jakiś obszar, który wymaga rozwiązania. No i wtedy się zaczyna taka podróż. Podróż przez to, żeby ten problem na początek dobrze zrozumieć. Można sobie wyobrazić, że taka osoba zanurza się samodzielnie w ten problem i ten problem w jakiś sposób waliduje, uczy się, rozmawia z użytkownikami, rozmawia z biznesem, szuka danych i próbuje ten problem jakoś określić i ponownie zdefiniować, zredefiniować, zwalidować.
[00:04:30.24] – Jarosław
Natomiast bez wsparcia zespołu inżynierskiego to zawsze jest gorsze, bo rezultat jednej pracy, jednego umysłu chociażby był wybitny, z reguły powiedzmy jest trochę gorszy niż ten wynik takiej synergii różnych umysłów. I to, na co ty właśnie zwracasz uwagę przy budowaniu zespołów, że te umysły są jakoś zdywersyfikowane, że ludzie mają różny background, mają różny wiek, mają różne doświadczenia za sobą. Bogactwo i różnorodność tych umysłów sprawia, że rozpoznanie tego problemu i jego eksploracja jest dużo bardziej skuteczna.
[00:05:06.12] – Jarosław
Także poza tym, że zespół odpowiada za rozwiązanie techniczne, to jeszcze użycza swoich umysłów, swoich mocy obliczeniowych. Każda z nich jest trochę inna po to, żeby żeby ten problem dobrze zbadać i dobrze go zrozumieć i ponownie zredefiniować. Bo wstępne rozumienie problemu często jest różne od tego wynikającego z tego, powiedzmy, naukowego podejścia do jego eksploracji.
[00:05:29.16] – Paweł
Ciekawą rzecz powiedziałeś odnośnie podejścia naukowego czy różnego typu zasad, workflow, sposobów pracy w projektach, Bo to jest często tak, że mamy ten Agile, Scrum czy Kanban, Waterfall, Prince, metodologie i tak dalej. No ale gdybyś Ty miał powiedzieć, jaka forma z Twojej praktyki, współpracy z zespołem developerskim, współpracy z liderem jest najbardziej skuteczna, najbardziej praktyczna i najłatwiejsza do zastosowania wdrożenia. Bo z mojego doświadczenia jest tak, że jak ludzie zaczynają się skupiać na książkach opisujących procesy, to nie dość, że nic nie robią w tym czasie, a później i tak ten proces do nich nie pasuje, to jak to jest z Twojego doświadczenia?
[00:06:09.17] – Jarosław
Z mojego doświadczenia to wygląda trochę tak, że ten zespół to musi sobie poukładać sposób pracy taki jak najbardziej rezonuje w tym zespole. Z mojej perspektywy istotne jest, żeby ten proces był taki iteracyjny. Żeby pozwalał na szybko wkładać rzeczy do procesu, szybko je walidować i szybko też dostawać w jakiś sposób rezultat tej walidacji. To nie może być taki proces, który zabetonujemy na Scrumie, że można 8 tygodni betonować. No ale im krótsza jest ta kadencja betonowania tego procesu, tym lepiej dla budowy produktu, rozwiązania problemu.
[00:06:48.20] – Jarosław
Drugi element jest taki, żeby w tym procesie była okazja, żeby ten proces sprzyjał tej synergii umysłów, o której wcześniej wspominałem, żeby była intensywna komunikacja, żeby to daily, które zwykle we wszystkich tych metodykach występuję, żeby to daily nie było jedyną okazją, kiedy ten zespół ze sobą się komunikuje.
[00:07:07.15] – Jarosław
Czyli iteracyjność, łatwe wkładanie rzeczy do procesu oraz synergia umysłów. To są chyba takie kluczowe właściwości procesu. I oczywiście można się opierać o Scruma i Kanbana. Może właśnie na początek warto, kiedy ten zespół jest sformułowany. Warto podejść tak bardzo kanonicznie do tych metodyk, żeby nałożyć na siebie wszystkie te ograniczenia i żeby tę płaszczyznę zbudować tak w pełni.
[00:07:32.08] – Jarosław
Natomiast z czasem zespół, ucząc się pracy ze sobą, takie najbardziej dojrzałe zespoły, z którymi miałem okazję pracować, one z czasem wypracowały sobie własną metodę. I to już nie był Scrum, to już nie był Kanban, nie było nic nazwane. Oni sobie wypracowali własną metodykę pracy z problemami.
[00:07:51.17] – Paweł
Teraz od strony Product Ownera, jak Ci jest wygodniej? Bo też widziałem różne rozwiązania. Widziałem Product Ownerów, którzy wrzucali coś do zespołu i znikali. Ich nie było, ale też widziałem Product Ownerów, takich, którzy pracowali ramię w ramię w tym zespole pod względem rozwiązania problemu. I teraz, która opcja dla ciebie jest wygodniejsza i sensowniejsza?
[00:08:11.04] – Jarosław
Ta druga dlatego, że w interesie Product Ownera jest to, żeby wykorzystać potencjał zespołu technicznego. Czyli praca nad rozwiązaniami, nad produktem, nad rozwiązaniem problemu. Ona wymaga takiej dość dużej kreatywności, dużej komunikacji. I wtedy następuje ten zwrot z inwestycji. Inwestując w komunikację z zespołem i włączenie tego zespołu w proces, Product Owner otrzymuje taki zwrot z inwestycji w postaci lepszych rozwiązań. Zaskakujących. Mówi się o takie sformułowanie enabling technology. To nie ma szans zaistnieć albo ma bardzo znikome szanse, żeby zaistnieć, jeżeli nie ma właśnie tej intensywnej pracy z zespołem na co dzień. Dlatego tak preferuję to drugie rozwiązanie.
[00:08:51.10] – Paweł
To nawet Wam powiem, że to jest bardzo dobra rzecz dla was jako dla liderów, żeby mieć po pierwsze dobrego Product Ownera, ale po drugie dobrze z nim żyć, bo żyjąc dobrze z Product Ownerem, ustawiając cały proces jesteśmy w stanie i zarządzić, i zmotywować zespół, żeby miał zabawki, cały projekt działał, szedł w tę stronę, w którą byśmy chcieli, żeby iść, żeby zadbać o te wszystkie aspekty ludzkie, ale też biznesowe i żeby to się kleiło, bo jednak to tak jak Jarek pracowaliśmy też lata razem, ostatni rok żeśmy się rozeszli na różne działy, różne segmenty, ale jednak chyba taką największą wartość z mojej perspektywy to było to wtedy, kiedy robimy rzeczy, które mają sens dla firmy, które mają sens, dla ludzi, które mają sens, dla biznesu, dla projektów, przyniosą kasę i jeszcze są sensowne, rozwojowe i długofalowe. Jak Ty to widzisz?
[00:09:38.23] – Jarosław
Jak najbardziej. W ogóle tutaj mógłbym sięgnąć do jednego z takich autorytetów jeśli chodzi o to, co nas motywuje w pracy, to jest Evan LaPointe, można też trochę zagłębić się w te jego prace związane z takim neuroscience, jeśli chodzi o o pracę zespołów. Evan był gościem podcastu Lenny’ego Raczyńskiego.
[00:10:03.04] – Paweł
Podlinkujemy wszystko w notatkach do tego odcinka.
[00:10:05.15] – Jarosław
Generalnie zachęcam też nerd managerów do tego, żeby zaglądali na podcast Lenny’ego, dlatego że to jest takie bezpośrednie źródło informacji z Doliny Krzemowej, jak ludzie pracują nad produktami, ale też jak inżynierowie pracują z produktami.
[00:10:19.10] – Jarosław
Evan jako jeden z elementów tego, żeby zespół pracował wydajnie to jest danie temu zespołowi jakiegoś znaczącego celu. Wobec tego ta twoja obserwacja niejako jest potwierdzona w badaniach naukowych Evana, że cel jest kluczowy dla tego, żeby ten zespół wszedł na wyższy poziom takiego performance’u.
[00:10:38.03] – Jarosław
Jest jeszcze jedna rzecz, ona chyba tam nie była. W podcaście wymieniana jest kultura zespołu i mi to kiedyś dało taką perspektywę rozpoznawania, czy ta postawa zespołu jest odpowiednia do tego, żeby rozwiązywać problemy. Evan to podzielił na cztery czy pięć takich poziomów. Ten poziom najniższy to jest to, kiedy rozmawiamy o rozwiązaniu jakimś i zespół wychodzi z pozycji takiego poszukiwania, negacji tego rozwiązania problemu. Czasem jest ciężko rozpoznać, dlatego że czasem ta negacja rzeczywiście jest uzasadniona. Często poruszamy się w takim mało zdefiniowanym obszarze. I tu z jednej strony jest łatwo zanegować sytuację ze względu na to, że ta praca Product Ownera nie była właściwie wykonana. Jest za dużo niewiadomych rzeczy. Ale też łatwo z drugiej strony zanegować cokolwiek.
[00:11:35.11] – Paweł
Chodzi o to, że „się nie da”. Po prostu się nie da. Tego się nie da, to nie pasuje, to tamto.
[00:11:40.13] – Jarosław
Wymówki. Ta koncentracja na ograniczeniach.
[00:11:43.08] – Jarosław
Kolejne poziomy to jest poszukiwanie, żeby Product Owner podał instrukcję, jak rozwiązać, jak opracować to rozwiązanie. Kolejny poziom był, żeby ten Product Owner podyktował to rozwiązanie samo w sobie. Natomiast te poziomy, które dawały duży zwrot, jeśli chodzi o efektywność zespołów, to jest poziom, kiedy zespół poszukuje takiego głębokiego zrozumienia. Jeżeli rozmawiamy o zespole, to on się nie koncentruje na odrzuceniu, na instrukcjach, na rozwiązaniu, tylko on się koncentruje na tym głębokim zrozumieniu kontekstu, głębokim zrozumieniu problemu. I wtedy ta praca staje się efektywna. I taką pracę najbardziej lubię w zespołach. Kiedy są otwarci na zagłębienie się w problem.
[00:12:24.05] – Paweł
Tutaj dodam taką rzecz od siebie, bo to jest istotne, żeby wiedzieć z kim gramy. Jeżeli mamy w zespole, załóżmy samych juniorów, którzy marudzą, narzekają, albo z drugiej strony no, samych takich seniorów, którzy zjedli wszystkie rozumy i tak naprawdę uważają, że są najmądrzejsi na świecie, a w praktyce niekoniecznie dużo produkują czy niekoniecznie dużo są w stanie rozwiązać. No to musimy sobie zdawać z tego jako liderzy sprawę i zadbać o to, żeby ten zespół zdywersyfikować.
[00:12:50.07] – Paweł
Bo jeżeli mamy osoby, które jedyne co są w stanie zrobić, to są w stanie świetnie wykonać powierzoną pracę i trzeba im pokazać palcem to robisz, tak ma być, tak chcemy. Masz to na wejściu, chcemy to na wyjściu, idź i rób. No to też jest OK. No nie przeskoczymy tego. To musi być też na tyle dojrzałe, ludzie muszą być na tyle ogarnięci i doświadczeni, też muszą mieć postawę określoną do tego. Więc to jest ważne na etapie budowania zespołu, żeby takich ludzi też mieć.
[00:13:16.21] – Paweł
No i na koniec dnia w sumie tak z mojej perspektywy, no to też jedni i drudzy są potrzebni, no bo czasem są takie zadania proste, które najzwyczajniej w świecie ktoś musi zrobić. I są rzeczy takie koncepcyjne, gdzie naprawdę trzeba się zmierzyć, trzeba wejść głęboko w temat, trzeba się zastanowić. Więc w sumie chyba miejsce jest dla jednych i drugich.
[00:13:34.08] – Jarosław
Nie wszyscy w zespole muszą się angażować w tę pracę, taką kreatywną. Natomiast konieczne jest, żeby w zespole były jedna, dwie, może trzy osoby, które odnajdują w tym swoją pasję i chcą dołączyć do tej podróży związanej z budowaniem, z budowaniem rozwiązań i produktów.
[00:13:50.10] – Paweł
No dobra, ale to teraz rzućmy kij w mrowisko. Słuchaj, bo ja widziałem ostatnio, że w sumie ty jako dobry Product Owner, który jest ogarnięty w technologiach bieżących, używa narzędzi i widzi w tym fun i chce się tym bawić. Tak naprawdę chyba już nie potrzebuje tak naprawdę zespołu deweloperskiego. Pochwal się, co Ty żeś tam zrobił.
[00:14:11.02] – Paweł
Ostatnio jesteśmy świadkami, niektórzy nazywają to eksplozji tych rozwiązań związanych ze sztuczną inteligencją. Są różne predykcje odnośnie tego, gdzie to nas zaprowadzi. Już dziś możemy korzystać z produktów tej eksplozji narzędzi związanych ze sztuczną inteligencją. Dzisiaj jeszcze patrzymy na to w ten sposób, dotykając tego samemu, możemy w jakiś sposób tę produktywność naszą poprawić o te 10, 20, może 30%. Natomiast są predykcje takie, że rzeczywiście niektóre z zawodów o takiej charakterystyce, dużej powtarzalności pracy mogą wręcz zostać zastąpione.
[00:14:49.23] – Paweł
Teraz trudno powiedzieć, czy Product Owner mógłby zastąpić zespół deweloperski. Moim zdaniem nie, ale być może mój horyzont jest za krótki na to, żeby to zobaczyć.
[00:15:00.22] – Paweł
Zanim przejdziemy do tego, co, bo super jest dać taki kontekst. Ja ostatnio miałem takie doświadczenie, które wspominam dość ciężko. Byłem na konferencji AgileByExample na jesieni zeszłego roku i tam prezentację, taki keynote miał Craig Larman, autor tej metodyki LeSS, ze świata Agile. Craig teraz zajmuje się głównie wpływem sztucznej inteligencji na cały ekosystem, na firmy, jak firmy są zbudowane. I tytuł prelekcji był AI w HR, w kadrach czy coś takiego. Ja zostawię link.
[00:15:39.11] – Paweł
Ta prezentacja, ja ją dość ciężko przyjąłem, dlatego, że przedstawia jakąś taką perspektywę drastycznych zmian na rynku pracy, że tak jak dzisiaj sobie mówimy o tym, że AI pomoże nam zwiększyć naszą produktywność o ileś procent, no to Craig uważa, że pewne zawody będzie można zastąpić całkowicie. Produktywność będzie wzrastała nie o ileś procent, ale kilkukrotnie, stukrotnie, tysiąckrotnie. I z tego budzi się taka konkluzja, która może też wpływać na jakiś niepokój, że rzeczywiście te role, które wymagają w szczególności takiej rutyny, te role mogą być bardzo zagrożone.
[00:16:18.12] – Paweł
Z drugiej strony są te publikacje od Martina Fowlera czy z ThoughtWorks i tam w tych publikacjach jest takie bardzo naukowe podejście, oni mierzą, jak im pomagają narzędzia AI, Copilot i te wszystkie narzędzia związane z oprogramowaniem. No i oni wykazują, że to jest 10%-15%. Z tym że też oni uznają, to jest już bardzo dużo. Natomiast prawdopodobnie skończy się na zwielokrotnieniu tej efektywności zespołów.
[00:16:47.06] – Paweł
No dobra, ale w praktyce Ty jako Product Owner, mając te wszystkie zabawki dostępne, to co jesteś w stanie dzisiaj zrobić?
[00:16:53.21] – Jarosław
Jestem w stanie podać zespołowi dużo lepiej opisane wymagania, które gdzieś powstały w wyniku tego researchu wcześniejszego. Dużo szybciej dostarczyć draft. Jestem w stanie dostarczyć lepiej analizowane dane. Jestem w stanie dostarczyć kontent, który jest lepiej zoptymalizowany. I wracając do pierwszego punktu. Dotychczas te wymagania można było opisywać tekstowo. Można było budować jakieś mapy, rysować mock upy w Figmie. Natomiast te dzisiejsze narzędzia, kilka miesięcy temu na przykład to narzędzie, do którego zmierzamy, Lovable, opublikowane kilka miesięcy temu to był chyba listopad czy październik. Te narzędzia robią znaczącą różnicę, jeśli chodzi o o jakość dostarczania tych wymagań, dlatego że tam jestem w stanie zbudować prototyp, który od razu działa. Tam jestem w stanie zbudować prototyp, doprowadzić do sytuacji, kiedy on wręcz fizycznie zapisuje dane do bazy danych. Fizycznie umożliwia autentykację użytkowników, że ten kod, który ten LLM generuje on jest zapisywany na GitHubie. Tym kodem można się dzielić, można go wziąć i potem spróbować go użyć.
[00:18:13.07] – Jarosław
To był właśnie ten przykład zwielokrotnienia produktywności, dlatego że my stanęliśmy w takim, w takiej sytuacji, że problem, który rozwiązaliśmy, to był problem, natury compliance. Na compliance raczej firmy nie chcą wydawać dużo pieniędzy i product ownerowie nie chcą angażować zespołów na długo, żeby takie problemy rozwiązywać. To był problem polegający na tym, że trzeba zbierać dokumenty, takie prawne, dotyczące produktów. Zatem no, należałoby to dostarczyć rozwiązanie takie jak najbardziej lekkie, szybko i tak dalej. Natomiast w drodze tej eksploracji, w drodze kolejnych prototypów, okazało się, że tych wymagań nie jesteśmy w stanie szybko dostarczyć, że prawdopodobnie stoimy przed takim dylematem albo wcale, albo kilka miesięcy pracy.
[00:19:00.08] – Paweł
Czyli tak źle i tak niedobrze.
[00:19:02.08] – Jarosław
I nie miałem dużych oczekiwań wchodząc w fabułę. Ja właściwie chciałem narysować prototyp po to, żeby wspólnie potem zrobić taki brainstorming. Jak tą funkcjonalność możemy w jakiś prosty sposób na skróty zbudować po to, żeby, żeby dostarczyć chociażby MVP. Natomiast im bardziej zaczynaliśmy się w to rozwiązanie wygenerowane przez Lovable wgłębiać, okazało się, że właściwie możemy ten cały frontend wziąć i zintegrować z naszymi wewnętrznymi systemami. I tak jesteśmy w środku. I tak ta obawa o bezpieczeństwo tego rozwiązania gdzieś jest zmitygowana i tak możemy to spróbować też zwalidować. Natomiast cała ta praca frontendowa związana z załączaniem dokumentów, drag and drop, listowaniem produktów, stronicowanie, jakieś komponenty, które umożliwiają wybieranie wielu produktów, podłączanie do jednego dokumentu. Te wszystkie funkcje niejako mamy dane po paru godzinach promptowania w fabule i wręcz taką decyzję podjęliśmy. Jako MVP bierzemy front wygenerowany przez maszynę i spinamy to z naszym backendem, żeby podać prawdziwe produkty, żeby te dokumenty zapisać u nas w infrastrukturze wręcz nawet jako dodatkowy ekran w jednym z naszych systemów. Ci ludzie, którzy mają z tym pracować, żeby nie musieli logować się do innego interfejsu, tylko mieli nową stronę, trochę inaczej wyglądającą przez kogoś innego, zaprojektowaną przez maszynę w naszych wewnętrznych systemach.
[00:20:30.04] – Jarosław
Do tej pory by to nie było możliwe. Do tej pory byśmy postawili siebie i tą organizację przed faktem albo bardzo drogo, albo wcale. A dzięki tym narzędziem okazało się, że to jest naprawdę enabling technology. Produktywność razy ileś, nawet nie chciałbym tutaj teraz estymować o ile razy, bo to jest też łatwe do podważenia. Natomiast to sprawiło, że byliśmy w stanie to rozwiązanie dostarczyć.
[00:20:56.02] – Paweł
Czyli jako Product Owner to nie tylko możesz na przykład narysować czy opisać, ale wręcz możesz wygenerować projekt, który będzie działał. I mało tego, on działał produkcyjnie. Tak, wyście to wrzucili na produkcję, to obsługuje pliki i działa dużo szybciej niż powinno, prawda?
[00:21:10.24] – Jarosław
To jest w trakcie, to rozwiązanie jeszcze się nie zmaterializowało. Natomiast rzeczywiście to wszystko wskazuje na to, że za chwilę to może być wdrożone i użytkowane.
[00:21:21.17] – Paweł
I z tego doświadczenia twojego. Powiedz, jak ty to widzisz, jeżeli chodzi o też przyszłość programistów. No bo jeżeli Ty jako Product Owner, mając wiedzę biznesową, wiedzę domenową, mając zebrane wymagania, potrafiąc użyć narzędzi, które promptując wyklikają Ci to co trzeba, to gdzie tak naprawdę jest potrzebny ten zespół deweloperski. Biorąc tę sytuację i ten stan faktyczny?
[00:21:47.04] – Jarosław
Trudno mi o takie predykcje, bo to trzeba być trochę być.
[00:21:50.08] – Paweł
Chodzi mi o to właśnie jak to wygląda teraz, bo myślę, że z jednej strony mamy ludzi, którzy są zajarani tematami, a z drugiej strony są ludzie, którzy się tego boją. A chodzi o to, jak to zadziałało w praktyce.
[00:22:01.23] – Jarosław
Na pewno jest potrzebna rola programisty do tego, żeby to zintegrować, żeby to zwalidować, żeby w przyszłości, jeżeli okazałoby się, że to rozwiązanie jest użytkowane, i jest użytkowane coraz większej skali, żeby sprawić, żeby to było skalowalne, żeby to było bezpieczne i tak dalej. Kolejna potrzeba, która się tu pojawia, no to jest wracamy z powrotem do tych umysłów. Potrzebne są umysły tych ludzi, bo my do tego rozwiązania doszliśmy, czy pomysłu na to rozwiązanie doszliśmy po iluś dniach pracy z biznesem, z użytkownikami, z tymi dokumentami. To wymagało tej pracy koncepcyjnej, której LLM nie jest w stanie wykonać. Zatem jeżeli myślimy o zespołach, jak ja to sobie wyobrażam, to potrzebne są takie kompetencje full stack owe. Takie bardziej wszechstronne, żeby integrować, dobierać, zastępować. Bardziej kontrola tego ekosystemu niż niż samego tworzenia kodu. A do tego właśnie ta kreatywność, ta otwartość, te umiejętności, takie społeczne, miękkie do tego, żeby być w stanie użyczyć swojego umysłu do rozwiązywania problemów.
[00:23:12.20] – Paweł
Czyli to nie jest tak, że programiści są do wywalenia i bezużyteczni. Oni się przydają, tylko muszą awansować tak naprawdę na ten wyższy poziom. Czyli jeżeli macie ludzi, którzy będą klepać tylko i wyłącznie kod, no to ich czas już jest policzony, albo właściwie to już się skończył. Ale ci, którzy potrafią myśleć, chcą myśleć, chcą się rozwijać – tak naprawdę potencjał tutaj jest ogromny i to jest, jeżeli mówimy o AI, to tak naprawdę narzędzie, które dobrze wykorzystywane może tę pracę przyspieszyć diametralnie i pomóc i programistom, developerom robić rzeczy szybciej, sprawniej, fajniej, milej, przyjemniej.
[00:23:47.01] – Paweł
Liderom łatwiej tym zarządzać też kwestią budżetów, i tak dalej. I tak samo tobie jako Product Ownerowi zapanować nad tym, że nie musisz czekać teraz miesiące czy lata na coś. Bo tutaj jeszcze też ważne zaznaczyć, że no my razem pracujemy w eMAG, gdzie ta skala jest duża, może się to wydawać, no „jakieś dokumenty” i tak dalej, ale tutaj mówimy o skali kilkuset milionów dokumentów, które muszą być dostępne. Trzeba to utrzymywać i tak dalej. Więc nawet takie w teorii proste tematy wcale nie są proste.
[00:24:14.17] – Jarosław
No tak, jest to proste, jest dużo ograniczeń I dlatego mówimy o tym, że to, że to środowisko jest takie, no nierozpoznane, za każdym razem jest w jakiś sposób niewiadome. Brakuje mi tego słowa.
[00:24:27.13] – Paweł
Taka niepewność.
[00:24:29.08] – Jarosław
Tak, tak, bo ja to określiłem pewien model współpracy Product Ownera z zespołem nad produktem, nad rozwiązywaniem problemów biznesowych, czy ten Product Owner jest tą osobą, która odpowiada w pełni za to rozwiązanie i to może dla niektórych, którzy pracują w innych warunkach to może być trochę takie dziwne, niezrozumiałe, nie oparte o jakieś praktyki, które się stosuje na rynku, jako kontrast do tej pracy, w której zespół bierze własność, czy Product Owner bierze własność tego problemu. To jest taki kontrast z tym, co w wielu przypadkach widzimy i my widzimy u nas też czasem w organizacji, to jest to, że ten problem czy ten produkt nie ma tak naprawdę właściciela.
[00:25:12.04] – Jarosław
I teraz co znaczy własność takiego problemu? Może przykład, powiedzmy szef działu handlowego czy szef działu prawnego obserwuje pewien problem albo objawy, wobec tego zgłasza się do IT z prośbą o rozwiązanie tego problemu cyfrowo w postaci jakiegoś jakiegoś rozwiązania informatycznego. No i teraz to IT może akurat pracować nad innymi problemami, które ta osoba wcześniej…
[00:25:35.24] – Paweł
Na pewno będzie pracować, bo przecież roboty mamy potąd.
[00:25:38.13] – Jarosław
No właśnie. Zazwyczaj tej roboty jest dużo więcej niż się jest w stanie zrobić. Wobec tego IT pyta o to, żeby ten szef działu handlowego przyniósł wymagania. No i teraz ten szef działu handlowego musi te wymagania jakoś wygenerować. Pojawia się jakiś analityk biznesowy, systemowy, może powiedzieć jakiś kierownik projektu, który to wszystko orkiestruje, spina. I w pewnym momencie te wymagania powstają. Ten zespół bierze te wymagania, one są wygenerowane, cały koncept, cały design tego rozwiązania jest zrobione w głowie tego szefa działu handlowego i analityka, czyli osoby, które są trochę odizolowane od ekosystemu, od możliwości, od tego enabling technology, ja tu użyję tego słowa.
[00:26:24.05] – Jarosław
I wtedy ten zespół IT przejmuje to rozwiązanie. Co robi? Estymuje, ile to będzie kosztowało i określa deadline. No i teraz ta estymacja tak do końca nie obchodzi tego szefa działu handlowego, bo on to musi zrobić, bo on ma target do zrobienia, który jest dużo wyższy niż poprzedni i jego nie obchodzi koszt. Jego obchodzi deadline i jest negocjacja deadline’u i tak dalej i dochodzi do budowania tego rozwiązania w oparciu o te wymagania, o ten design, który został stworzony gdzieś poza zespołem.
[00:26:54.19] – Jarosław
I teraz jak taki produkt nie wychodzi, nie rozwiązuje tego problemu, nie da się go użyć, w jakiś sposób ten projekt się nie udaje, to kto jest winny w takiej sytuacji? No nie ma właściciela tak naprawdę. Bo IT mówi, że to szef działu handlowego zawinił, bo dał dziurawe wymagania, albo tak naprawdę to nie był taki problem warty rozwiązania. Szef działu handlowego mówi, że no w IT to są patałachy. No nie? On im wszystko podał, a oni to skiepścili. Kierownik projektu. Kierownik projektu nie jest od rozwiązania problemu, on jest od zarządzania, żeby zakres był dostarczony, w tym deadline. I ewentualnie może wynegocjować, żeby tego zakresu trochę obciąć, tak żeby zdążyć przed tym deadlinem. Natomiast kierownik projektu nie jest od rozwiązywania problemów, on jest od dostarczenia projektu.
[00:27:38.13] – Jarosław
I to jest właśnie ta sytuacja, kiedy nie ma właścicielstwa. I to jest ten kontrast między tym, że właścicielstwo jest i to właścicielstwo jest w postaci właśnie product managera czy Product Ownera, który pracuje razem z zespołem nad rozwiązaniem tego.
[00:27:53.03] – Jarosław
I to też nie jest taki model nie jest też jakąś egzotyką, dlatego że wracając znowu do Doliny Krzemowej, te koncepcje pracy nad pełną własnością i empowermentem zespołów produktowych i project managerów, Product Ownerów one się wykształciły w całą gałąź, cały nurt w Dolinie Krzemowej jest propagowany na całym świecie. I tutaj warto wspomnieć i też zachęcam nerd managerów do tego, żeby też sięgnęli do literatury albo przynajmniej do tych linków, które umieścimy pod tym odcinkiem. To jest Silicon Valley, Product Group i Marty Cagan, który opublikował już chyba cztery książki w tym temacie. Każdy jest trochę z innego obszaru. Może tutaj sięgnę, „Transformed”, to jest ostatnia o budowaniu takich organizacji produktowych. Wcześniejsza „Empowerment”, o budowaniu zespołów produktowych takich empowered.
[00:28:49.10] – Jarosław
I tam się właśnie to ukształtowało moje postrzeganie jaka jest rola tego product managera i Product Ownera, że to jest pełna własność tego problemu. Tam znajdziecie opis, co to jest product team, że on jest empowered product team. Za jakie obszary w tym rozwiązaniu odpowiadają, jakie osoby. Tam znajdziecie to, że ważne jest szybkie iterowanie, szybkie wdrażanie, łatwe wdrażanie, ale, ale też pewne drobnych rzeczy. Tam znajdziecie też, że istotna jest ta synergia umysłów, o której wspomniałem i że konieczność zaangażowania inżynierów do pracy nad problemem, dlatego, że to oni dostarczają to enabling technology.
[00:29:30.04] – Jarosław
Także zachęcam wszystkich nerd menedżerów do jeżeli jeszcze nie sięgali do sięgnięcia do tego, dlatego że to jest cały nurt, może to nie jest taka eksplozja jak w przypadku AI, natomiast to jest nurt, który coraz bardziej, zwłaszcza ten świat budowania, świat IT. Możecie zaobserwować jakieś takie objawy, że część Agile coachów się transformuje w kierunku product coachów, dlatego że coraz większy nacisk jest na budowanie po co my to robimy, czemu to ma służyć, niż fokusowanie się na procesie? Bo proces to jest to wdrażać szybko, pewnie w oparciu o dane empiryczne zebrane wcześniej i podążanie krok po kroku. To jest wymaganie dla procesu. Natomiast tutaj nacisk jest dużo na to, po co my to robimy i jak my dążymy do rozwiązywania tych problemów i czynimy te rozwiązania bardziej prawdopodobnymi.
[00:30:19.15] – Paweł
To jest coś, co jest bardzo dobrą konsekwencją wprowadzenia tych właśnie narzędzi AI, technologii, przyspieszenia mocnego tej technologii, że nie będziemy robić bzdurnych rzeczy czy po prostu głupich, nikomu niepotrzebnych, bo ktoś akurat, znajdzie się inwestor, który gdzieś tam się naczytał, że jak położy kilka baniek na aplikację do zarządzania niczym, to wyciągnie coś. W końcu trzeba zacząć myśleć po co to robimy i mieć to wszystko ułożone, żeby miało to ręce i nogi. Myślę, że to jest mega dobre podsumowanie tego, czym się Ty zajmujesz jako Product Owner.
[00:30:51.24] – Paweł
Powiedz mi jeszcze taką rzecz, gdybyś miał jedną rzecz albo kilka rzeczy jedną, dwie, trzy, jak uznasz, przekazać takim świeżo upieczonym liderom, początkującym liderom, których nie wyszkolili, których nie nauczyli, jak wiesz, jak być dobrym liderem. Często to są specjaliści, którzy by chcieli pisać dalej kod, ale tak naprawdę nie mogą, bo wrzucili ich od strony HRowej w widełki i w rolę tego lidera, i teraz zamiast pisać kod, muszą z ludźmi rozmawiać. Takie kilka takich dobrych rad, współpracy z Product Ownerem, które mogą sprawić, że ta robota naprawdę będzie fajna, miła i przyjemna.
[00:31:24.13] – Jarosław
No to właśnie jest chyba wyjście z tej perspektywy zespołu wytwórczego. Koncentracja na kontekście. Po co my to robimy? To jest to, że w modelach, które przyszły do nas z Doliny Krzemowej, w tych modelach podstawowy jest ten empowerment zespołu. Wobec tego pracą takiego menadżera jest to, żeby dać temu zespołowi, umożliwić temu zespołowi złapanie kontekstu tej organizacji, kontekstu tego celu, po co my to robimy. Znalezienia, wymuszenia tego celu na tym otoczeniu. Bo jeżeli product manager, owner nie przynosi go, no to znaczy, że coś jest dysfunkcyjnego. To właśnie ten nerd manager musi się rozejrzeć, że coś jest, coś tu nie gra i doprowadzić do sytuacji czy zwalidować dlaczego to nie gra? Dlaczego nie ma celu? Dlaczego product manager nie sięga do zespołów, żeby budować rozwiązania?
[00:32:15.07] – Jarosław
Kolejną rzeczą jest, że ci ludzie w zespole, oni muszą też być w jakiś sposób zmotywowani, zachęceni do tej otwartości i do tej odwagi po to, żeby oni mogli wyrazić swoje zdanie, po to, żeby to wyrażenie tego zdania wiązało się z jakimś takim bezpiecznym otoczeniem, bo bezpieczne otoczenie sprawia, że to wyrażenie zdanie staje się bardziej naturalne. Generalnie bezpieczne. Wracając do Evana, to bezpieczeństwo tego środowiska, ono tak naprawdę gdzieś tam w fundamentach wyzwala to właśnie wyjście otwartość, kreatywność, odwagę. Tylko na początek musi być to bezpieczeństwo. Że ja mogę, że że nie będę skarcony, że się nie będą ze mnie śmiać. To jest coś, co ja też wspieram managerów w tym dążeniu do budowania, bo każde zdanie wypowiedziane przez kogokolwiek w trakcie takich warsztatów, brainstormingu itd. ono każde jest cenne. Nawet jeżeli wydaje się nieadekwatne. Ono jednak pobudza do jakiejś refleksji odnośnie tego, nad czym my teraz pracujemy, albo przynajmniej nam pozwala zdefiniować, że ten obszar jest poza naszym zainteresowaniem. Także każde zdanie się liczy.
[00:33:25.14] – Paweł
Dzięki wielkie. Jarek. Powiedz jeszcze na koniec, gdzie można Cię znaleźć, gdyby chciał ktoś poszerzyć temat, dopytać, jeszcze zebrać więcej informacji. Jak najłatwiej się z Tobą skontaktować?
[00:33:34.08] – Jarosław
Jestem dostępny na LinkedInie i tam mam takie publiczne konto i to jest chyba jedyna, jedyna ścieżka.
[00:33:40.11] – Paweł
Także podlinkujemy też profil Jarka w notatkach do tego odcinka. Także śmiało walcie, walcie do Jarka, chętnie pomoże. Dzięki za dzisiaj.
[00:33:48.13] – Jarosław
Dziękuję.
[00:33:49.16] – Krzysztof
To teraz już chyba wiecie czemu zawsze gdy słyszałem z naszej firmy opinie o Jarku, to były same pozytywne, dotyczące jego profesjonalizmu i tego w jaki taki skondensowany, analityczny sposób podchodzi do tych rzeczy, którymi się zajmuje.
[00:34:04.01] – Krzysztof
A jaka jest konkluzja dla nas z tego odcinka? No taka, że AI to nie jest coś, co zabierze nam robotę, ale jednak drastycznie usprawni naszą pracę. Teraz będzie się liczyć ta jednak merytoryczna wartość, skończył się czas klepania kodu przez 8 godzin, który nic nie przynosi ani nie pcha niczego do przodu.
[00:34:23.08] – Paweł
Wszystkie linki, materiały i książki, o których mówił Jarek podlinkujemy w notatkach do tego odcinka, także zobaczcie koniecznie, bo trochę tego było i warto z tego korzystać. Warto się tym zainteresować. A jeżeli chcecie, żeby przeszkolić Was tego, jak Wy jako liderzy w Waszej firmie, liderzy mogą lepiej współpracować z Product Ownerami, z ludźmi od produktu, z ludźmi od biznesu, lepiej się komunikować i rozwiązywać problemy tak, żeby to miało ręce i nogi, miało sens, to wbijajcie na stronę nerd.management/konsultacje, wypełnijcie formularz i z przyjemnością pomożemy Wam funkcjonować lepiej rozwinąć Waszych liderów czy Was samych.
[00:34:57.21] – Krzysztof
No i jak zwykle słyszymy się za dwa tygodnie we wtorek o 8:00. Cześć!
Transcript in English
[00:00:58.06] – Krzysztof
Hello, welcome to Nerd Management. This is Krzysztof Rakowski…
[00:01:01.11] – Paweł
…and Paweł Rekowski.
[00:01:02.21] – Krzysztof
Today we have one of those episodes that we really enjoy, namely interviews with guests and meetings with guests. And today our guest is someone who is very special to us personally, because it is someone we have been working with for a very, very, very long time. Paweł, who is your guest?
[00:01:18.21] – Paweł
My guest today is Jarosław Burda, Senior Product Owner at eMAG, with whom I have worked for over six and a half years. It has been a great collaboration and I highly value Jarek as a specialist and expert Product Owner with real passion. Jarek is a person with a technical background. He started out as a developer, worked as an analyst in various fields, and eventually his passion led him to product management. He also had stints managing people, so he has a very broad perspective on process, project and team management. We talk about how current developments in technology and AI may affect the work of Product Owners and development teams, and how we can work together to find solutions that will make our lives better.
[00:02:04.09] – Krzysztof
A very juicy interview. Watch it.
[00:02:06.23] – Paweł
Hi Jarek. Nice to see you.
[00:02:08.08] – Jarosław
Hi, Paweł.
[00:02:09.05] – Paweł
Thanks a lot for accepting the invitation to the Nerd Management podcast. Tell us something, because you are a Product Owner through and through, you are a Senior Product Owner, as we already mentioned with Krzysiek, and you are also a leader, a team leader, a technical leader. Tell me, what is the real purpose of a Product Owner?
[00:02:26.20] – Jarosław
Some people think that if there is a problem, it is worth having someone who is fully responsible for that problem, for solving it. Well, I am just such a product owner who takes responsibility for solving a problem.
[00:02:40.15] – Paweł
What is your experience with development teams? Because this is part of the design and product development process, depending on the company, as it varies. What is your experience with working with developers? Because it seems to me, from my experience, that it varies, that developers’ sense of responsibility is not quite what people would like it to be in business. On the other hand, developers think that this business is full of idiots who don’t understand anything. As a product owner, you’re stuck in the middle. How do you deal with this? How do you bring these worlds together?
[00:03:11.21] – Jarosław
Firstly, it is a matter of building synergy and shared responsibility for the problem being solved. At the end of the day, as I said earlier, this problem rests on the shoulders of the Product Owner. However, the technical team is there primarily to support these solutions from a technical perspective. The technical team is responsible for the technical solution to the problem, but from the Product Owner’s perspective, it is extremely important to involve this team so that they can contribute their minds to the entire journey related to the problem, product and solution.
[00:03:49.06] – Jarosław
Because this story begins with the problem being defined in some way. Perhaps some symptoms of the problem have been noticed, and these symptoms, this problem, have been assigned to the Product Owner to solve. Or perhaps the Product Owner himself has noticed an area that needs to be addressed. And that’s when the journey begins. A journey to first understand the problem well. You can imagine that this person immerses themselves in the problem and validates it in some way, learns, talks to users, talks to the business, looks for data, and tries to define the problem somehow and redefine it, validate it.
[00:04:30.24] – Jarosław
However, without the support of an engineering team, it is always worse, because the result of one person’s work, even if it is outstanding, is usually a little worse than the result of the synergy of different minds. And what you focus on when building teams is that these minds are somehow diversified, that people have different backgrounds, different ages, different experiences. The richness and diversity of these minds makes identifying and exploring a problem much more effective.
[00:05:06.12] – Jarosław
In addition to being responsible for the technical solution, the team also lends its minds and computing power. Each member is a little different, which helps to thoroughly examine and understand the problem and redefine it. This is because the initial understanding of the problem often differs from that resulting from, say, a scientific approach to its exploration.
[00:05:29.16] – Paweł
You said something interesting about the scientific approach or different types of rules, workflows, and ways of working on projects. Because it is often the case that we have Agile, Scrum, Kanban, Waterfall, Prince, methodologies, and so on. But if you were to say which form from your practice, cooperation with the development team, cooperation with the leader is the most effective, most practical and easiest to implement. Because in my experience, when people start focusing on books describing processes, not only do they do nothing at that time, but later on, the process doesn’t suit them anyway. How is it in your experience?
[00:06:09.17] – Jarosław
In my experience, it seems that this team needs to figure out a way of working that resonates with them the most. From my perspective, it is important that this process is iterative. It should allow you to quickly put things into the process, quickly validate them, and quickly get some kind of result from that validation. It can’t be a process that we make rigid in Scrum, where you can spend 8 weeks working out things. But the shorter the cementing period for this process, the better for building the product and solving the problem.
[00:06:48.20] – Jarosław
The second element is that this process should provide an opportunity for the synergy of minds that I mentioned earlier, for intensive communication, so that the daily meetings that are usually part of all these methodologies are not the only opportunity for the team to communicate with each other.
[00:07:07.15] – Jarosław
So, iterativeness, easy incorporation of things into the process, and synergy of minds. These are probably the key characteristics of the process. And, of course, you can rely on Scrum and Kanban. Maybe it’s worth doing that at the beginning, when the team is formed. It is worth approaching these methodologies in a very canonical way, so as to impose all these restrictions on each other and build this platform as fully as possible.
[00:07:32.08] – Jarosław
However, over time, as the team learned to work together, the most mature teams I had the opportunity to work with developed their own method. It was no longer Scrum, it was no longer Kanban, it was not named anything. They developed their own methodology for working with problems.
[00:07:51.17] – Paweł
Now, from the Product Owner’s perspective, which is more convenient for you? Because I’ve seen different solutions. I’ve seen Product Owners who threw something at the team and disappeared. They weren’t there, but I’ve also seen Product Owners who worked side by side with the team to solve the problem. So now, which option is more convenient and makes more sense to you?
[00:08:11.04] – Jarosław
The second reason is that it is in the Product Owner’s interest to utilise the potential of the technical team. This means working on solutions, on the product, on solving problems. This requires a great deal of creativity and communication. And then you get a return on your investment. By investing in communication with the team and involving the team in the process, the Product Owner gets a return on their investment in the form of better solutions. Surprising solutions. There is a term called enabling technology. It has no chance of happening, or very little chance, if there is no intensive work with the team on a daily basis. That is why I prefer the second solution.
[00:08:51.10] – Paweł
I will even tell you that it is a very good thing for you as leaders to have, first of all, a good Product Owner, but secondly, to get along well with them, because by getting along well with the Product Owner and setting up the entire process, we are able to manage and motivate the team so that they have the tools they need, the entire project works, and moves in the direction we want it to go. to take care of all the human aspects, but also the business aspects, and to make it all stick together, because, after all, just like Jarek, we worked together for years, and last year we split up into different departments, different segments, but I think the greatest value from my perspective was when we did things that made sense for the company, that made sense for people, that made sense for the business, for the projects, that bring in money and are also meaningful, developmental and long-term. How do you see it?
[00:09:38.23] – Jarosław
Absolutely. In fact, I could refer to one of the authorities on what motivates us at work, Evan LaPointe. You can also delve a little deeper into his work on neuroscience in relation to teamwork. Evan was a guest on Lenny Rachitsky’s podcast.
[00:10:03.04] – Paweł
We will link everything in the notes for this episode.
[00:10:05.15] – Jarosław
In general, I also encourage nerd managers to check out Lenny’s podcast, because it’s such a direct source of information from Silicon Valley about how people work on products, but also how engineers work with products.
[00:10:19.10] – Jarosław
Evan, one of the elements that makes a team work efficiently is giving that team a meaningful goal. So your observation is confirmed by Evan’s research, which shows that a goal is crucial for a team to reach a higher level of performance.
[00:10:38.03] – Jarosław
There is one more thing, I don’t think it was mentioned. The podcast talks about team culture, and it gave me a perspective on how to recognise whether a team’s attitude is appropriate for solving problems. Evan divided it into four or five levels. The lowest level is when we talk about a solution and the team starts from a position of searching for and negating that solution. Sometimes it’s hard to recognise because sometimes this denial is actually justified. We often find ourselves in a poorly defined area. On the one hand, it’s easy to deny the situation because the Product Owner’s work wasn’t done properly. There are too many unknowns. But on the other hand, it’s also easy to deny anything.
[00:11:35.11] – Paweł
The point is that „it can’t be done.” It simply can’t be done. It can’t be done, it doesn’t fit, this and that.
[00:11:40.13] – Jarosław
Excuses. This focus on limitations.
[00:11:43.08] – Jarosław
The next levels involve seeking instructions from the Product Owner on how to solve a problem and how to develop a solution. The next level was for the Product Owner to dictate the solution itself. However, the levels that yielded the greatest return in terms of team effectiveness were those where the team sought a deep understanding. When we talk about a team, it does not focus on rejection, instructions or solutions, but on a deep understanding of the context and the problem. And then the work becomes effective. This is the kind of work I like best in teams. When they are open to delving deeper into the problem.
[00:12:24.05] – Paweł
I would like to add something here, because it is important to know who we are playing with. If we have a team consisting only of juniors who whine and complain, or, on the other hand, only seniors who think they know everything and believe they are the smartest people in the world, but in practice do not necessarily produce much or are not necessarily able to solve many problems. Well, then we, as leaders, have to be aware of this and make sure that the team is diversified.
[00:12:50.07] – Paweł
Because if we have people who are only capable of doing their assigned work perfectly, and we have to show them exactly what to do, this is how it should be done, this is what we want. You get this at the beginning, we want this at the end, go and do it. Well, that’s OK too. We can’t get around that. It also has to be mature enough, people have to be organised and experienced enough, and they also have to have the right attitude. So it’s important at the team-building stage to have people like that.
[00:13:16.21] – Paweł
And at the end of the day, from my perspective, both are needed, because sometimes there are simple tasks that simply have to be done. And there are conceptual things that really require you to dig deep, get to the bottom of the issue, and think things through. So I think there’s room for both.
[00:13:34.08] – Jarosław
Not everyone in the team needs to be involved in this kind of creative work. However, it is essential that there are one, two, or maybe three people in the team who find passion in this and want to join this journey of building solutions and products.
[00:13:50.10] – Paweł
Okay, but let’s stir things up a bit. Listen, because I’ve noticed recently that, as a good Product Owner who is well versed in current technologies, you use tools, see the fun in it, and want to play around with it. In reality, you probably don’t really need a development team anymore. Show us what you’ve done.
[00:14:11.02] – Paweł
Recently, we have been witnessing what some call an explosion of artificial intelligence solutions. There are various predictions as to where this will lead us. We can already use the products of this explosion of artificial intelligence tools. Today, we still look at it this way: by touching it ourselves, we can somehow improve our productivity by 10, 20, maybe 30%. However, there are predictions that some professions with such characteristics, involving highly repetitive work, may actually be replaced.
[00:14:49.23] – Paweł
It is difficult to say at this point whether a Product Owner could replace a development team. In my opinion, no, but perhaps my perspective is too limited to see this.
[00:15:00.22] – Paweł
Before we move on to that, it’s good to provide some context. I recently had an experience that I find quite difficult to talk about. I was at the AgileByExample conference last autumn, and Craig Larman, the author of the LeSS methodology from the Agile world, gave a keynote presentation. Craig is now mainly concerned with the impact of artificial intelligence on the entire ecosystem, on companies, on how companies are built. The title of the lecture was AI in HR, in human resources or something like that. I’ll leave the link.
[00:15:39.11] – Paweł
I found this presentation quite difficult to accept because it presents such a drastic change in the labour market. Today, we talk about AI helping us increase our productivity by a certain percentage, but Craig believes that certain professions will be completely replaced. Productivity will not increase by a certain percentage, but several times, a hundred times, a thousand times. This leads to a conclusion that may also cause some concern, namely that roles that require routine tasks in particular may be at serious risk.
[00:16:18.12] – Paweł
On the other hand, there are publications by Martin Fowler and ThoughtWorks, which take a very scientific approach, measuring how AI tools, Copilot and all these software-related tools help them. And they show that it’s 10-15%. However, they also acknowledge that this is already a lot. But it will probably end up multiplying the effectiveness of teams.
[00:16:47.06] – Paweł
Okay, but in practice, as a Product Owner with all these tools at your disposal, what are you able to do today?
[00:16:53.21] – Jarosław
I am able to provide the team with much better described requirements that were developed earlier as a result of this research. I can deliver drafts much faster. I am able to provide better analysed data. I am able to deliver content that is better optimised. And coming back to the first point. Until now, these requirements could be described in text. You could build maps, draw mock-ups in Figma. However, today’s tools, for example, the tool we are moving towards, Lovable, published a few months ago, I think it was November or October. These tools make a significant difference in terms of the quality of delivery of these requirements, because there I am able to build a prototype that works right away. There, I am able to build a prototype and get it to the point where it physically writes data to the database. It physically enables user authentication, so that the code generated by the LLM is saved on GitHub. This code can be shared, taken and then tried out.
[00:18:13.07] – Jarosław
This was precisely an example of productivity multiplication, because we found ourselves in a situation where the problem we solved was a compliance issue. Companies don’t want to spend a lot of money on compliance, and product owners don’t want to engage teams for long periods of time to solve such problems. The problem was that legal documents relating to products had to be collected. So, we needed to provide a solution that was as lightweight and fast as possible. However, during our exploration and subsequent prototyping, it turned out that we were unable to deliver these requirements quickly, and that we were probably facing a dilemma: either no solution at all or several months of work.
[00:19:00.08] – Paweł
So it’s bad either way.
[00:19:02.08] – Jarosław
I didn’t have high expectations when I got into the story. I actually wanted to draw a prototype so that we could brainstorm together. How could we build this functionality in a simple, shortcut way in order to deliver at least an MVP? However, the more we delved into the solution generated by Lovable, the more we realised that we could actually take the entire frontend and integrate it with our internal systems. And so here we are. Our concerns about the security of this solution have been mitigated, and we can try to validate it. However, all the frontend work related to attaching documents, drag and drop, product listing, pagination, some components that allow you to select multiple products and connect them to a single document. We have all these features after a few hours of prompting in the plot, and we have made this decision. As an MVP, we take the front end generated by the machine and connect it to our back end to provide real products and save these documents in our infrastructure, even as an additional screen in one of our systems.
[00:20:16.07] – Jarosław
The people who are going to work with it won’t have to log into a different interface, they’ll just have a new page that looks a little different, designed by a machine in our internal systems.
[00:20:30.04] – Jarosław
Until now, this would not have been possible. Until now, we would have faced a choice between spending a lot of money or not doing it at all. Thanks to this tool, it turned out that this is truly enabling technology. Productivity has increased many times over, and I don’t even want to estimate how many times, because it’s easy to dispute. However, it has enabled us to deliver this solution.
[00:20:56.02] – Paweł
So, as a Product Owner, you can not only draw or describe something, but you can actually generate a project that will work. And not only that, it worked in production. Yes, you put it into production, it handles files and works much faster than it should, right?
[00:21:10.24] – Jarosław
It is in progress, the solution has not yet materialised. However, everything indicates that it may be implemented and used very soon.
[00:21:21.17] – Paweł
And from your experience. Tell me how you see the future of programmers. Because if you, as a Product Owner, have business knowledge, domain knowledge, have gathered requirements, and are able to use tools that prompt you to click on what you need, where is the development team really needed? Taking this situation and the current state of affairs into account?
[00:21:47.04] – Jarosław
It’s difficult for me to make such predictions, because you have to be a bit like that.
[00:21:50.08] – Paweł
I mean how it looks now, because I think that on the one hand we have people who are excited about these topics, and on the other hand there are people who are afraid of them. And the point is how it worked in practice.
[00:22:01.23] – Jarosław
A programmer is definitely needed to integrate and validate this, so that in the future, if it turns out that this solution is being used and is being used on an increasingly larger scale, it can be made scalable, secure, and so on. Another need that arises here is that we are back to those minds. We need the minds of these people because we came up with this solution, or the idea for this solution, after several days of working with the business, with users, with these documents. It required conceptual work that LLM is not capable of doing. So if we think about teams, as I imagine them, we need full stack competencies. More versatile ones, to integrate, select, replace. More control over the ecosystem than over the code itself. And on top of that, you need creativity, openness, social and soft skills to be able to lend your mind to problem solving.
[00:23:12.20] – Paweł
So it’s not that programmers are useless and should be fired. They are useful, but they need to be promoted to a higher level. If you have people who are only going to write code, then their time is numbered, or rather, it’s already over. But those who can think, want to think, want to develop – there is huge potential here, and when we talk about AI, it is really a tool that, when used well, can dramatically speed up the work and help programmers and developers do things faster, more efficiently, in a cooler, nicer and more enjoyable way.
[00:23:47.01] – Paweł
It is also easier for leaders to manage budgets and so on. And the same goes for you as a Product Owner, you don’t have to wait months or years for something. It’s also important to note that we work together at eMAG, where the scale is large, so it may seem like „just some documents” and so on, but we’re talking about hundreds of millions of documents that need to be available. This has to be maintained and so on. So even topics that are simple in theory are not simple at all.
[00:24:14.17] – Jarosław
Well, yes, it’s simple, there are a lot of limitations. And that’s why we say that this environment is, well, unrecognised, and every time it’s somehow unknown. I can’t find the right word for it.
[00:24:27.13] – Paweł
Such uncertainty.
[00:24:29.08] – Jarosław
Yes, yes, because I defined a certain model of cooperation between the Product Owner and the team working on the product, on solving business problems, whether the Product Owner is the person who is fully responsible for the solution, and this may be a little strange for some people who work in different conditions, incomprehensible, not based on any practices used on the market, in contrast to this work, where the team takes ownership or the Product Owner takes ownership of the problem. This is a contrast to what we see in many cases, and what we sometimes see in our organisation, which is that the problem or the product does not really have an owner.
[00:25:12.04] – Jarosław
And now, what does ownership of such a problem mean? Let’s take an example: say the head of the sales department or the head of the legal department observes a certain problem or symptoms, so they report it to IT with a request to solve this problem digitally in the form of some kind of IT solution. And now IT may be working on other problems that this person previously
[00:25:35.24] – Paweł
It will definitely work, because we have robots here.
[00:25:38.13] – Jarosław
Exactly. Usually, there is much more work than can be done. So IT asks the sales department manager to provide the requirements. And now the sales department manager has to generate these requirements somehow. A business analyst or system analyst appears, perhaps a project manager who orchestrates and ties everything together. And at some point, these requirements are created. The team takes these requirements, they are generated, the entire concept, the entire design of the solution is done in the heads of the sales department head and the analyst, i.e. people who are somewhat isolated from the ecosystem, from the possibilities, from the enabling technology, to use that term.
[00:26:24.05] – Jarosław
And then the IT team takes over the solution. What do they do? They estimate how much it will cost and set a deadline. And now this estimate doesn’t really matter to the sales manager, because he has to do it, he has a target to meet, which is much higher than the previous one, and he doesn’t care about the cost. He cares about the deadline, and there are negotiations about the deadline, and so on, and the solution is built based on these requirements, on this design that was created somewhere outside the team.
[00:26:54.19] – Jarosław
And now, if such a product does not work, does not solve the problem, cannot be used, somehow the project fails, who is to blame in such a situation? Well, there is no owner, really. Because IT says that it is the sales manager’s fault, because he gave flawed requirements, or because it was not really a problem worth solving. The head of the sales department says that IT is a bunch of incompetents. Right? He gave them everything, and they messed it up. The project manager. The project manager is not there to solve problems, he is there to manage, to ensure that the scope is delivered, including the deadline. And possibly negotiate to cut the scope a little so that it can be done before the deadline. However, the project manager is not there to solve problems, he is there to deliver the project.
[00:27:38.13] – Jarosław
And this is precisely the situation where there is no ownership. And this is the contrast between the fact that ownership exists and that ownership is in the form of a product manager or Product Owner who works with the team to solve the problem.
[00:27:53.03] – Jarosław
And this model is not that exotic, because, going back to Silicon Valley, these concepts of working on full ownership and empowerment of product teams and project managers, Product Owners, have developed into a whole branch, a whole trend in Silicon Valley that is being promoted all over the world. And here it is worth mentioning, and I encourage nerd managers to reach for the literature or at least the links that we will include below this episode. This is Silicon Valley, Product Group and Marty Cagan, who has already published four books on this topic. Each one is from a slightly different area. Maybe I’ll mention „Transformed”, which is the latest one on building such product organisations. The earlier one, „Empowerment”, is about building empowered product teams.
[00:28:49.10] – Jarosław
That’s where my perception of the role of a product manager and product owner took shape, that it’s full ownership of the problem. There you will find a description of what a product team is, that it is an empowered product team. What areas they are responsible for in this solution, what people. You will find that it is important to iterate quickly, implement quickly, implement easily, but also some minor things. You will also find that the synergy of minds I mentioned is important and that it is necessary to involve engineers in working on the problem because they are the ones who provide the enabling technology.
[00:29:30.04] – Jarosław
I also encourage all nerd managers who haven’t done so yet to check it out, because it’s a whole trend. It may not be as explosive as AI, but it’s a trend that is growing, especially in the world of construction and IT. You can observe signs that some Agile coaches are transforming into product coaches, because there is an increasing emphasis on building why we are doing something, what it is for, rather than focusing on the process. Because the process is about implementing quickly, probably based on empirical data collected earlier, and following step by step. That’s what the process requires. Here, however, the emphasis is much more on why we are doing it and how we are striving to solve these problems and make these solutions more likely.
[00:30:19.15] – Paweł
This is a very positive consequence of introducing these AI tools and technologies and accelerating their development, because we won’t be doing stupid things that are useless to anyone just because some investor somewhere has read that if they put a few million into a management application, they’ll get something out of it. Ultimately, we need to start thinking about why we are doing this and have everything organised so that it makes sense. I think that’s a great summary of what you do as a Product Owner.
[00:30:51.24] – Paweł
Tell me one more thing, if you had one thing or a few things, one, two, three, as you see fit, to pass on to these newly minted leaders, novice leaders who haven’t been trained, who haven’t been taught, as you know, how to be a good leader. Often these are specialists who would like to continue writing code, but in reality they can’t because HR has thrown them into the role of a leader, and now instead of writing code, they have to talk to people. A few pieces of good advice on working with the Product Owner that can make this job really fun, nice and enjoyable.
[00:31:24.13] – Jarosław
Well, that seems to be the way out of this perspective of the production team. Focus on context. Why are we doing this? The thing is that in the models that came to us from Silicon Valley, team empowerment is fundamental. Therefore, the job of such a manager is to give this team, to enable this team to grasp the context of this organisation, the context of this goal, why we are doing this. To find, to enforce this goal on this environment. Because if the product manager, the owner, does not deliver it, then something is dysfunctional. It is the nerd manager who has to look around, see that something is wrong, and either fix it or validate why it is not working. Why is there no goal? Why is the product manager not reaching out to the teams to build solutions?
[00:32:15.07] – Jarosław
Another thing is that the people in the team also need to be motivated and encouraged to be open and courageous so that they can express their opinions, and so that expressing those opinions is associated with a safe environment, because a safe environment makes expressing opinions more natural. Safe in general. Coming back to Evan, the safety of this environment, which is really somewhere in the foundations, triggers this openness, creativity and courage. But first, there has to be safety. That I can, that I won’t be scolded, that they won’t laugh at me. This is something I also support managers in striving to build, because every sentence spoken by anyone during such workshops, brainstorming sessions, etc., is valuable. Even if it seems inadequate. However, it stimulates reflection on what we are currently working on, or at least allows us to define that this area is outside our interest. So every sentence counts.
[00:33:25.14] – Paweł
Thanks a lot, Jarek. Finally, could you tell us where we can find you if anyone would like to discuss this topic further, ask more questions or gather more information? What is the easiest way to contact you?
[00:33:34.08] – Jarosław
I am available on LinkedIn, where I have a public account, and that is probably the only way to contact me.
[00:33:40.11] – Paweł
We will also link Jarek’s profile in the notes for this episode. So go ahead and contact Jarek, he will be happy to help. Thanks for today.
[00:33:48.13] – Jarosław
Thank you.
[00:33:49.16] – Krzysztof
Now you probably understand why, whenever I heard opinions about Jarek at our company, they were always positive, concerning his professionalism and the concise, analytical way in which he approaches the issues he deals with.
[00:34:04.01] – Krzysztof
And what is the conclusion for us from this episode? Well, that AI is not something that will take our jobs away, but it will drastically improve our work. Now, it will be the substantive value that counts. The days of tapping away at code for 8 hours, which brings nothing and pushes nothing forward, are over.
[00:34:23.08] – Paweł
All links, materials and books mentioned by Jarek will be included in the notes for this episode, so be sure to check them out, because there was quite a lot and it’s worth using. It’s worth checking out. And if you want to be trained on how you, as leaders in your company, can better collaborate with Product Owners, product people, and business people, communicate better, and solve problems in a way that makes sense, then visit nerd.management/konsultacje, fill out the form and we will be happy to help you function better and develop your leaders or yourselves.
[00:34:57.21] – Krzysztof
Well, as usual, we’ll talk in two weeks on Tuesday at 8:00. Bye!