Strategia produktowa według Melissy Perri – jak wyjść z Build Trap i rozwijać product management #EN341

TL;DR

• Build trap to wytwarzanie funkcji bez związku z wynikiem klienta i biznesu
• Priorytet mają outcomes nad outputs; liderzy wyznaczają kierunek i ograniczenia
• Cztery poziomy decyzji: wizja i intencje, portfolio, strategia produktu i inicjatywy, opcje rozwiązań
• Strategię wdraża się kadencją góra–dół, nie jednorazowym slajdem
• Cost of Delay (koszt opóźnienia) porządkuje kolejność prac przez wpływ i pilność
• Product Ops przyspiesza decyzje w skali (często 30–50 mln ARR i środowisko wieloproduktowe)
• Product Kata: cel, przeszkody, najbliższy krok, nauka

Wstęp

Poniższe notatki powstały na podstawie rozmowy Melissy Perri w podcaście Product Growth. Melissa jest autorką książek „Escaping the Build Trap” oraz „Product Operations”, prowadzi Product Institute i program CPO Accelerator. Przez lata prowadziła transformacje produktowe w firmach – od startupów po Fortune 50.

Wszystkie przedstawione koncepcje, spostrzeżenia i przykłady pochodzą bezpośrednio od rozmówców podcastu.

O co chodzi i dla kogo

Materiał wyjaśnia, dlaczego organizacje wpadają w build trap oraz jak z tego wyjść dzięki klarownej strategii, priorytetyzacji i dyscyplinie operacyjnej.

Adresaci:

• Zarządy i C-level
• CPO/VP Product
• PM-owie w firmach w fazie wzrostu

Build Trap – czym jest i jak z niego wyjść

Definicja i różnica od Feature Factory

Według Melissy, Build Trap to moment w czasie, gdy organizacja buduje bez końca, ale nigdy nie sprawdza, czy tworzy właściwe rzeczy dla klientów. Firma koncentruje się na liście funkcji do wydania, jednak nie łączy ich z wynikami biznesowymi ani problemami użytkowników.

Feature Factory to termin stworzony przez Johna Cutlera. Melissa rozróżnia te pojęcia: Build Trap to stan, z którego można wyjść, natomiast Feature Factory to sposób operowania. Jeśli organizacja funkcjonuje jako Feature Factory i nie chce się zmienić, utknie tam na stałe. Z kolei z obu stanów można wyjść przy odpowiedniej chęci działania.

Melissa podkreśla, że wszystkie organizacje trafiają w Build Trap w którymś momencie. Małe startupy upadają, jeśli wpadną tam za wcześnie. Duże firmy mogą spędzić tam lata, ponieważ dysponują kapitałem do spalenia.

Syndrom „waiter mode”

Jeden z głównych symptomów Build Trap to „waiter mode” – sytuacja, gdy product managerowie i organizacja przyjmują wszystko od klientów jako feedback i po prostu to budują.

Dzieje się tak szczególnie w czasie szybkiego wzrostu. Wszyscy klienci żądają funkcji, jednak firma nie ma procesu, który pozwoliłby to przesiać i upewnić się, że priorytetyzowane są rzeczy naprawdę istotne. Zamiast tego organizacja ugina się pod kaprysami największych klientów i tych, którzy krzyczą najgłośniej, bojąc się utraty dużych kont.

Pułapka brzmi: „To jest customer feedback, więc po prostu idźmy to zbudować.” Brakuje jednak kluczowego kroku weryfikacji, czy dana funkcja faktycznie rozwiązuje najważniejsze problemy zgodne ze strategią firmy.

Sekwencja wychodzenia z pułapki

Melissa zaczyna od podstawowego pytania: czy w ogóle rozwiązujemy właściwe problemy klientów? Czasem organizacje wiedziały to kiedyś, jednak w okresie szybkiego wzrostu straciły proces weryfikacji.

Pierwszy krok to cofnięcie się i zadanie pytań:

• Kim są nasi klienci dziś (nie rok temu)?
• Czy nadal chcemy ich obsługiwać?
• Jakie są największe problemy, które możemy dla nich rozwiązać?

To musi zacząć się na poziomie C-suite. Konieczne jest zrozumienie, dokąd firma zmierza jako całość. Product managerowie muszą móc połączyć to, co budują, z „dlaczego” całej organizacji.

Wejście do strategii – jakie dane zebrać:

• analizy win–loss ze sprzedaży
• użycie według person/kohort
• hipotezy i rozmowy z kluczowymi segmentami
• lista rzeczy, których organizacja nie robi

Dwa scenariusze transformacji

Fortune 50 przeprowadzające transformację cyfrową:

Organizacje reorganizują się w zespoły Agile i nagle mają tysiące „product owners”, jednak nikt nie wie, co z nimi zrobić. Brakuje strategii produktowej od góry do dołu. Występuje ogromna luka w C-suite dotycząca product management.

Melissa pracuje wtedy z executive teams, pokazując, że product management to dyscyplina wymagająca executive product leadera oraz VP-ów produktu na różnych poziomach strategii. Nie można po prostu powiedzieć zespołom „innowujcie” bez podania kierunku.

Typowy początek brzmi: „Inwestujemy w software. Co z tego mamy?” To uruchamia konwersację. Melissa pokazuje: faktycznie potrzebujecie strategii produktowej. Product management to dyscyplina i rola składająca się z wielu poziomów. Potrzebujemy executive product leadera i VP-ów produktu, którzy zajmują się różnymi aspektami strategii i wdrażania w dół do zespołów, aby mogły one wymyślić, jakie rozwiązania budować.

Nie możemy tylko patrzeć na zespoły i mówić „innowujcie” – to tak nie działa. Zwykle transformacja trwa wiele lat – to nie jest podejście „w tym roku zrobimy product i będzie gotowe”.

Growth-stage scale-upy (20-50M ARR):

Firmy znalazły product-market fit jako mały startup z jedną linią produktu i rozwijają się szybko, jednak nigdy nie wdrożyły solidnego systemu product management. W rezultacie nie nadążają z feedbackiem, nie monitorują postępu właściwie.

Chcą wejść w multi-product, więc pytają: jak to zrobić? Zwykle wprowadzają koncepcję CPO. Często, szczególnie w firmach wspieranych przez VC, chodzi o połączenie strategii produktowej z wynikami, które firma chce osiągnąć w określonym czasie, aby pokazać inwestorom: ten product roadmap i portfolio osiągnie nasze cele wzrostu.

Te firmy mają zazwyczaj świetnych IC PM-ów i foundera z product sense. Więcej chodzi o: jak robimy strategię produktową na skali, jak łączymy ją z perspektywy finansowo wspieranego celu, jak wiążemy z wynikami, jak wdrażamy i jak budujemy infrastrukturę do mierzenia rzeczy na skali?

Strategia produktowa – fundamenty

Różnica między strategią firmy a produktu

Melissa opisuje strategię jako dwustronną: patrząc na strategię firmy i priorytety, pytamy: jak nasze produkty lub portfolio rozwinie się, by spełnić te cele? Co zbudujemy, jakie problemy rozwiążemy i jak zaprojektujemy właściwe rozwiązanie?

Jest wiele warstw, a strategia produktowa i firmowa wzajemnie się zasilają. Typowo, gdy Melissa pracuje z organizacjami (przez board work czy advising), prawie zawsze istnieje teza za inwestycją. Nawet duże organizacje mają tezę dotyczącą tego, co chcą robić i gdzie ekspandować. Problem w tym, że nie jest ona skomunikowana w dół w sposób pozwalający połączyć wszystkie działania produktowe z tymi wynikami.

Cztery warstwy decyzji w strategii

Model porządkujący drogę od wizji do rozwiązań:

Warstwa 1: Wizja firmy i strategic intents

• Wizja firmy – dokąd zmierzamy, jak chcemy być zróżnicowani (coś namacalnego, za czym można stanąć)
• Intencje strategiczne (strategic intents) – jak chcemy rosnąć, gdzie stawiamy zakłady. Również „rebuilding year”, np. replatforming

Melissa widzi wiele strategii firm i wizji brzmiących jak „bądź najlepszy, rób kasę”. Cały zespół reaguje: ok, ale jak? Mogłabym pójść do McDonald’s, podjąć zmianę i dać ci zarobioną kasę, ale wyobrażam sobie, że nie chcesz, żebym rozwijała firmę w ten sposób.

Ten typ słabości w strategii firmy jest zazwyczaj powodem, dla którego wiele strategii produktowych zawodzi na starcie. Trzeba wrócić do góry i zapytać: czy mamy silną wizję firmy? Czy wiemy, gdzie chcemy grać, jak to ewoluować, jakie problemy rozwiązać, jak chcemy być różni od konkurencji?

Warstwa 2: Strategia portfolio (w większych organizacjach)

CPO patrzy: jaka jest wizja portfolio? Rola każdego produktu w tworzeniu wartości jest jasna. Jak produkty współdziałają? Czy możemy wyciągnąć więcej wartości, myśląc o nich razem?

Kluczowe elementy:

• zdefiniowane przepływy danych między produktami i ich wpływ na wartość
• świadoma decyzja „platforma czy produkt”

