Dzisiaj druga część poradnika o tym jak pracować w środowisku tzw. bullshit product managementu - rzeczywistości niestety wielu PMów. Jesteśmy tutaj 👇

Poradnik powstał na podstawie mojej rozmowy z Davidem Pereirą w podcaście „Dodane do Backlogu". David to CPO w MailerLite, autor książki "Untrapping Product Teams" i jeden z najbardziej bezkompromisowych głosów w świecie PMów. A jeśli wolisz możesz posłuchać pełnej rozmowy z Davidem 🎧.

W części pierwszej rozłożyliśmy na czynniki pierwsze, czym jest Bullshit Product Management. Mówiąc krótko: to sztuka marnowania energii na rzeczy, które nie tworzą wartości (a jak wiemy, więcej bullshitu = mniej wartości).

Może teraz myślisz: „Przecież robię, co mogę!", „To nie moja wina, że organizacja tak działa!", "Ale ja nie mam wpływu na...".

I masz rację.

Bullshit Product Management to rzadko wina samego PM-a. To zwykle konsekwencja kultury organizacyjnej, presji na delivery, braku przestrzeni na discovery, stakeholderów, którzy „wiedzą lepiej", roadmap pełnych deadline’ów i kolejnych pomysłów na outputy -ficzery.

Ale - i to jest kluczowe - możesz zacząć robić lepszy product management także w takim środowisku.

Jak powiedział David Pereira:

W tej części pokażę Ci, na podstawie rozmowy z Davidem, jak odnaleźć się w takim środowisku i zacząć przesuwać swoje działanie z bullshit PM, na prawdziwy product management. Rozłożymy to na 3 konkretne kroki, które możesz zacząć robić, bez rewolucji w organizacji:

Większość PM-ów, którzy odkrywają, że robią bullshit product management, popełnia ten sam błąd: chcą od razu wszystko zmienić.

Widzisz problem i myślisz: „Muszę wdrożyć discovery! Muszę zmienić roadmapę! Muszę wprowadzić OKRy! Muszę zacząć mierzyć outcome’y produktowe!". I rzucasz się w wir zmian.

Efekt? Uderzasz w ścianę.

Organizacja się broni. Stakeholderzy mówią „nie". Zespół nie rozumie, o co Ci chodzi. A TY zostajesz z frustracją i myślą: „Tu się nic nie da zrobić".

David mówi o tym bardzo wprost:

Czyli nie zaczynaj od działania, tylko od obserwacji.

Brzmi banalnie? Może :D. Ale to jest najbardziej niedoceniany krok w całym procesie wychodzenia z bullshit PM. Bo jeśli nie rozumiesz, co się dzieje w Twojej organizacji - będziesz walczyć z wiatrakami.

To jest Twój punkt wyjścia - zidentyfikuj, czego NIE ma - co się w organizacji nie dzieje, na co nie mamy czasu, bo ciągle dostarczamy i pracujemy nad outputem. To Twoja dźwignia do późniejszych zmian. Bo możesz sprawić, ze te rzeczy zaczną się pojawiać.

Jak ro zrobić w praktyce? Zrób sobie 2 tygodniowy sprint podczas którego będziesz obserwować organizację, oraz obserwować siebie i swój czas.

Zrób sobie dedykowaną notatkę / spreadsheet i przez 2 tygodnie po prostu notuj, jakie tematy dominują w rozmowach:

Ustal, co się NIE dzieje, bo cały czas spędzacie na pracy na OUTPUTACH:

Jeśli chcesz wejść w temat głębiej i bardziej szczegółowo zweryfikować Wasze braki - możesz odwołać się do poszczególnych pryncypiów i zasad „Product Modelu” Model Marty Cagan. Dzięki temu od razu masz “checklistę” tematów którym warto się przyjrzeć:

Znajdziesz to w moim poradniku:

Przygotowałem w nim także praktyczny arkusz, który możesz użyć do obserwacji i samooceny stosowania pryncypiów w Twoim zespole:

Przez 2 tygodnie prowadź również dziennik swojej pracy. Tak, żebyś mógł / mogła ocenić czym tak naprawdę się zajmujesz - „na co idzie Twój czas”.

Na koniec podziel działania na 3 kategorie:

Zrób to szczerze i krytycznie. Na koniec tygodnia policz: ile % czasu spędziłeś w każdej kategorii?

Jeśli na Tworzeniu wartości spędzasz mniej niż 30% - jesteś głęboko w bullshit PM i musisz to zmienić. David w podcaście mówi o tym bardzo otwarcie:

To zadanie pomoże Ci zobaczyć, gdzie marnujesz energię. Ale co ważniejsze - da Ci od razu konkretne dane, żeby coś z tym zrobić - możesz wybrać pierwsza działania których chcesz się “pozbyć” lub zminimalizować, by dać sobie przestrzeń na wartościową pracę.

Osobiście robiłem takie audyty na 2 sposoby:

