We wrześniu zakończyliśmy letnią edycję Product Management Academy - ponad 40 uczestników ukończyło nasz 7 tygodniowy program warsztatów product managementu.

📈 Ocena satysfakcji to 4,6 / 5, a finalny NPS mamy na poziomie... 95 😍😱.

Sam też się jak zawsze dużo nauczyłem i postanowiłem się tym z Wami tym merytorycznym mięskiem podzielić. Poniżej zebrałem moje najciekawsze lessons learned z poszczególnych modułów: znajdziesz w nich kluczowe koncepcje do wykorzystania przy rozwoju produktów cyfrowych.

• 1️⃣ [FOUNDATION] Jak zacząć jako PM z nowym zespołem? - szablon do warsztatów z team alignementu

• 2️⃣ [DISCOVERY] Jak oceniać pewność swoich pomysłów? - skala (nie)pewności Itamara Gilada

• 3️⃣ [DELIVERY] Czy Product Manager powinien zajmować się delivery? - moje wnioski i wskazówki

• 4️⃣ [ANALYTICS] Jak podejść do ewaluacji (nowych) funkcji w produkcie? Framework TARS

• 5️⃣ [STARTEGY] Cele (OKRy) to też hipotezy - 4 nieoczywiste fundamenty

• 🎁 BONUS: 5 pełnych lekcji z PMA - zuperłnie za free

PRODUCT FOUNDATION

1️⃣ Jak zacząć jako PM z nowym zespołem?

Jak zacząć jako PM z nowym zespołem? ...to temat, który najbardziej otworzył mi głowę podczas modułu o fundamentach pracy PMa.

Przygotowując dla uczestników nową lekcję przepracowywałem ponownie świetne case study Patrycja Walencik w którym opowiadała jak sama dołączyła do nowego zespołu w Zendesk-u i jak zbudowała alignement w zespole.

Zabieram z tego case study dla siebie na pewno szablon warsztatu do team alignementu, ale zanim szablon (poniżej) to kilka moich lessons learned.

Moje LESSONS LEARNED:

1️⃣ Na start jako PM muszę chcieć (ale tak serio chcieć) schować swoją egocentryczną postawę i zacząć od lepszego zrozumienia jakie WARTOŚCI i POSTAWY WYZNAJE ZESPÓŁ. To one będą terminować, czy się dogadamy.

2️⃣ Zespół też będzie chciał znać nasze wartości - jesteśmy na starcie dla nich "ciałem obcym" i naturalne jest, że członkowie zespołu będą chcieli wiedzieć jakie my mamy podejście, jak się zachowujemy w poszczególnych sytuacjach. Musimy być przygotowani, by umieć to jasno przedstawić.

3️⃣ Nie ma dobrej produktowej pracy zespołu bez TEAM ALIGNMENTu - zarówno pomiędzy członkami zespołu, jaki i też nowo dołączający product managerem. Musimy być “alignmentowani” w kontekście tego jak ze sobą współpracować, ale też wspólnego zrozumienia kierunku, celów, priorytetów i strategii.

4️⃣ Kluczowe jest jasne określenie swoich ról i czego możemy od siebie oczekiwać. Każdy może mieć różne doświadczenia i zrozumienie tego jak powinien pracować zespół / PM.

I teraz NAJWAŻNIEJSZE 💎:

5️⃣ Nie chodzi tu o tworzenie opasłych dokumentacji i rozkmin. Na start świetnie sprawdzi się warsztat z team alignementu z wykorzystaniem Miro/Murala. Potem powinniśmy co jakiś czas weryfikować (np. podczas retro) czy to co wypracowaliśmy podczas warsztatu jest wystarczające, czy może jako zespół potrzebujemy to odświeżyć i wprowadzić jakąś zmianę.

Przykładowy szablon na Miro:

I jeszcze słowo od autorki case study:

PRODUCT DISCOVERY

2️⃣ Jak oceniać pewność swoich pomysłów?

Jak pokazywać naszą niepewność, gdy stakeholder ma kolejny "mega ważny i pilny" pomysł? Narzędziem, które może w tym pomóc jest skala (nie)pewności Itamar Gilada. Ta prosta skala zawsze rozsadza mi głowę i uczestnikom modułu Product Discovery.

Skala Gilada to jedno z moich ulubionych narzędzi - świetnie pokazuje i otwiera oczy na to jak bardzo możemy być pewni swoich pomysłów na podstawie posiadanych informacji (zebranych dowodów).