Częsty problem: każdy patrzy na swój produkt osobno, nikt nie patrzy na wszystkie produkty razem. Nikt nie myśli: jak te produkty współdziałają i czy możemy je wykorzystać, żeby stworzyć coś potężniejszego? Na przykład: co jeśli wziąłbym dane z jednego produktu i zintegrował w drugi? Jeśli to pomaga rozwiązać problemy klientów, powinno iść do naszej wizji portfolio.

Warstwa 3: Strategia produktu i inicjatywy

• Wizja produktu – dokąd zmierza, kogo obsługuje (dla kogo budujemy, jakie problemy rozwiązujemy)
• Jak ewoluuje w czasie
• Jakie problemy chcemy rozwiązać
• Jakie cele chcemy osiągnąć

Melissa widzi wiele wizji produktowych, gdzie ludzie nawet nie wspominają o rozwiązaniach, jednak niektórzy nie wiedzą, że budują platformę – a to jest platforma. Jeśli ambicją jest platforma i rozszerzalność, trzeba to nazwać. Po prostu powiedz ludziom, co budujesz.

Te typy decyzji pomagają kierować zespołami w tym, co będą robić. Nie chcesz dawać tak dużo szczegółowego kierunku w strategii produktowej jak „chcę, żebyś zbudował ten widget pozwalający na integracje”. Być może twoja wizja produktu dotyczy bycia rozszerzalnym i możliwości pobierania danych z różnych źródeł. To świetny wskaźnik mówiący: integracje to coś, na co chcemy patrzeć.

Warstwa 4: Product options – możliwe rozwiązania

Inicjatywy to duże problemy do rozwiązania, nie konkretny zestaw funkcji. Na przykład w e-commerce idącym up-market: „pomóc klientom lepiej marketować ich produkty”. To duży obszar.

Pod tym znajdują się opcje produktowe – rozwiązania, które możesz zbudować, żeby to osiągnąć. Melissa celowo nazywa je „opcjami”, ponieważ nie chce, żeby ludzie zamknęli się na konkretne rozwiązanie przed walidacją. Zaczyna się jako problem i ewoluuje w rozwiązanie.

Być może ktoś patrzy i mówi: programy lojalnościowe to świetny sposób na marketing – choć to bardziej strategia retencji. Ale może dla marketingu chodzi o integracje z narzędziami, których już używają klienci. A może chodzi o to, że nie wiedzą, jak marketować produkty lub co robią inne firmy, więc powinniśmy dać im wskazówki na platformie.

Wszystkie to różne rozwiązania, jednak chodzi o twój kontekst – czy wraca do wizji firmy i produktów? Czy się zgadza? Tak wybieramy, co robić na poziomie opcji produktowych.

Proces tworzenia strategii (Hoshin Kanri)

Melissa bazuje w dużym stopniu na Hoshin Kanri – procesie wdrażania strategii wymagającym wielu decyzji i dopasowania.

Duży błąd: firmy idą do pokoju, wymyślają nową wizję, wdrażają ją w dół do zespołów mówiąc „do dzieła”. Jednak gdy robisz dobre kadencje strategiczne (Melissa bazuje na Hoshin Kanri), na każdym poziomie organizacji mówisz: oto kierunek, w którym chcę iść, oparty na twardych danych i faktach. Zrobiłem analizę, research, rozmawiałem z klientami – myślę, że powinniśmy iść w tym kierunku.

Wdrażasz strategię w dół. Następny poziom organizacji ma powiedzieć: co musimy zrobić, żeby tam dotrzeć? I czy możemy? To wymaga dużo komunikacji w górę i w dół na każdym poziomie oraz w poprzek organizacji.

Chcesz upewnić się: jeśli robisz coś w produkcie, engineering faktycznie to obsłuży. Jeśli robisz coś w sales, produkt ma to na roadmapie. Powinniśmy dopasować się w poprzek organizacji, gdy budujemy strategie i upewniać się, że idziemy we właściwym kierunku przed zobowiązaniem.

Kluczowe elementy wdrażania:

• stała kadencja góra–dół do uzgodnień wykonalności
• ten sam kierunek komunikowany różnymi formami
• jawna lista „stop doing” na poziomie firmy i produktów

Jak komunikować strategię

Forma ma służyć zrozumieniu:

Memo:

• wizja
• stan obecny (co działa, co jest zepsute)
• priorytety
• lista „stop doing”

Slajdy:

• dane i trendy
• przykłady
• mock-upy wizualizujące potencjał (z zastrzeżeniem „to nie jest zobowiązanie”)
• cytaty z wywiadów klientów

Prototypy i wideo: Wizualizują kierunek bez betonowania szczegółów. Melissa współpracuje obecnie z firmą, gdzie stworzyli klikalny prototyp pokazujący połączenie dwóch produktów w jedną platformę. Pozwoliło to członkom zarządu zobaczyć: och, ok, rozumiem, jak to się składa.

Ramy myślenia:

• Three Horizons
• canvasy (value proposition, lean strategy)
• modele Gibbs

To narzędzia myślenia, nie cel sam w sobie. Melissa podkreśla: „Strategia to dokonywanie wyborów.”

Three Horizons Model

Melissa lubi Three Horizons Model jako punkt startowy do myślenia: gdzie jesteśmy teraz, co myślimy robić dalej, żeby rozwijać nasze obecne silniki wzrostu, i gdzie chcemy innowować lub wprowadzać zmiany przełomowe.

Model pomaga ludziom wyjść z nastawienia: musimy ciągle robić rzeczy tak samo LUB musimy przeskoczyć w innowację do czegoś szalonego i nowego. Pomaga myśleć w kategoriach ewolucji, a także przewidzieć, czy firma będzie zdominowana przez konkurencję – szczególnie istotne dla legacy business.

Melissa nie uważa, że to idealny model strategii – nie wyjaśnia wszystkiego. To jedno narzędzie pomagające przemyśleć, jak chcesz prezentować strategię.

Przykład Netflix: Melissa myśli, że mają świetną strategię. Gibson Biddle pisał o tym wiele razy. Prawdopodobnie myśleli o Three Horizons: rozwinąć się na DVD, potem pivot do streaming, następnie original content. Zdominowali całą branżę przez tworzenie treści oryginalnych.

Przykład: ING jako platforma finansowa

Melissa używa ING jako przykładu dla banków. ING nie mówi już o sobie jako o banku – określają się jako platforma finansowa. Otwierają się, żeby ludzie mogli integrować i dzielić się danymi. To była świadoma zmiana strategii – odejście od bycia bankiem.

Melissa czyta ich materiały korporacyjne, patrzy na strategię i sposób wyjaśniania. Czy to 100% doskonała praktyka? Nie myśli, że jakakolwiek firma ma w pełni doskonałą strategię, jednak lubi, że jest ekstremalnie jasna. Bardzo łatwo zobaczyć, dokąd idą i co robią. Mówią o wyborach, które podjęli, żeby tam dotrzeć – w przekonujący sposób.

Melissa pyta banki: „Oni nawet nie nazywają się bankiem. Pomyślcie, czym moglibyście być, co moglibyście zrobić, gdybyście chcieli iść tą drogą.” To też wybór – strategia to robienie wyborów. ING powiedział: chcę iść w tym kierunku. Każda dobra strategia jasno mówi: to nasz wybór, to gdzie chcemy iść. Nie zostawia tego otwartym.

Przykład strategii up-market

Melissa daje bardzo praktyczny przykład typowego ruchu strategicznego w growth-stage companies:

Wspólny ruch w corporate/company strategy: pójść up-market. Wszyscy wiedzą, że chcą iść up-market, jednak pytanie brzmi: jak?

Jeśli rozwiązujesz problemy dla SMB businesses, wiele firm próbuje skoczyć i zrobić coś z enterprises. Zazwyczaj dlatego, że jeden enterprise przychodzi, puka do drzwi mówiąc: hej, chcę to zrobić. Firma skacze: tak, duża umowa, zróbmy to.

Jeśli jednak wrócisz i spojrzysz na produkt, musisz odpowiedzieć:

• Ile wysiłku i inwestycji zajmie przygotowanie produktu dla enterprise?
• Jak tylko ich dostaniemy, czy możemy ich zatrzymać, czy możemy ich utrzymać?

To wraca do pytań o strategię produktową. Strategia produktowa i firmowa zasilają się nawzajem, ponieważ chcemy priorytetyzować rzeczy na poziomie strategii firmy (Melissa nazywa to strategic intents), które pomagają określić, jak będziemy robić strategię produktową.

Jeśli jeden z naszych strategic intents – pierwszy – to: go up-market, chcemy powiedzieć: idziemy up-market, gdzie się przenosimy – z SMB do mid-market? Jeśli tak, gdzie chcemy startować? Czy idziemy do enterprise? Czy nie gramy w enterprise?

Robiąc to, co targetujemy? Czy to nowe logo, rozszerzanie zespołu, pozyskiwanie nowych jednostek, rosnąc na różne sposoby – co próbujemy robić, jaki jest nasz cel?

Chcemy wyłożyć te strategic intents jako executive team – zazwyczaj pokrywają wszystko. Bo jeśli idziesz up-market, nie tylko wpływa na produkt, wpływa też na sales. Jeśli nie masz zespołu sprzedaży, który wie, jak sprzedawać do enterprise, musisz go zatrudnić. To bardzo inny zestaw umiejętności niż SMB companies, które mogą być product-led growth play.

Musisz patrzeć: jakie rzeczy mamy w organizacji, możliwości, żeby móc zrobić te strategiczne ruchy.

