Dziś zapraszam Cię na kolejny odcinek specjalny 🇬🇧 podcastu „Dodane do Backlogu". Naszym gościem jest Daniele Ronca - organizator jednej z najszybciej rosnących społeczności i konferencji produktowych w Europie - berlińskiego ProductLab.

Dzisiaj Daniele ściąga na jedną scenę liderów z Google, Amazona, Stripe, n8n, GetYourGuide oraz speakerów pokroju Raviego Mehty (ex-CPO Tinder). A zaczynał od czegoś, czego nikt sobie nie życzy: w 2024 roku zwolniono jego i cały jego zespół produktowy.

Rozmawiamy o tym:

• Jak zbudował biznes od zera po lay-offie - traktując community jak produkt. JTBD, marketplace, retencja, discovery - dokładnie te narzędzia, których używasz w pracy.

• Co łączy najlepsze produktowe społeczności w Europie i jak wyglądają kulisy organizacji konferencji ze speakerami z topowych produktowych firm;

• Jak maksymalnie skorzystać ze społeczności i eventów, na które chodzisz.

Zaczynamy 👇

Słuchaj na Spotify

lub Apple Podcast.

• Dlaczego po lay-offie Daniel rozpoczął pracować nad ProductLab-em?

• Jaki problem naprawdę rozwiązują dziś produktowe community - i dlaczego connection stał się cenniejszy niż wiedza

• Jak budować community jak produkt - JTBD, dynamika marketplace’u i dlaczego warto stawiać na podaż, nie popyt

• Jak wyciągać realną wartość z konferencji i meetupów (i jedno pytanie, które otwiera każdego product leadera)

• Największe mity o budowaniu community - w tym ten o darmowym alkoholu

• Kulisy organizacji jednej z największych konferencji produktowych w Europie - ze speakerami z n8n, Stripe, Reforge, Parloa i Ravim Mehtą

Poniżej znajdziesz też moje rozbudowane notatki z rozmowy z Daniele ⤵️

Moje notatki z podcastu

• 1️⃣ Od PMa do Foundera (jak to się zaczęło)

• 2️⃣ Daniele podszedł do społeczności jak do produktu

• 3️⃣ Samotność lidera - problem, o którym mało kto mówi

• 4️⃣ Jak wyciągać wartość z community (bez cringe’u)

• 5️⃣ Podsumowanie

• 🎁 Bonusy dla społeczności (~500 euro)

1️⃣ Od PMa do Foundera (jak to się zaczęło)

Zacznijmy od czegoś, co łatwo przeoczyć w tej historii - timingu. Fala produktowych layoffów przetoczyła się przez Berlin (i całą Europę) w 2024. Setki produktowców nagle szukało tego samego: miejsca, gdzie mogą się uczyć, poznawać ludzi i szukać nowych szans.

A takiego miejsca nie było.

„Wiele osób, jak ja, szukało community, żeby się uczyć, znaleźć nowe kontakty. I go nie było.”

To jest moment, w którym większość ludzi widzi tylko własny problem („straciłem pracę”). Daniele zobaczył rynek. Berlin - stolica, tech hub, tysiące PM-ów. Po COVID robienie eventów nie było modne, więc konkurencji praktycznie zero. Lenny dopiero zaczynał uruchamiać community z ambasadorami, Luma raczkowała.

Timing, market size, realna potrzeba i brak konkurencji. Jeśli to brzmi znajomo, to dlatego, że to dokładnie ta sama checklist, którą stosujesz, oceniając czy warto budować nowy produkt. Daniele po prostu zastosował ją do siebie.

„To znów był timing. Jak w każdej firmie - zaczynasz od timingu, company, market size i need. To normalny startup.”

Pierwsza lekcja: świetne produkty (i community) nie powstają z genialnego pomysłu. Powstają, gdy realna potrzeba spotyka się z odpowiednim momentem. Twoja robota jako PM-a to ten moment rozpoznać - a nie wymyślić.

2️⃣ Daniele podszedł do społeczności jak do produktu

Tu jest sedno całej historii i powód, dla którego w ogóle o niej piszę.

Daniele nie myśli o Product Lab jak o zwykłej konferencji. Myśli o tym jak o produkcie. Dosłownie. Gdy pytam go, co przeniósł z product managementu do budowania community, odpowiada bez wahania: Jobs to be Done i continuous discovery.

2.1. Za co ludzie naprawdę płacą?

Zadaj sobie pytanie: po co ktoś miałby płacić setki euro za bilet na konferencję albo poświęcać wolny wieczór na meetup? Wiedza jest dziś za darmo.

„Jesteśmy w momencie, gdzie ludzie nie potrzebują już informacji ani wiedzy. To jest publicznie dostępne za darmo albo bardzo tanio.”

Lenny’s Newsletter, setki innych newsletterów, podcasty, YouTube, książki. Każda druga osoba ma swój side-project edukacyjny. Jeśli chcesz się czegoś nauczyć, materiał jest na wyciągnięcie ręki.

Więc wiedza to nie jest job to be done, który rozwiązuje community.

To, co zostaje deficytowe - i według Daniele będzie coraz cenniejsze - to connection. Możliwość spotkania ludzi, którzy pozwolą Ci zbenchmarkować, gdzie jesteś. Jak wygląda rynek naprawdę. Jak te firmy rekrutują. Kto może Cię komuś przedstawić, zamiast wysyłania CV w próżnię na LinkedIn.

To jest głęboko produktowe myślenie. Daniele nie sprzedaje features (prelekcje, warsztaty, networking). Sprzedaje outcome: „poczujesz, gdzie jesteś i z kim warto się połączyć, żeby ruszyć dalej”.

2.2. Continuous discovery - “wywiady” z dosłownie każdą osobę

Najbardziej uderzyło mnie to, jak Daniele robi discovery. Każdej osobie, która dołączyła do zeszłorocznej konferencji, napisał na LinkedIn. Zagadał. Zapytał, czego szuka i dlaczego.

„Każdą osobę, która dołączyła w zeszłym roku, przywitałem na LinkedIn. Pytałem - przez czat albo rozmowę - czego szukają i dlaczego.”

I tu pada obserwacja, którą zna każdy, kto robił discovery interviews:

„To ‘dlaczego’ jest naprawdę trudne. Ludziom ciężko powiedzieć, po co tam są. Albo nie potrafią, albo wolą nie mówić.”

Znasz to uczucie, prawda? To samo dzieje się w rozmowach z userami. Ludzie nie mówią wprost, o co im chodzi - musisz to wyłuskać. Daniele traktuje uczestników community jak userów swojego produktu. Bo nimi są.

2.3. Społeczność to… marketplace

To jest fragment, po którym zapisałem sobie notatkę „to trzeba dać do newslettera”.

Daniele traktuje community jak marketplace. I nie chodzi tu o przenośnię. On naprawdę traktuje swoją społeczność według zasad związanych w zbudowanym produktu typu marketplace.

W tym marketplace masz dwie strony:

• Podaż (supply) - ludzie z wiedzą i doświadczeniem. Ci, którzy wnoszą 7, 10, 15 lat doświadczenia i wychodzą na scenę.

• Popyt (demand) - ludzie, którzy chcą connection i learningu. Czyli większość.

I teraz uwaga - większość organizatorów skupia się na popycie. Bo to popyt kupuje bilety, popyt wypełnia salę, popyt generuje przychód. Daniele robi odwrotnie.

„Od początku skupiam się bardziej na podaży niż na popycie.”