1️⃣ Po prostu spisując moje zadania w spreedsheet z konkretnego tygodnia i potem je klasyfikując. Dla cyklicznych zadań - spisuję też ile czasu na to poświęcam co tydzień / dwa tygodnie.

To podejście bardzo fajnie mi się sprawdziło, gdy robię sobie audyt bardziej odpowiedzialności i większych obszarów działań. Natomiast, gdy schodzę do poziomu mniejszych pojedynczych działań lepiej sprawdziło mi się:

2️⃣ Zapisując swoje wszystkie spotkania, ale też i działania (także indywidualne) w kalendarzu i stosując tzw. color coding - oznaczając każdy blok odpowiednim kolorem oznaczającym jedną z 3 wspomnianych kategorii.

Wiele aplikacji daje taką opcję dodawania kolorów. Np. kalendarz Google potrafi także zliczyć samodzielnie potem czas poświęcony na poszczególne obszary (oraz więcej inisghtów). Można tez sobie po prostu stworzyć dedykowane kalendarze na poszczególne kategorie.

Po 2 tygodniach obserwacji wiesz już, czego NIE ma w Twojej organizacji i na co tracisz swój. Widzisz luki. Widzisz, że nikt nie mierzy outcome'ów. Że nikt nie sprawdza, czy ficzery działają. Że roadmapa to lista życzeń, nie strategia.

I teraz pojawia się pokusa, żeby powiedzieć: „Musimy zacząć robić discovery! Musimy mierzyć outcome! Musimy zmienić sposób pracy!"

Jeśli przyjdziesz do organizacji z postulatami zmian, usłyszysz:

Dlaczego? Bo mówisz o zmianie procesu, nie o wartości. Mówisz o tym, co organizacja POWINNA robić, zamiast pokazać, co może ZYSKAĆ.

David nauczył się tego na własnej skórze i ma na to bardzo konkretną receptę:

Zacznij od ewaluacji tych problemów, nie od rewolucji.

Zamiast krytykować, najpierw pokaż, że stary sposób działania jest kosztowny i jakie są jego minusy. Wtedy naturalnie zacznie się poszukiwanie lepszych podejść.

Kluczowa rzecz: nie pozycjonuj się jako krytyk, tylko raczej jako pomocnik / przewodnik, który chce pomóc:

David bardzo wyraźnie to podkreśla:

Różnica jest ogromna. Pierwsze podejście tworzy konflikt (JA vs WY). Drugie podejście tworzy bardziej partnerstwo - zobaczcie jak to wyglada, jeśli Wam to przeszkadza, to pomyślmy co możemy z tym zrobić.

Przykładowo:

Fajna metodą, którą wpisuje się w takie pozycjonowanie jest tzw. „Mirror Method” - czyli metoda lustra. Zamiast krytykować, po prostu starasz się by inni mogli się zobaczyć trochę jak w lustrze - zobaczyć sytuację, aktualny stan taki jak realnie jest jest. Z jego plusami i minusami.

Sam jestem wielkim fanem tej metody.

Poniżej znajdziesz kilka przykładów - jakich “luster” możesz użyć w swojej organizacji, a w kolejnym rozdziale szczegółowy przykład ewaluacji ficzerów.

Metodę lustra do wielu sytuacjach i do wielu problemów które zidentyfikowałeś (-aś) w KROK 1. Jedną z pierwszych rzeczy, który często od razy wykrywasz jest to, że nie ewaluujecie swoich inicjatyw / nowych feater’ów.

Jeśli nie robicie tego - Ty zacznij i zrób właśnie metodą lustra. Zmierz wyniki ostatnich feature'ów i zaprezentuj wyniki w swoim zespole.

Jak to zrobić konkretnie?

Pokaż to liderom zespołów i stakeholderom. Zwykle na start lepiej na spotkaniu 1:1, niż na publicznym na forum.

Nikt nie lubi, gdy marnuje się pieniądze. Jeśli potrafisz połączyć koszt budowy (inwestycje) z zerową lub niską wartością, masz ich uwagę.

Ludzie słuchają, gdy mówisz o konkretnych stratach.

Gdy pokażesz, że organizacja marnuje pieniądze - ludzie zaczną słuchać. Zaczną pytać "jak możemy tego uniknąć?". I wtedy możesz wprowadzić zmiany.

Podczas podcastu David pokazał fajny przykład jak wykorzystał tę metodę: w swoim zespole przeanalizował i ocenił ficzery starsze niż rok.

50% z tych ficzerów nie było nawet dotykane przez użytkowników. I wtedy przyszedł do stakeholderów z prostym pytaniem: "Czy powinniśmy dalej tak robić?"

Pokazał, że połowa pracy inżynierów i budżetu poszła na marne. To jest realny obraz sytuacji. Nie mówił: "Robicie źle". Mówił: "Oto dane. Co o tym myślicie?"

Co się stało?