❌ Masz tylko pojedynczą opinię swojego szefa/stakholdera - tak naprawdę jesteś na początku tej skali i nie masz żadnej pewności.

🤔 Masz pojedyncze opinie użytkowników, dowody anegdotyczne, sygnały z pierwszych wywiadów lub feedbacku - jesteś w środku te skali, coś już wiesz, ale do pewności jeszcze Ci daleko.

🖤 Zrobił_ś badania ilościowe, eksperymenty, wypuszczasz MVP, analizujesz dane - dopiero wtedy możesz twierdzić, że Twoje pierwotne założenia z dużą większą dozą pewności mają sens.

Już samo pokazanie takiej skali np. interesariuszom, którzy mają kolejny "mega ważny i pilny" pomysł - zasiewa ziarno niepewności, często przekonuje do robienia więcej discovery.

Wykorzystanie w ICE Score

Skala świetnie też nadaje się na literkę C w ICE score, którego często używamy do priorytetyzacji pomysłów ze stakeholderami.

ICE score =  Impact x CONFIDENCE x Ease. 

Zamiast intuicyjnie określać CONFIDENCE (jak się pewnie czujemy z tym pomysłem) np. od 1 do 5 j - użyj po prostu skali pewności Itamara. Jest ona mega obrazowa dla interesariuszy, trudno się z nią też ^{nie zgodzić} .

Najważniejsze jest zawsze pytanie "gdzie jesteśmy na tej skali niepewności?" i tym samym ile jeszcze Discovery musimy zrobić, by zyskać pewność co do naszego pomysłu. Mając nawet te same zebrane "dowody" - dyskusja nad odpowiedzią bywa gorąca. Ale to dobrze, już sama dyskusja będzie miała ogromną wartość.

PRODUCT DELIVERY

3️⃣ Czy Product Manager powinien zajmować się product DELIVERY 👀?

Czy Product Manager powinien zajmować się product DELIVERY ...to kolejny temat, który mocno rogrzał dyskusję podczas letniej edycji Product Management Academy (w module Product Delivery).

No bo, czy za wdrażanie rozwiązania nie powinien odpowiadać zespół developerski, albo wręcz wprost tech lead zespołu albo delivery manager? Dyskusje na ten temat były gorące.

Moje LESSONS LEARNED:

1️⃣ Bez dobrego Delivery, nie ma szans na dobry produkt. Słaba praca na OUTPUT'ach przekłada się na słabą pracę nad OUTCOME'ach. A to się wprost przekłada na szansę sukcesu w produkcie i to jak ja jako PM jestem postrzegany (i finalnie mój większy/mniejszy wpływ).

Dlatego, pewnie to niepopularna opinia, ja jako product manager zawsze CZUJĘ SIĘ ODPOWIEDZIALNY za to czy nasze Delivery działa dobrze - nawet jeśli są do tego "dedykowane" role.

Nie, nie chodzi o to bym by moja rola sprowadzała się do backlog managementu, dowożeniu ficzerów i usprawnianiu pracy zespołu. Ale czuje się odpowiedzialny za to, by to delivery dobrze działało i reaguję/wspieram, gdy jest to potrzebne.

2️⃣ Sztywny podział na Delivery i Discovery jest absurdalny - praca nad Product Delivery... to przecież dalej testowanie naszych pomysłów i obniżanie niepewności produktowych. Pod to też powinniśmy dobierać co i jak dostarczamy.

Dopiero jak wypuścimy pierwszą wersję naszego rozwiązania na rynek, która zderzy się z realnym użytkownikami, będziemy wiedzieli, czy poczliśmy w dobrą stronę. Czy przyniosło to wartość dla użytkownika 🎁, wartość biznesową 💰 i czy byliśmy w stanie to zbudować 🛠️.

3️⃣ Jeśli dostarczamy produkt wolniej i w gorszej jakości, to... wolniej też iteruję i tym samym wolniej jestem w stanie dostosowywać produkt do potrzeb użytkowników. Z produktowego punktu widzenia - nie mogę sobie na to pozwolić.

I teraz ponownie NAJWAŻNIEJSZE lessons learned 💎:

4️⃣ Dlatego tak ważna jest dobra współpraca Product Managera z Tech Leadem w Product Trio i zespołem DEV. Budujmy wspólną odpowiedzialności za sukces produktu - także proces product delivery 🛠️.