Z perspektywy produktu, gdy idziesz up-market do enterprise, bardzo powszechne potrzeby to:

• Security
• Integrations

Czy w ogóle mamy możliwości integracyjne, jeśli chcemy to robić? Jak to wygląda? Jak faktycznie o tym myślimy? Gdzie to priorytetyzujemy? Te typy rzeczy wpłyną na strategię produktową.

Outcomes przed outputs

Founder mode – kiedy pomaga, kiedy szkodzi

Melissa jest bardzo krytyczna wobec koncepcji founder mode: „Nienawidzę founder mode. Myślę, że jest źle wyjaśniona.”

Jej zdaniem founderzy to specjalni ludzie rozumiejący ryzyko i znajdujący product-market fit. Firmy przechodzą jednak różne fazy wzrostu – bycie dobrym w 0-to-1 nie oznacza, że możesz rozwijać firmę z 20M ARR do 150M ARR lub do rozmiaru Facebooka.

Melissa patrzy na to jako symptom pytań: Czy zatrudniłeś właściwych ludzi? Czyjej rady słuchałeś? To nie była rada wszystkich.

Wiele firm, które wpada w problemy, rozwija się szybko. Rozwijają z pieniędzmi (strona przychodów), ale też rozwijają ludzi jak szaleni, myśląc: jeśli tylko dodamy więcej ludzi, będziemy dalej robić więcej kasy. To tylko działa, gdy masz strategię.

Co się dzieje: patrzą na zespoły mówiąc: zatrudniliśmy tych wszystkich ludzi, innowujcie oddolnie. Jednak nie ma strategii od góry.

Silniejsze sterowanie ma sens w kryzysie, bo porządkuje kierunek i zawęża rozproszenie. Jeśli masz młodszych ludzi – powiedzmy zatrudniłeś niewłaściwych ludzi lub ludzie w organizacji są młodsi – musisz dać więcej kierunku jako lider. Melissa myśli o tym jako zacieśnianie ograniczeń: nie chcemy iść tutaj, tutaj, tutaj – działaj w tym obszarzu. Nie chodzi jednak o dyktowanie w dół wszystkich rozwiązań.

W okresie wzrostu ten sam styl tłumi innowację. Jeśli masz bardzo doświadczony zespół, możesz poluzować ograniczenia – powinni móc znajdować rzeczy sami, ponieważ przeszli przez to wcześniej, widzieli wzorce, mogą użyć intuicji. Wtedy należy luzować ograniczenia i budować centra kreatywności poza założycielem.

Melissa widzi jednak wszystkich mówiących o founder mode jako powód do nie mieć product managerów lub ludzi produktowych – to nigdy nie wypełni tej luki.

Priorytetyzacja przez Cost of Delay (koszt opóźnienia)

Melissa poznała cost of delay, gdy studiowała – robiła zarządzanie łańcuchem dostaw i inżynierię informacji. To był pierwszy raz, gdy to widziała, jednak tylko w kontekście produkcji. Potem spotkała Joshaua Arnolda i Ozela Nucci. Joshua prowadzi firmę Black Swan Farming i zaaplikował to do product development.

Kluczowe pytanie brzmi: jaki koszt ponosimy, opóźniając inicjatywę B, gdy najpierw realizujemy A? Gdy porządkujesz rzeczy do wypuszczenia (priorytetyzacja) – powiedzmy priorytetyzujemy A nad B – jest koszt opóźniania B, jeśli nie możemy zacząć pracować nad nim przy A.

Gdy myślisz o planowaniu zasobów w organizacjach, musisz wybierać, czy robić to pierwsze czy tamto pierwsze. Mamy te wybory każdego dnia w roadmapingu i strategii produktowej.

Jak to kalkulować – przykład liczbowy

Sposób, w jaki Melissa o tym myśli: jeśli chciałabym zbudować produkt A przed produktem B – będę pracować nad tym jako pierwszym i to dostarczyć – jaki jest cost of delay?

Przykład z rozmowy:

A: wpływ 25 mln USD w przychodach, czas dostarczenia 6 miesięcy
B: wpływ 10 mln USD w przychodach, czas dostarczenia 3 miesiące

Scenariusz 1 (kolejność A→B):
- Przez pierwsze 6 miesięcy budujemy A
- Nie możemy zacząć B przez 6 miesięcy
- B będzie gotowe dopiero w 9. miesiącu
- Opóźniamy przychód z B o 9 miesięcy

Scenariusz 2 (kolejność B→A):
- Przez pierwsze 3 miesiące budujemy B
- B zaczyna generować przychód od 3. miesiąca
- Podczas budowania A (miesiące 4-9), B już zarabia
- Wcześniejszy przepływ gotówki

Ile pieniędzy byśmy zarabiali miesięcznie na produkcie B, podczas gdy budujemy produkt A? I czy to jest większe? Możesz to wykalkulować.

Jeśli patrzysz na BlackSwanFarming.com i cost of delay, pokazują, jak to kalkulować – tak o tym myśli Melissa.

Profile opóźnienia

Jest też sposób jakościowy, jeśli nie możesz sprowadzić tego do liczb przychodowych, gdzie możesz zacząć myśleć o wpływie vs pilności. To są profile – możesz zacząć to przesuwać.

Profile opóźnień:

• Profil terminowy: spóźnienie na okno sprzedażowe/budżetowe oznacza utratę całego roku. Wyobraź sobie, że jesteś w firmie, która ma cykl sprzedaży dla twoich klientów, który kończy się w listopadzie. Nie masz produktu gotowego do demo lub pokazania do listopada – możesz musieć czekać cały kolejny rok, zanim go sprzedasz. To wysokie opóźnienie, wysoki cost of delay.
• Profil liniowy: wartość rośnie w miarę dostaw, przychód generowany jest stopniowo po wypuszczeniu.

Dla Melissy ten mentalny model myślenia o: jak pilne jest i jaki jest wpływ, jest naprawdę ważny. Teraz musisz wyważyć wszystko bez powtarzających się przychodów lub zabezpieczenia tego.

Zastosowanie dla liderów

Melissa myśli, że liderzy naprawdę powinni używać cost of delay, gdy myślą o jakichkolwiek implikacjach strategii produktowej, gdy myślą o jakichkolwiek tych dużych kawałkach inicjatyw. Chcesz upewnić się, że priorytetyzujesz naprawdę duże obszary pracy, żeby pchały biznes do przodu.

Możesz cofnąć się i modelować wszystkie te rzeczy w przychodach i kosztach i dochodzić do dolarów. Zajmuje trochę modelowania finansowego, jednak to właśnie CPO-si powinni robić – powinni finansowo modelować ze swoimi partnerami finansowymi i ze swoimi partnerami inżynieryjnymi i z wszystkimi innymi w C-suite: jaki jest wpływ robienia X vs Y dla biznesu i czy pomaga to naszemu wzrostowi?

Product Ops – kiedy i po co

Czym naprawdę jest Product Ops

Melissa napisała książkę o Product Operations, ponieważ widziała, że rola dostaje złą reputację – ludzie myślą tylko o procesach. Dla niej Product Ops to strategiczne wsparcie.

Celem nie jest kontrola procesu, lecz lepsze i szybsze decyzje. Gdy myśli o Product Ops, chodzi o pytania:

• Czy mogę dostarczyć właściwe dane do organizacji, żeby product managerowie i liderzy mogli podejmować decyzje?
• Jak przeglądamy decyzje, które faktycznie podejmujemy?
• Czy mamy dobry rytm na to?
• Czy możemy śledzić metryki, które chcemy osiągnąć – czy jest to zautomatyzowane, powtarzalne?
• Czy muszę pytać inżyniera danych, żeby wyciągnął coś z bazy za każdym razem?
• Czy możemy dotrzeć do klientów i dostać od nich feedback?
• Gdzie faktycznie żyje customer feedback?
• Jak wykorzystujemy to, co mamy wokół organizacji?

Wszystkie te pytania to to, na co Product Ops faktycznie odpowiada i pomaga zbudować.

To jak product managerowie dla product managerów. Nie potrzebujesz miliona z nich w organizacji – to nie powinno być 1:1 ratio w żadnym wypadku. Chodzi o: jak myślimy o standaryzowaniu tego, co robimy wewnętrznie w sposób, który umożliwia ludziom podejmowanie strategicznych decyzji szybciej, żeby wszyscy bezpośrednio związani z przychodami mogli tam dotrzeć szybciej. To przyspiesza silnik.

Zakres obejmuje:

• dane o użyciu
• głos klienta
• metryki rezultatów
• standardy map drogowych
• spójny zestaw narzędzi

Kiedy organizacja potrzebuje Product Ops

Według Melissy, gdy firma jest naprawdę mała, nie potrzebujesz Product Ops – po prostu odwracasz

się i pytasz. Jednak gdy się rozwijasz, to jest moment, gdzie Product Ops staje się naprawdę ważny.

Funkcję można zacząć od jednej osoby; potrzeba zwykle ujawnia się przy 30–50 mln ARR i środowisku wieloproduktowym. Melissa zazwyczaj zatrudnia pierwszą osobę Product Ops przy tym poziomie – gdy zaczynasz multi-product lub komplikujesz się w portfolio. To zwykle moment, gdy zatrudniasz CPO, ponieważ potrzebujesz więcej strategicznego kierunku nad tym portfolio.