Stakeholderzy zobaczyli dane. Zobaczyli, że połowa ich pracy i pracy zespołów idzie na marne. I nagle pytanie: "Może powinniśmy robić więcej discovery?" przestało brzmieć jak teoretyzowanie, a zaczęło brzmieć jak... zdrowy rozsądek.

David wtedy powiedział: "Zacznijmy od małego discovery przed następną dużą inicjatywą. Sprawdźmy, czy problem istnieje, zanim wydamy pół roku na kolejne rozwiązanie."

Ludzie nie reagują na postulaty zmian. Reagują na problemy, na to że coś tracą.

Masz już dowód, że stary sposób jest drogi. Teraz pokaż, że nowy jest szybki i skuteczny. Fundamentem product managementu i tym co może wnieść od razu największą wartość i zmianę jest… product discovery.

I od product discovery rekomenduję by zwykle zacząć robić jakieś zmiany.

I teraz z jednej strony jest pokusa, żeby powiedzieć:

Stop ❌. Znowu chcesz za dużo, za szybko.

Efekt zwykle będzie taki, że wszyscy stwierdzą… „Nie mamy na to czasu, nie możemy tyle czekać, nie mamy na to budżetu! Zespół musi przecież nad czymś pracować!”. A Ty szybko zyskasz renomę osoby, która blokuje wszystko i krytykuje każdy pomysł, bo „nie ma discovery”

Z drugiej strony często też Tobie pojawi się w głowie: żeby zrobić “prawidłowe” discovery to będziecie potrzebować mnóstwa czasu. Jak ja mam to pogodzić z dotychczasową pracą? Muszę poprosić o pozwolenie na to.

To jest najbardziej kontrowersyjna część tej taktyki, więc napiszę to wprost:

Dlaczego? Bo organizacja, która robi bullshit PM, nie rozumie wartości discovery. Dla nich to brzmi jak: "Chcę wydać tydzień na rozmowy zamiast budować ficzer". To brzmi jak opóźnienie. To brzmi jak blokada. Więc powiedzą „nie mamy na to czasu" albo „zróbmy to później" (co znaczy: nigdy).

David mówi o tym bardzo wprost:

Nie prosisz o pozwolenie, bo:

Aby jednak takie podejście zadziałało 👉 Musisz ZACZĄĆ od czegoś małego.

Wybierz JEDEN Feature z Roadmapy - taki, co do którego masz największe wątpliwości. Najlepiej wystarczająco duży, strategiczny, na który firma planuje wydać 2-3 miesiące.

Taki jeden ficzer to będzie idealne miejsce, by pokazać wartość discovery. Ale nie jest to wielka zmiana dotycząca całej firmy.

Do tego by zacząć robić discovery i się uczyć w ramach jednej inicjatywy - nie potrzebujesz wielkiego formalnego i idealnego procesu ani budżetu. Inwestujesz swój czas, nie budżet firmy.

Największa wymówka PM-ów brzmi: „Nie mam dostępu do klientów" albo „To zajmie mi miesiąc, żeby to zorganizować".

Bullshit.

Nie potrzebujesz research teamu, nie potrzebujesz formalnego procesu rekrutacji, mie potrzebujesz budżetu na incentywy, żeby zacząć w ogóle rozmawiać z użytkownikami.

Potrzebujesz po prostu 3-5 rozmów po 30 minut. To może zająć Ci kilka dni, jeśli działasz sprytnie.

Kluczowe zasady przy wszystkich taktykach:

Jeśli wykorzystasz 2-3 z tych taktyk jednocześnie, będziesz miał 5 wywiadów w ciągu tygodnia.

Na koniec stwórz 1-slajdowe podsumowanie wyników swojego discovery i wróć do stakeholderów. Zastosuj ponownie metodę lustra - pokaż po prostu dane, które udało Ci się zebrać.

David podaje bardzo konkretny przykład:

Przykład prezentacji do stakeholderów:

Jeśli pomożesz dzięki temu uniknąć złych decyzji - inwestycji w feature, która pewnie zostałaby zmarnowana - budujesz zaufanie do siebie i wiekszą swobodę we wprowadzaniu dalszych zmian.

Sukces tego kroku NIE polega na tym, że:

Sukces tego kroku polega na tym, że:

I to powinien być Twój najważniejszy cel w tym momencie.

Gdy stakeholderzy zaczynają SAMI pytać o discovery - wygrałeś. Bo przeszedłeś z pozycji "PM, który blokuje" na pozycję "PM, który pomaga podejmować lepsze decyzje".

W ostatniej części poradnika podrzucę Ci trochę rad jak kontynuować rozpoczętą zmianę, zdobywać zaufanie interesariuszy i uniknąć najważniejszych pułapek.

BTW. Jeśli chcesz posłuchać pełnej rozmowy z Davidem Pereirą - znajdziesz ją w podcaście „Dodane do Backlogu" 🎧.