Dlaczego? Bo to strona podażowa napędza całą wartość. To ludzie z doświadczeniem przynoszą okazje, zostają mentorami, kształtują trajektorię kariery innych. Jeśli przyciągniesz najlepszych ludzi po stronie podaży, popyt przyjdzie sam. Odwrotnie to nie działa.

Jeśli myślisz o marketplace’ach w kategoriach produktowych, od razu widzisz tu network effect. Wartość community rośnie z każdym kolejnym wartościowym człowiekiem po stronie podaży - a to przyciąga jeszcze więcej popytu. Klasyczna pętla, którą znasz z Airbnb czy Ubera.

I Daniele idzie o krok dalej. Zauważył, że najcenniejsza jest strona podażowa - więc buduje community wewnątrz community. Osobne grupy dla liderów (CPO, VP Product), bo ich problemy są zupełnie inne niż seniora czy principala. Small people management, stres, boardroomy. Zaczął od group coachingu, teraz eksperymentuje z podgrupami tylko dla liderów.

Lekcja, którą wyciągnąłem: w każdym marketplace (i w wielu produktach) jedna strona jest trudniejsza do zdobycia i cenniejsza. Zidentyfikuj ją i skup tam większość energii. Reszta podąży.

2.4. Jak mierzyć, czy community działa?

Pytanie, które zadaliśmy wprost: jakie sygnały mówią, że community naprawdę działa? Bo „fajna atmosfera” to nie jest metryka.

Retencja - jak w produkcie

Pierwszy sygnał był ode mnie: czy ludzie z poprzedniego wydarzenia pojawiają się na następnym.

„To jak retencja w product managemencie. Jeśli pokazali się na poprzednim i chcą się pokazać na następnym - wiem, że chcą być w tym community.”

To jest dokładnie retencja, którą śledzisz w swoim produkcie. Ilu userów wraca? Ale Daniele dorzucił do tego ważną uwagę - w Niemczech pojawił się teraz nadpodaż eventów, więc sam wskaźnik show-upu spada wszystkim i przestaje być wiarygodny w oderwaniu od kontekstu.

Klasyczna pułapka metryki, która działa, dopóki nie zmieni się rynek.

„Time to yes” - metryka, której nie znałem

I tu pada coś, co usłyszałem pierwszy raz w życiu, a jest genialne w swojej prostocie.

Daniele mierzy „time to yes” - jak długo zajmuje przekonanie topowego speakera (z firmy poziomu TOP 10, którą wszyscy znają, często z osobnym procesem PR), żeby powiedział „tak, wchodzę w to”.

„Czujesz to po prostu. Jak szybko idzie operacja.”

Rok temu ściągnięcie mocnego nazwiska wymagało rund wprowadzeń, przekonywania, proszenia o intro. W tym roku - jedno intro i „lecimy”. To proxy dla siły brandu. Im silniejszy Twój brand i pozycjonowanie, tym szybciej najlepsi mówią „tak”.

Pomyśl, ile Twoich produktowych „metryk” to tak naprawdę wyczucie, które wyrobiłeś przez powtarzanie. Time to yes to dokładnie to - Daniele nie liczy tego w arkuszu, ale czuje różnicę między rokiem pierwszym a drugim. I to mu wystarcza, żeby wiedzieć, że idzie w dobrą stronę.

3️⃣ Samotność lidera - problem, o którym mało kto mówi

Teraz coś osobistego, bo ten wątek trafił we mnie mocno.

Prowadzę kilka community, w tym jedno mniejsze - meetup dla senior PM-ów i product leaderów. I wiesz, co się okazało głównym powodem, dla którego ludzie tam przychodzą?

Samotność.

Im wyżej jesteś w produkcie, tym mniej masz z kim rozmawiać o produkcie. Brzmi paradoksalnie, ale sam tego doświadczyłem - jako head of product wtedy i teraz, w scale-upie.

Masz Zarząd, ale Zarząd nie myśli produktowo. Masz zespół, ale to są Twoi product managerowie, którym raczej Ty nadajesz kierunek, niż odbijasz z nimi trudne decyzje jak z równymi sobie. I nagle okazuje się, że nie masz nikogo na swoim poziomie, kto zrozumie, z czym się mierzysz.

„Jesteś CPO albo VP Product i nie masz z kim pogadać w firmie.”

To jest realny, głęboki job to be done dla wielu - i według mnie jeden z najsilniejszych motorów całego ruchu community. Ludzie nie przychodzą tam po wiedzę (tę mają za darmo). Przychodzą, żeby znaleźć ludzi, którzy myślą tak jak oni. Którzy łapią te same wewnętrzne żarty, ten sam żargon, te same frustracje.

To zresztą łączy się z czymś, o czym rozmawialiśmy w odcinku - Marcin przywołał książkę Cultish Amandy Montell, o języku fanatyzmu. Jeśli odłożysz na bok mroczną stronę „kultów”, zostaje fascynujący mechanizm: ludzie są zaprogramowani, żeby szukać przynależności i sensu w grupach. Dwa pytania, na które community odpowiada, brzmią: „kim jestem?” i „gdzie pasuję?”.

I jako product leader - jeśli to czytasz i czujesz tę izolację - to nie jest Twoja słabość. To strukturalna cecha roli. Warto o tym wiedzieć i świadomie szukać swojego kręgu.

4️⃣ Jak wyciągać wartość z community (bez cringe’u)

Skoro już wiesz, po co iść na konferencję czy meetup, to zostaje pytanie: jak robić to dobrze? Bo większość ludzi przychodzi, konsumuje, łapie za darmowe piwo i wychodzi bez jednego wartościowego kontaktu. Marcin ujął to wprost: „ludzie przychodzą, konsumują i wychodzą”. Szkoda, bo realna wartość konferencji nie jest na scenie - jest w korytarzu.

Rozłóżmy więc na czynniki pierwsze, jak podejść do tego jak PM. Bo - i to jest sedno tej sekcji - dobry networking to nie sprzedaż siebie. To discovery. Te same zasady, których używasz w rozmowach z userami, działają w rozmowie z founderem przy kawie.

Zasada 1: Otwieraj pytaniem o problem (a nie o pogodę ;))

Marcin ma swoje ulubione pytanie otwierające, które naprawdę działa:

„What’s on top of your mind?” - co teraz najbardziej zaprząta Ci głowę?

Świetnie sprawdza się przy product liderach, bo rozpakowuje realny problem, nad którym ktoś aktualnie siedzi. Otwiera prawdziwą rozmowę, a nie small talk o tym, jak dojechałeś na konferencję.

To dokładnie ta sama mechanika co w dobrym discovery. Nie pytasz, co jest świetne - pytasz, co nie działa. Nikt Ci nie powie nic wartościowego, jeśli poprosisz o komplement. Ludzie otwierają się dopiero, gdy dotkniesz czegoś, co ich uwiera.

Zasada 2: Najpierw chemia, potem szczerość

Jest jeden warunek, o którym łatwo zapomnieć: musisz najpierw zbudować minimum chemii. Nikt senior nie odpowie Ci szczerze na pytanie o swoje problemy, dopóki nie poczuje, że warto z Tobą gadać.

I tu pada ciekawe pytanie, które sam zadałem w rozmowie - czym w ogóle jest ta „chemia”, skoro spotykasz kogoś pierwszy raz w życiu? Bo to nie jest znajomość. To raczej ten sam poziom energii, wspólny kontekst, może anegdota, która pokazuje, że rozumiesz świat rozmówcy. W praktyce: zanim zadasz mocne pytanie, daj drugiej osobie sygnał, że jesteś „z tego samego plemienia”.

Zasada 3: Do najlepszych podchodź jak do randki, nie jak do rekrutera