W dużych przedsiębiorstwach z 7000 PM-ów: jak rozumiesz, nad czym pracuje 7000 ludzi, jeśli nie mamy nawet systemu roadmapingu? Większość z nich nie ma takiego systemu.

Jak powiesz tym 7000 product managerom i upewnisz się, że wiedzą, jak pisać najlepszą inicjatywę w formacie, gdzie możemy porównywać każdy inny poziom inicjatywy produktowej i rozumieć wyniki oraz powiedzieć: czy podejmujemy właściwe decyzje strategiczne?

Z perspektywy procesu i zarządzania robią takie rzeczy. Ale też wychodzą i mówią: czy potrzebujemy Pendo? Czy potrzebujemy Amplitude? Jak upewnić się, że dostajemy właściwą rzecz dla naszego kontekstu? Czy pójdę walczyć z zespołem danych i upewnić się, że możemy podłączyć wewnętrzne strumienie danych do Power BI, żeby ludzie zaczęli robić własne raporty?

Jeśli product leader robi to – jak CPO dużego przedsiębiorstwa – to dużo pracy dla kogoś, kto powinien wyznaczać strategiczny kierunek dla 7000 ludzi.

Przykład z Insight Partners

Melissa daje konkretny przykład z własnego doświadczenia. Z scale-upami (mówimy o 20 do 30M ARR, typowo gdzie mogą zatrudnić CPO – to był ich model z Insight), patrzysz na firmy i mówisz: jeśli robisz multi-product lub zaczynasz być bardziej skomplikowany w swoim portfolio produktów, zazwyczaj około 30, może 50M ARR.

Zazwyczaj zatrudniasz CPO, ponieważ potrzebujesz więcej strategicznego kierunku nad tym portfolio – tam Melissa patrzyłaby na zatrudnienie Product Ops też.

Konkretny przypadek: Z Insight miała analityków danych produktowych, którzy byli ludźmi Product Ops. Szliby, ręcznie wyciągali wszystkie dane, pomagali ustawić strategię. Mogli zacząć wkładać to w formy, które miały sens dla kadry kierowniczej – i potem mogli ustawić strategię.

Zazwyczaj to można zrobić ręcznie, jednak dane były w tak złym stanie czasem, że spędzali 2 miesiące robiąc to. Masz jedną osobę spędzającą prawie 8 miesięcy rocznie ręcznie wyciągając dane.

Zamiast tego rzecz, którą chcesz zrobić, to uczynić to powtarzalnym. Po pierwszym razie pytanie brzmi: jak to zautomatyzować, żeby następnym razem po prostu kliknęliśmy odśwież, bo będziemy chcieli widzieć te same widoki i możemy je aktualizować z czasem.

Narzędzia i platformy

Melissa wymienia konkretne narzędzia w ekosystemie Product Ops:

Analityka i user research:

• Pendo
• Amplitude
• Mixpanel
• Power BI
• Dovetail (do repozytoriów research)

Customer feedback i insights:

• Zelda AI (przejęty przez Pendo) – podłącza się do produktów sprzedaży i wsparcia
• HubSpot
• Salesforce
• Gong
• Zendesk

Przykład Zelda AI: Podłączają się do twojego HubSpot lub Salesforce, potem też twojego Gong i wszystkich tych rzeczy. Przetwarzają to, następnie z ich modelami AI lub generatywnymi modelami AI zaczynają wyłaniać: jakie są trendy tematyczne od twoich klientów. Potem przypisują do tego wartość w przychodach. Niesamowite – teraz masz punkt startowy jako product manager, masz hipotezę, dokąd iść.

Osoba Product Ops byłaby odpowiedzialna za wymyślenie, jakie typy narzędzi powinniśmy pozyskać. Melissa mówi: zamiast tworzyć to sam, bo robiliśmy rzeczy jak Dovetail – odtwarzali to od zera w Athenahealth. Jen Cardello praktycznie zrobiła to sama w Fidelity – robili repozytoria research od podstaw.

Teraz mamy wszystkie te narzędzia. Byłoby krzywdą nie myśleć o: co możemy podłączyć i zacząć dostarczać dane i informacje z powrotem do zespołów tak szybko, jak to możliwe.

Błędy w rozwijaniu Product Ops (antywzorce)

Melissa widzi zespoły próbujące rozwiązywać problemy punktowo zamiast myśleć o holistycznych rozwiązaniach. W porządku jest zbudować rozwiązanie manualne, powiedzmy żeby dostać jakieś dane dla CPO lub kogoś do podjęcia decyzji strategicznej. Czasem muszą to zrobić ręcznie – robiła to ręcznie dużo z zespołem, którym kierowała z Insight.

Antywzorce Product Ops:

• ręczne „łatanie” danych
• nadmiar formalizmów
• równoległe narzędzia bez obrazu całości

Rzecz, którą chcesz zrobić, to uczynić to powtarzalnym, ponieważ inaczej masz jedną osobę spędzającą czasem 8 miesięcy rocznie ręcznie wyciągając dane. Zamiast tego powinno być: ok, może potrzebujemy tego raz, ale jak tylko widzimy to raz, jak to zautomatyzować?

Melissa widzi też wiele zespołów na skali z Product Ops skupiających się intensywnie na procesie i zarządzaniu. Marty Kagan lubi krzyczeć o tym. Co Melissa widzi: nie jest złym miejscem do startu. Nie obwinia ludzi, którzy startują z roadmaps, ponieważ jeśli nie możesz powiedzieć, nad czym ludzie pracują, jak możesz podjąć decyzję o kompromisie jako lider?

To ok, jednak nie przesadzałaby z całym procesem, chyba że służy podejmowaniu decyzji strategicznych. Nie chcesz wchodzić w tryb agile coach – nie próbujemy kontrolować każdej minuty ceremonii, które product managerowie robią. To nie jest cel Product Ops.

Cel Product Ops: Umożliwić silnikowi product management działanie, żebyśmy mogli podejmować strategiczne decyzje na skali, przynosić przejrzystość do firmy i ludzie mogą robić swoje prace lepiej. Zazwyczaj też zdejmuje dużo pracy z talerzy product managerów, więc wszyscy będą szczęśliwi, gdy faktycznie to zrobimy.

Nie myśl o tym jak próba nadmiernego definiowania procesu lub specyfikowania każdego szczegółu. Chodzi o: zakres: wsparcie decyzji, nie „policja procesu”.

Dlaczego role ops’owe ucierpiały w czasie cięć

Melissa faktycznie nie widzi spadku – przeciwnie, widzi więcej firm adoptujących Product Ops. Anthropic ma Product Ops. Blake Samak, który zaczynał w Uberze, poszedł do Stripe’a, jest teraz head of Product Ops w OpenAI.

Jej teoria: gdy Product Ops jest rozumiany tylko jako procesy, dostaje cięcie. Gdy jest o umożliwianiu strategicznych decyzji na skali, staje się krytyczny.

Największy powód, dla którego Melissa widzi chief product officers lub VPs produktu wymieniani w organizacjach (zdarza się cały czas): nie skupiają się na strategii, nie komunikują w górę, nie pracują z resztą executive team. Bo ugrzęźli w próbowaniu rozgryźć wszystkie szczegóły operacyjne.

Jakiego oprogramowania roadmapowego powinienem użyć i jak go ustawić, żeby moje zespoły faktycznie wiedziały, jaki typ formatu używać? Lub jak też coachować wszystkich moich członków zespołu, upewniać się, że robią to? Wchodzą tak w szczegóły, że nie mogą faktycznie ustawić kierunku, dokąd firma i produkt idzie. Dlatego Melissa myśli, że Product Ops jest naprawdę ważny.

Product Kata jako narzędzie pracy

Pochodzenie koncepcji

Melissa nauczyła się Product Kata, gdy faktycznie zaczynała konsultować. Pracowała z ludźmi, których znała, robiąc Kanban – pracowała w świecie Agile i Kanban. To było wtedy, gdy dużo ludzi myślało, że nie potrzebują product managerów.

Freelance’owała dla tych osób, ucząc ich trochę więcej o przepływie i rzeczach opartych na przepływie i jak używać Kanban. Była to jak godzina dziennie, którą spędzała z tym zespołem – tam nauczyła się, jak robić Kata.

Houkin Force faktycznie stworzył coś zwanego Kanban Kata na bazie Toyota Kata i uczył ludzi, jak optymalizować ich tablice i ich przepływ w ten sposób. Melissa spojrzała na to i pomyślała: prowadziłam eksperymenty długi czas.

Nauczyła się eksperymentacji przez Lean Startup Machine i mieli bardzo przepisaną metodę robienia eksperymentacji, która niezbyt pasowała do niej. Było jak: najpierw robimy eksperyment concierge, potem będziemy robić Wizard of Oz, potem zrobimy to. Wewnątrz firmy – ponieważ nie robiła własnego startupu, aplikowała to do OpenSky – spojrzała na to i była: to nie jest sposób, w jaki podchodzę do eksperymentacji, nie działa naprawdę.

Nauczyła się Kata i była: to faktycznie jest sposób, w jaki myślę. To jak ustawiam, co powinniśmy robić dalej lub jak myślę przez to, jak zrobić eksperyment lub jaki jest następny krok do wzięcia, jeśli chodzi o product management.