PRODUCT ANALYTICS

4️⃣ Jak podejść do ewaluacji (nowych) funkcji w produkcie? Framework TARS

Jak podejść do ewaluacji (nowych) funkcji w produkcie? Jakie metryki wybrać?

Framework TARS do ewaluacji funkcji/produktu to chyba był mój ulubiony temat i narzędzie z modułu Product Analytics podczas letniej edycji Product Management Academy.

Framework jest mega prosty, ale robi genialną robotę ✅.

TARS został opracowany przez Reforge i jest akronimem od nazw miar, które warto mierzyć w swoim produkcie: Targeted Users, Active Users, Retention i Satisfaction.

TARS jednak to coś więcej niż tylko zbiór miar - to framework, który pozwala jasno oceniać funkcje produktu, analizować jak dobrze docieramy z propozycją wartości do użytkowników i czy rzeczywiście rozwiązujemy problemy tych użytkownika. Marzenie product managera 😅.

Co dokładnie mierzymy w TARS?

Używając TARS dla każdej funkcji produktu mierzymy:

1️⃣ ACTIVE TARGET users (Użytkownicy docelowi): Wszyscy aktywni użytkownicy zainteresowani korzystaniem z nowej funkcji. Może to być 80%, 50% lub nawet 30% całej bazy aktywnych użytkowników.

💡 Kluczowe jest, że mówimy tu o AKTYWNYCH użytkownikach z grupy docelowej danej funkcji. Nie każda funkcja jest dla każdego użytkownika naszego produktu. To jest mocno otwierające oczy spojrzenie.

2️⃣ ACTIVE ADOPTED users (Aktywni użytkownicy): Liczba użytkowników z grupy docelowej, którzy skorzystali przynajmniej raz z funkcji.

💡 Ta miara pozwala na monitorowanie czy użytkownicy wyrazili zainteresowanie funkcją - czyli czy rzeczywiście dobrze zidentyfikowaliśmy ich problem (zainteresowała ich wartość).