A jak zdobyć uwagę naprawdę zajętych ludzi - speakerów, top founderów, sponsorów? Tu Daniele rzuca porównanie, które zostaje w głowie:

„To nie różni się od randkowania. Wysyłanie kwiatów speakerom, żeby przyszli na konferencję, to jak ‘chcesz iść na kawę?’. Są zajęci. Wiele osób do nich pisze.”

Ich LinkedIn to 30 nieodpisanych wiadomości. I - co gorsza - każda ma ten sam „pickup”: „szukam pracy”, „szukam nowych możliwości”. Jeśli podejdziesz z tym samym, wtapiasz się w tłum i zostajesz zapomniany w 5 sekund.

Jak się wyróżnić? Nie idź z własnym celem wypisanym na czole. Przyjdź z ciekawą myślą, która coś doda do sposobu myślenia tej osoby albo go przełączy.

„Jeśli przyjdziesz z interesującą myślą, która zmieni ich sposób myślenia albo coś do niego doda - zapamiętają Cię.”

To brzmi miękko, ale ma twardą logikę. Ci ludzie są bystrzy i przemyślani. Nie kupisz ich charyzmą (chyba że naprawdę ją masz), za to możesz ich kupić treścią. Paradoks polega na tym, że im mniej pchasz swój cel, tym większa szansa, że ktoś sam do niego wróci - bo Cię zapamiętał.

Zasada 4: Zbuduj sieć, zanim jej potrzebujesz

I tu dochodzimy do najważniejszej rzeczy, którą powiedział Marcin - takiej, która zmienia całe podejście do networkingu:

Najlepsi freelancerzy i PM-owie nie szukają pracy. To praca szuka ich.

Nie dlatego, że mają szczęście. Dlatego, że latami, meetup po meetupie, budowali sieć kontaktów, która ich pamięta i odzywa się, gdy pojawia się okazja. Networking to nie jest coś, co odpalasz, gdy stracisz pracę (patrz: historia Daniele z początku artykułu). To coś, co budujesz zanim będzie Ci potrzebne.

To zresztą łączy się z metryką „time to yes” z wcześniejszej sekcji. Daniele w rok skrócił czas potrzebny na ściągnięcie topowego speakera z 10 godzin do 30 minut - bo przez ten rok konsekwentnie budował relacje. Ty budujesz dokładnie to samo, tylko dla własnej kariery.

Ciekawostka: Ile… pije się na konferencjach produktowych?

I jeszcze jedno, obalony mit. Myślisz, że konferencje to picie? Daniele przy pierwszej edycji zapytał ChatGPT, ile alkoholu zamówić - dostał rekomendację 3 litry na osobę, zamówił 4. Skończyło się na oddaniu 20 skrzyń napojów.

„Ludzie piją mniej, niż myślisz. Ledwie dwa litry dziennie, i to głównie kawa.”

Najlepsi freelancerzy i PM-owie nie mają problemu ze znalezieniem pracy - to praca znajduje ich. Bo latami, meetup po meetupie, budowali sieć kontaktów, która pamięta ich i odzywa się, gdy pojawia się okazja.

5️⃣ Podsumowanie

Nawet jeśli nigdy w życiu nie zbudujesz community, historia Daniele daje Ci kilka rzeczy do zastosowania od zaraz 👇

• ✅ Timing bije pomysł. Świetne produkty (i community) powstają, gdy realna potrzeba spotyka odpowiedni moment. Twoja robota to go rozpoznać, nie wymyślić.

• ✅ Sprzedawaj outcome, nie features. Daniele nie sprzedaje prelekcji. Sprzedaje connection i benchmark. Zapytaj siebie: jaki realny job to be done rozwiązuje mój produkt?

• ✅ Zidentyfikuj trudniejszą stronę marketplace’u. W community to podaż. W Twoim produkcie może to być coś innego - ale prawie zawsze jedna strona jest cenniejsza i trudniejsza. Skup tam energię.

• ✅ Mierz to, co naprawdę mówi o zdrowiu produktu. Retencja. Time to yes. Czasem najlepsza metryka to wyczucie wyrobione przez powtarzanie - byle było oparte na realnym sygnale.

• ✅ Jeśli jesteś liderem i czujesz się samotnie - to normalne. Znajdź swój krąg ludzi, którzy myślą jak Ty. To nie luksus, to potrzeba.

• ✅ Networking to discovery, nie sprzedaż siebie. Przyjdź z ciekawą myślą, nie z CV. Pytaj, co nie działa, nie proś o komplementy.

Cała ta rozmowa utwierdziła mnie tylko w czymś, co powtarzam od dawna: realny product craft to sposób myślenia, który działa wszędzie - na produkcie, na własnej karierze, na budowaniu społeczności, a nawet (jak pokazał Daniele) na wyjściu z zawodowego dna.

🎁 Bonusy dla społeczności (~500 euro)

Powyżej wyciągnąłem najważniejsze wątki, ale w odcinku jest znacznie więcej - m.in. pełny lineup berlińskiej konferencji, kulisy zapraszania speakerów i cała dyskusja o tym, jak zmienia się rola product leadera.

A jeśli chcesz zobaczyć to na żywo - Daniele organizuje w Berlinie trzydniową konferencję ProdcutLab (15-17 września) ze speakerami z n8n, Stripe, Reforge, Parloa i Ravim Mehtą. Spacjlanie dla społeczności “Dodane do Backlogu” przygotował promocody na konferencję:

• 🏆 €100 zniżki dla dwóch liderów na bilet Leadership Workshop + 3 dniowy bilet konferencję.

• 🎟️ 20% ZNIŻKI dla 5 osób na 3 dniowy bilet na konferencję.

Szczegóły i kody w opisie odcinka na Spotify ⤵️

→ Posłuchaj odcinka

Brzmi znajomo? No właśnie.

W tym odcinku Dodanego do Backlogu startujemy z nowym formatem - bierzemy cztery takie hot take’i i zderzamy je z tym, co faktycznie widzimy w swoich organizacjach. Spoiler: nie zgadzamy się ze sobą równie często, co z influencerami👇

→ Słuchaj na Spotify

lub Apple Podcast.

• czy ⁠roadmapy umierają? czy małe zespoły z OKR-ami zastąpią długoterminowe planowanie?

• większość PMów nie przetrwa AI - czystka czy hype napędzany strachem?

• determinizm AI stanie się głównym wyróżnikiem produktów - kto okiełzna nieprzewidywalność, wygra

• ⁠liderzy produktu wracają do bycia IC - czy zarządzanie bez kontrybuowania ma jeszcze sens?

Z odcinka dowiesz się:

• (02:13) - Hot take #1: Śmierć roadmap - CPO Slacka ogłosił koniec długoterminowego planowania, zastępując je małymi cross-funkcjonalnymi zespołami z OKR-ami. Czy to kolejny Spotify model, który wszyscy będą naśladować - albo który porzucą po roku?

• (08:30) - Jak roadmapy wyglądają w praktyce naszych organizacji - i dlaczego różnica między “nie mamy roadmapy” a “mamy roadmapę na rok” jest mniejsza niż myślisz

• (19:29) - Hot take #2: Większość PM-ów nie przetrwa AI - czy grozi nam wielka czystka backlog managerów, czy to tylko hype napędzany strachem, który sprzedaje kursy produktowe?

• (27:00) - Czy AI to multiplier dla PM-ów czy wymówka do zwolnień - jak lay-offy przez AI wyglądają od środka i co tak naprawdę jest ich przyczyną

• (35:57) - Hot take #3: Determinizm stanie się głównym wyróżnikiem produktów AI - kto okiełzna nieprzewidywalność LLM-ów, wygra rynek. Jak to się ma do tego, co budujemy dziś?