Używa tego jako narzędzia, ponieważ myśli, że jest dobrym mentalnym modelem i dobrym sposobem na uczenie ludzi, jak rozbijać problemy, które próbują rozwiązać, i co jest następnym krokiem do wzięcia.

Pętla Product Kata – cztery kroki prowadzą od celu do nauki

Sposób, w jaki Kata działa:

1. Zdefiniuj cel inicjatywy i oczekiwany wynik

Patrzysz na swój duży cel. Dla product managera w zespole, na przykład, to inicjatywa produktowa. Jaki problem próbujemy rozwiązać? Dokąd próbujemy dotrzeć? Cel inicjatywy jest mierzalny i znany zespołowi.

2. Wypisz przeszkody (luki wiedzy, tarcia, zależności)

Potem mówisz: co stoi na drodze nam w osiąganiu tego celu? To są wyzwania. Na początku product development dużo z tego jest oparte na odkrywaniu – nie wiem X, Y, Z o moich klientach, nie wiem, jakie są problemy, które faktycznie mają. Mogą to być luki w wiedzy, może być wyzwanie. Masz aktualną listę przeszkód i zależności.

3. Wybierz najbliższy krok (badanie, eksperyment, mała zmiana)

Potem mówisz: jaki następny krok zamierzam wziąć, żeby pomóc stawić czoła temu wyzwaniu? Najpierw chcesz priorytetyzować wszystkie swoje wyzwania. Potem wracasz i mówisz: co mogę zrobić, żeby się nauczyć? Jaki krok mogę zrobić? To może być rozmawianie z klientami, może być robienie jakiegoś researchu samemu. Masz zdefiniowany najbliższy krok i termin przeglądu nauki.

4. Zamknij pętlę nauki i zdecyduj, co dalej

Potem chcesz wrócić do pętli i powiedzieć: jak dużo bliżej jesteśmy naszego celu? Dokąd próbujemy dotrzeć.

Product Kata w praktyce – przykład

W namacalnej formie product management to może wyglądać jak:

Robisz jakieś odkrywanie, żeby zrozumieć, w jakim kierunku chcesz iść. Mam tę dużą inicjatywę produktową – chcę rozbić ją na to, co zamierzam rozwiązać najpierw. Będę robić jakieś odkrywanie wokół problemów, chcę zdobyć te informacje. Zamierzam zdefiniować, jakie są problemy, które chcę faktycznie podjąć. Zamierzam wybrać pierwszy i potem zamierzam zdecydować się go podjąć.

Zazwyczaj rozbiłam to na opcję produktową – tam docieramy. Ustawiam cel dla tej opcji produktowej i potem przechodzę przez eksperymentację i wydania, żeby pomóc osiągnąć ten cel.

Product Kata to sposób na systematyczne przejście przez to.

Jako lider to, co mógłbyś robić ze swoim zespołem, który próbuje rozbijać opcje produktowe i pracować przez te inicjatywy produktowe, to mówiąc: oto nasz cel inicjatywy produktowej. Co stoi w drodze nam w osiąganiu tego celu?

Zespół wychodzi, robi trochę pracy nad swoimi produktami, wracają i wynajdują to mówiąc znowu: nasze wyzwanie dla naszych klientów polega na tym, że chcą lepiej marketować w e-commerce do ludzi kupujących rzeczy, chcą pomocy z marketingiem. Ok, nie rozumiem tego.

Product managerowie: idźcie zróbcie rozpoznanie tego, zbadajcie odkrywanie.

Product manager wraca mówiąc: hej, znalazłem jakieś specyficzne problemy wokół kwestii marketingowej.

Jeden: faktycznie mają dobrą wiedzę, jak robić marketing. Po prostu nie integrujemy się dobrze z ich narzędziami, więc muszą robić dużo pracy manualnej, żeby dostać wszystkie rzeczy w naszym systemie do ich systemów. I nie jest połączone, więc jest tylko dużo tarcia tutaj w tym, co robimy vs co chcą robić i jakie są ich przepływy pracy.

Dwa: chcą móc oferować różne rabaty i pakiety do ludzi. Marketing tutaj nie jest tylko o marketingu, jest też o przyciąganiu ludzi z powrotem. Więc myślą o tym, co mogą zrobić dla programów lojalnościowych. Może to odgałęzienie większego problemu, ale może to opcja produktowa.

Ale mamy te dwa problemy teraz. Którym chcemy się zająć? Ok, nauczmy się więcej o tym, jak robimy integracje do innych systemów. Jako product manager zamierzam zapytać siebie: ok, jaki jest cel, który próbujemy osiągnąć z tymi integracjami? Jaki byłby sukces? To będzie moim celem w Kata.Potem zamierzam powiedzieć: jak daleko jestem od tego celu? Jaki jest obecny stan? Na przykład, jeśli chodzi o zwiększenie sprzedaży dla tych klientów przez ten marketing lub zwiększenie zasięgu – to mój cel. Jaki jest dzisiaj?

Potem zamierzam powiedzieć: co stoi w mojej drodze osiągnięcia tego celu? Czy to, że czegoś nie wiem? Czy to, że nasi użytkownicy nie robią czegoś? Czy to, że coś jest zepsute? Zamierzam to rozbić i patrzeć przez wszystkie pytania, które muszę odpowiedzieć.Potem mówię: co mogę zrobić, żeby nauczyć się więcej o tej przeszkodzie?

Na przykład, jeśli chodzi o klienta – nie mogą robić X, Y, Z, bo te elementy są zepsute – może mój następny krok to naprawić to w prosty sposób i zobaczyć, czy sprzedaż tam rośnie. Lub jeśli nie mam sposobu na robienie kampanii, może biorę to na siebie ręcznie, prowadzę eksperyment, prowadzę kampanie dla moich ludzi i zobaczę, czy dostaje nas bliżej celu w tym zakresie.

Potem iterujesz przez to, żeby zrobić pełne rozwiązanie do wyjścia. Zasadniczo przechodzisz przez Product Kata i po prostu rozbijasz: jaki problem rozwiązujesz na mniejsze kawałki, żebyś mógł zacząć priorytetyzować i rozgryźć, jak się uczysz o tym, a potem jak wracasz i dalej widzisz, czy osiągnąłeś ten cel.

Iteracyjne podejście

Drugi element, który Melissa kocha w tym: jest iteracyjny. Zawsze mówimy o tym, jak wypuszczamy V1 i nigdy do tego nie wracamy. Gdy podążasz za Product Kata, zawsze wracasz i mówisz: osiągnęliśmy nasz cel?

Kata działa w fazie odkrywania i po wdrożeniu, aby nie porzucać wersji 1.0 przed osiągnięciem celu.

Jeśli nie, to mówisz: jaki jest nasz następny krok? Co powinniśmy robić dalej, żeby faktycznie osiągnąć ten cel? Czego oczekujemy? Dlaczego tego nie zrobiliśmy? Czego się nauczyliśmy z tego? Pytania w środku są zawsze o uczenie się – czego się nauczyliśmy? Co myśleliśmy, że się stanie? Co się nie stało, dlaczego? Pytamy o to.

Mike Rother jest osobą, która napisała książkę Toyota Kata i wyjaśnia to. Pochodzi z perspektywy produkcji oczywiście z Toyota Kata, jednak jego książka Coaching Kata jest bardzo o tym, jak wdrażasz to w dół w organizacjach – jak jesteś liderem i próbujesz coachować swoje zespoły przez ten wzorzec i wypływać strategię i myśleć przez to.

Wszystko z tego faktycznie wraca do sposobu wdrażania strategii produktowej. To sposób na doprowadzenie ludzi do myślenia przez strategię, wracanie do niej. Gdy to widzę działać naprawdę dobrze w organizacjach, pytamy to dlaczego i pozwalamy ludziom wychodzić i rozumieć to. Potem wracamy mówiąc: to właśnie zamierzamy zrobić, żeby to osiągnąć.

Rzemiosło PM i współpraca

Kontekst zamiast mikro-specyfikacji

To duży temat, o którym Melissa mówi do nowych product managerów, szczególnie product owners, którzy przeszli przez szkolenie scrum i nic innego. Zazwyczaj to ludzie, którzy kończą brać jej zajęcia i wiele dużych organizacji, z którymi pracuje.

Widzi to też w mniejszych organizacjach – product managerowie. Ludzie ustawiają kontekst czasem, gdy patrzą na product managera: twoja praca to utrzymywać deweloperów zajętych.

To jest najgorszy kontekst, jaki kiedykolwiek możesz ustawić dla product managera. To nie twoja praca. Oczywiście będziesz utrzymywać deweloperów zajętych. Jeśli określasz zakres rzeczy i odkrywasz problemy i priorytetyzujesz je – to wynik z robienia twojej pracy. Deweloperzy będą zajęci.

Ale też mówi: dlaczego zatrudniamy deweloperów, którzy nie są tani, nawiasem mówiąc? Żaden deweloper nie jest tani. Potem nie ufamy im w podejmowaniu decyzji?

Jeśli dasz deweloperom właściwy kontekst, powinni móc podejmować bardzo małe decyzje o kompromisach. Duże decyzje o kompromisach też, szczerze, jeśli ustawisz ich dobrze. Zespół podejmuje drobne decyzje i może pisać historyjki użytkownika, gdy rozumie cel i ograniczenia.

