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.