• (46:33) - Hot take #4: Elena Varna, była head of growth w Amplitude, Miro i Dropboxie, wróciła do roli IC - i mówi, że to jest przyszłość managerów. Coraz mniej liderów zarządzających ludźmi, coraz więcej super-indywidualnych kontrybutorów

• (53:00) - Czy organizacja stanie się softwarem? Wojtek stawia tezę, że people managerowie nie znikną - tylko staną się orkiestratorami opisującymi firmę kodem zamiast rozmowami

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. PM ma unikalny profil ryzyka psychicznego. I nie chodzi o “stres w pracy”. Accountability without authority - odpowiadasz za produkt, revenue, OKR-y, a nie masz formalnej władzy nad nikim. Inżynierowie raportują do CTO, designerzy do head of design. Ty każdego dnia przekonujesz wszystkich do wszystkiego. To nie jest normalne napięcie. To się kumuluje - i ma swoją nazwę w psychologii: ciężar emocjonalny.

2. Sandwich pressure wykańcza nie gorzej niż praca w call center. Z góry lecą pytania “czemu tak wolno shipujecie?”, z dołu “czemu ciągle zmieniacie scope?”. Ty jesteś buforem. A bufory się zużywają. Badania pokazują, że pracownicy obsługi klienta - którzy muszą codziennie odbierać czyjąś frustrację i oddawać uśmiech - mają największe problemy z kontrolą emocji. PM w sandwich pressure działa dokładnie tak samo.

3. Impostor syndrome u PM-ów jest na sterydach - i AI go nakręca. Musisz rozmawiać z inżynierami o architekturze, z biznesem o revenue, z data scientistami o metrykach, z designerami o UX. Nigdzie nie jesteś ekspertem. W kulturach nagradzających pewność siebie przyznanie się do “nie wiem” kosztuje ogromnie dużo energii. A AI dokłada do tego AI anxiety - poczucie, że pociąg odjeżdża i nie zdążysz wskoczyć.

4. Traktuj swój well-being jak produkt. PM-owie są ekspertami od rozwiązywania problemów innych - i nagminnie ignorują własne sygnały. Przepis jest prosty: zmierz stan wyjściowy, zdefiniuj konkretny problem, przetestuj rozwiązanie, zmierz ponownie, iteruj. Dokładnie ten sam framework, którego używasz przy produkcie. Ty też możesz być single point of failure.

5. Peer support to nie “miękkie HR-owe rzeczy” - to realna interwencja. Gadaj z innymi PM-ami. Nie żeby rozwiązywać problem, żeby go znormalizować. Usłyszenie od kogoś “mnie też to dotknęło, to jest naprawdę trudne” robi robotę, której żaden framework nie zrobi. Piątkowa kawa z PM-ami, na której wylewacie żale - to jest kozetka u terapeuty. I działa.

6. Porażki niech będą porażkami - przestań szukać happy endu. Fuck Up Nights to świetna technika - ale tylko jeśli nie kończysz każdej historii morałem “i właśnie dzięki temu odnieśliśmy sukces”. Większość porażek nie ma happy endu. Są po prostu porażkami. Normalizowanie tego - bez obowiązku przekucia w lekcję - buduje odporność psychiczną lepiej niż jakikolwiek kurs produktowy.

7. Siła psychiczna to przewaga konkurencyjna - mierzalna w złotówkach. Firma z tysiącem pracowników korzystających z platformy wsparcia psychicznego odzyskuje 0,8 dnia pracy miesięcznie per osoba. W skali roku to równowartość 36 dodatkowych etatów. Wypalona organizacja rosnąca w 40% rocznie to predyktor przyszłego kolapsu - nie sukcesu. Zdrowie psychiczne zespołu to nie koszt. To inwestycja z mierzalnym ROI.

Nasza produktowa branża jest zakochana w temacie AI jako narzędzia - ChatGPT do PRD, Claude do analizy, Perplexity do researchu. OK, ale mało kto mówi o tym, jak realnie budować produkty i ficzery oparte o AI? Skąd wiem, że ten model AI działa tak jak powinien?

Bo to są trudniejsze pytania.

Na to drugie pytania odpowiada temat AI Evals. I to jest fundament każdego produktu opartego o LLM-y. W tym odcinku Dodane do backlogu pokazujemy jak my do podchodzimy do ewaluacji ficzerów AI. Trzej PMowie, którzy zderzają się z tym problemem na codzień👇

→ Słuchaj na Spotify

lub Apple Podcast.

• czym są evals i skąd bierze się ich rosnąca rola w produktach opartych o AI

• czy evals faktycznie mierzą jakość, czy tylko to, co łatwo zmierzyć

• kto powinien być odpowiedzialny za evals — PM, QA, engineering, czy może zupełnie nowa rola

• jakie są praktyczne metody i sposoby wdrażania evals

• jak evals zmieniają rolę Product Managera i wpływają na strukturę organizacji

Z odcinka dowiesz się:

• (03:50) - Czym w ogóle są AI Evals i dlaczego klasyczne myślenie o testach tu nie działa? - tłumaczymy różnicę między deterministycznym a niedeterministycznym outputem na przykładzie botów konwersacyjnych

• (13:00) - Jak wygląda cykl ewaluacji w praktyce - od ręcznego przeglądania outputów, przez zero-jedynkowe labelowanie, po automatyzację i zamykanie pętli feedbacku do produktu

• (20:45) - Kiedy AI w ogóle nie jest potrzebne - dlaczego prosta reguła deterministyczna często wygrywa z LLM-em i jak to zmienia podejście do budowania evals

• (24:19) - Jakich narzędzi używać do budowania evals - od Excela i CSV, przez gotowe platformy, po moment gdy budujesz własne narzędzie i dlaczego prawie zawsze tam trafiasz

• (29:02) - Gorąca dyskusja: dlaczego to PM, a nie QA powinien być właścicielem jakości AI - i czy rodzi się zupełnie nowa rola w organizacjach produktowych

• (38:37) - Jak wygląda wielka reorganizacja w świecie AI - raport z 50 firm, mniejsze zespoły, nowe role (system architect, validator) i co to znaczy dla PM-ów

• (44:47) - Optymalizacja kosztów LLM-ów jako kluczowa inicjatywa - jak wybierać modele do różnych zadań, dlaczego nie zawsze chcesz najlepszego i jak evals pomagają podjąć tę decyzję świadomie

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. Trudność z AI Evals polega na tym, że oceniać coś c o z definicji jest nieprzewidywalne - w klasycznym produkcie dajesz input i dostajesz zawsze ten sam output. W AI ten sam input może dać 99,9% razy świetną odpowiedź - i raz coś kompletnie absurdalnego. Evals istnieją po to, żeby próbować panować nad tym chaosem.

2. Zacznij od ręcznej oceny (nawet jeśli masz miliony generacji LLM miesięcznie) - wszyscy przez to przechodzą - CSV, spreadsheet, człowiek który klika i labeluje. To jest fundament. Bo tylko ręczna próbka pozwala wyłapać problemy, których żaden automat jeszcze nie szuka - bo ich jeszcze nie znasz.

3. Ocena zero-jedynkowa działa lepiej niż skala - zamiast “jak dobra jest ta odpowiedź AI w skali 1-5”, pytaj: “czy to jest zgodne z oczekiwanym zachowaniem, tak czy nie?”. Brzmi prymitywnie, ale lepiej działa. Ułatwia automatyzację i pozwala mierzyć jakość w czasie.