Melissa mówi: najlepsza rzecz, którą możesz zrobić, jeśli czujesz się przytłoczony – dostaje wiele pytań w swoim podcaście o: hej, moi deweloperzy, chcą, żebym specyfikowała wszystko do najdrobniejszych szczegółów. Nie będą pracować nad niczym, chyba że jest super szczegółowo określone. Melissa: no cóż, co robisz, żeby budować kontekst z nimi, zanim dojdzie do rozbijania historii lub pracy w Scrum?

Co Melissa odkryła z wchodzenia do wielu organizacji i trenowania ich całych zespołów produktowych: szczególnie ludzie, którzy przychodzą z tła Scrum, skupiają się na wkładaniu historii w backlog. Nigdy jednak nie rozgryzają: jaka jest ta wizja produktu? Jak buduję kontekst o tym? Jak opisuję wszystkie problemy, które zamierzamy rozwiązać? Jak maluję obraz tego, co budujemy dla deweloperów, żeby gdy dojdzie do decyzji – zazwyczaj super prostej odpowiedzi – mogli po prostu zrobić to sami i dalej iść?

To część, gdzie wielu młodszych product managerów pomija. Po prostu nie budują kontekstu o tym, co robimy jako całość i gdzie idziemy z ich zespołami. Jeśli to zrobisz, faktycznie możesz tylko zaufać swoim deweloperom, żeby szli budować rzeczy.

Współpraca PM × UX

To samo z projektantami. Pracujesz z projektantami, upewniasz się, że rozumieją kontekst klientów. Często są zaangażowani w badania użytkowników, więc słyszą to. Mówisz im o priorytetach po stronie biznesu, mówisz im o kompromisach projektowych, mówisz im o tym, gdzie wiesz, co reszta zespołów robi. Pomagasz przynieść ten kontekst.

Współpraca PM × UX – praktyczne zasady:

• wspólne szkice i komentarze
• pełna edycja przez PM sensowna przy odpowiednich kompetencjach i małej skali
• w większej skali ustala się zasady pracy w Figmie (np. prawo weta po stronie UX)

Będą wychodzić i pomagać projektować to. Powinni pracować z inżynierem też, żeby upewnić się, że jest faktycznie możliwe do zbudowania. Mogą mieć tę rozmowę. Potem powinni pracować z tobą, żeby upewnić się, że spełnia potrzeby zarówno biznesu, jak i użytkowników w sposobie, w jaki zostanie dostarczone, w sposobie, w jaki zamierza działać ze wszystkim innym.

Gdy robisz to wszystko razem i budujesz ten kontekst, potem wszystkie zespoły mogą po prostu iść pracować. Mogą wykonać twoją pracę. Teraz się uwalniasz. Teraz nie tylko piszesz 10,000 user stories dziennie.

Szczerze, deweloperzy mogą pisać user stories, jeśli mają tyle kontekstu – pozwól im pisać user stories. Kogo obchodzi, kto pisze user story, tak długo jak rozumieją, dokąd idziemy? Możesz to sprawdzać, możesz wrócić i powiedzieć: tak, to właściwe.

Ale jeśli nie budujesz tego kontekstu, nie bierzesz czasu to robić – co wielu ludzi nie robi – tam będziesz dostawać się w ten tryb, gdzie po prostu odpowiadasz na pytania, jesteś reaktywny cały czas i nie możesz faktycznie być strategiczny.

Stan rynku product management

Wzrost 1999-2021 i szczyt w ZIRP

Melissa pamięta pracę w NYC w 2010s, gdy ludzie argumentowali z nią, że nie potrzebują product managerów. Dwa duże przesunięcia w 2010s sprawiły, że product management nabierało mocy:

Pierwsze: Wielu założycieli lub firm z Silicon Valley zaczęło przenosić się do innych miast i zakładać firmy tam. Przynieśli rolę product management ze sobą, zaczęli zatrudniać. Dostaliśmy wielką eksplozję startupów w NYC. Melissa pracowała w Silicon Alley – była w Flatiron. Mieli wszystkich obok, w górę i w dół ulicy – PM-i wszędzie.

Gdy się przeprowadziła do NYC, nikt nie wiedział, co robiła. Zawsze była: zamierzam iść do San Francisco, bo nikt nie wie, co robię tutaj. Zaczęli się przenosić, zaczęli zakładać nowe firmy, zaczęli eksplodować – jest więcej product managerów.

Drugie: Ten sam czas Agile pojawia się na scenie. Wszystkie te firmy zaczęły robić transformacje Agile, wszystkie przyjmują tę rolę product owner. Teraz nagle mamy – w błysku jednego roku – wyobraź sobie firmę z 45,000 ludzi. W jeden rok mogli stworzyć coś jak 5,000 ról product management.

Melissa mówi, że to się stało. W latach 2010. pojawiło się wielu w tych dużych organizacjach robiących masywne transformacje Agile, instantancznie tworzących role związane z produktem – niekoniecznie product manager, ale role związane z produktem.

ZIRP era (Covid i później):

Potem dostajemy się do Covidu i byliśmy w erze ZIRP. Nagle: och, nie mamy już darmowych pieniędzy. Co robisz, gdy nie masz już darmowych pieniędzy? Idziesz: och, musimy priorytetyzować.

Gdy rzeczy były udane jak w latach 2010., ludzie rozwijali się jak szaleni i nie priorytetyzowali. Wraca do strategii firmy – wielu ludzi nie podejmowało nawet strategicznych decyzji, ponieważ były tylko darmowe pieniądze, szczególnie z niskimi stopami procentowymi. To samo w erze Covid.

Wszyscy oczekiwali, że Covid zatopi kilka firm technologicznych. Dalej rosnęliśmy, ponieważ pieniądze były darmowe. Potem nagle, gdy pieniądze stają się ograniczone, wymusza to priorytetyzację. Gdy wymuszasz priorytetyzację, zdajesz sobie sprawę: hej, faktycznie nie potrzebuję wielu zespołów. Potem zaczynasz je zwalniać.

Korekta 2021-2024 – szczyt przypadł na około 2021 r.

Melissa widziała kilka rzeczy dziać się w erze post-ZIRP:

Wymusiło ludzi do bezwzględnego priorytetyzowania. Powinni byli robić to wcześniej, po prostu nie. Myśleli, że jeśli rzucę pieniądze na problem, rozwiążę go. Myśli, że był to duży strategiczny błąd wielu firm – wielu ludzi niechętnych do priorytetyzowania.

Dwa: Wiele z tych firm, które zaczęły swoje wczesne transformacje Agile, stały się bardziej dojrzałe. Wyszkoliły swoich ludzi produktowych, potem faktycznie połączyły kilka swoich produktów i wymyśliły dla tego strategię. Zdali sobie sprawę, że nie potrzebują tylu ludzi, co mieli.

Gdy reorganizowali, wiele firm, które Melissa widziała, szczególnie w przestrzeni Fortune 500, przemodelowywało z perspektywy komponentowej. Każdy produkt i każda funkcja miała product managera nad sobą. Kończyłeś z tymi ludźmi, którzy mieli tak mały zakres i niewiele do roboty, ponieważ albo nie było priorytetyzującej strategii, albo nie było zepsute. Po prostu tworzyli pracę.

Jak tylko dotarli do pewnego punktu w pewnej dojrzałości w tych większych firmach, myśli, że zdali sobie sprawę: och, nie potrzebuję robić wszystkiego z tego lub faktycznie mogę podnieść poziom moich ludzi produktowych nad większą funkcję. Nie potrzebuję wszystkich przy każdym małym komponencie. Wiele reorganizacji się wydarzyło – wielu ludzi zostało zwolnionych z powodu tego.

Trzy: Melissa była też w wielu firmach, gdzie podczas tych transformacji Agile – prowadziła ich ogromną ilość, trenując tych product managerów w

dużych firmach Fortune 50 z Product Institute – po części tego szkolenia, gdy ludzie są nowi w product management, mówią: och, nie chcę tego robić.

Melissa widzi to dziać się cały czas. Myśli, że bierzemy to za pewnik, jak zawsze słyszymy o ludziach, którzy zawsze chcieli być product managerem, bo chcą być mini-CEO. Jak tylko dostają się do roli, Melissa widzi wielu ludzi mówiących: nie chcę tego robić. Faktycznie to nie jest to, co myślałem, że to było. Myślałem, że po prostu mogę podejmować wszystkie decyzje. Nie zdawałem sobie sprawy, że muszę iść zajmować się wszystkimi tymi ludźmi i dopasowywać ich. Nie chciałem tego typu odpowiedzialności.

Melissa widzi też ludzi wycofujących się z tego, odchodzących od tego, ponieważ to ciężka praca. To masywna ilość pracy, masywna ilość umiejętności interpersonalnych. Pracujesz od 50 do 80 godzin tygodniowo – po prostu nie wyłączasz tego.

Melissa myśli, że wielu ludzi też wybiera wyjście z produktu, którzy mogli myśleć, że było bardzo efektowne i bardzo fajne. Teraz jak spędzili kilka lat w tym, byli jak: to naprawdę nie jest to, co myślałem, że będzie.

Inflacja wynagrodzeń w FAANG i jej konsekwencje

Melissa ma ogromną empatię dla ludzi po zwolnieniach z naprawdę dużych firm, jednak myśli, że Google, Facebook i Amazon trochę zrujnowały rynek product management.

