→ 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.