4. Zmiana modelu AI w produkcie bez evals to strzelanie w ciemno - ogólne benchmarki “kłamią” w kontekście naszego produktu. Model, który wygrywa na leaderboardzie, może na Twoich danych i Twoim use case’ie wypaść dramatycznie gorzej. Dopiero jak sprawdzisz na własnych danych - przez własne evale - zobaczysz prawdę. I dlatego bez evals zmiana modelu to kosmos.

5. Nie zawsze potrzebujesz AI od oceny wyników - prosta reguła oparta o regex może zastąpić drogi LLM w zadaniu klasyfikacyjnym. Jeśli człowiek mówi o kredycie hipotecznym, jest skończona liczba słów, których użyje. Zanim wrzucisz problem do modelu - sprawdź, czy deterministyczne podejście nie zrobi tego taniej, szybciej i równie skutecznie.

6. Wybór modelu to decyzja biznesowa, nie techniczna - nie chodzi o “który model jest najlepszy”, tylko o to który jest najlepszy dla tego use case’u, przy tym koszcie, dla tego segmentu klientów. Zmiana modelu to tak naprawdę rozmowa o modelu biznesowym i o tym, na jaki rynek celujesz. Klienci premium akceptują wyższy koszt i oczekują wyższej jakości. I odwrotnie.

7. PM powinien być właścicielem jakości AI - jakość outputu LLM-a staje się produktem samym w sobie. Jeśli Twój produkt stoi na AI, prompt engineering i ocena jakości to często 90% roboty. To zbyt strategiczne, żeby oddać komuś, kto nie rozumie use case’u i kontekstu biznesowego. Możesz angażować innych - ale odpowiedzialność będzie zawsze po Twojej stronie.

Dlatego w kolejnym odcinku podcastu Dodane do backlogu porozmawialiśmy z najlepszą osobą łączącą świat produktu i zdrowia psychicznego - Adamem Ploną, CEO Mindgram (platforma wsparcia psychicznego) i produktowcem z 18-letnim stażem.

Accountability without authority. Sandwich pressure. Decision fatigue. Impostor syndrome na sterydach. I AI anxiety na dokładkę. Czas potraktować swój well-being tak samo poważnie, jak traktujesz backlog.

→ Słuchaj na Spotify

lub Apple Podcast.

Adam Plona jest współzałożycielem i CEO Mindgram - największej platformy wsparcia psychicznego dla organizacji w Polsce, z dostępem dla prawie miliona pracowników i ich rodzin. Wcześniej przez 18 lat rozwijał produkty cyfrowe m.in. w Wirtualnej Polsce, Domodi i Homebook. Ukończył program executive na Stanford University. W Mindgramie zaczynał jako COO - rolę CEO objął w 2025 roku.

Z odcinka dowiesz się:

• (03:27) - Skąd wziął się Mindgram i dlaczego Adam - po 18 latach kariery produktowej - uznał, że to ludzie, nie technologia, są wąskim gardłem w skalowaniu organizacji

• (09:04) - 4 główne bariery w dostępie do pomocy psychologicznej i gdzie technologia naprawdę może pomóc (a gdzie nie)

• (17:37) - Jak mierzyć ROI ze zdrowia psychicznego? Adam rozkłada na czynniki pierwsze, ile odzyskanych dni pracy znaczy dla firmy w złotówkach

• (37:40) - Unikalny profil ryzyka PM-a: accountability without authority, sandwich pressure, decision fatigue i impostor syndrome na sterydach - dlaczego ta rola jest naprawdę trudna psychicznie

• (43:48) - AI anxiety - czyli dlaczego sztuczna inteligencja nakręca poczucie bycia z tyłu, nawet jeśli już z niej korzystasz

• (46:36) - Potraktuj swój well-being jak produkt: zmierz, przetestuj rozwiązanie, iteruj - praktyczny framework dla PM-a, który świetnie rozwiązuje cudze problemy, ale ignoruje własne

• (50:46) - Peer support, Fuck Up Nights i Gratitude Friday - konkretne techniki, które działają i kosztują dosłownie zero złotych

• (56:38) - Osobiste doświadczenia Adama: od sceptyka terapii do człowieka, który świadomie buduje swoją siłę psychiczną jako przewagę - i co konkretnie zmienił w codziennym funkcjonowaniu

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. PM ma unikalny profil ryzyka psychicznego. I nie chodzi o “stres w pracy”. Accountability without authority - odpowiadasz za produkt, revenue, OKR-y, a nie masz formalnej władzy nad nikim. Inżynierowie raportują do CTO, designerzy do head of design. Ty każdego dnia przekonujesz wszystkich do wszystkiego. To nie jest normalne napięcie. To się kumuluje - i ma swoją nazwę w psychologii: ciężar emocjonalny.

2. Sandwich pressure wykańcza nie gorzej niż praca w call center. Z góry lecą pytania “czemu tak wolno shipujecie?”, z dołu “czemu ciągle zmieniacie scope?”. Ty jesteś buforem. A bufory się zużywają. Badania pokazują, że pracownicy obsługi klienta - którzy muszą codziennie odbierać czyjąś frustrację i oddawać uśmiech - mają największe problemy z kontrolą emocji. PM w sandwich pressure działa dokładnie tak samo.

3. Impostor syndrome u PM-ów jest na sterydach - i AI go nakręca. Musisz rozmawiać z inżynierami o architekturze, z biznesem o revenue, z data scientistami o metrykach, z designerami o UX. Nigdzie nie jesteś ekspertem. W kulturach nagradzających pewność siebie przyznanie się do “nie wiem” kosztuje ogromnie dużo energii. A AI dokłada do tego AI anxiety - poczucie, że pociąg odjeżdża i nie zdążysz wskoczyć.

4. Traktuj swój well-being jak produkt. PM-owie są ekspertami od rozwiązywania problemów innych - i nagminnie ignorują własne sygnały. Przepis jest prosty: zmierz stan wyjściowy, zdefiniuj konkretny problem, przetestuj rozwiązanie, zmierz ponownie, iteruj. Dokładnie ten sam framework, którego używasz przy produkcie. Ty też możesz być single point of failure.

5. Peer support to nie “miękkie HR-owe rzeczy” - to realna interwencja. Gadaj z innymi PM-ami. Nie żeby rozwiązywać problem, żeby go znormalizować. Usłyszenie od kogoś “mnie też to dotknęło, to jest naprawdę trudne” robi robotę, której żaden framework nie zrobi. Piątkowa kawa z PM-ami, na której wylewacie żale - to jest kozetka u terapeuty. I działa.

6. Porażki niech będą porażkami - przestań szukać happy endu. Fuck Up Nights to świetna technika - ale tylko jeśli nie kończysz każdej historii morałem “i właśnie dzięki temu odnieśliśmy sukces”. Większość porażek nie ma happy endu. Są po prostu porażkami. Normalizowanie tego - bez obowiązku przekucia w lekcję - buduje odporność psychiczną lepiej niż jakikolwiek kurs produktowy.

7. Siła psychiczna to przewaga konkurencyjna - mierzalna w złotówkach. Firma z tysiącem pracowników korzystających z platformy wsparcia psychicznego odzyskuje 0,8 dnia pracy miesięcznie per osoba. W skali roku to równowartość 36 dodatkowych etatów. Wypalona organizacja rosnąca w 40% rocznie to predyktor przyszłego kolapsu - nie sukcesu. Zdrowie psychiczne zespołu to nie koszt. To inwestycja z mierzalnym ROI.

→ Słuchaj na Spotify

lub Apple Podcast.

Zderzyliśmy jak zawsze nasze różne doświadczenia - jak planujemy tydzień, żeby dowieźć to co naprawdę ważne (a nie tylko być zajętym), jakieś są nasze rutyny i jak nasza praca ewoluowała przez lata.