Wpływ miały przeinwestowanie, zawyżone płace w big tech i zbyt wąskie zakresy ról, a później redukcje. Przeprowadzili zwolnienia, ale wcześniej zawyżyli pensje tak wysoko dla product managerów, że Melissa miała ludzi kończących Harvard MBA i nie mieli żadnego doświadczenia w product management. Dostawali pracę w jednej z tych wielkich firm i zarabiali prawie 300k dolarów rocznie.

300k dolarów rocznie w firmie growth-stage to jak pensja podstawowa CPO. Kto może sobie pozwolić na to? Jest tylko kilka Amazonów i Facebooków na świecie. Jest dużo więcej firm growth-stage.

Melissa czuje się źle mówiąc to tym biednym ludziom, którzy zostali zwolnieni z tych ról zarabiających kupę tych pieniędzy, ponieważ prawdopodobnie kupili domy na tym z tym kredytem hipotecznym i rzeczami. Ale to, co Melissa myśli, że widzimy teraz, to korekta rynku w realizację wartości dla tej roli. Bo 300k nie jest pensją individual contributor PM – nie powinno być.

Firmy growth-stage i mniejsze firmy i nawet po prostu normalnej wielkości przedsiębiorstwa – nie zamierzają płacić tego za individual contributor PM.

Dla ludzi, którzy szukają: To może być trudne, ale możesz potrzebować wziąć krok w tył, żeby zrobić krok do przodu w niektórych z tych firm. Mogą potrzebować wziąć obniżkę pensji, żeby to zrobić. Na początku Melissa rozmawiała z wieloma ludźmi, którzy nie byli skłonni tego robić.

Zdaje sobie sprawę, że wszyscy mają różne okoliczności finansowe. Ale jeśli naprawdę chcesz być realistyczny i chcesz dostać pracę teraz, to mniejsze firmy, które potrzebują pomocy, będą zatrudniać. Nie mówi: zejdź o 60k dolarów rocznie, ale musisz trochę ponownie ocenić, co miałeś vs co będziesz w stanie robić przez czas. Prawdopodobnie wrócisz tam.

Melissa jest trochę zła, szczerze, o to, jak źle myśli, że te duże firmy FAANG ustawiły product managerów przez przeszacowanie tego, próbując brać cały talent, a potem będąc jak: och, faktycznie nie mieliśmy nic dla nich do pracy, zwolnijmy ich. To było prawdopodobnie wygodne, gdy ludzie tam byli i było miło, jednak to nie była rzeczywistość. Teraz po prostu zostawiło wszystkich tych biednych ludzi w naprawdę trudnej sytuacji.

Melissa myśli, że zajmie chwilę wrócić z tego.

Zmiany w strukturze ról

Rola „menedżera 2–3 PM-ów” zanika; w praktyce to szeroki IC albo lider większego obszaru. Melissa wspomina konkretne liczby z Wharton, gdzie studiowała: poszło z czegoś jak 2% absolwentów do 16-17%. Investment banking i consulting były każde około 20%, więc PM prawie osiągnęło to i teraz wycofało się z powrotem do bardziej stabilnego, prawdopodobnie lepszego dla branży poziomu.

Harvard był taki sam. Wszystkie studentki Melissy chciały być product managerami – oczywiście uczyła product management, więc wszystkie jej studentki chciały być product managerami. Jednak pod koniec jej zajęć to samo się działo. Wielu z nich było jak: nie, myślę, że będę trzymać się consultingu lub sprzedaży. To naprawdę nie było to, co myślałam, że będzie.

Melissa myśli, że to uczciwe. To nie jest dla wszystkich. Nie myśli jednak, że będziemy mieć stosunek 1:1 product managerów do inżynierów, więc będzie dalej rosnąć.

Kontekst ma znaczenie

Kontekst ma znaczenie: nie każdy wzorzec product-led growth działa w każdym kraju (przykład Niemiec i niższej penetracji kart). Melissa daje świetny przykład. Pracuje z firmą w Niemczech teraz. Sposób, w jaki firmy w Niemczech kupują produkty, jest ekstremalnie inny niż sposób, w jaki robią to w USA. Modele product-led growth nie działają super dobrze w Niemczech, ponieważ większość ludzi nie ma karty kredytowej.

Tak – społeczeństwo oparte na gotówce nadal. Więc te typy rzeczy – jeśli patrzysz na to, jak inne firmy to zrobiły i tylko chcesz kopiować, nie rozumiesz głęboko kontekstu. To jest tak ważne, jeśli chcesz być bardziej strategiczny: musisz rozumieć kontekst i musisz chcieć rozumieć kontekst.

Melissa myśli, że product management będzie dalej rosnąć jako dyscyplina, prawdopodobnie trochę wolniej teraz. Są jednak nadal firmy bardzo wcześnie w swoich transformacjach cyfrowych. Są nadal firmy właśnie zaczynające wchodzić w oprogramowanie. Trudno uwierzyć czasem, bo pracujemy w oprogramowaniu cały dzień, ale są nadal firmy właśnie startujące.

Będą potrzebować product managerów. Będą potrzebować, miejmy nadzieję, doświadczonych product managerów też. Będą tworzyć rolę, miejmy nadzieję trenując swoich ludzi, potem miejmy nadzieję wprowadzając więcej product managerów. Potem będzie się rozwijać – tak to działa.

Nie wie, czy to wybuchowy wzrost, który będziemy widzieć jak zrobiliśmy z boomem Agile. Myśli jednak, że będziemy widzieć zapotrzebowanie na bardziej kompetentnych product managerów. Słyszy to już tam w świecie: potrzebuję ludzi, którzy wiedzą, co robią tutaj, którzy mogą naprawdę zagłębić się i rozumieć, że ich praca to rozgryźć, jaka jest wartość dla klienta, która zamierza napędzać tę wartość biznesową i składać to razem i przekształcać w rozwiązanie, dostarczać to.

Będziemy potrzebować więcej tych ludzi. Będziemy potrzebować więcej kompetentnych liderów produktowych też.

Jak młodszy PM może wpłynąć na strategię

Problem młodszych PM-ów

Melissa wspomina swoje początki: „Prawdopodobnie byłam jednym z tych PM-ów. Byłam w firmie na wczesnym etapie. Miałam trochę doświadczenia w product management, jednak byłam arogancka jak diabli i myślałam, że jestem niesamowitym product managerem.”

Prawdopodobnie myślała, że powinna być VP produktu. Patrzy wstecz na to teraz: była jak: człowieku, to było naiwne. Ilość tego, czego się nauczyła w ostatnich 15 lat od tego czasu, jest szalona. Nie miała pojęcia o żadnej z tych rzeczy, dopóki nie dostała ekspozycji.

Ale to nie znaczy, że nie możesz dostać ekspozycji. Nie znaczy, że nie możesz iść uczyć się od innych ludzi.

Diagnoza i studiowanie wzorców

Jeśli jesteś w tej pozycji i robiłeś to tylko kilka lat i dostajesz feedback, że nie jesteś strategiczny lub nie myślisz wystarczająco daleko do przodu: pierwsza rzecz, którą musisz zrobić, to wziąć krok w tył i powiedzieć: ok, czy to luka kompetencji? Czy to luka komunikacji? Czy to luka wiedzy? Co sprawia, że ludzie to mówią?

Czasem to luka kompetencji. Studiuj inne strategie. Melissa kocha obserwować inne firmy i jak rosną i co je napędza. Jak tam dotarły? Czy to faza product-led growth? Patrz jak Figma eksplodowało. Dlaczego Figma eksplodowało? Wow, wzięli ten problem, rozwiązali go niesamowicie. Potem zrobili to łatwo dla ludzi do wchodzenia i zaczynania używania tego – product-led growth.

Patrz na wzorce, potem wróć i zobacz, czy te wzorce stosują się do twojej firmy. Porównaj i zestawiaj.

Melissa lubi studiować wzorce. Robi to w sposobie, w jaki ludzie pracują, w sposobie, w jaki organizacje się rozwijają. Robi to we wszystkim. Jeśli zaczynasz widzieć wzorce w strategii, będziesz zaczynać łapać, co może działać dla twojej firmy vs co może nie działać.

Pisze świetny newsletter o wielu strategiach i jak ludzie to robią. Lenny pisze świetny newsletter na tym. Studiuj, co inni ludzie robią, słuchaj ich historii. Potem wracasz i próbujesz zastosować kontekst do tego.

Nie chodzi tylko o kopiowanie, co inne firmy zrobiły. Strategia product-led growth nie działa dla wszystkich. Nie kopiuj tylko, co te firmy zrobiły. Zamiast tego próbuj rozgryźć: dlaczego to zadziałało dla nich? Jakie były warunki dla sukcesu? Czy masz te warunki? Czy kierujesz się na tych samych ludzi? Czy idziesz za innym rynkiem, inną geografią?

Zagłębiaj się w to. Możesz obserwować to z wielu innych miejsc. Potem przynoś to z powrotem do twojej organizacji.

Zadawaj pytania (nie atakuj)

Co Melissa mówi wielu ludziom: gdy są sfrustrowani – faktycznie wysłała newsletter o tym dzisiejszego ranka – wielu ludzi dostaje frustrację, ponieważ strategie firm są niejasne lub raportują do ludzi, którzy nie mają bardzo silnej strategii. Rozpoznają to, rozpoznają, że jest luka i nie dostają, czego potrzebują.