3️⃣ ACTIVE RETAINED users (Retencja użytkowników): Jaki jest procent użytkowników, którzy nadal korzystają z funkcji w codziennej, tygodniowej lub miesięcznej rutynie (w zależności od częstotliwości występowania use case'u dla tej funkcji).

💡 Ta miara pozwala na monitorowanie długoterminowego sukcesu funkcji, czy nasze rozwiązanie rzeczywiście rozwiązuje problem użytkowników. Jeśli użytkownicy wracają, to znaczy że przynosi im to wartość.

4️⃣ ACTIVE SATISFIED users (Satysfakcja użytkowników): Jaki procent użytkowników jest zadowolonych z funkcji? Możemy użyć np. Customer Effort Score.

💡 A to na pozwala sprawdzić jak dobrze rozwiązujemy problem użytkowników, czy są zadowolenie z rozwiązania / UX.

Do czego używam TARS?

Pamiętam jak TARS pozwolił mi uporządkować myślenie o analityce całego produktu i poszczególnych funkcji. Dzięki niemu zacząłem też na bieżąco śledzić jak nasze zmiany w produkcie wpływają na realne zachowania użytkowników..

Uporządkował też mój sposób pracy - np. jeśli użytkownicy nie zauważyli lub nie rozumieją Twojej funkcji i dlatego jej nie korzystają z niej - niewiele możesz zrobić, aby poprawić jej utrzymanie i satysfakcję. Dlatego najpierw zaczynasz od pracy i weryfikowaniu hipotez związanych z adopcją.

PRODUCT STRATEGY

5️⃣ Cele (OKRy) to też hipotezy

„OKR to też jest hipoteza!” - to proste stwierdzenie totalnie otworzyło mi głowę podczas spotkania case study z mentorem modułu Product Strategy.

Mentorowała nas świetna specjalistka - Elena Zhukova z OKR Poland. Lena opowiedziała jak krok po kroku wdrożyć i wykorzystywać OKRy na przykładzie konkretnej firmy.

Tutaj świetny obrazek, kótry przedstawia tę koncpecję

Moje LESSONS LEARNED:

1️⃣ Praca nad strategią to PRACA CIĄGŁA

Bez strategii OKRy nie mają sensu. Jeśli mamy strategię, to OKRy właśnie mogą nam pomóc ułożyć ciągłą, iteracyjną pracę nad realizacją, mierzeniem i uaktualnianiem tej strategii.

2️⃣ OKRy reprezentują nasze HIPOTEZY

OKR roczny powinien reprezentować nasz najlepszy pomysł (najlepszą szansę / "bet"), naszą hipotezę na sprawdzenie, czy nasza długoterminowa strategia firmowa/produktowa ma sens.

OKR kwartalny to też reprezentacja naszej hipotezy - naszego najlepszego pomysłu na sprawdzenie, czy nasz OKR roczny ma sens.

Oczywiście wybór hipotez powinien opierać się na wcześniejszym procesie discovery 🔍 Proste, ale bardzo odświeżające.

3️⃣ OKRy można ZMIENIAĆ

Jako, że OKRy reprezentują nasze hipotezy, to oznacza że możemy „się pomylić” przy ich stawianiu. Dlatego framework OKR świetnie pozwala mierzyć postęp, wyciągać wnioski i zdecydować, że nasze OKRy były błędne i czy trzeba je ZMIENIĆ.

I teraz ponownie najważniejsze moje lessones learned 💎:

4️⃣ KLUCZOWE REZULTATY DEFINIUJE AUTOR CELu

Nie ma czegoś takiego, że ktoś pisze Objective'y, a ktoś inny Key Results'y. Kluczowe rezultaty są wyjaśnieniem, dokładnym wytłumaczeniem jak chcemy osiągnąć Cel. Dlatego to osoba stawiająca Cel powinna jasno określić kluczowe rezultaty.

Temat OKRów mnie tak zainspirował, że razem z Mateuszem Paprockim z OKR Poland tworzymy cały proadnik “OKR dla product managerów”:

🎁 BONUS: 5 pełnych darmowych lekcji z Product Management Academy

Bonusową lekcją, którą wyciągnąłem z ostatnich edycji PMA było to… że lekcje wideo i materiały online PMA mają bardzo dużą wartość dla uczestników.

W ankietach dostaliśmy mnóstwo pozytywnego feedback na ten temat, także wiele osób mówi nam, że wraca do tych materiałów po zakończonej Akademii. Tu wprost przykład z ostatniego tygodnia:

Dlatego postanowiliśmy, że udostępnimy 5 pełnych lekcji z programu Product Management Academy 🎉. Co ważne, zrobimy to zupełnie za darmo 🎁. Po jednej lekcji z każdego kluczowego modułu. To będą dokładnie te same materiały, z których korzystają uczestnicy Akademii.

Aby otrzymać lekcje - wystarczy, że zapiszesz się poniżej na lekcje, a w październiku trafią one na Twoją skrzynkę mailową:

Co znajdę w lekcjach?

Czeka nas 5 mega ciekawych tematów:

1. [FOUNDATION] Adopcja i zaangażowanie – ocena funkcji produktu. W tej lekcji dowiesz się w jaki sposób podejść do analizy i oceny funkcji produktu.

2. [DSICOVERY] 4 typy niepewności produktowych - W tym materiale poznasz koncepcję czterech typów niepewności produktowych, które będziesz systematycznie weryfkować w procesie product discovery.

3. [DELIVERY] Backlog refinement - najważniejsze informacje i wskazówki dotyczące prowadzenia backlog refinmentu

4. [LEADERSHIP] Jak ułożyć współpracę z interesariuszami - techniki i narzędzia pozwalające efektywnie współpracować i budować zaufanie.

5. [STARTEGY] Synchronizacja pracy zespołów produktowych poprzez OKRs - Elena Zhukowa opowie o swoim case study wdrażania OKRs w dojrzałej organizacji produktowej.

Lekcje zawierają prezentacje wideo, materiały dodatkowe, a część z nich także szablony do wykorzystania w praktyce. Tutaj mały sneak peek:

Po zapisie damy Ci też znać, gdy ruszy sprzedaż kolejnej edycji Product Management Academy. Nie będziemy rozsyłać Ci SPAMu ❌, wysyłamy tylko informacje związane z PMA. W każdej chwili możesz się wypisać z otrzymywanych wiadomości.

Lekcje zaczniemy wysyłać w okolicach połowy października.

Mam nadzieję, że te materiały Ci się przydadzą. Tymczasem pracujemy z Mateuszem nad kolejną częścią naszego Poradnika OKR dla product managerów.