Trochę taktycznie, ale jak zawsze na bazie naszych kilkudziesięciu (:D) lat błędów i doświadczeń w pracy produktowej:

• Wojtek Smajda (Senior Product Manager, IBM)

• Jakub Tutaj (Growth Product Manager, Mixmax)

• Marcin Jedrzejczak (Principal Product Manager, Celonis)

• Tomek Tomaszewski (Head of Product, BrainBits.ai)

W odcinku usłyszysz:

• (01:36) - Nasza poranna rutyna w pracy i wojna o Slacka - czy sprawdzać wiadomości od razu po przebudzeniu?

• (10:20) - Jak dbamy o czas na „Deep Work”?

• (16:16) - Budżet uwagi: Czy wydajesz go na drobne po 5 groszy, czy na grube tematy?

• (28:00) - Zasada 5 wiadomości: Kiedy przestać pisać i po prostu zadzwonić?

• (47:00) - Planowanie tygodnia: Metoda 3 celów i dlaczego poniedziałek jest lepszy niż piątek.

• (58:23) - Dlaczego przestaliśmy chodzić na wszystkie spotkania

Słuchaj odcinka

Moje najważniejsze insighty z rozmowy:

1. Twój budżet deep work to średnio 2-4 godziny dziennie - i koniec. Nie 8 godzin „skupienia”. Nie 6. Dosłownie 2-4 godziny efektywnej pracy głębokiej to wybitny dzień. Resztę zjada bieżączka, kontekst switching i rozgrzewka. Im szybciej to zaakceptujesz i zaczniesz chronić te godziny jak skarb, tym lepsze będą Twoje wyniki.

2. Sprawdzenie Slacka rano nie jest złe - ale masz świadomie wybrać, kiedy to robisz. Jedni zaczynają od przeglądu (żeby wiedzieć, czy nie ma pożaru - to JA), inni chronią rano jak źrenicę oka i wchodzą w deep work od razu. Nie ma jednej odpowiedzi. Jest tylko jedna pułapka: wchodzenie na Slacka odruchowo, bez intencji. To właśnie kradnie Ci focus zanim w ogóle zaczniesz myśleć.

3. Nie musisz odpowiadać szybko – musisz ustawiać oczekiwania u stakholderów. Kuba ma na to fajną zasadę, którą komunikuje wprost: „Jeśli jestem online, odpiszę w ciągu godziny – ale ta odpowiedź może Cię nie zachwycić.”. Responsywność nie polega na byciu zawsze dostępnym. Polega na tym, żeby ludzie wiedzieli, czego i kiedy mogą się po Tobie spodziewać. To jest zarządzanie zależnościami, nie unikanie ich.

4. Tygodniowe planowanie działa - ale tylko jeśli masz max 3 priorytety. Jeden duży cel + dwa poboczne. Jeśli zrobiłeś te 3 rzeczy – był zarąbisty tydzień. Reszta to szum, który i tak się pojawi. Im wyższe seniority, tym krótsza lista: junior PM pisze 15 rzeczy, senior – dwie. Nie dlatego, że robi mniej. Dlatego, że wie, co naprawdę jest ważne

5. Rozmowa na żywo czasem rozwiązuje w 3 minuty to, co na Slacku ciągnie się godzinami. Praca synchroniczna nie jest złem. Złem jest brak intencjonalności - czyli gadanie non-stop, bo wszyscy siedzą w jednym pokoju. Ale jeśli w wątku na Slacku wymieniasz już piątą wiadomość i nadal nie ma decyzji - zrób calla.

6. Większość naszej pracy i tak okazuje się błędna – więc wykryj to jak najszybciej. Bez względu na to, jak świetnie priorytetyzujesz, zbierasz insighty i prowadzisz discovery – duża część rzeczy, które robisz, okaże się po prostu nietrafionym kierunkiem. Nie ma czym się frustrować. To jest powód, żeby budować krótkie pętle feedbackowe i nie wkładać 3 miesięcy pracy w coś, zanim sprawdzisz czy w ogóle warto.

7. PM odpowiada za energię zespołu - nawet gdy sam ma dołek. Kiedy eksperyment nie wyszedł, sprint leży, a morale siada – ktoś musi powiedzieć żart, zrobić oddech i zapytać „dobra, jak do tego podchodzimy jeszcze raz?". Nie chodzi o udawanie, że jest dobrze. Tylko o świadome zarządzanie atmosferą, która bezpośrednio wpływa na to, czy zespół spróbuje kolejny raz z energią - czy odpuści.

To dość unikalna opcja, by zobaczyc co myślą i jak podejmują decyzje ludzie na poziomie VP w globalnych firmach. Porozmawaliśmy o tym:

• 1️⃣ Jak nawigować po hierarchii w dużej organizacji?

• 2️⃣ Współpraca z product managerami z perspektywy VP of ENG

• 3️⃣ Trudne decyzje o „ubijaniu” istniejących produktów

• 4️⃣ Jak nie dać się „hypowi” na AI?

Rozmowy możesz posłuchać w formie podcastu, a dla tych co wolą czytać - forma wywiadu w newsletterze ⤵️. Rozmowa przeprowadzona w składzie: Marcin Jędrzejczak, Wojtek Smajda, Jakub Tutaj. Dzięki chłopaki z ten podcast 🙌.

Todd Roman to obecny SVP of Engineering w Zendesk, kierujący zespołami inżynierów w regionie EMEA, włączając AI/ML, automatyzację, komunikację i platformy dla deweloperów. Wcześniej pełnił funkcję Senior Director Software Engineering w Under Armour, gdzie nadzorował inżynierię dla MapMyFitness, MyFitnessPal i Under Armour Record.

1️⃣ Jak nawigować po hierarchii w dużej organizacji?

Zacznijmy od tematu wywierania wpływu i podejmowania decyzji w globalnych firmach. Większość Product Managerów nie do końca wie, jak nawigować w strukturze orgniazacyjnej, szczególnie w dużych organizacjach. Jakie widzisz tu największe, nieoczywiste wyzwanie przed którymi stają PMowie?

Todd Roman: To ciekawe pytanie. Myślę, że odpowiedź różni się w zależności od organizacji, jej struktury i stylu zarządzania liderów. Mogę mówić z własnego doświadczenia.

Największym wyzwaniem, jakie widzę, jest sytuacja, w której PM-owie stają się zbyt odizolowani i skupieni na swoim wąskim obszarze.

To naturalna pułapka - codzienna praca operacyjna potrafi pochłonąć cały ich czas.

• Dzieje się tak często pod presją terminów i codziennej pracy operacyjnej ze swoimi zespołami deweloperskimi, gdzie głównym celem staje się "dowiezienie" kolejnej funkcjonalności.

• W takim trybie PM-owie wahają się lub mają trudności z dotarciem do swoich przełożonych, często z obawy, że zadając pytania o strategię, okażą się niekompetentni lub po prostu "zawracają głowę".

• W efekcie tracą pewność, czy ich działania są zgodne z celami firmy, co w skrajnych przypadkach prowadzi do marnowania cennych zasobów na inicjatywy, które nie przybliżają biznesu do jego celów.

Zawsze staram się znaleźć chwilę dla każdego, kto tego potrzebuje. To chyba sedno sprawy - w miarę jak organizacje rosną, powstają kolejne warstwy, co naturalnie prowadzi do nieporozumień lub braku komunikacji.

Przekaz, który na górze jest jasny, może zostać zniekształcony, gdy przechodzi przez kilka szczebli zarządzania. To nie jest celowe, to po prostu efekt skali.