Czasem nie wiedzą, czego potrzebują, ale po prostu wiedzą, że tego nie dostają. Wtedy, co im mówię, to: zacznij zadawać pytania.

To naprawdę łatwy sposób dla ciebie na zaangażowanie się, na zaczynanie rozumieć, co się dzieje i gdzie leżą priorytety w organizacji.

Ostatecznie to jest praca kadry kierowniczej do priorytetyzowania dużych inicjatyw dla firmy. Więc czy zgadzasz się z nimi, czy nie, będą priorytetyzować. Potem dostajesz zdecydować, czy chcesz tam być, czy nie. Możesz jednak rozgryźć, jakie są ich priorytety i możesz robić to przez zadawanie im pytań.

Hej, wiem, że naprawdę chcesz zbudować tę funkcję. Przekazałeś to w dół do mnie. Co myślisz, że się stanie? Co się stanie, gdy ją wypuścimy? Jakie metryki myślisz, że się zmienią? Czy to jak retention play, czy to growth play? Skąd o tym usłyszałeś? Z jakimi klientami o tym rozmawiałeś? Czy mogę skontaktować się z nimi, żebym mógł zobaczyć trochę więcej?

Bierzesz to z perspektywy nie kwestionowania. Melissa widziała wielu ludzi wracać do swoich liderów będąc jak: nie wiesz, co robisz, strategia jest do kitu. Faktycznie to widziała. To okropne. Nie rób tego. Naprawdę, nie.

Nie zacznij tylko krzyczeć, że twoi liderzy dają ci rozwiązania i nie dają ci problemów. Zamiast tego zadawaj pytania, bądź pokorny.

Co myślisz, że się stanie, gdy to zrobimy? Czego oczekujesz, że się stanie? Co masz nadzieję, że się stanie? Czy mamy jakieś metryki sukcesu? Jak wymyśliłeś ten pomysł? Powiedz mi trochę więcej o tym, bo desperacko tylko chcę zbudować właściwą rzecz.

To wszystko. Pokornie tylko pytam o więcej informacji, bo chcę upewnić się, że dostaję to właściwie dla ciebie i buduję ci właściwą rzecz. Dadzą ci jakieś informacje. Możesz nauczyć się, że są luki.

Gdy uczysz się, że jest luka – może nie przyszło od klienta lub powiedzmy przyszło od jednego dużego klienta – bierzesz inicjatywę, żeby zobaczyć, czy stosuje się do innych klientów. Dostałeś tę rzecz. Właśnie rozgryzłeś, jaki jest problem, który myśleli, że to zamierza rozwiązać. Tam product managerowie muszą brać inicjatywę, potem powiedzieć: zamierzam zwalidować to z innymi ludźmi i tylko upewnić się, że to działa na większą skalę i rozumiemy to dobrze.

Idź i to zrób.

Weź inicjatywę – historia z OpenSky

W wielu firmach Melissa słyszy product managerów mówiących: nie mam czasu na odkrywanie, nie mam czasu robić wszystkie te rzeczy. Stwórz czas. Weź jakąś inicjatywę, żeby wyjść tam i rozgryźć, czy to właściwa rzecz do zbudowania.

Melissa robiła to dużo we swoich młodszych latach, gdy była individual contributor product manager i działało. CEO dawał jej funkcje do zbudowania. Byłaby jak: ok, co myślisz, że to zrobi? Powiedziałby jej. Potem po prostu szłaby prowadzić wiele eksperymentów.

Potem wracała będąc jak: nie zadziałało. Możemy o tym porozmawiać? Byłby jak: och wow, definitywnie myślałem, że to zadziała. Była jak: po prostu nie działa. Ale znalazłam coś, co zadziałało. Czy chcemy zrobić – tak, idź zrób to zamiast tego. Po prostu chciałem zrobić tę rzecz.

Te rzeczy zaczynają wyłaniać rozmowy. Faktycznie Melissa właśnie dowiedziała się – to jest historia z OpenSky. Gdy tam była, to ponad 10 lat temu teraz. Miała to, gdzie CEO dawał im – dawał jej wiele funkcji do zbudowania. Szłaby je testować i prowadziła wiele eksperymentów na tym. Wszystkie jej eksperymenty, które miały zwiększać sprzedaż, kończyły się niepowodzeniem.

Co dowiedziała się później – ponieważ nie słyszała o tym w tym czasie. Powiedziała, była arogancką małą individual contributor i była jak: zamierzam pójść dalej na większe i lepsze rzeczy, poszła gdzie indziej.

Cała ta rozmowa, wszystkie jej eksperymenty faktycznie spowodowały pivot całej firmy. Potem została sprzedana do Alibaby. Jej rzeczy połączone z innymi rzeczami, których się uczyli, sprawiły, że spojrzeli na to mówiąc: hej, nie wiem, czy to jest zrównoważone, powinniśmy patrzeć na inny pivot. Zrobili ten pivot z firmą, potem ją sprzedali do Alibaby.

Rzeczy, które robisz jako individual contributor PM – ma znaczenie. Ale ma znaczenie, jeśli dostajesz to w ręce właściwych ludzi. Patrzy wstecz na to mówiąc: OpenSky był jednym z najlepszych zespołów, z którymi kiedykolwiek pracowała. To było tylko wszystko w retrospektywie, ponad 10 lat później.

Teraz może wrócić i zobaczyć wszystkie elementy składające się, ale po prostu nie mogła widzieć tego, gdy była individual contributor.

Komunikacja strategii – ile razy powtarzać

Melissa śmieje się czasem, gdy liderzy są jak: człowieku, powiedziałem to milion razy. Dlaczego muszę powiedzieć to milion i jeden?

To dlatego, że reszta firmy nie robiła pracy wymyślania strategii. Zazwyczaj nie byli tak mocno zaangażowani. Ludzie, którzy nie byli tak mocno zaangażowani, tak to ujmijmy – nie mają tyle kontekstu, co ty masz.

Jeśli nie powtarzasz się sto razy, to nie wsiąka w innych ludzi. To dlaczego jako liderzy musisz powtarzać raz za razem i upewniać się, że jest przyswajalne na różne sposoby. Tam wszystkie te narzędzia komunikacji stają się naprawdę ważne.

Pięć praktycznych checklistów

1. Strategia i wdrożenie

• 3–5 strategic intents na 12–24 mies.
• metryki i hipotezy dojścia dla każdego intentu
• jawna lista „stop doing” na poziomie firmy i produktów
• stała kadencja góra–dół do uzgodnień wykonalności
• ten sam kierunek komunikowany różnymi formami

2. Portfolio

• rola każdego produktu w tworzeniu wartości jest jasna
• zdefiniowane przepływy danych między produktami i ich wpływ na wartość
• świadoma decyzja „platforma czy produkt”

3. Priorytety przez Cost of Delay

• oszacowany wpływ i czas dla kluczowych inicjatyw
• porównane scenariusze kolejności (A→B vs B→A)
• ocenione profile opóźnień (terminowy vs liniowy)
• macierz wpływ × pilność z uwzględnieniem okien rynkowych

4. Pętla Product Kata

• cel inicjatywy jest mierzalny i znany zespołowi
• aktualna lista przeszkód i zależności
• zdefiniowany najbliższy krok i termin przeglądu nauki

5. Product Ops

• stały dostęp do głosu klienta i danych o użyciu w jednym widoku
• standard rezultatów i map drogowych na poziomie organizacji
• automatyzacja powtarzalnych zapytań danych
• zakres: wsparcie decyzji, nie „policja procesu”
• start możliwy od jednej osoby; skala rośnie wraz z portfolio

Kluczowy insight

Dodaj wartość przez odejmowanie

Standardowo myślimy: im więcej równoległych inicjatyw i większy backlog, tym szybciej dowieziemy wartość.

W praktyce okazuje się, że: mniej inicjatyw ułożonych według kosztu opóźnienia daje wcześniejszy efekt biznesowy.

Dlaczego to jest istotne: nadmiar prac w toku maskuje złe wybory i przesuwa wpływ przychodowy.

Test na jutro: Planując sprint lub kwartał, zamiast dopisywać kolejne zadania, ułóż top-10 inicjatyw w macierzy wpływ × pilność, usuń trzy najsłabsze, a kolejność reszty ustaw według kosztu opóźnienia; zweryfikuj czas do pierwszego mierzalnego wyniku.

Polecane książki i zasoby

Z autorstwa Melissy:

• „Escaping the Build Trap” – główna książka o wychodzeniu z pułapki budowania
• „Product Operations” – o tym, kiedy i jak ustawiać Product Ops

Od innych autorów:

• „Toyota Kata” – Mike Rother (o metodzie Kata z perspektywy produkcji)
• „Coaching Kata” – Mike Rother (jak wdrażać Kata w organizacjach, wdrażanie strategii)

Inne inspiracje wymienione:

• Hoshin Kanri (proces wdrażania strategii)
• John Cutler (koncepcja Feature Factory)
• Joshua Arnold / Black Swan Farming (cost of delay w product development)
• Lenny Rachitsky (newsletter o produkcie i wzroście)
• Gibson Biddle (modele Gibbs – były VP Netflix, strategia)

Podsumowanie

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów, webinarów i innych treści wartościowych do późniejszego wykorzystania. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Product Growth Podcast – Everything You Need to Know About Product Strategy with Melissa Perri