O robieniu product managementu w czasach prosperity powiedziano już prawie wszystko. Wiemy, jak tworzyć produkty w ociekających finansowaniem od VC startupach oraz bogatych korporacjach.

Co jednak robić, gdy sytuacja się zmieniła? Jak robić product management, mamy kryzys, zwolnienia i okrojone budżety zespołów produktowych?

1. 📕 Jak kryzys wpływa na product management?

2. ⚔️ Kryzys vs Praktyka (moje doświadczenia)

   1. Discovery i Priorytety

      1. 1.3. Większy nacisk na eksperymenty i MVP

      2. 1.3. Większy nacisk na eksperymenty i MVP (ship it …

   2. Produktowa Intuicja

   3. Multidyscyplinarność Zespołu

   4. Automatyzacja Product-Ops

   5. Współpraca z Inwestorami

   6. Forsuj Product-Led Growth i produktowe porządki

3. 💬 Kluczowe pytanie - czy Ci zależy?

W ostatnich kwartałach przez ekosystem produktów cyfrowy przetoczyła się kolejna fala zwolnień – także w PRODUCT MANAGEMENCIE.

Google zwolniło 13 00 osób (6% załogi), Facebook/Meta pozbyła się ponad 20 000 osób w dwóch dużych rundach, Twitter/X rozstał się z połową pracowników. Szybko rosnące i wysoko wyceniane scaleupy zapowiedziały lub rozpoczęły redukowanie załogi (Stripe, Lift, Bolt).

W drugiej części 2023 roku na szczęście trochę ta fala wychamowała, 2024 to jednak cały czas duża niewiadoma, a pierwsze sygnały nie są zbyt optymistyczne.

📕 Jak„kryzys” wpływa na robienie product managementu?

Co ma jednak „kryzys” do robienia dobrego product managementu? Techniki przecież są te same – trzeba po prostu opracowywać dobrą strategię produktową, odkrywać potrzeby użytkowników, obniżać ryzyka produktowe przez product discovery, no i skutecznie wdrażać rozwiązania…

Tak to przynajmniej wygląda na salach szkoleniowych i w teorii. Rzeczywistość bywa bardziej brutalna.

Możesz robić świetny produkt, ale niespodziewany „black swan” (ostatnio choćby COVID, wojna) potrafi zatrząść fundamentami finansowymi firmy w której pracujesz. Możesz np. pracować w korpo, którą dotknęło spowolnienie gospodarcze, a Twój świetnie rozwijający się produkt jest tylko mała częścią portfolio.

I nagle wtedy okazuje się, że…

• ❌ „Nie, nie możemy zatrudnić kolejnych developerów, designerów, czy researcherów do zespołu – nawet jeśli widać fajny progres w Twoim produkcie”.

• ❌ „Nie, nie możemy zainwestować w super proces product discovery, który zwróci się za X miesięcy. Musimy podjąć strategiczne decyzje już teraz”.

• ❌ „Czemu tracisz nasze pieniądze na jakieś eksperymenty i pomysły, które się nie udają?”

• ❌ „Nie, nie sfinansujemy szybkiego wzrostu kolejną łatwą rundą od inwestorów.”

Mniejszy zespół, mniejszy budżet, krótsze horyzonty działania, więcej zewnętrzych nacisków – jak sobie z tym radzić? Jak w takich warunkach robić product management?

⚔️ Kryzys vs Praktyka (moje doświadczenia)

W ciągu 12 lat swojej kariery przechodziłem już kilka takich kryzysowych sytuacji w roli PM-a i Heada Produktu. Poniżej zabrałem najważniejsze z moich doświadczeń w 6 obszarach:

1. Discovery i priorytety

2. Produktowa intuicja

3. Multidyscyplinarność zespołu

4. Automatyzacja Product-Ops

5. Współpraca z inwestorami - to nie wrogowie

6. Wykorzystaj kryzys – forsuj product-led growth i produktowe porządki

1. Discovery i priorytety

To chyba najistotniejszy punkt. Okrojony budżet to mniej ludzi i czasu. Zwykle na pierwszy ogień pod redukcję idzie obszar discovery. Wynika to wprost ze zmieszenia składu osobowego lub pośrednio, przez dokładanie zespołowi dodatkowych obowiązków i odpowiedzialności (zamiast np. stworzenia nowego zespołu do nowych wyzwań).

Więcej odpowiedzialności, mniejszy (lub ten sam) skład prowadzi wprost do tego, że mniej czasu poświęcamy na discovery, a więcej na delivery i operacyjną pracę. Konsekwencje są jasne – podejmujemy produktowe decyzje w warunkach większej niepewności.

1.1. Priorytetyzacja discovery i inicjatyw

W takich warunkach, paradoksalnie, discovery i walidacja rozwiązań zyskują na jeszcze większym znaczeniu. Musisz nauczyć się umiejętność priorytetyzacji i szacowania IMPACTu szans produktowych. Nie będziesz mieć po prostu czasu / zasobów na szczegółową weryfikację wszystkich pomysłów. Dlatego tak ważna będzie ocena tego, w jakie inicjatywy warto zainwestować większe moce w obszarze discovery i walidacji rozwiązań.

To, co mi tutaj pomaga, to powiedzenie sobie, zespołowi i interesariuszom wprost – nie zrobimy do wszystkiego świetnego discovery. Ja dzielę wtedy inicjatywy na 3 kategorie:

1. Priority – inicjatywy, na których chcemy się skupić, bo mają dać nam najwięcej korzyści, a jednocześnie są mocno ryzykowne. To inicjatywy, w których gdy popełnimy błąd, konsekwencje będą długoterminowe i słabo odwracalne. To na tych inicjatywach skupiamy nasze główne moce związane z Discovery.

2. Good enough – inicjatywy, dla których realizujemy discovery tylko pod najbardziej ryzykowne obszary / hipotezy. To inicjatywy, które nie mają krytycznego IMPACTu, a błędy w nich są łatwo odwracalne. Robimy tu po prostu „wystarczająco dobrą” robotę – nic więcej, nie musi być idealnie.

3. Neutral – inicjatywy i prace, które są dla nas neutralne i w których świadomie odpuszczamy sobie robienie procesu discovery, poza prostą walidacją rozwiązania. Nie mają dużego IMPACTu, a błędy w nich są łatwo odwracalne. Skupiamy się tutaj na mocno przyrostowej pracy z wykorzystaniem koncepcji MVP – wdrażamy minimalną zmianę i na podstawie obserwacji realnych userów podejmujemy dalsze działania.

Decyzję o przydziale do odpowiedniej kategorii podejmuję na podstawie:

• potencjalnego IMPACTu inicjatywy,

• poziomu niepewności (używam modelu 4 ryzyk produktowych Marty Cagana),

• oraz tego jak łatwo odwracalne są podejmowane decyzje (czy w przypadku błędnej, możemy się szybko z niej wycofać).

Oczywiście w idealnym świecie dla wszystkich inicjatyw jesteś w stanie robić pełne discovery. Realnie, często tak nie jest (np. kompletny brak designerów/researcherów). Stosuję wtedy regułę 80/20 – czyli 80% discovery przeznaczyliśmy na 20% najważniejszych inicjatyw z roadmapy. I tylko one są tymi „Priority”. Pozostałe 80% inicjatyw z roadmapy ląduje w grupie „Good enogh” i „Neutral”.

1.2. Jakie discovery jest “good enough”?

W dobrze “ile” i “jakie discovery” jest wystarczającego do konkretnej inciajtywy może Ci pomóc matryca Problem Clarity vs Risk:

W zależność od:

• Zrozumienia Problemu (Problem Clarity) - poczucia jak dobrze rozumiecie rozwiązywane problem

• Ryzyka (Risk) - możemy to rozumieć jako koszt błędnej decyzji

możesz objąć odpowiednią strategie względem Twojego procesu Discovery.

1.3. Większy nacisk na eksperymenty i MVP (ship it and measure)

Zmniejszenie budżetu na discovery nie zawsze wiążę sie ze zmniejszenieniem budżetu zespołu developerskiego. Mamy mniej czasu na odkrywanie co robić, a capacity pod “robienie” (delivery) pozostaje bez zmian. A zespół “dobrze jak coś robi”.

Dostarczenie rozwiązania jest zwykle najdroższą metodą testowania naszego pomysłu i robienia discovery, ale… wciąż jednak to jest sposób na redukowanie niepewności (i tym samym forma discovery). Itamar Gilad świetnie to pokazuje na swojej skali niepewności produktowej:

Dlatego, z mojego doświadczenia, będziemy musieli (przynajmniej czasowo) zaakceptować, że w wielu inicjatywach będziemy przechodzić do delivery bez solidnych dowodów i rozpoznania, ale… potraktujmy to delivery jako element discovery i testowania pomysłu:

• uczmy i przestawiajmy zespół, żeby myślał o budowanych rozwiązaniach jak o eksperymentach - MVP, które w praktyce, empirycznie będzie nam pokazywało w którą stronę iść. Budujemy je iteracyjnie, włąśnie po to, żeby w praktyce sprawdzić czy miały sens. Często zespół sam wtedy będzie szukał na to różnych dowodów, bo mało kto lubi pracować “bez sensu”

• wskażmy sobie jasno jakie sygnały będą świadczyły, ze wdrażane rozwiązanie przynosi pozytywną wartość dla użytkownika. Sygnały, które może nie bedą idealne, ale które jesteśmy w stanie zmierzyć i będa nam zwiększały prawdopobieństwo że idziemy w dobrą stronę

• zadbajmy o podstawowe narzędzie, które pozwolą oceniać wdrażane rozwiązanie, a do których możemy włączyć także na stałe nasz zespół developerski

  • podstawowa analityka i łątwo dostępne dashboardy analityczne - tak by kazdy mógł z nich skorzystać

  • HotJar lub inne narzędzie na nagrywek użytkowników, z którego także człownkowie zespołu będą mogli korzystać

  • pobliczne product / sprint review, na którym zbieramy feedback

2. Produktowa intuicja

Mało czasu i możliwości na discovery (patrz punkt wyżej), warunki skrajnej niepewności, ale decyzje produktowe i tak trzeba będzie podjąć. A osobą, która będzie musiała to zrobić… będziesz Ty, product manager.

W takiej sytuacji kluczowa staje się produktowa intuicja. To ona podpowiada nam, w którą stronę pójść, gdy nie mamy jasnych odpowiedzi na pytania. Im jesteśmy bardziej doświadczeni, tym częściej „podświadomie czujemy” co będzie lepszą drogą.

Przez 12 lat swojej kariery wypracowałem kilka mechanizmów, które pomagają mi w pracy, gdy intuicja gra dużą rolę:

2.1. Odwracalność decyzji

W warunkach dużej niepewności zadaje sobie (oraz zespołowi) wprost pytanie: „Czy ta decyzja jest odwracalna? Co się stanie jeśli zrobimy to źle?”. Okazuje się, że większość naszych decyzji jest w bardzo prosty sposób odwracalnych. 

Uświadomienie sobie tego prostego faktu powoduje, że nie popadam w paraliż decyzyjny. Jeśli zrobimy coś źle, po prostu to zmienimy / naprawimy. Jeśli jednak decyzja jest trudno odwracalna i może mieć duży IMPACT – w takim wypadku mówimy sobie wprost, intuicja to za mało. Potrzebujemy lepszego zrozumienia i obniżenia ryzyk produktowych.

2.2. Otaczanie się ludźmi o dobrej intuicji

Wiele osób z firmy, nawet bez dedykowanego procesu Discovery, ma dobrą produktową intuicję i zrozumienie potrzeb użytkowników. To ludzie, którzy pracują z użytkownikami/klientami na co dzień – dzięki temu świetnie znają ich problemy, bolączki, narzekania.

Znajduję kilka takich osób, nawiązuje z nimi bliską relację i angażuję przy podejmowaniu produktowych decyzji (przez warsztaty, formalną grupę doradczą, spotkania 1-1). Poza UX, zaczynam zawsze od Customer Service i Sales – oni robią „discovery” cały czas.

Możesz wykorzystać prosty kanał na Slacku, do którego zaprosisz osoby o dobrej produktowej intuicji i znajomości potrzeb użytkownika. Stanie się on wtedy Twoim „Advisory Board” - przy podejmowaniu decyzji zawsze możesz poprosić o feedback, dzięki któremu uwzględnisz więcej punktów widzenia.

Ten sam kanał (lub osobny) możesz też wykorzystać do zbierania bieżącego feedbacku od użytkowników, który będzie przesyłany przez osoby z Twojej firmy, które mają najczęstszy kontakt z użytkownikiem (np. customer service, sales).

2.3. Dokumentacja produktowa

Gdy robię już jakieś elementy discovery, dbam o to by powstała z tego choćby najprostsza, nieformalna dokumentacja (nawet proste zapiski), którą łatwo można przeszukać. Przy każdej produktowej decyzji mogę wtedy zacząć od przeszukania dotychczasowej bazy feedbacku, insightów i wyników badań.

3. Multidyscyplinarność zespołu

Kryzys to zwykle mniej dedykowanych specjalistycznych kompetencji w zespole. Budowanie multidyscyplinarnego zespołu brzmi jak banał, ale w czasie kryzysu nabiera jeszcze większego znaczenia. Ja bym to jeszcze rozwiną o dbania o multidyscyplinarność poszczególnych członków zespołu. Brak dedykowanych ludzi, to… świetna okazja dla wszystkich, by uczyć się nowych kompetencji.

• Zaczynam od siebie – dla mnie product manager musi być trochę człowiekiem-orkiestrą. Gdy trzeba, potrafi od strony produktowej zająć się niemalże wszystkim na poziomie „good enough”. Straciliśmy analityka od Mixpanela? Jako PM musisz przynajmniej w podstawowym stopniu umieć wypełnić tę lukę. Oczywiście nikt nie jest omnibusem i nie jest w stanie podołać wszystkiemu. Jeśli jednak pokażesz, że potrafisz wyjść poza swój zakres specjalizacji dla dobra zespołu, masz większą szansę że inni dołączą także do Ciebie.

• Jeśli mam wpływ na skład zespołu – staram się by było w nim jak najwięcej osób, które lubią się rozwijać, nie boją się wyjść poza zakres swojej specjalizacji. Kto jednak powiedział, że np. do prostego discovery potrzebujesz researchera? Że developerzy, chcą „tylko” kodować? Oczywiście wszystko dzieje się kosztem czegoś – minusem będzie mniejsza specjalizacja.

4. Automatyzacja Product-Ops

Uproszczanie i automatyzacja działań product-operations jest kluczowa. Dostęp do danych, zbierania i analiza feedbacku, prowadzenie komunikacji. Im prostsze, bardziej powtarzalne i automatyczne mamy operacyjne procesy, tym więcej mamy czas na realną produktową pracę.

Kilka taktyk, które mi pomagają:

1. Rola Dev Lead i Feature Lead-a – moim celem jest jak największa samodzielność i samoorganizacja zespołu deweloperskiego w obszarze delivery. Bardzo pomocna okazuję się tutaj rolę Dev Lead-a i Feature Leda. Dev Lead odpowiada za optymalizację działań zespołu deweloperskiego w procesie delivery, a Feature Lead odpowiada technicznie za za realizację danej inicjatywy z roadmapy (oczywiście nie realizuje jej sam). Te role mogą coraz bardziej przejmować też operacyjne definiowanie zadań i zarządzanie backlogiem.

2. Szablony komunikacji – Do powtarzalnej komunikacji staram się jak najszybciej wypracować odpowiednie szablony, tak by można było taką komunikację zautomatyzować lub delegować (np. do członków zespołu). Release notes, podsumowania, cykliczne update’y – to wszystko świetnie się do tego nadaje.

3. Publiczne dashboardy, plany i bazy wiedzy, feedback – im więcej danych i insightów udostępnimy w prostej, transparentnej i łatwo wyszukiwanej formie, tym bardziej samodzielnie ludzie w całej firmie będą w stanie pracować. Roadmapy, plany inicjatyw, dashboardy z danymi z analityki produktowej, insighty – za każdy razem, gdy powstaje jakiś produktowy artefakt, zastanawiam się jak sprawić by mógł być on publiczny i dostępny dla jak największego grona osób.

5. Współpraca z inwestorami - to nie wrogowie

W kryzysie Twoja firma (szczególnie jeśli jest startupem lub scaleupem) zacznie szukać dodatkowych źródeł finansowania i to może się nawet stać celem samym w sobie. Pojawią się wtedy naciski na robienie rzeczy „pod inwestorów”.

Kiedyś miałem do tego mocno negatywny stosunek – „Jak to? Przecież robimy product dla użytkowników / klientów, a nie inwestorów!”. Z czasem zrozumiałem, że to droga do nikąd. Brak finansowania prowadzi wprost do zmniejszenia zespołu, budżetu i możliwości wzrostu – więc finalnie i tak będziemy gorzej służyć naszym użytkownikom.

Nie ma więc co się na taką sytuację obrażać, tylko realnie zastanowić – jak ja / mój zespół może kontrybuować w realizacji tego celu? Czasem oznacza to robienie też rzeczy mało ważnych długoterminowo lub wręcz będących w przyszłości problemem. Zaciągamy więc DŁUG INWESTYCYJNY.

Dług inwestycyjny

Ale czy nie tak samo wygląda sytuacja z długiem technicznym? Czasem zaciągamy świadomie dług techniczny, by szybciej coś przetestować na rynku. Tak samo może być z podejściem do inwestorów – czasem musimy zaciągnąć długi inwestycyjny, żeby szybciej pozyskać finansowanie. Ważne jest, by potem świadomie go spłacić.

Jeśli jesteśmy w takiej sytuacji – chcę żebyśmy sobie w zespole powiedzieli jasno:

• priorytetowym celem firmy jest pozyskania inwestora,

• poszukajmy więc produktowych outcome’ów które mogą w tym pozyskaniu inwestora pomóc,

• zamieszczamy te outcome’y normalnie jako cele na roadmapie.

Czasem to będą konkretne funkcje, czasem podkręcenie konkretnych wskaźników – ważne jednak by świadomie sobie powiedzieć, że to jest naszym strategicznym celem i pod to porządkujemy nasze prace. Będzie to wtedy dla wszystkich jasne, dlaczego pracujemy nad taką, a nie inna inicjatywą.

Drugą kwestią jest właśnie świadomie zarządzanie wspomniane DŁUGIEM INWESTYCYJNYM. Przed realizacji zmian, które długoterminowo nie są dobrym kierunkiem, zastanawiam się jak w przyszłości pozbyć się tego długu. Staje się to elementem planowania takiej inicjatywy.

Przykładowo, przy wprowadzeniu jednej z funkcji mających robić efekt WOW „pod inwestorów”, wdrożyliśmy ją jako funkcję eksperymentalną dostępną tylko dla wybranych userów. Dzięki temu nie zanurzyliśmy pracy realnych użytkowników.

6. Wykorzystaj kryzys – forsuj product-led growth i produktowe porządki

Paradoksalnie, kryzys może też okazać się świetną szansą na produktowe innowacje i zwiększenie znaczenie obszaru produktowego w firmie.

Ograniczone budżety marketingowe powodują, że firmy zaczynają szukać innych, bardziej organicznych motorów wzrostu. Koncepcja product-led growth, w której to product i holistyczne spojrzenie na niego jest w centrum motoru wzrostu, świetnie wpisuje się w ten kierunek. Oczywiście temat nie jest prosty do wprowadzenia, ale spowolnienie może być świetnym momentem, by zacząć forsować taki kierunek.

Jeśli ogólnie w firmie jest poczucie, że mamy spowolnienie i trzeba „oszczędzać” to jest to też zwykle najlepszy moment na forsowanie usunięcia mało istotnych ficzerów i produktowych procesów. Jeśli uzasadnisz odpowiednio decyzję kosztowo, to opór w takich sytuacjach bywa zdecydowanie mniejszy.

💭 Kluczowe pytanie – czy naprawdę Ci zależy?

Na koniec, w “czasach kryzysu” IMHO trzeba sobie odpowiedzieć na jedno zajebiście bardzo ważne pytanie: „Czy naprawdę zależy Ci na produkcie i Twoim zespole?”. Jeśli tak – to w kryzysie masz świetną okazję, by sprawdzić się w roli prawdziwego produktowego lidera.

Będzie trudno – okrojone budżety, dużo stresu, wiele nacisków i trudnych problemów do rozwiązania. Pozytywny finał bywa jednak ogromnie satysfakcjonujący, a droga do celu bardzo rozwijająca Ciebie i spajająca zespół produktowy. Mam nadzieję, że moje przedstawione doświadczenia pomogą Ci na tej drodze. Powodzenia!