Dlatego moja rada dla PM-ów brzmi: miejcie odwagę, wyjdźcie z inicjatywą, połączcie się z liderami i utrzymujcie z nimi relacje.

Często po stronie PM-ów brakuje chęci zrozumienia jak działa biznes - realnego połączenia ich codziennej pracy z celami finansowymi firmy. Jak liderzy mogą zachęcać PMów do mówienia językiem biznesu?

Todd Roman: Im większa organizacja i więcej warstw, tym wyzwanie staje się większe. Zespoły zaczynają pracować nad coraz bardziej specyficznymi zadaniami i łatwo tracą z oczu szerszy obraz. Dlatego powtarzanie celów biznesowych musi być jak codzienna mantra.

Trzeba nieustannie przypominać nie tylko, co robimy, ale przede wszystkim, dlaczego to robimy. Kontekst biznesowy musi być obecny na spotkaniach typu all-hands, w komunikacji wewnętrznej i podczas planowania. Nie wystarczy ogłosić roczny plan na jednym spotkaniu. To musi być regularny, powtarzalny rytm potwierdzania kierunku.

Zendesk - globalna platforma służąca do zarządzania obsługą klienta i wspierania sprzedaży

W niektórych organizacjach, w których pracowałem, "dlaczego" było całkowicie pomijane. Skupiano się na "co" i "kiedy", a wszyscy po prostu ruszali do przodu.

Taki stan rzeczy prowadzi do sytuacji, w której zespoły, nie rozumiejąc celu, podejmują setki małych, suboptymalnych decyzji, które w skali całej firmy oddalają nas od sukcesu. Regularna komunikacja pozwala każdemu połączyć swoją pracę z nadrzędnym celem biznesowym, a co ważniejsze – z wartością dla klienta.

2️⃣ Współpraca z product managerami z perspektywy VP of ENG

W dużych organizacjach, gdzie rośnie liczba PM-ów o różnym doświadczeniu, firma może stracić swój unikalny „product taste". Jak z perspektywy lidera myślisz o utrzymaniu tej spójności, podobnie jak robił to Steve Jobs, który potrafił wnikać w najdrobniejsze szczegóły, by go zachować?

Todd Roman: Pracowałem w miejscach, gdzie nadzór był ogromny, ale nie uważam, że sam w sobie jest czymś złym. Regularne product reviews i dema są niezwykle ważne, aby uniknąć rozminięcia się z celem.

• Kiedy zespoły PM-ów działają w izolacji, w swoich enklawach, stają się echem dla samych siebie.

• Wpadają w pułapkę myślenia grupowego, tracąc kontakt z szerszą perspektywą użytkownika i spójnością całego produktu.

• Brakuje im feedbacku z zewnątrz, który mógłby zakwestionować ich założenia.

Uwielbiam „demo days”, gdzie można namacalnie doświadczyć tego, co buduje zespół, i dać im informację zwrotną. Te dwa elementy - współpraca i feedback - są kluczowe, aby upewnić się, że idziemy w dobrym kierunku i możemy w porę skorygować kurs.

Ostatnią rzeczą, jakiej byśmy chcieli, jest wielki projekt w modelu waterfall, po którym zespół wraca po roku z czymś, co jest całkowicie niezgodne z potrzebami firmy czy klienta. To nie tylko strata pieniędzy, ale też ogromny cios dla morale zespołu.

Jaka jest jedna rzecz w trakcie współpracy z PM-ami lub zespołami produktowymi, której po prostu NIE AKCPETUJESZ?

Todd Roman: Staram się nie akceptować w milczeniu czegoś, co uważam za błędne. Informacja zwrotna to dar, nie kara. Najlepsze, co możemy dać naszym współpracownikom, to bezpośredni i szybki feedback.

Rzeczą, która zmusza mnie do natychmiastowej reakcji, jest sytuacja, gdy widzę, że zespół zapomniał, dlaczego coś robi. Kiedy tracą z oczu wartość dla klienta.

• To może objawiać się na przykład obsesją na punkcie metryki technicznej, jak skrócenie czasu odpowiedzi o kilka milisekund, podczas gdy sama funkcja nie rozwiązuje realnego problemu użytkownika.

• Innym przykładem jest ślepe kopiowanie funkcji konkurencji bez zrozumienia, czy nasi klienci faktycznie mają ten sam problem.

To wymaga natychmiastowej korekty i przypomnienia: zacznij od klienta i pracuj wstecz (backwards). Czasem stajemy się zbyt skoncentrowani na tym, co próbujemy zrobić, a może to po prostu zła rzecz.

To są te momenty, w którym czuję silną potrzebę, by wkroczyć i zadziałać.

Chciałbym, żeby więcej PM-ów zapraszało swoje zespoły developerski na spotkania z klientami. Zamiast być tarczą, która chroni deweloperów, powinni budować bezpośrednie połączenie między zespołem a potrzebami klienta. Gdy deweloperzy słyszą problemy bezpośrednio od użytkowników, zyskują empatię i kontekst, co przekłada się na lepsze decyzje projektowe i większe zaangażowanie w sukces produktu. To niezwykle ważne.

Bardza ważna jest też komunikacja na styku PM-Eng-Founderzy. Czy masz jakieś doświadczenia, gdzie doskonała komunikacja ze strony pojedynczego PM-a uratowała produkt, który nie był w dobrej kondycji?

Todd Roman: W jednej z poprzednich firm przez długi czas próbowaliśmy wprowadzić na rynek płatną, subskrypcyjną wersję naszego produktu. Projekt był wielokrotnie uruchamiany i zatrzymywany.

To był okres, kiedy firmy B2C były oceniane głównie przez pryzmat liczby aktywnych użytkowników, a nie wyników finansowych, ale my widzieliśmy w tym złotą szansę na przychód. Problem polegał na tym, że za każdym razem, gdy zaczynaliśmy, zarząd mówił: „to nie jest to, czego chcę”.

W końcu jeden z PM-ów, do którego mam ogromny szacunek, złamał ten impas.

• Jego metodą była konsekwentna, ciągła praca ze founderami, kalibrowanie ich oczekiwań i przekazywanie tego feedbacku zespołowi w czasie rzeczywistym.

• To oznaczało cotygodniowe spotkania, pokazywanie prototypów, otwarte dyskusje o kompromisach i priorytetach.

Dzięki temu mogliśmy na bieżąco korygować kurs i uniknęliśmy budowania przez pół roku czegoś, co na końcu zostałoby odrzucone. To wymagało wytrwałości, wysiłku i ciągłej komunikacji.

3️⃣ Trudne decyzje o „ubijaniu” istniejących produktów

Brałeś udział w trudnych decyzjach, także dotyczacych „ubijania” produktów. Kiedy pojawia się ten moment, jakie są symptomy, że nadszedł czas na rozpoczęcie rozmów o zamknięciu produktu?

Todd Roman: Jestem zwolennikiem powiedzenia, które przypisuje się Churchillowi:

Niestety, jako ludzie mamy tendencję do odkładania trudnych decyzji na później, aż do momentu, gdy wybucha kryzys. Robimy to z obawy przed zdenerwowaniem klientów, z powodu wewnętrznej polityki, albo po cichu licząc, że problem sam się rozwiąże. Wtedy nasze opcje stają się bardzo ograniczone.

Najgorzej jest, gdy zostaje nam tylko jeden wybór. Idealnie byłoby działać wcześniej. Staram się patrzeć na to:

• Ile inwestujemy, a jaką wartość z tego uzyskujemy?

• Czy widzimy malejące zyski?

