Jak odnieść sukces jako menedżer produktu w fabryce funkcji (z Aakashem Guptą, autorem newslettera Product Growth Guy)
Przeczytaj transkrypcję:
Wypróbowujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Wybaczcie ewentualne literówki, ponieważ bot nie zawsze działa w 100% poprawnie.
Hannah Clark: Fabryka funkcji: rzeczownik. Definicja: firma programistyczna, która koncentruje się na ciągłym tworzeniu i wydawaniu nowych funkcji, zamiast budować produkt, którego użytkownicy rzeczywiście chcą. Użycie w zdaniu: „Myślałem, że zatrudniono mnie, abym poprowadził zespół produktowy w odważnym, nowym kierunku, ale zamiast tego po prostu pracuję w fabryce funkcji”.
Powiedz mi: czy obok tego hasła w słowniku znajdowałoby się twoje zdjęcie? Twoje i zdjęcia tysięcy innych menedżerów produktu, mój przyjacielu. Skoro więc tak właśnie wygląda sytuacja, co możesz z tym zrobić?
Moim dzisiejszym gościem jest Aakash Gupta, autor kultowego newslettera Product Growth. Zanim w pełni skupił się na newsletterze, Aakash przez ostatnie 12 lat zajmował wyższe i kierownicze stanowiska związane z produktem w firmach takich jak Epic Games, Affirm i Apollo. Oznacza to, że doświadczył niemal każdego poziomu wpływu, jaki może mieć menedżer produktu.
Jak można się domyślić, Aakash doskonale zna okoliczności prowadzące do powstawania fabryk funkcji, a jego sposób zarządzania pracą menedżera produktu w takich organizacjach jest niezwykle praktyczny i odświeżająco realistyczny. To odcinek, którego warto wysłuchać z dużą uwagą do samego końca, więc zaczynajmy.
Witamy ponownie w podcaście Klubu CPO.
Aakash, bardzo dziękuję, że znalazłeś dziś dla nas czas.
Aakash Gupta: Oczywiście. Miło tu być. I dziękuję za zaproszenie.
Hannah Clark: Cała przyjemność po naszej stronie. Czy możesz opowiedzieć nam trochę o swojej karierze i o tym, jak dotarłeś do miejsca, w którym jesteś dzisiaj?
Aakash Gupta: Kiedy zaczynałem pracę w zarządzaniu produktem, mniej więcej w 2008 roku, miałem wrażenie, że ta dziedzina nie była jeszcze tak rozwinięta. Wydaje mi się, że książka INSPIRED ukazała się właśnie w tamtym okresie i rzeczywiście bardzo pomogła uporządkować wiele kwestii. Wcześniej istniał chyba tekst Bena Horowitza o dobrym i złym menedżerze produktu, ale poza tym ta dziedzina nie była jeszcze w pełni profesjonalna. W praktyce istniała głównie w firmach z Doliny Krzemowej i startupach.
Poznałem ją, ponieważ założyciele startupu, w którym pracowałem, byli zagorzałymi zwolennikami wszystkiego, co robił Y Combinator. Wiele firm Y Combinator miało wówczas menedżerów produktu. Dlatego, mimo że po dołączeniu do startupu liczącego zaledwie sześć osób, zostałem zatrudniony jako menedżer produktu. Na szczęście miałem wykształcenie techniczne, więc tworzyłem wiele aplikacji, programowałem i miałem pewne doświadczenie z Photoshopem.
Kiedy zaczynałem, zajmowałem się praktycznie wszystkim. Samodzielnie zaprojektowałem naszą stronę internetową, projektowałem i przeprojektowywałem ogromne części aplikacji, mimo że moje umiejętności projektowe były bardzo skromne. W przypadku strony zarządzałem również naszym systemem CMS i całą technologią, która za nim stała. Jako menedżer produktu na wczesnym etapie pomagałem więc we wszystkim, jednocześnie próbując zrozumieć, czym właściwie jest zarządzanie produktem i ucząc się tej pracy. Był to jednak typowy styl pracy startupu.
Później założyłem własny startup o nazwie Rap to Beats. W zasadzie robiłem tam dokładnie to samo, tylko programowałem jeszcze więcej. Tworzyłem znacznie więcej wersji aplikacji. Tak naprawdę do zarządzania produktem trafiłem więc z perspektywy osoby, która przede wszystkim budowała. Następnie przeszedłem do właściwego zarządzania produktem w firmie thredUP, która jest dziś spółką publiczną.
Dołączyłem do niej na etapie serii C, a odszedłem podczas serii E. Wspólnie zbudowaliśmy tam wiele pierwszych zespołów zajmujących się wzrostem. W 2014 roku program poleceń Ubera był bardzo popularny. Pamiętam, że kiedy uruchomiliśmy własny program poleceń, stał się on ogromnym źródłem wzrostu. Można było robić tak proste rzeczy.
Nie był on nawet zoptymalizowany. Zacząłem więc dostarczać produkty i uświadomiłem sobie, że jako menedżer produktu możemy fundamentalnie zmieniać trajektorię rozwoju firm. Wtedy naprawdę zaangażowałem się w rzemiosło zarządzania produktem. Od tamtej pory pracowałem jako menedżer produktu między innymi w Google, Affirm i Epic Games, a ostatnio w Apollo.io, gdzie byłem wiceprezesem ds. produktu. Obecnie zajmuję się zawodowo newsletterem.
Hannah Clark: Świetnie. Wiem, że bardzo wiele osób czerpie z niego ogromną przyjemność.
Dziś skupimy się na fabrykach funkcji, a konkretnie na tym, jak menedżerowie produktu mogą przetrwać w organizacji będącej taką fabryką. To określenie niemal stało się dziś przekleństwem w naszej branży.
Zacznijmy więc od początku. W jaki sposób organizacje przeobrażają się w fabryki funkcji i dlaczego tak często do tego dochodzi?
Aakash Gupta: Właściwie uważam, że wszystkie drogi prowadzą do fabryki funkcji. Załóżmy, że pracujesz w środowisku, które jest klasycznie umocowane i daje zespołom dużą autonomię. W ciągu ostatnich czterech czy pięciu lat wydarzyło się kilka rzeczy.
Albo, jak w przypadku Airbnb, założyciel ponownie przejął kontrolę i powiedział: „Dobrze, oto kilka rzeczy, które chcę, żebyście zbudowali”. Albo liderzy produktu przejęli kontrolę poprzez liczne zwolnienia i reorganizacje. Często wykorzystują ciągłe reorganizacje jako sposób na umieszczanie ludzi na określonych stanowiskach oraz realizowanie pracy i budowanie funkcji, które sami chcą stworzyć.
Ostatecznie prezesi lub liderzy produktu, pod presją obecnej sytuacji rynkowej, mówią: „Nie możemy po prostu dawać zespołom pełnej autonomii. Nie możemy tak po prostu przekazać decyzji biznesowych dotyczących produktu wartego miliard dolarów osobom, które mają 26 lat i cztery lata doświadczenia”. W rezultacie nawet w środowiskach, które tradycyjnie zapewniały dużą autonomię, od Google po Netflix, menedżerowie produktu nie wyznaczają nagle 100% planu rozwoju produktu.
Często równolegle funkcjonują dwa niewidoczne procesy: oddolny i odgórny. W procesie oddolnym menedżer produktu przygotowuje swoje pomysły i zgłasza je do planowania, ale gdy spojrzymy na to, co ostatecznie zostaje uzgodnione, duża część obejmuje rzeczy, które musieli zaakceptować lub których musieli dać się przekonać menedżerowie. Często sami mieli te pomysły.
Dlatego uważam, że wiele osób tworzy jedynie dekorację wokół środowiska zapewniającego autonomię — w postaci celów i kluczowych rezultatów oraz kwartalnego planowania — ale ostatecznie i tak powstaje fabryka funkcji. Być może na początku dotyczy to tylko jednej czwartej firm, które rzeczywiście zapewniają autonomię, lecz z czasem przechodzą one w model fabryki funkcji.
W przypadku pozostałych 75% firm powiedziałbym, że około 30% znajduje się w fazie transformacji. Te firmy rozumieją, że muszą przejść na metodykę zwinną i że potrzebują menedżerów produktu z większą autonomią. Problem polega na tym, że gdy zespoły produktowe współpracują z projektantami, inżynierami, biznesem czy sprzedażą — na przykład w bankowości lub ochronie zdrowia, gdzie zachodzi wiele transformacji cyfrowych — te osoby nadal są przyzwyczajone do pracy w modelu fabryki funkcji, czyli w modelu kaskadowym.
Nawet jeśli dział produktu chce wprowadzić zmiany, zajmuje to lata. Rozmawiałem z Martym Caganem, który powiedział, że trwa to trzy lata. Myślę, że to trafna ocena. W rezultacie menedżerowie produktu odpowiadają za wskaźniki, a jednocześnie ktoś narzuca im funkcje, które mają zbudować.
To bardzo chaotyczny stan pośredni. Ostatnia grupa to firmy działające w sposób oczywiście kaskadowy i oczywiście będące fabrykami funkcji — a wiele miejsc całkowicie akceptuje taki model. Jeśli porozmawiasz z przeciętnym menedżerem produktu w Apple, zobaczysz, że kadra kierownicza podejmuje wiele decyzji dotyczących funkcji produktu. Jony Ive i Steve Jobs, kiedy tam pracował, podejmowali wiele kluczowych decyzji.
Ten model nadal może działać. Ludzie myślą: „To nie może odnieść sukcesu. Marty powiedział, że najlepsze firmy zapewniają pełną autonomię”, ale ja odkryłem, że wszystkie drogi prowadzą do fabryki funkcji.
Hannah Clark: Kiedy śledzi się ten tok rozumowania, wszystko wydaje się logiczne.
Porozmawiajmy o kilku krokach, które opisałeś na blogu poświęconym temu tematowi. Jeśli ktoś go nie czytał, warto podkreślić, że bardzo ciekawie rozłożyłeś ten temat na części i przyjąłeś nieco kontrowersyjne stanowisko dotyczące tego, jak reagować na pracę menedżera produktu w fabryce funkcji. Zanim przejdziemy do poszczególnych kroków, czy możesz opowiedzieć, jakie jest twoje stanowisko i jak ma się ono do poglądów Melissy Perry?
Aakash Gupta: Myślę, że istnieją idealiści i realiści. Po stronie idealistów mamy osoby takie jak Marty Cagan, Teresa Torres i John Cutler — wszystkich troje bardzo lubię, podziwiam i czytam wszystko, co publikują. Uważam jednak, że wierzą oni, iż jako menedżer produktu powinieneś próbować zmienić swoją organizację, jeśli pracujesz w fabryce funkcji.
To właśnie głoszą. Wiele narzędzi i spostrzeżeń, które tak hojnie udostępniają bezpłatnie, służy temu celowi. Bardzo ich szanuję, ale takie jest ich przekonanie. Ja, Melissa Perry i inne osoby, takie jak Clair Vaux czy Powell Hearn, jesteśmy nieco bliżej realistycznego końca spektrum. Oznacza to, że jako menedżer produktu — chyba że masz osiem lub dziesięć lat doświadczenia oraz stanowisko grupowego menedżera produktu albo wyższe — prawdopodobnie nie masz jeszcze doświadczenia ani wpływu potrzebnych do skutecznej transformacji całej organizacji.
Zamiast tego warto rozważyć inną strategię. Mówię tak, ponieważ widziałem bardzo wiele osób próbujących żyć zgodnie z idealistycznym podejściem. Często powtarzam anegdotę, którą niektórzy mogli już ode mnie słyszeć, ponieważ chyba stałem się w tej kwestii monotematyczny. Lubię sortować wpisy na podforum dotyczącym zarządzania produktem według najpopularniejszych w całej historii.
Wydaje mi się, że do dziś osiem na dziesięć takich wpisów pochodzi od menedżerów produktu, którzy piszą: „Nienawidzę swojej pracy, moja praca jest koszmarem”. Kiedy czytasz szczegóły, okazuje się, że są to menedżerowie produktu pracujący w fabrykach funkcji. Piszą na przykład: „Dołączyłem do zarządzania produktem po przeczytaniu INSPIRED i myślałem, że będę mógł wyznaczać kierunek rozwoju produktu, ale jestem tylko wykonawcą poleceń prezesa”.
To niezwykle częsty scenariusz. Ludzie pracują w 75% firm, które jawnie są fabrykami funkcji, i są niezadowoleni ze swojej pracy, ponieważ rzeczywiście nie wygląda ona tak, jak oczekiwali. Dlatego moja realistyczna rada dla czytelników newslettera brzmi: po prostu to zaakceptujcie. Poddajcie się fabryce. Lepiej wiedzieć, że się w niej pracuje. Możecie wtedy powiedzieć: „Dobrze, skoro jestem pracownikiem fabryki, co muszę zrobić, aby to zaakceptować i ruszyć dalej?”.
Hannah Clark: Myślę, że nastawienie ma ogromny wpływ na to, jak radzimy sobie w każdej trudnej sytuacji. Nie musi ona jednak być trudna.
Porozmawiajmy o krokach opisanych w twoim wpisie, zaczynając od poddania się fabryce, o którym już wspomniałeś. Kiedy naprawdę zrozumiałeś, że jest to niezbędny etap tego procesu?
Aakash Gupta: Myślę, że stało się to po nieudanych próbach transformacji. Pracowałem w różnych typach środowisk. Wielu menedżerów produktu nie miało na przykład doświadczenia w branży gier. Pracowałem w Epic Games przy Fortnite. Wiele osób myśli o fabryce funkcji w kategoriach prezesa, dyrektora ds. produktu albo dyrektora ds. projektowania, którzy coś narzucają. W firmie tworzącej gry często wygląda to jednak tak, że projektanci wymyślają niezwykle interesujące rzeczy, a osoby kreatywne mówią: „To będzie niesamowite”.
Następnie wypełniają kolejną sezonową premierę najbardziej niezwykłymi doświadczeniami. Jako menedżer produktu widziałem wiele łatwych do wykorzystania możliwości poprawy wydajności, procesu wdrażania i aktualizacji. Jeśli ktoś próbował aktualizować Fortnite, wie, że do dziś nastąpiło wiele ulepszeń, ale niedawno sam przeprowadzałem aktualizację.
Plik miał 42 GB. Mój komputer potrzebował dwóch godzin, a korzystam z Maca, co jest szczególnie problematyczne. Sama instalacja aktualizacji zajęła około 50 minut. Mówimy więc o ogromnym utrudnieniu występującym dwa razy w tygodniu, ponieważ firma wydaje takie aktualizacje dwa razy w tygodniu. W sklepie z elementami monetyzacji istniały również łatwe możliwości stworzenia większej liczby wariantów dla osób wydających w sklepie trzy lub cztery tysiące rocznie.
Aby przekonać osoby, którym zależało na tym, co jest atrakcyjne, mogłem powiedzieć: „Musimy skupić się na rezultatach, a nie na danych wyjściowych, fajnych funkcjach i wszystkim podobnym”. Próbowałem tego, ale nikt nie chciał słuchać. Później pracowałem w Affirm, gdzie infrastruktura planowania była bardzo scentralizowana. Pomyślałem: „Dobrze, jestem grupowym menedżerem produktu, więc mój zespół będzie zajmował się bardziej nieprecyzyjnymi problemami”. Kiedy przeszedłem przez pierwszy cykl planowania, okazało się, że to zupełnie nie działało.
Kadra kierownicza patrzyła na plan i pytała: „Czy wy w ogóle coś zrobiliście? Wszystkie pozostałe plany są znacznie bardziej szczegółowe, zawierają niesamowite makiety funkcji, a zespoły analityczne oszacowały z dokładnością do siedmiu cyfr znaczących wpływ na przychody i zysk”. Wypadało się więc fatalnie.
To wynik własnych błędów, ale także pracy z wieloma menedżerami produktu, których później szkoliłem. Część z nich zgłaszała się do mnie, ponieważ miała pewne trudności w karierze albo otrzymała niższą ocenę wyników, niż oczekiwała. Kiedy analizowałem sytuację dokładniej, często przeprowadzaliśmy ocenę 360 stopni i odkrywałem, że projektanci oraz inżynierowie współpracujący z tymi osobami mówili: „Ich dokumenty wymagań produktu nie były wystarczająco szczegółowe”.
Ci menedżerowie produktu myśleli, że pracują w świecie zapewniającym autonomię, podczas gdy w rzeczywistości znajdowali się w fabryce funkcji, która wymagała bardzo szczegółowych dokumentów wymagań produktu. Pomijali więc podstawowe zasady i osiągali gorsze wyniki. Wszystko sprowadza się do poprawy własnych rezultatów. W moim doświadczeniu z różnych środowisk nie widziałem, aby można było natychmiast wprowadzić taką zmianę. Udało mi się to dopiero po osiągnięciu poziomu dyrektora i wiceprezesa.
Kiedy pracowałem w thredUP i Affirm, moim zadaniem było podnoszenie poziomu praktyk w organizacji. Wtedy trzeba było celowo i stopniowo zmieniać poszczególne elementy. Dobrze, że zdefiniowaliśmy, czym jest fabryka funkcji, ponieważ można powiedzieć: „Będę powoli usuwać każdy jej element, bo to antywzorzec”. Jako radę zawodową powiedziałbym jednak, że jeśli nie jesteś na odpowiednim poziomie, nie powinieneś próbować naprawiać tego antywzorca.
Hannah Clark: To prowadzi nas do kolejnego kroku, czyli dostosowania się do środowiska. Napisałeś, że najważniejsze jest skupienie się na tym, czym naprawdę jest twoja praca — po prostu wykonuj swoją prawdziwą pracę. Czy możesz rozwinąć ten krok i opowiedzieć o towarzyszących mu podetapach?
Aakash Gupta: Zadziwia mnie, że kiedy analizuję rodzaje materiałów, które tworzyłem w poszczególnych miejscach pracy, zwłaszcza te, które spotykały się z dobrym odbiorem, były one całkowicie różne. W Epic Games były to przede wszystkim prezentacje atrakcyjnych funkcji.
Często siedziałem do drugiej w nocy z projektantem technicznym i tworzyliśmy grywalne demo ciekawej funkcji z niedopracowaną grafiką. To właśnie dobrze działało. W Affirm środowisko wyglądało zupełnie inaczej. Sukces odnosiłem wtedy, gdy przedstawiałem świetnie przygotowany plan wpływu, zawierający arkusze danych i modele szacowania wpływu. Były to zupełne przeciwieństwa.
Trzeba więc ocenić, jak wygląda sukces w zarządzaniu produktem w twoim środowisku. Polecam przeprowadzić rozmowy z osobami, które najdłużej pracują w firmie jako menedżerowie produktu, oraz z osobami, które niedawno awansowały. To dwa bardzo dobre źródła informacji.
Nie należy jednak poprzestawać na powierzchownych relacjach. Spróbuj umówić się z taką osobą na lunch, najlepiej osobiście. Na pierwszym spotkaniu nie musisz od razu zadawać zbyt dociekliwych pytań. Najpierw spróbuj zaoferować jej jakąś wartość. Gdy zbudujesz silną relację i osoba ta zacznie cię wspierać, możesz przejść do bardziej szczegółowych rozmów.
Lubię zadawać pytania takie jak: „Czy tworzysz dokument wymagań produktu dla każdej funkcji?”, „Czy możesz udostępnić swój najlepszy dokument?”, „Czy możesz pokazać mi swój ostatni pakiet awansowy?” albo „Czy możesz udostępnić notatki z ostatniego spotkania jeden na jeden z przełożonym?”. To bardzo praktyczne pytania, ale nie można ich zadawać osobie, która nie jest twoim przyjacielem.
Najpierw więc zbuduj przyjaźń, a być może także relację mentorską. Nie polecam jednak pytać wprost, czy ktoś zostanie twoim mentorem. Wiele osób chce widzieć, że ich menedżerowie produktu i liderzy produktu mają własny punkt ciężkości. Pomyślą wtedy: „To osoba dociekliwa, która naprawdę chce odnieść sukces”.
Traktuj te rozmowy jak własny proces produktowy. Kiedy dołączasz do firmy, rozmawiasz z klientami, osobami niebędącymi klientami, konkurencją i innymi pracownikami. Następnie zdecydowanie zalecam odbycie bezpośrednich rozmów jeden na jeden z liderem technicznym, kierownikiem zespołu inżynierskiego, projektantem, badaczem użytkowników, analitykiem, a prawdopodobnie także z przełożonym i przełożonym wyższego szczebla. Wspólnie jasno określcie role i odpowiedzialności.
Bądź bardzo precyzyjny. Zapytaj projektanta: „Co sądzisz o tym, żeby menedżer produktu tworzył szkice i makiety?”. Większość projektantów odpowie, że nie jest tym szczególnie zainteresowana. Niektórzy powiedzą, że to w porządku, o ile szkice nie powstają w Figmie. Musisz znać takie niuanse i rozumieć, jak współpracować z konkretnymi interesariuszami.
Błędem, który widziałem u osób przeprowadzających takie rozmowy, jest założenie, że ich praca menedżera produktu wygląda tak samo jak praca innego menedżera produktu z innego zespołu. W rzeczywistości projektant, inżynier i analityk, z którymi pracujesz, mają własny zestaw oczekiwań. Wszyscy chcą wspinać się na górę przywództwa produktowego i dotrzeć do stanowiska wiceprezesa, ale na razie skup się na jednym kroku przed sobą — na najbliższych współpracownikach. Stwórzcie wspólną umowę, a następnie sprawdzaj, co spotyka się z dobrym odbiorem, a co nie.
Czasami kierownik zespołu inżynierskiego może nie wiedzieć, że inżynierowie w jego zespole bardzo lubią być zapraszani na rozmowy dotyczące odkrywania potrzeb klientów. Tego dowiesz się dopiero w praktyce. Pozostań więc uważny na swoją małą grupę. To podstawowa rada dotycząca kariery, ale umieszczam ją tutaj, ponieważ chodzi o zrozumienie, na czym naprawdę polega twoja praca menedżera produktu. Nie sądzę, aby jakiekolwiek dwa stanowiska menedżera produktu wyglądały tak samo.
Hannah Clark: Mam wrażenie, że w każdym środowisku pracy osoby, z którymi współpracujesz najbliżej, tworzą swego rodzaju mikrokulturę. Ważne jest więc zrozumienie jej niuansów, języka, którym posługują się wszyscy członkowie zespołu, oraz upewnienie się, że wzajemne oczekiwania są spójne. Bardzo to doceniam.
Wspomniałeś także o spotkaniach jeden na jeden z osobami, które przez dłuższy czas odnosiły sukcesy na danym stanowisku.
Kolejnym krokiem na twojej ścieżce jest stworzenie drogi awansu, a te osoby odgrywają w tym procesie istotną rolę. Czy możesz opowiedzieć nieco o strategii tworzenia takiego planu rozwoju kariery?
Aakash Gupta: W fabryce funkcji zwykle istnieje spójny zestaw kryteriów, które trzeba spełnić. Kryteria te często nie są zapisane ani wypowiedziane, a ponadto mogą być błędnie interpretowane przez twojego przełożonego. Wiele osób polega wyłącznie na swoim przełożonym. Miałem w zespołach osoby, które bardzo naciskały podczas spotkań jeden na jeden w sprawie awansu, ale musiałem im tłumaczyć, że nie jestem jedyną osobą podejmującą decyzję o ich awansie.
Weźmy jako przykład Affirm. Przygotowuję dla ciebie pakiet awansowy i przedstawiam go komisji awansowej. W jej skład wchodzą wszyscy liderzy produktu na moim poziomie lub wyższym. Każda z tych osób przynajmniej raz zabiera głos w dyskusji. Po przekonaniu mnie musisz więc przekonać każdego lidera produktu na moim poziomie lub wyższym, aby miał o tobie coś pozytywnego do powiedzenia.
Musisz z nimi współpracować — i właśnie to działało w Affirm. Chodzi o zrozumienie tego, co niewypowiedziane. Pracowałem z menedżerką produktu w Affirm, która od około trzech lat była prawdopodobnie starszą menedżerką produktu i wykonała wiele dobrej pracy, ale miała trudności z awansem.
Zacząłem spotykać się z nią jeden na jeden, mimo że nie pracowała w moim zespole, i awansowała w następnym cyklu. Powiedziałem jej, że uczestniczyłem w jej ostatniej komisji awansowej i tylko jej przełożony zabierał głos na jej korzyść. Jej przełożony nie udzielił jej takiej informacji.
Nie zawsze można więc polegać na własnym przełożonym. Trzeba budować relacje z innymi menedżerami, którzy skutecznie awansują swoich ludzi. Znajdź takie osoby i nawiąż z nimi relacje. Ponownie radzę najpierw zostać przyjacielem, a także wspólnie coś z nimi zrobić, aby mogli zobaczyć, że dobrze pracujesz.
Następnie możesz zapytać: „Jakie masz doświadczenia z komisjami awansowymi?”. Najlepsze informacje uzyskiwałem osobiście, często przy piwie po pracy. Wtedy naprawdę można dowiedzieć się, co się dzieje. Niektórzy podchodzą do tego jak do zwykłego tygodnia pracy od dziewiątej do siedemnastej. Ja powiedziałbym: od czwartku i piątku odejmij czas od 16:00 do 17:00 i przeznacz go na rozmowy od 20:00 do 21:00, ponieważ będzie to znacznie skuteczniejsze.
Poświęć ten czas na zrozumienie, jak ludzie otrzymują awanse. Wiele osób pytało mnie: „Jak tak szybko zostałeś wiceprezesem?”. Podstawowa odpowiedź brzmi: rozumiałem ścieżki awansu w różnych firmach. W niemal każdej firmie, do której dołączałem, awansowałem w ciągu roku lub dwóch. Otrzymywałem większy zakres odpowiedzialności i dołączali do mnie kolejni członkowie zespołu. Byłem po prostu całkowicie skupiony na tej ścieżce.
Kiedy pytałem znajomych: „Czy rozmawiałeś z kimś na ten temat?” albo „Co o tym wiedziałeś?”, często nie mieli nawet świadomości, że w Affirm istnieje komisja awansowa. To prawdziwa luka w wiedzy. Uzupełnienie tej luki jest pierwszym krokiem. Drugim jest zastanowienie się nad własnymi wyjątkowymi mocnymi stronami.
Jako menedżer produktu prawdopodobnie każdy gdzieś popełnia błędy. Twoja informacja zwrotna dotycząca projektu może być oceniana na osiem punktów na dziesięć, a umiejętność zarządzania trudnymi interesariuszami na siedem. Niezależnie od tego, czym dysponujesz, oprzyj się na swoich mocnych stronach. W moim przypadku była to umiejętność pisania.
Wykorzystaj ją. Możesz na przykład stworzyć cotygodniową aktualizację albo przedstawić świetną strategię produktową większej liczbie zespołów produktowych niż zwykle. W ten sposób wykorzystujesz swoje mocne strony w ramach wyjątkowych kryteriów awansu. Ja często udostępniałem swoje teksty i mówiłem: „Hej, ten fragment mojej strategii dotyczący fundamentów produktu wpływa na zespół produktowy zajmujący się fundamentami. Zanim sfinalizujemy nasz plan rozwoju, chciałem podzielić się tym zrzutem ekranu”. To wystarczało, aby wzbudzić zainteresowanie i skłonić innych do przeczytania całego dokumentu oraz stwierdzenia: „To naprawdę dobra praca produktowa”. Chodzi więc o wykorzystanie swoich mocnych stron w odniesieniu do tych kryteriów.
Hannah Clark: To niezwykle mądre i bardzo praktyczne. Naprawdę doceniam takie konkretne podejście.
Kolejny krok to podnoszenie poziomu wybranych praktyk. Co masz na myśli, mówiąc o wybranych praktykach, i jakie są konkretne przykłady umiejętności, które można w ten sposób rozwijać?
Aakash Gupta: Wspomniałem, że szczególnie na poziomie grupowego menedżera produktu i wyżej należy robić to na poziomie całej organizacji.
Powinieneś pilotażowo wdrażać opisane przeze mnie rozwiązania w wybranych zespołach i sprawdzać, czy działają. Jeśli jesteś poniżej poziomu grupowego menedżera produktu, powinieneś testować je w swoim zespole. Kiedy podczas spotkań jeden na jeden ustalisz z partnerami z obszaru projektowania, inżynierii i analityki warunki współpracy, a następnie udowodnisz, że potrafisz odnieść sukces w ramach ich oczekiwań, możesz powiedzieć: „Dobrze, spróbujmy przenieść to na wyższy poziom”.
Warto również poprosić ich o informację zwrotną i na jej podstawie zmienić niektóre elementy. Moim zdaniem najbardziej skuteczna kolejność technik jest następująca.
Po pierwsze, podsumowania rezultatów funkcji. Są one bardzo mało zagrażające w środowisku fabryki funkcji. Funkcja została wdrożona, być może na polecenie prezesa, ale chce on wiedzieć, co się wydarzyło i dlaczego. W fabrykach funkcji liderzy rzeczywiście chcą rozumieć, dlaczego coś się wydarzyło.
Menedżerowie produktu często raportują: „A osiągnęło lepszy wynik niż B, więc wybieram A”. To nie jest jednak szczególnie imponujące. O wiele lepiej powiedzieć: „A osiągnęło lepszy wynik niż B, ponieważ…”. W ten sposób zaczynasz wpływać na to, co wydarzy się później.
Weźmy konkretny przykład. Jeśli pracujesz w Airbnb i właśnie wdrożyłeś całkowitą cenę, ponieważ Brian Chesky kazał ci to zrobić, powinieneś wrócić do niego z informacją, co się stało i dlaczego. Wiemy, że współczynnik konwersji przy zakupie prawdopodobnie spadnie, ale pytanie brzmi: o ile? Wiemy, że wskaźnik NPS wzrośnie, ponieważ użytkownicy nie będą zaskakiwani ceną.
Możemy przypuszczać, że gdy użytkownicy dodadzą ofertę do koszyka i zakończą rezerwację, współczynnik konwersji wzrośnie. Nie wiemy jednak, jaki będzie łączny wpływ na konwersję. Brian będzie chciał to wiedzieć.
Dane wracają i okazują się interesujące. Współczynnik konwersji na stronie mapy spadł tylko o 2%, ale na stronie zakupu wzrósł o 6%. Łącznie konwersja wzrosła o 4%. Wygląda więc na to, że jego pomysł był rzeczywiście świetny.
Dlaczego tak się stało? Warto przeanalizować to dokładniej. Przeprowadź rozmowy z kilkoma osobami, obserwuj je i porozmawiaj z badaczem użytkowników. Możesz odkryć, że wcześniej użytkownicy i tak nie ufali cenom wyświetlanym na mapie — na przykład 357 — i że udało się rozwiązać problem zaufania.
Możesz wtedy powiedzieć Brianowi: „Całkowita cena poprawiła współczynnik konwersji, a nawet wyniki na mapach, ponieważ użytkownicy mieli bardzo małe zaufanie do informacji o cenie za noc”. Brian może następnie zapytać, gdzie jeszcze użytkownicy mają do nas małe zaufanie — w recenzjach, lokalizacjach Airbnb Plus czy gdzie indziej. Na tej podstawie można stworzyć plan rozwoju produktu.
Podaję ten długi przykład, aby wyjaśnić, że podsumowania rezultatów funkcji są mało zagrażające i pomagają rozpocząć właściwy proces.
Drugą interesującą rzeczą jest szacowanie wpływu. Menedżerowie produktu często odpowiadają za rezultaty, ale otrzymują do realizacji konkretne dane wyjściowe. W takiej sytuacji warto przygotować najlepszy możliwy argument, poparty jak największą ilością danych, pokazujący, jak funkcja może zadziałać.
Prezes thredUP uważał, że zwiększenie programu poleceń z 10/10 do 30/30 może nagle przynieść 5% wzrost przychodów w następnym miesiącu. Przyjąłem najbardziej korzystne założenia, największą możliwą liczbę udostępnień i najwyższy odsetek akceptacji poleceń z naszych najlepszych kampanii. Po połączeniu wszystkiego okazało się, że maksymalny możliwy wzrost przychodów w kolejnym miesiącu wynosi zaledwie 0,1%. Stało się więc oczywiste, że ta funkcja nie osiągnie celu, który chciał zrealizować prezes. Budowanie modelu finansowego szacującego wpływ jest drugim krokiem.
Po trzecie, ludzie często stawiają sprawę na głowie i chcą zaczynać od odkrywania. Uważam, że odkrywanie powinno być trzecim krokiem. Najpierw tworzysz podsumowania rezultatów funkcji i szacujesz wpływ funkcji, zanim zostaną zbudowane. Kiedy otrzymujesz gotowe dane wyjściowe, możesz powiedzieć: „Dziękuję za makietę. Teraz przeprowadzimy właściwe odkrywanie i zabierzemy pana prezesa lub panią wiceprezes w tę podróż”. Możesz pokazywać nagrania, korzystać z narzędzi takich jak Dovetail i w ciągu 30 sekund przedstawiać najważniejsze wnioski dotyczące problemów.
W ten sposób przechodzisz od odkrywania rozwiązania do odkrywania problemu. Problem, który próbowano rozwiązać za pomocą danego projektu, może w rzeczywistości wymagać rozwiązania w zupełnie innej części produktu.
Czwartym krokiem jest przejście do celów i kluczowych rezultatów. Na tym etapie wchodzimy na terytorium grupowego menedżera produktu. Czy jako główny menedżer produktu powinieneś wdrażać cele i kluczowe rezultaty, jeśli robi to reszta firmy? Prawdopodobnie nie. Jeśli jesteś grupowym menedżerem produktu, cele i kluczowe rezultaty mogą być bardzo skuteczne, gdy zespoły zaczną już zajmować się odkrywaniem.
Wiele osób wdraża cele i kluczowe rezultaty jako drugi krok, zaraz po odkrywaniu, ale nie rozwija wcześniej umiejętności podsumowywania rezultatów funkcji i szacowania wpływu. W takich firmach cele i kluczowe rezultaty często są fikcją, a większość nie zostaje osiągnięta. Dotyczy to prawdopodobnie 90% firm.
Dlatego tak ważna jest określona kolejność. Następnie, pomiędzy celami i kluczowymi rezultatami, pojawiają się drzewa celów, problemów i rozwiązań, które pomagają połączyć cele z problemami i rozwiązaniami. Na końcu dochodzą strategie produktowe. To ciekawe, ponieważ wszyscy uważają, że zarządzanie produktem oznacza strategię produktu, ale moim zdaniem nie można jej naprawdę tworzyć, dopóki nie ma się kontroli nad całym drzewem celów, problemów i rozwiązań. Do tego czasu strategię produktu tworzy za ciebie prezes.
Hannah Clark: Kolejnym krokiem jest oczywiście zbudowanie koalicji. Rozmawialiśmy już o tworzeniu bliskich relacji z osobami odpowiedzialnymi za projektowanie i inżynierię. Czy możesz opowiedzieć o sytuacji, w której wyglądało to tak w praktyce?
Aakash Gupta: Wróćmy do Epic Games. Wspominałem o tym środowisku. Relacje leżały u podstaw każdego sukcesu opartego na wpływie, który tam odniosłem. Jedną z rzeczy, nad którymi bardzo chciałem pracować, była wydajność Fortnite.
Fortnite to gra wymagająca wysokich umiejętności. Ludzie grają w nią około 2000 godzin rocznie, jakby była pełnoetatową pracą. Im więcej czasu poświęcają, tym więcej z niej czerpią. Problem pojawia się, gdy opóźnienie jest bardzo wysokie albo liczba klatek na sekundę jest niska, ponieważ wtedy ogranicza się maksymalny poziom umiejętności.
W danych zauważyłem, że osoby grające na słabym sprzęcie lub przy słabym połączeniu internetowym odchodzą po około 1000–2000 godzinach, podczas gdy osoby z dobrą wydajnością pozostają w grze przez 12 000 czy 14 000 godzin. Nie mogłem jednak po prostu przedstawić tego spostrzeżenia i powiedzieć: „Dlatego powinniśmy nadać wydajności priorytet”. Musiałem zdobyć wpływ wśród kluczowych projektantów i inżynierów.
Istniał tam człowiek o imieniu Jason. Stworzył Call of Duty, a później kierował Fortnite. Ostatecznie podejmował wszystkie decyzje dotyczące tego, co działo się w grze. Bardzo szanował opinie najbardziej pracowitych inżynierów i projektantów — tych, którzy pracowali po 120 godzin tygodniowo i nieustannie dostarczali nowe rozwiązania.
Postanowiłem więc zbudować koalicję właśnie z tymi osobami. Ponieważ pracowały tak ciężko, nie miały czasu sprawdzać, jak działały rozwiązania, które wdrażały. To była moja szansa. Zacząłem pokazywać im rezultaty ich pracy: „Wdrożyliście poprawkę 6.4 w rozdziale drugim i sezonie czwartym Fortnite. Oto jej wpływ na grę. Użycie karabinów snajperskich wzrosło o 8%, liczba zabójstw spadła o 6%, a gracze o niskim poziomie pokonują graczy o wysokim poziomie częściej niż kiedykolwiek”.
Byli podekscytowani efektami swojej ciężkiej pracy i zaczęli liczyć się z tym, co mówię. Dodałem informacje o wydajności: gracze z opóźnieniem powyżej 200 milisekund odchodzili częściej niż kiedykolwiek. Dodanie karabinów, pojazdów i innych elementów sprawiało, że osoby z pingiem powyżej 100 milisekund traciły poziom w niespotykanym tempie.
Takie spostrzeżenia pomogły im stopniowo uwzględniać wydajność w pracy nad grą. Zaczęli dostrzegać, jak duży wpływ ma ona na rozgrywkę, i znacząco ją poprawiliśmy. To przykład strategicznego myślenia o tym, kto powinien należeć do mojej koalicji. Najpierw budowałem relacje i wpływ, a dopiero potem dążyłem do zmiany.
Hannah Clark: To mądre na wielu poziomach. Budujesz dobre relacje, ludzie ci ufają, a wpływ staje się niemal naturalnym skutkiem. Genialne.
Zanim zakończymy, chciałabym porozmawiać o typowych błędach, które zauważyłeś u menedżerów produktu pracujących w fabrykach funkcji. Jednym z nich jest oczywiście brak rozpoznania, że pracuje się w fabryce funkcji. Jakie są inne błędy, o których warto wspomnieć?
Aakash Gupta: Jest ich około sześciu. Pierwszy polega na ściganiu wyłącznie wskaźników danych wyjściowych. Ktoś usłyszał moją radę, aby poddać się fabryce, więc optymalizuje tylko to, na czym fabryce zależy: szybkość realizacji zadań, liczbę dużych funkcji dostarczonych na czas i liczbę przesunięć terminów.
To nadal błąd. Trzeba patrzeć na rezultaty wszystkich funkcji. Nie chcę, aby poddanie się fabryce oznaczało rezygnację z dobrej pracy produktowej. Fabryka może kazać ci zbudować okropną i pozbawioną wpływu funkcję, ale przed jej stworzeniem nadal powinieneś wykorzystać swoje wyczucie produktu.
Po pierwsze, dzięki temu podejmiesz właściwe decyzje dotyczące alokacji zasobów tam, gdzie będzie to możliwe. Po drugie, będziesz rozwijać mięśnie potrzebne do dobrej pracy produktowej. Widziałem osoby, które dołączały do fabryki funkcji i przestawały rozwijać swoje umiejętności.
Drugi błąd polega na zaniedbywaniu długu technicznego. Kiedy pojawiają się kolejne duże funkcje, zespoły zaczynają ignorować fakt, że środowisko pracy deweloperów działa coraz gorzej. Czas kompilacji wynosi trzy godziny, a prosta zmiana zajmuje cały dzień, ale zespół mówi: „Nadchodzi ważny sezon i musimy go dostarczyć”.
Warto rozróżniać przypadkowy i celowy dług techniczny. Przypadkowy dług techniczny wynika z doświadczenia użytkownika i należy go minimalizować. Celowy dług techniczny powstaje wtedy, gdy świadomie wybierasz dużą funkcję i akceptujesz kompromisy. Jeśli później wrócisz do tej funkcji i poprawisz problemy, jest to dopuszczalne.
Trzeci błąd to ignorowanie informacji zwrotnych od użytkowników. Pokazywanie użytkownikom nawet gotowych makiet i wprowadzanie na ich podstawie zmian powinno być standardem. Kiedy pytam: „Wdrożyliście tę dużą funkcję — ilu użytkownikom pokazaliście ostateczne projekty?”, około połowa menedżerów produktu odpowiada, że nikomu. To ogromny błąd.
Nawet jeśli utknąłeś w fabryce funkcji, na szali leży twoja kariera. To, co dostarcza twój zespół, staje się twoim życiorysem i wpływa na to, czy zostaniesz zwolniony, czy awansujesz. Dopilnuj więc, aby zła idea została zrealizowana w najlepszej możliwej wersji.
Czwarty błąd to pozwalanie, aby strach przed pozostaniem w tyle wyznaczał plan rozwoju. HubSpot wydał system CRM, więc my też musimy go mieć. Typefully ma publikowanie na LinkedIn, więc nasze narzędzie Twittera, Tweet Hunter, też musi je mieć. Obawiamy się, że ktoś odbiera nam klientów, albo tracimy największego klienta i nagle chcemy zbudować wszystko, co mogłoby go zatrzymać.
To ogromny błąd. Spróbuj pokazać kadrze kierowniczej zakres funkcji. Właśnie dlatego ważne jest szacowanie wpływu. Ile osób może skorzystać z nowego produktu? Jeśli nasz ostatni nowy produkt jest używany przez 0,2% użytkowników, czy naprawdę musimy inwestować w kolejny produkt, z którego również skorzysta 0,2% użytkowników? Strach przed pozostaniem w tyle powinien być sygnałem ostrzegawczym.
Piąty błąd to doprowadzanie zespołu do wypalenia. Jest to częste nawet w środowiskach zapewniających autonomię. Szybkie dostarczanie jest ważne, ale zdrowy i dobrze zmotywowany zespół zwykle osiąga najlepsze rezultaty.
Jako menedżer produktu zawsze opowiadaj się za lepszymi narzędziami, budżetem na naukę i rozwój oraz dobrze zaplanowanym wyjazdem zespołowym. Możesz powiedzieć przełożonemu: „Właśnie dostarczyliśmy dużą funkcję albo wkrótce ją dostarczymy. Myślę, że świetnie byłoby, gdyby zespół mógł się spotkać i to uczcić”. Takie drobne gesty mają ogromne znaczenie.
Kiedy zaczynałem pracę w zarządzaniu produktem, przynosiłem deweloperom brownies po wdrożeniu dużej funkcji i przybijałem piątki projektantom, gdy wykonali świetną pracę. W fabryce funkcji cierpi nie tylko menedżer produktu. Niezadowoleni są również projektanci i inżynierowie.
Szósty błąd to utrata z oczu szerszego obrazu. Otrzymujemy polecenia dotyczące tego, co mamy zrobić, i zapominamy o powodach. Mówiłem o powodach w kontekście wskaźników i problemów użytkowników, ale nie zapominajmy również o strategii produktu.
Nawet jeśli strategia produktu pojawia się jako ostatni element, warto rozwijać tę umiejętność. W ostatnich trzech czy czterech latach rynek pracy dla menedżerów produktu bardzo się skurczył. Jest mniej stanowisk tego typu, podczas gdy liczba stanowisk związanych z projektowaniem produktu i inżynierią produktu nadal rośnie.
Jeśli chcemy, aby menedżerowie produktu odnosili sukces w warunkach kurczącego się rynku pracy, musimy dążyć do wpływu na strategię produktu. Nawet w fabryce funkcji istnieje 10–15% planu rozwoju, na które możesz wpływać. Istnieje również 10–15% sprintu, w którym projektant lub kierownik zespołu inżynierskiego może poprosić cię o pomoc.
Nadal jesteś częścią zespołu, nawet jeśli pracujesz w fabryce i zaakceptowałeś jej priorytety. Dopilnuj, aby dostarczane funkcje były naprawdę strategiczne. Jeden z najlepszych menedżerów produktu, których znam, nadal pracuje w Epic Games. Każda funkcja, którą dostarcza, zmienia trajektorię firmy.
Nie dostarcza ich często, ponieważ pracuje w takim środowisku, ale kiedy już to robi, efekt jest przełomowy. W Affirm pewien menedżer produktu wdrożył uczenie maszynowe do organizowania pożyczek, które warto spłacić. Była to głęboka aplikacja działająca po stronie serwera, ale poprawiła spłacalność o około 15%, zapewniając Affirm przewagę nad konkurencją.
To właśnie powinno motywować ludzi. Jeśli utknąłeś w fabryce funkcji, spróbuj samodzielnie wymyślać genialne pomysły na funkcje i umieszczać je w planie tam, gdzie jest to możliwe.
Hannah Clark: To zdecydowanie moment, po którym można odłożyć mikrofon. Aakash, bardzo dziękuję, że znalazłeś czas na rozmowę. Gdzie mogą cię znaleźć osoby, które jeszcze cię nie obserwują?
Aakash Gupta: Najlepiej w newsletterze. Jestem na Substacku. Wiem, że niektórzy nie lubią wyskakującego okna z prośbą o adres e-mail.
Można je zamknąć i kontynuować czytanie. Obecnie nad każdym tekstem pracuję średnio z ponad dziesięcioma osobami. Przy ostatnim artykule miałem gościa współpracującego ze mną. Każdy z nas rozmawiał z dziesięcioma osobami i przeprowadzaliśmy wywiady. Uzyskaliśmy prawdziwe spostrzeżenia.
To nie są zwykłe treści produktowe, które można zobaczyć na LinkedInie lub platformie X. Są to badania oparte na rozmowach z prawdziwymi ludźmi. Przy tekście o poszukiwaniu pracy na stanowisku lidera produktu rozmawialiśmy z liderami produktu, którzy niedawno zdobyli stanowiska wiceprezesa lub dyrektora, oraz z rekruterami, którzy rzeczywiście obsadzają stanowiska w tej branży.
Chcę dostarczać prawdziwe dane i prawdziwe spostrzeżenia. Jeśli kogoś to interesuje, właśnie nad tym pracuję i tam można mnie znaleźć.
Hannah Clark: Wspaniale. Do zobaczenia. I bardzo dziękuję, że do nas dołączyłeś.
Aakash Gupta: Dobrze, bardzo dziękuję.
Hannah Clark: Dziękujemy za wysłuchanie. Aby poznać więcej ciekawych spostrzeżeń, poradników i recenzji narzędzi, zasubskrybuj nasz newsletter na stronie theproductmanager.com/subscribe. Więcej podobnych rozmów znajdziesz, subskrybując Klub CPO w dowolnym miejscu, w którym słuchasz podcastów.