• Czy jest szansa to odwrócić, czy po prostu nie mamy odpowiedniego dopasowania do rynku, popytu lub ludzi, by osiągnąć sukces?

• Czy to na pewno właściwa rzecz, na którą powinniśmy poświęcać czas?

Myślę, że kluczowe jest, by nie doprowadzić do kryzysu, choć to właśnie on często stwarza wyjątkową okazję do podjęcia działań, na które wcześniej nie było zgody.

Aby jednak działać wcześniej, potrzebujemy danych - i to nie tylko ilościowych, ale też jakościowych: opinii klientów, analizy konkurencji, trendów rynkowych. Brak danych to jedna z głównych przyczyn złych decyzji. Nigdy nie będziemy mieli pełnego obrazu, ale musimy czuć się komfortowo, podejmując decyzje na podstawie niekompletnych informacji.

Jak podchodzisz do balansu między dwiema opcjami: próbą odwrócenia losu produktu, a decyzją o jego zamknięciu, aby uwolnione zasoby przeznaczyć na coś innego? Czy kiedykolwiek widziałeś sytuację, w której wybrano bardziej ryzykowną ścieżkę ponownego, większego zainwestowania w produkt?

Todd Roman: Takie decyzje rzadko się zdarzają, ale tak. Jeśli już, to zwykle dzieje się tak, gdy istnieje wyraźny popyt rynkowy, a rozwijanie istniejącego produktu jest lepsze niż budowanie czegoś od zera.

Częściej miałem do czynienia z ratowaniem rozwiązań technicznych, które były dobre, ale zostały zaniedbane:

• Wtedy zainwestowanie w ich poprawę jest znacznie lepsze niż budowanie czegoś nowego.

• Jest taka naturalna tendencja, zwłaszcza gdy przychodzą nowi ludzie, że patrzą na istniejące rozwiązanie i ich pierwszą reakcją jest: „nie chcę się tym zajmować, zbudujmy nowe”.

• To często wynika z chęci pracy z nowymi technologiami i dumy deweloperskiej.

• Tak powstaje klasyczny problem, gdzie mamy dziewięć rozwiązań, budujemy dziesiąte, żeby je skonsolidować, a kończymy z dziesięcioma rozwiązaniami.

Pamiętam też sytuację, gdy podjęliśmy decyzję o end-of-life produktu pochodzącego z przejęcia. Nie działał dobrze, był na zupełnie innej architekturze, a doprowadzenie go do porządku wymagałoby ogromnych inwestycji. Choć istniało na niego zapotrzebowanie rynkowe, uznaliśmy, że te same osoby mogą przynieść znacznie więcej wartości, pracując nad czymś innym. To była trudna decyzja, zwłaszcza że wiązała się z utopionymi kosztami akwizycji, ale okazała się słuszna.

Mówiłeś o potrzebie danych. Jak ocenić, ile ich wystarczy, by podjąć odważną decyzję, a jednocześnie nie utknąć w paraliżu analitycznym?

Todd Roman: Nigdy nie będzie idealnie i nigdy nie będziesz miał wszystkiego, czego potrzebujesz. To jedno z wyzwań przywództwa.

Kluczowe jest zrozumienie perspektywy klienta. To nie tylko patrzenie na metryki, ale też prowadzenie wywiadów, testów użyteczności i analizowanie zgłoszeń do wsparcia, by znaleźć dlaczego za danymi.

Jeśli klienci nie adoptują produktu, to dlaczego? Czy rozumiemy, czego im brakuje?

Kiedy mamy wystarczająco dużo informacji na ten temat, obraz staje się jaśniejszy. Możemy ocenić, jaki byłby koszt i potencjalny zysk z wdrożenia brakujących funkcji. Jeśli inwestycja w stosunku do przewidywanego rezultatu wygląda niekorzystnie, decyzja staje się prostsza.

Ilość potrzebnych danych będzie się różnić w zależności od sytuacji, ale fundamentem jest zrozumienie potrzeb klienta.

4️⃣ Jak nie dać się „hypowi” na AI?

Przejdźmy do gorącego tematu AI. Wszyscy chcą integrować sztuczną inteligencję ze swoimi produktami. Czy z Twojej perspektywy widziałeś przypadki użycia AI, które w praktyce nie zadziałały - czy to technologicznie, czy produktowo?

Todd Roman: Inżynierowie od uczenia maszynowego powiedzieli mi kiedyś, że pierwszą zasadą AI jest to, że go nie potrzebujesz. Wiele problemów można rozwiązać bez sztucznej inteligencji.

Dziś największym wyzwaniem jest to, że jeśli coś nie działa dzisiaj, jest duża szansa, że zadziała jutro lub za pół roku. Technologia rozwija się w niewiarygodnym tempie.

• Dlatego „posypywanie” wszystkiego AI to nie jest strategia.

• Często widzimy, jak firmy dodają chatbota, który nie rozwiązuje realnego problemu, albo używają AI do prostych zadań, które mógłby wykonać zwykły skrypt. To jest napędzane presją marketingową, a nie potrzebą użytkownika.

• Z drugiej strony, jeśli nie mówisz, że używasz AI, ryzykujesz, że zostaniesz uznany za przestarzałego.

Prawdziwe wyzwanie polega na tym, że każda strategia AI, którą opracujesz dzisiaj, za kilka miesięcy może być nieaktualna. Dlatego kluczowe staje się utrzymanie elastyczności i zdolności do adaptacji.

Dla mnie pytanie nie brzmi „czy to zadziała”, ale „kiedy to zadziała”. Dojdziemy do momentu, w którym AI będzie rozwiązywać 80-90% problemów w danym obszarze, ale te ostatnie 10-20% nadal będzie wymagało ludzkiego osądu.

Maszyny nie można pociągnąć do odpowiedzialności tak jak człowieka.

OK, to w obliczu tego dynamicznego rozwoju AI - jakie fundamentalne zasady myślenia o produkcie powinni PM-owie zachować, żeby nie dać się ponieść hype’owi?

Todd Roman: Myślę, że to te same „first principles”, co przy każdym innym produkcie: zacznij od klienta i pracuj wstecz. Zastanów się, jak to pomoże klientowi.

Ale też - co tu może pójść katastrofalnie źle.

Intersujące jest, jak antropomorfizujemy LLMy, używając słowa “halucynacja”. To przypomina nam, że ich działanie nie zawsze jest deterministyczne. Dlatego kluczowe jest zrozumienie, co może pójść nie tak, i budowanie guardrails.

Praktyczne przykłady to wymóg ludzkiej weryfikacji dla treści generowanych przez AI, czy zapewnienie łatwej ścieżki eskalacji do człowieka w bocie obsługowym.

Technologia staje się coraz lepsza, ale musimy rozumieć ryzyko. Z czasem, gdy nasza pewność co do jej niezawodności wzrośnie, będziemy mogli te zabezpieczenia poszerzać lub obniżać.

Ostatecznie, wszystko sprowadza się jednak do zrozumienia wartości dla klienta i świadomości, że nawet jeśli AI nie pasuje tutaj dzisiaj, to może zacząć pasować za pół roku.

Dzięki Todd za szczerą i pełną insightów rozmowę

Todd Roman: Dziękuję bardzo!

P.S. Treść wywiadu nie jest zwykłą transkrypcją rozmowy. Treść została przeze mnie dostosowana do lepszego odbioru w formie tekstowej, ale z zachowaniem całej merytoryki. Tak, pomógł mi w tym AI, ale długie ręczne review było dalej niezbędne ;).

Zapraszam też do subskrypcji naszego podcastu „Dodane do Backlogu” po więcej takich rozmów.