Product Management w erze AI: Dlaczego najlepsi menedżerowie wracają do ról specjalistycznych #EN369

Uwaga wstępna: Poniższy tekst to zestaw notatek z rozmowy Gokula Rajarama w podcaście „Product Thinking” (prowadzony przez Marka i Bena). Wszystkie przemyślenia, obserwacje i rekomendacje pochodzą bezpośrednio od rozmówców. Artykuł ma charakter stenogramu ich dyskusji, nie własnej analizy autora notatek.

TL;DR

Równanie przewagi się zmieniło: Pojedynczy specjalista z zespołem agentów AI może wykonywać pracę 10-osobowego zespołu
Wiarygodność wymaga doświadczenia: Bez pracy w środowisku natywnie opartym na AI trudno zbudować kredybilność jako lider w firmach przyszłości
Największy problem rekrutacyjny: Firmy AI nie mogą znaleźć Head of Product, ponieważ kandydaci nie mają doświadczenia z generatywną AI
Rezultaty dla klienta > wypuszczenie produktu: Wypuszczanie bez jasnej hipotezy o zmianie zachowania klienta to marnowanie zasobów
Ścieżka rozwoju ważniejsza niż status: Lepiej być PM w rosnącej firmie niż VP w stagnującej
Pierwsze 60 dni = pierwsze zwycięstwo: Organizacja ocenia nowych pracowników po pierwszym sukcesie, nie po ilości spotkań
Niska ego, wysoka energia: Najszybsza ścieżka do sukcesu to branie na siebie tego, czego inni się boją

Kontekst: Exodus z zarządzania do ról specjalistycznych

Po dekadzie taniego pieniądza i rozbudowanych struktur zarządzania (era ZIRP – Zero Interest Rate Policy), rynek technologiczny przechodzi fundamentalną transformację.

Gokul Rajaram to były product leader w Google (AdSense), Facebook (Ads) i Square. Obecnie zasiada w radach nadzorczych Coinbase, Pinterest i The Trade Desk oraz aktywnie inwestuje w startupy. Jego perspektywa łączy doświadczenie operacyjne z widokiem inwestora na setki firm.

Zaobserwowany przez niego trend jest nietypowy. Doświadczeni liderzy – dyrektorzy czy wiceprezesi – którzy przez ostatnie 10 lat wspinali się po szczeblach zarządzania, teraz aktywnie szukają ról specjalistycznych (individual contributor – IC). Dzieje się to szczególnie w firmach natywnie opartych na AI, gdzie oczekuje się „zakasania rękawów” i bezpośredniej pracy z technologią.

Dlaczego teraz to dobry moment na powrót do roli specjalisty

Według Rajarama, wszystko zaczęło się od rozmów z ludźmi z jego orbity. Jedna obserwacja to ciekawostka. Natomiast dwie lub trzy to już schemat.

Kilka osób, które wcześniej prowadziły zespoły jako menedżerowie menedżerów, zaczęło prosić go o referencje do ról specjalistycznych. Zaintrygowało go to.

Zmiana równania przewagi

Rajaram zauważa fundamentalną zmianę w produktywności specjalistów. Narzędzia AI (do kodowania, pisania, analizy) sprawiły, że pojedynczy pracownik może być wielokrotnie bardziej produktywny. Być może nie dokładnie dziesięciokrotnie, ale na pewno kilka razy.

Wcześniej menedżer zarządzający 10 osobami, które zarządzały kolejnymi 10, mógł mieć wpływ na pracę 100-200 ludzi. Teraz specjalista, który zbuduje zestaw dobrze wytrenowanych agentów, może wykonywać pracę 10-osobowego zespołu.

Różnica między wysoko wydajnym specjalistą a menedżerem zwęziła się pod względem rezultatów.

Wiarygodność w firmach natywnie opartych na AI

Drugi argument jest jeszcze mocniejszy. Jeśli nigdy nie pracowałeś w środowisku AI, trudno będzie zaakceptować cię jako wiarygodnego w firmach natywnie opartych na tej technologii.

Większość z nas za 10 lat będzie pracować w jakiejś formie takiej firmy. Dla osób z dwoma latami do emerytury to nieistotne. Jednak jeśli chcesz pracować kolejne 10-20 lat, niemądre jest ignorowanie długoterminowej perspektywy.

Umiejętność zarządzania ludźmi nigdzie nie zniknie. Trzeba być bliżej pracy. W erze AI wszystko się spłaszcza – będziesz zarządzać większą liczbą specjalistów lub agentów, a nie menedżerami. Pracownicy indywidualni cenią sobie menedżerów, którzy sami wykonywali tę pracę. Jeśli jako manager potrafisz zakasać rękawy i dostarczyć wyniki bezpośrednio (albo pokazałeś, że kiedyś to robiłeś), lepiej połączysz się z zespołem i lepiej zrozumiesz, jak nimi zarządzać.

Największy problem rekrutacyjny dekady: Head of Product w erze AI

Dyrektorzy generalni firm natywnie opartych na AI przychodzą do Rajarama z tym samym problemem. Najtrudniejsza rola do rekrutacji to dziś Head of Product.

Dlaczego? Bo nie mogą już po prostu wybrać product leadera „z taśmy produkcyjnej” Google, Facebooka czy innej dużej firmy. Ci ludzie dorastali w erze, gdzie AI oznaczało machine learning i predykcyjną sztuczną inteligencję, nie generatywną AI.

Rada: Promuj z wewnątrz

Rajaram ma konsekwentną radę dla założycieli: promuj z wewnątrz.

Często widzi, że założyciele próbują zatrudnić Head of Product za wcześnie. Mają tylko dwóch PM. Po co im menedżer dla dwóch osób?

Jego zalecenie w trzech krokach:

Zatrudnij senior PM, który pracował 2-3 lata w firmie natywnie opartej na AI
Niech przyjdzie i robi pracę jako specjalista
Dopiero jak urośniesz do trzech PM, rozważ wypromowanie któregoś na menedżera

Pojawia się jednak pytanie: czy w ogóle potrzebujesz menedżera? Dlaczego nie możesz sam nimi zarządzać jako założyciel?

Założyciel musi najpierw nauczyć się funkcji

Rajaram mocno wierzy, że jako założyciel musisz najpierw nauczyć się zarządzać różnymi funkcjami osobiście, żeby wiedzieć, kogo zatrudniać.

Zbyt często zatrudnia się ludzi bez jasnego wyobrażenia, czego się oczekuje.

Zna założyciela, który niestety zwolnił CFO, CMO, CRO, CPO i jeszcze jedną osobę (łącznie pięć kluczowych ról). Zatrudniał źle, potem zwalniał, następnie musiał przez sześć miesięcy robić ich pracę. Dopiero wtedy nauczył się, kogo powinien zatrudnić. Wtedy zatrudnił właściwą osobę.

Nowe kompetencje PM w erze AI

Według Rajarama, dobre wieści są takie, że osąd sytuacji (który zawsze był ogromną częścią roli PM) pozostaje kluczowy.

Osąd i wpływ nie do zastąpienia

Każdy z nas, mając produkt, mógłby w pół godziny wymyślić może 100 pomysłów, jak go ulepszyć. Osąd polega na wyborze, które z tych pomysłów rzeczywiście przesuwają firmę i produkt do przodu. Które najlepiej rozwiązują ból klienta.

Jak je sekwencjonować? W jaki sposób wpłynąć na resztę organizacji, żeby się zgrała, że to właściwa rzecz do zrobienia?

Osąd i wpływ to rzeczy, których nie można łatwo oddelegować maszynom.

Execution radykalnie się zmienia

Natomiast wykonanie to miejsce, gdzie AI naprawdę zmienia grę.

Rajaram obserwuje fundamentalną zmianę. Microsoft miał model kaskadowy w latach 80., gdy wymyślono tam rolę program managera. Google w latach 2000. uczyniło PM bardziej zwinnym, z PRD (Product Requirements Document) jako żywym dokumentem, stale iterowanym z zespołem inżynierów.

Teraz sam dokument się przesunął. Zamiast długiego dokumentu jakiegokolwiek rodzaju, masz bardzo krótki dokument kontekstowy plus prototyp.

Potrzebny jest ktoś, kto rozumie, jak wykonywać pracę z inżynierami używając narzędzi AI. Ktoś, kto jeśli trzeba, może przejąć część innych ról – wziąć system projektowy firmy i stworzyć nowy prototyp. Pokazać, co ma być zbudowane, nie przez słowa, ale przez obrazy. Bardzo szybko i w formie prototypu.

Anegdota: Pierwszy PRD w Google

Rajaram wspomina własne doświadczenie z 2003 roku. Napisał pierwszy PRD w Google – był bardzo zły, skupiał się na schemacie bazy danych i szczegółach technicznych zamiast na wartości dla klienta.

Jonathan, wiceprezes ds. produktu, rozesłał go do CAŁEJ firmy Google jako wzór „tak powinien wyglądać PRD”. Dlaczego? Bo Google nigdy wcześniej nie miało PRD. Rajaram wprowadził tę praktykę, mimo że jego pierwszy dokument był daleki od idealnego.

Konwergencja czterech ról w dwie osoby

Rajaram identyfikuje cztery role poza inżynierią: analityk, projektant, product manager, frontend developer. Backend developer to nieco inna kategoria.

Te cztery role ostatecznie zbiegną się w dwie. Być może z czasem w jedną, ale na razie dwie wydają się bardziej wykonalne. Jedna osoba w czterech rolach to duże wyzwanie. Dwie osoby w czterech rolach – możliwe do zarządzania.

Dlaczego dwie? Bo projektanci – potrzeba kogoś z okiem do designu. Jako PM musisz pomyśleć o swojej supermocy.

Są różne archetypy PM w zależności od tego, skąd pochodzą:

Marketerzy → PM: Mogą pokryć marketing + PM
Analitycy → PM: Mogą pokryć analizę + PM + frontend
Inżynierowie → PM: Mogą pokryć frontend + PM
Projektanci → PM: Mogą pokryć projektowanie + PM + frontend

Jeśli jesteś projektantem, który został PM, możesz być teraz jednocześnie projektantem i PM. Analogicznie jeśli byłeś analitykiem – możesz być analitykiem i PM. Te trzy role mogą faktycznie zbiec się.

W efekcie masz dla wielu zespołów może jednego dedykowanego projektanta, który ustala systemy projektowe, upewnia się, że wszystko działa razem, prowadzi przeglądy projektowe. Nie potrzebujesz już dedykowanego projektanta na zespół, dedykowanego frontend developera na zespół, dedykowanego analityka na zespół.

PM staje się zastępcą, który wskakuje i wykonuje różne role.

Ale: głos klienta nie może zniknąć

Rajaram ma jednak obawy. Im więcej czasu spędzasz na wykonaniu, tym mniej na tym, czego interesariusze od ciebie oczekują najbardziej: znasz klientów.

Musisz rozmawiać z klientami, rozumieć ich bolączki lepiej niż ktokolwiek w firmie. Jeśli spędzasz za dużo czasu na wykonaniu, to sztuka równoważenia.

Rajaram nie był bardzo kwantytatywnym PM, gdy zaczynał na początku lat 2000. (bo narzędzi nie było). Spędzał mnóstwo czasu rozmawiając z klientami.

Dzisiejsi PM są tak dobrzy w analizie, że stracili sztukę rozmów z klientami. Wielu po prostu przegląda recenzje w sklepie aplikacji i myśli, że to wystarczy. Zamiast iść i przeprowadzać wywiady, wydobywać historie o doświadczeniach.

To zanikająca sztuka. Rajaram obawia się, że im więcej ludzie spędzają czasu na wykonaniu, tym bardziej stracą umiejętność rozmawiania z klientami i wydobywania tego, co naprawdę się liczy.

Rezultaty dla klienta jako jedyna miara sukcesu

Około 10 lat temu, gdy Rajaram dołączył do Square, żeby prowadzić produkt, design i inżynierię, zauważył coś istotnego. Wiele zespołów produktowych i inżynieryjnych świętowało wypuszczenie produktu jako metrykę.

Wysłaliśmy coś – hurra!

Square podjęło mocną decyzję: nie będziemy już świętować wypuszczeń. Wypuszczenie to nie sukces.

Rezultaty dla klienta ≠ rezultaty biznesowe

Rajaram podkreśla subtelną, ale kluczową różnicę. Rezultaty dla klienta to nie to samo co rezultaty biznesowe.

Rezultaty dla klienta to zmiany zachowania klienta. Żaden rezultat biznesowy nie dzieje się bez zmiany zachowania klienta. Klient zmienia zachowanie z nie-bycia-klientem na bycie klientem. Z bycia odchodzącym klientem na reaktywowanego. Ze sporadycznego na lojalnego. Z używania pewnej rzeczy na nie-używanie. Lub odwrotnie.

To wszystko zmiany, które można potem powiązać z metryką biznesową.

Zadanie numer jeden dobrego product leadera lub PM: wymyślić właściwe rezultaty dla klienta, które czysto mapują się na rezultaty biznesowe.

Następnie: co możemy zbudować, żeby przesunąć te rezultaty? Jakie mamy opcje? W jaki sposób je priorytetyzować – ICE, RICE, cokolwiek.

„Czy funkcja naprawdę się wypuściła?”

Rajaram stawia prowokacyjne pytanie: „Jeśli funkcja się wypuściła, ale żadne zachowanie klienta się nie zmieniło – czy funkcja naprawdę się wypuściła?”

Analogia do drzewa w lesie – jeśli spadnie i nikt tego nie usłyszy, czy spadło? Jeśli nie zmienił się sposób zachowania, funkcja jest bezużyteczna i powinna być usunięta.

Test dla CEO: „Dlaczego wypuszczacie tę funkcję?”

Według Rajarama, wielu dyrektorów generalnych nie wie, jak właściwie współpracować ze swoimi zespołami produktowymi.

Jego rada: musisz zadać tylko jedno pytanie – „dlaczego?”

Dlaczego wypuszczacie tę funkcję? Jeśli nie mogą powiedzieć, jaki rezultat dla klienta ta rzecz zmieni, albo nie mają jasnej hipotezy – musisz to zatrzymać. Musisz powstrzymać ich od wypuszczania.

Szczególnie w erze AI wiele zespołów myśli o wypuszczaniu szybko i z wysokim tempem jako oznace sukcesu. Rajaram twierdzi, że to przeciwieństwo sukcesu.

Jeśli wypuszczasz za dużo rzeczy, nie masz czasu nawet stworzyć hipotezy. Zalewasz klientów bylejakością – mnóstwem funkcji. Najlepsze produkty usuwają funkcje zamiast je dodawać. Wszyscy możemy wymyślić 100 funkcji, ale najlepsze produkty, których używamy, mają minimalne funkcje.

B2B SaaS: Przychody to nie wszystko

Rajaram ma szczególne ostrzeżenie dla firm B2B SaaS. Największe niebezpieczeństwo to myślenie o „zarezerwowanych przychodach” jako głównej metryce.

Przychody to wskaźnik opóźniony. Wskaźnik wyprzedzający to UŻYCIE produktu.

Przykład: instancje Salesforce i innych tradycyjnych firm software – połowa licencji jest nieużywana w większości firm. Ludzie kupują, bo myślą, że powinni, jednak nie używają produktu.

Jeśli ktoś nie używa produktu regularnie (codziennie, co tydzień, cokolwiek jest odpowiednie dla tego typu produktu), to jest sygnał ostrzegawczy. Brak użycia oznacza prawdopodobnie odchodzącego klienta.

Nie możesz używać tylko przychodów jako wskaźnika sukcesu w B2B SaaS. Musisz rozumieć, jak ludzie używają produktu.

Studium przypadku: Test baristy w Square POS

Jeden z produktów, które Rajaram zawsze podziwiał jeszcze przed dołączeniem do Square: point of sale.

Przed Square barista musiał być szkolony przez kilka dni. Nawet dziś w wielu miejscach widać ludzi w trakcie szkolenia. To oznacza, że produkt nie jest wystarczająco dobry, żeby ktoś mógł go po prostu użyć.

Square? Po prostu ściągasz ze sklepu aplikacji i zaczynasz używać.

W kawiarni na Facebooku 12 lat temu był Square POS. Rajaram rozmawiał z baristami. Mówili: w poprzednich kawiarniach zawsze musieliśmy przejść kilkudniowe szkolenie na systemie kasowym. Ten? Nikt mnie nie szkolił. Po prostu zacząłem go używać.

Test baristy dla twojego produktu: czy klient może osiągnąć swój cel bez szkolenia?

Kultura eksperymentów: DoorDash jako punkt odniesienia

Rajaram chwali DoorDash za podejście do rezultatów dla klienta. Byli w tym doskonali – zawsze, nawet dziś.

Można argumentować, że wypuszczenie funkcji to zła rzecz, bo zakłada, że funkcję się „wypuszcza”. Natomiast każda funkcja to eksperyment, żeby udowodnić hipotezę o zachowaniu klienta.

Jeśli tak, to eksperyment powinien zawsze być uruchomiony na podzbiorze populacji, na grupie kontrolnej.

To zmiana nastawienia. To są eksperymenty. To są hipotezy. I powinieneś zapytać: dlaczego ta hipoteza w ogóle istnieje? Dlaczego myślisz, że ten eksperyment, dlaczego ta hipoteza jest ważna? Jakie dane masz?

Hipoteza powinna być oparta na wywiadach z klientami, zaobserwowanych zachowaniach. Przynajmniej kładziesz to na papier.

Następnie uruchamiasz eksperyment. Nie poddajesz całej bazy klientów temu eksperymentowi – tylko 5-10%, cokolwiek jest statystycznie istotne. Widzisz zmianę zachowania. Jeśli jest znacząca – wdrażasz stopniowo przez kilka dni.

Jeśli nie jest znacząca – masz obowiązek jako osoba produktowa zrozumieć dlaczego. Mieliśmy te założenia, że uruchomienie eksperymentu udowodni hipotezę. Dlaczego się nie stało?

Musisz dotrzeć do przyczyny źródłowej. Nie możesz być leniwy i powiedzieć: porzucam tę linię myślenia i przechodzę dalej. Musisz poświęcić czas.

DoorDash: Skupienie na przyczynach źródłowych

Mark wspomina, że przygotowują przewodnik do procesu rekrutacji PM w DoorDash. Co jest interesujące w porównaniu do Meta: w rozmowach o wyczuciu produktowym DoorDash bardzo mocno skupia się na rozpakowywaniu problemów, wskazywaniu PRZYCZYN ŹRÓDŁOWYCH i tworzeniu bardzo konkretnych rozwiązań dla jasno określonych przyczyn.

Ta umiejętność dotarcia do sedna problemu (nie powierzchownej analizy) jest bardzo ceniona w DoorDash. Widać to w produkcie. Gdy Rajaram zamawiał DoorDash wieczorem, dostał powiadomienie: masz 10 minut, żeby dodać lody z miejsca, które bardzo lubi. Jasny wyzwalacz behawioralny. Czy mamy lody w lodówce? Nie. Łatwo dodać. Klik. Zamówienie przyjdzie z lodami.

Ten maniacki nacisk na zmianę zachowania przebija przez produkt.

Tak budujesz zaufanie z interesariuszami. Doprowadzając do końca. Rozumiejąc – mieliśmy to założenie, okazało się nieprawdziwe. Docierasz do przyczyny źródłowej. Japończycy pytają „pięć razy dlaczego”.

Nie możesz po prostu przejść do następnego eksperymentu. Musisz kilka razy to przeprowadzić do końca. Czasem iteracja prowadzi do najlepszych odkryć.

Modele cenowe oparte na rezultatach: Dlaczego to trudniejsze niż się wydaje

Rajaram i prowadzący dyskutują o modelach cenowych opartych na rezultatach jako idealnym modelu w erze AI. Wyrównuje motywacje między klientem a firmą.

Jest jednak problem: możesz przejść na cenę opartą na rezultatach tylko wtedy, gdy masz pełną kontrolę nad rezultatem.

Ewolucja modeli cenowych

Rajaram obserwuje przejście przez trzy etapy:

Cena za stanowisko → Cena za użycie → Cena za rezultat

Im więcej masz atrybucji (im lepiej możesz przypisać rezultat do swojego produktu), tym łatwiej przejść do ceny opartej na rezultatach.

Przykład: Dlaczego Google nie przeszło na koszt za konwersję

Google nigdy nie przeszło na koszt za konwersję jako model cenowy dla reklam. Dlaczego?

Jedyne, co mogą kontrolować, to wykwalifikowane kliknięcie, które dostarczają. Ale co jeśli twoja strona jest źle zaprojektowana? Co jeśli wszystkie inne elementy doświadczenia są złe?

Od klienta zależy, czy weźmie wykwalifikowane kliknięcie i przekształci go w konwersję. Google nie może brać odpowiedzialności za rzeczy poza swoją kontrolą.

Gdzie cena za rezultat działa: Wsparcie klienta

Zautomatyzowane wsparcie klienta to miejsce, gdzie cena oparta na rezultatach działa świetnie. Dlaczego? Bo jest znacznie więcej kontroli – system działa na autopilocie.

Dlatego widać firmy jak FIN, Sierra, Intercom przechodzące na „dolary za rozwiązane zgłoszenie”. To cena oparta na rezultatach, która ma sens.

Gdzie to (jeszcze) nie działa: Asystenci kodowania

Cursor nie będzie naliczać opłat jak pensja inżyniera (cena oparta na rezultatach za „zaimplementowaną funkcję”). Dlaczego? Bo to IDE używane PRZEZ inżynierów. Nie mają pełnej kontroli.

Natomiast Devon (Cognition), Factory AI – to inny model. To autonomiczni inżynierowie. Oni mogą przejść na bardziej rezultatowy model cenowy, bo robią pracę od początku do końca.

Cursor używany w różnych trybach niż autonomiczne kodowanie. Dlatego różne modele cenowe.

Podsumowanie: Niemal wszystko zaczyna się jako cena za stanowisko. Gdy zyskujesz pewność w produkcie, lepiej rozumiesz kontekst, lepiej rozumiesz, co kontrolujesz – przesuwasz się w stronę ceny za rezultat. Ale nie możesz iść do ceny za rezultat, jeśli nie kontrolujesz rezultatu.

Jak wybrać firmę w erze AI

Jeśli rozważasz powrót do roli specjalisty albo wybór nowej firmy, Rajaram ma jasne ramy decyzyjne.

1. Dopasowanie misji (a właściwie: dopasowanie do bólu)

Pierwsza rzecz: czy firma ma misję, która rezonuje z tobą osobiście?

Rajaram się koryguje – może nie tyle misja, co coś bardziej pragmatycznego. Czy wierzysz w ból, który produkt rozwiązuje? Czy ten ból jest realny? Namacalny? Czy byłbyś podekscytowany byciem częścią tego przez kolejne X lat?

Musisz spojrzeć poza „atrakcyjność” pracy w tej firmie. Na co dzień – czy będziesz budować coś, w co wierzysz?

Jako osoba produktowa, miejmy nadzieję, że wyszedłeś i rozmawiałeś z potencjalnymi klientami tej firmy. Albo sam jesteś klientem. Rozumiesz produkt namacalnie.

Przykład: jeśli nigdy nie pisałeś kodu i chcesz dołączyć do Cursor jako PM – to może nie być dobre dopasowanie. Po prostu nie rozumiesz z zewnątrz, jaki jest ból.

Czy jest zgodne z tym, w co wierzysz? Czy wierzysz w to, co firma robi? Jeśli nie – nie dasz z siebie wszystkiego.

Mały test: jeśli firma buduje produkt dla księgowych, a nigdy nie siedziałeś z księgowymi – księgowi to unikalna kategoria osób. Albo dla firm HVAC. Jeśli dołączasz do firmy i twoją pracą są codzienne rozmowy z firmami HVAC – czy potrafisz to robić?

Powinieneś poświęcić czas, żeby spędzić go z firmami HVAC wcześniej i zobaczyć, czy chcesz to robić przez kolejne X lat.

2. Ścieżka rozwoju ważniejsza niż status

Rajaram ma ostrzeżenie: nie możesz patrzeć na firmę lub swoją rolę tak, jak istnieją dziś. Czy firma jest na dobrej ścieżce rozwoju?

Studium przypadku, które podaje, jest brutalne. 20 lat temu przyjaciel Rajarama wybrał stanowisko wiceprezesa ds. produktu w Yahoo zamiast roli Product Managera w Google.

W 2001 roku wydawało się to racjonalne. Yahoo było królem – firma za 100+ miliardów dolarów. Google było bardzo młode, niejasne. Mieli świetną technologię, oferowali jednak jedną z pierwszych ról PM. Druga firma oferowała stanowisko wiceprezesa.

Przyjaciel wybrał Yahoo. Nie patrzył na ścieżkę rozwoju firmy.

Musisz zachowywać się jak inwestor venture capital. Inwestujesz swoją karierę w tę firmę. To nieodwracalna decyzja. Jaka jest ścieżka rozwoju każdej firmy?

Gdy firma osiągnęła plateau, tort się nie powiększa albo kurczy. Wszyscy walczą o kawałki. Jeśli firma rośnie – zawsze jest więcej dla wszystkich.

Rajaram nie może przeliczyć, ilu dobrych ludzi po prostu awansowało i zyskało większą odpowiedzialność tylko dlatego, że byli w szybko rosnącej firmie. Nikt nie ma czasu walczyć. Wszyscy są zajęci robieniem rzeczy.

Chcesz firmy, która się rozszerza, rośnie – nie stagnuje ani kurczy.

3. Gęstość talentów

Według Rajarama, jedną z kluczowych rzeczy w ścieżce rozwoju jest gęstość talentów.

Przykład: Ramp. W swojej istocie robi coś nudnego – korporacyjne karty kredytowe. Mają jednak niewiarygodną gęstość talentów.

Były badania pokazujące, że liczba przedsiębiorców wychodzących z Ramp jest ekstremalnie wysoka. Jeden na X PM zostaje założycielem. To dobry sygnał talentu. Palantir – kolejny przykład gęstości talentów.

Chcesz być wokół ludzi, gdzie ludzie będą odchodzić i robić świetne rzeczy po tej firmie. Dlaczego to się liczy?

Wtedy masz adwokatów, którzy wyjdą w świat, będą pracować w innych świetnych firmach i będą cię przyciągać. To efekt znany jako „mafia PayPala” – gdy gęstość talentów buduje cały ekosystem przedsiębiorców i liderów.

Rajaram to doświadczył. Główny powód dołączenia do Facebooka: pracował z wieloma kolegami w Google, którzy poszli do Facebooka, włącznie z Sheryl Sandberg. Ona go przyciągnęła, wspierała, żeby dołączył.

Dołączył do Square, bo kolega z Google, Ajit, powiedział Jackowi Dorseyowi, że Rajaram jest jednym z najlepszych product people, z którymi pracował. Potem rekrutowali go do Square.

Gdy pracujesz w miejscu z wysoką gęstością talentów i robisz dobrą robotę, masz adwokatów, którzy wyjdą w świat i będą cię przyciągać do kolejnych świetnych firm.

Jak rozpoznać gęstość talentów: Studium przypadku D.E. Shaw

Rajaram wspomina jedną z pierwszych firm, do których aplikował – fundusz hedgingowy D.E. Shaw.

Opublikowali w Dr. Dobbs’ Journal (tradycyjny magazyn o hakerstwie, który Rajaram czytał) artykuł: „Hackers wanted” – bez podania nawet nazwy firmy. Tylko adres email.

Kto mógłby się oprzeć? Rajaram pomyślał: „Myślę, że jestem dobry” i wysłał CV.

Rozmowa kwalifikacyjna była najtrudniejsza, jaką kiedykolwiek miał. Na każdym etapie myślał, że oblał. Kompletnie. Rozmowa telefoniczna – oblałem. Rozmowa na miejscu – oblałem. Każda rozmowa.

Gdy dostał ofertę pracy, nie mógł nic innego zrobić jak przyjąć. Bo jeśli proces był TAK trudny, a mimo to go wzięli – znaczy, że będzie pracował z najlepszymi.

To samo w Google. Na każdym etapie myślał, że oblał. Rozmowy z Marissą, Susan – oblałem. Dali ofertę.

Gdy twój proces rekrutacji jest tak mocny, że czujesz, że zawiodłeś, a każda osoba, którą spotkałeś, była najmądrzejszą osobą, jaką kiedykolwiek spotkałeś – to firma, do której chcesz dołączyć.

Bo wiesz, że każdy, kto przeszedł przez ten proces, jest wyjątkowy. To jest gęstość talentów.

4. Jakość założyciela: szukaj niezadowolonych wizjonerów

Rajaram nie może wystarczająco podkreślić tego punktu. Był bardzo szczęśliwy mieć rozmowę z Larry’m Page’em pod koniec procesu w Google – było to oszałamiające.

Jakoś miał szczęście spotkać założyciela każdej firmy, w której pracował, zanim wziął pracę.

Jedna interesująca rzecz do szukania w założycielach: jak bardzo są niezadowoleni. Są nieco zawsze nieszczęśliwi ze stanem świata.

Czasem nie zdajesz sobie z tego sprawy do później. Nigdy jednak nie mówią, że firmie się dobrze wiedzie. Mówią: oto rzeczy, które są złe w firmie.

Czytając ich wywiady, nie słyszysz zbyt wiele bicia się w pierś. Może na sprawozdaniu dla inwestorów, ale w wywiadach: oto rzeczy, które możemy robić lepiej.

Chcesz kogoś takiego. Gdy tylko założyciel staje się zadowolony, nie mówiąc już o samozadowolony – to początek końca.

Musisz mieć założycieli, którzy – nawet patrząc na wywiady z Markiem Zuckerbergiem – facet nadal myśli, że jest w gorszej pozycji. Mimo że Facebook jest jedną z 10 najbardziej wartościowych firm. To jego supermoc. To jego sekret.

Długoterminowa wizja: Studium przypadku DoorDash

Gdy Rajaram rozmawiał z Tonym Hsu (DoorDash) wiele lat temu, Tony powiedział: „Zamierzamy na nowo wymyślić lokalny handel.”

Rajaram pomyślał wtedy: jesteś tylko firmą dostarczającą jedzenie, jaki „lokalny handel”? Nie ma mowy.

Okazało się, że Tony miał rację. To 10, 15, 20, 30, 50-letnia wizja.

To dlatego dyrektorzy generalni będący założycielami są tak potężni. Mogą myśleć ekstremalnie długoterminowo.

Założyciel jako CEO vs Profesjonalny CEO: Kluczowa różnica

Rajaram podkreśla fundamentalną różnicę:

Założyciele na stanowisku CEO mogą myśleć 10-20-30-50 lat w przyszłość. To ich firma, ich wizja, ich dzieło życia.

Profesjonalni dyrektorzy generalni – jakkolwiek dobrzy – są zobowiązani wobec akcjonariuszy i rady nadzorczej. Muszą podejmować bardziej krótkoterminowe decyzje. Po prostu taka jest natura ich pozycji.

Dlatego założyciele na stanowisku CEO mogą podejmować decyzje obstawiające całą firmę, których profesjonalny CEO by nie podjął.

Larry i Sergey: Najwięksi podejmujący ryzyko

Rajaram wspomina doświadczenie z przeglądów produktowych w Google.

Larry i Sergey byli największymi podejmującymi ryzyko w firmie. Wszyscy INNI (włącznie z Rajaramem i innymi liderami) byli bardziej konserwatywni.

Założyciele mówili zdecydowane rzeczy, podejmowali odważne decyzje. Zespół odpowiadał: „ale to narazi firmę na ryzyko!”

Rajaram zawsze czuł, że podczas przeglądów produktowych to założyciele pchnęli firmę do największych skoków.

Decyzja obstawiająca całą firmę: Google i AOL

Przykład takiego odważnego ruchu: Google obiecało AOL więcej gotówki w gwarancjach, niż miało w bilansie.

Dlaczego to zrobili? AOL było większe niż Google. Reklamodawcy chcieli reklamować się na AOL zamiast w Google. Więc zamiast budować własną platformę, Google powiedziało: zbudujemy dla was platformę reklamową. Gwarantujemy jednak wam więcej pieniędzy, niż kiedykolwiek byście zarobili.

Gwarantując tę kwotę (więcej niż gotówka, którą mieli), zmusili reklamodawców do przychodzenia do Google. To był początek AdWords. Mogli zbudować całą infrastrukturę aukcyjną.

To decyzja obstawiająca całą firmę. Można argumentować, że OpenAI robi podobne rzeczy dziś – wydają więcej, niż teoretycznie mogliby mieć przez następną dekadę. Już zrobili tyle zobowiązań.

Zasada „Advisor First”: Czas na analizę należytej staranności

Według Rajarama, te decyzje dotyczące kadry kierowniczej są niemal nieodwracalne. Powodują ogromny ból przy odwracaniu. To samo dotyczy członków rad nadzorczych.

Jego rada: nie możesz dodać ich jako kadry kierowniczej od razu? Weź ich jako doradcę najpierw. Pracuj z nimi przez kilka miesięcy. Zobacz, jak myślą o różnych rzeczach. Niech zaangażują się z twoim zespołem, z innymi członkami kadry jako doradca.

To relacja, która może trwać dekadę. Podejmujesz tę decyzję po dwóch tygodniach prezentowania komuś oferty? To trudne. To jak małżeństwo – wieloletnia, czasem wielodekadowa relacja.

Minimum czasu na due diligence: 6 miesięcy.

Najkrócej, co Rajaram pracował z firmą przed dołączeniem do rady nadzorczej: około 6 miesięcy (Coinbase, późny 2019, rada nadzorcza w połowie 2020). Pinterest: znał Bena Silvermana przez 15 lat przed dołączeniem. The Trade Desk: znał Jeffa Greena przez ponad 10 lat.

Jak zdominować pierwsze 60 dni w nowej roli

Jeśli już wybrałeś firmę i rolę specjalisty, Rajaram ma bardzo konkretne rady na pierwsze tygodnie.

Nastawienie: „Nic nie jest poniżej mojej godności”

Rajaram wspomina swoje wcześniejsze doświadczenie w firmie sprzętowej. Był PM w firmie robiącej wzmacniacze optyczne – ekstremalnie trudny produkt techniczny.

Mieli wykaz materiałów – to nie było jak oprogramowanie. Musieli pozyskiwać komponenty. Cisco było klientem. I Cisco zmusiło go (był na wczesnym etapie kariery) do podania ceny z dwóch, trzech lat w przód.

Mieli projekcję, że wykaz materiałów spadnie, będą mieli dodatnią marżę brutto. Dali im cenę. Cisco powiedziało: chcemy tej ceny dzisiaj.

Zmusili go do podania ceny bez żadnej jasnej wskazówki co do wolumenu, co uczyniłoby ich ujemną marżę brutto przez 2-3 lata. To naprawdę utkwiło mu w psychice.

Gdy dostał ofertę z Google i szedł tam pierwszego dnia, powiedział sobie: cokolwiek trudnego pojawi się w Google – nie będzie trudniejsze niż tamto. Po prostu zgłaszaj się na ochotnika.

Nie potrafił przeliczyć, jak bardzo entuzjazm, energia i chęć robienia rzeczy, zdejmowania rzeczy z płyty menedżera – jak bardzo to pomaga.

Numer jeden: daj przewagę swojemu menedżerowi

Rajaram podkreśla: wiele osób tego nie rozumie. Jak dać przewagę swojemu menedżerowi?

W jaki sposób zdjąć rzeczy z jego płyty i być typem osoby, która stale go informuje, ale po prostu robi rzeczy? Bycie osobą, która po prostu robi rzeczy w dobrych merytokratycznych firmach – to idzie długą drogą.

Wymyśl, jaka jest twoja supermoc. Upewnij się, że stawiasz się w miejscu, gdzie robisz rzeczy w tym wymiarze.

Im bardziej jesteś krytykantem, zawsze kwestionujesz rzeczy – dostajesz opinię osoby, która hamuje postęp. Musisz używać tego ostrożnie i przemyślanie.

Gdy decyzje są podjęte – są decyzje dwukierunkowe i jednokierunkowe.

Z decyzjami dwukierunkowymi: najważniejsze to szybko ustawić ramy dla hipotezy i eksperymentu. Uruchom szybko, zbierz dane, zobacz, czy warto – zamiast argumentować przez sześć tygodni.

Z jednokierunkowymi: jest tylko kilka nieodwracalnych decyzji. Na te trzeba poświęcić czas na argumentowanie.

Na dwukierunkowe – nie warto za wiele czasu. Sformułuj cel eksperymentu, uruchom szybko, zbierz dane.

Skupienie na szybkości: studium przypadku AdSense

Naprawdę skup się na szybkości.

AdSense, produkt, za który Rajaram był znany – zbudowany w Google – wystartował w trzy i pół miesiąca od zera. Najszybciej w historii dla produktu Google.

Rajaram skupił się na przecinaniu bzdur i po prostu uruchamianiu.

Sergey nagle wszedł i zredukował ich harmonogram. Mieli uruchomić we wrześniu. Powiedział: chcę, żebyście wystartowali w czerwcu. Przeciął z sześciu do trzech miesięcy.

Wtedy Rajaram: okej, co możemy wyciąć?

Nie argumentował nawet zbytnio. To było świetne, bo zmusiło ich do wystartowania z czymś i wypuszczenia tego.

Bycie znanym z szybkości, z poruszania się szybko, z dobrego osądu i robienia rzeczy.

Pierwsze 60 dni: zabezpiecz szybkie zwycięstwo

Rajaram ma ostrzeżenie. Im bardziej jesteś liderem, tym bardziej powinieneś się uczyć. Nadal jednak bardzo ważne jest mieć sukces w pierwszych 30-60 dniach.

Jeśli nie pokazujesz sukcesu, ludzie stale cię oceniają. Mają oczekiwanie, że robisz rzeczy.

Po 60 dniach, jeśli nie masz czegoś – mogłoby to być wypuszczenie funkcji, zapisanie kawałka kodu, gotowy projekt, cokolwiek, na co możesz wskazać i powiedzieć: zrobiłem to. Napisanie PRD. Coś.

Zmiana procesu jeśli koniecznie, miejmy jednak nadzieję coś więcej niż zmiana procesu.

Pierwsze 60 dni to ważne. Pierwsze 3-4 tygodnie – uczenie się jest w porządku. Potem jednak okres organizacyjnej cierpliwości się skraca.

„Możliwość pojawia się tam, gdzie porzucono odpowiedzialność”

Biegnij w stronę próżni.

Rajaram to potwierdza. W AdSense próbowali zatrudnić PM, ale on nie chciał nikim zarządzać. Powiedział: będę PM ds. rozliczeń. Będę PM ds. frontendu. Będę PM ds. targetowania.

Powoli więcej ludzi zostało przyciągniętych i zarządzał zespołem. Przez długi czas był jednak dosłownie PM pracującym z trzema, czterema, pięcioma różnymi zespołami inżynieryjnymi jako jeden PM.

Pierwsza rzecz: musisz robić główną rzecz dobrze. Jeśli nie robisz swojej głównej rzeczy dobrze, nie bierz na siebie więcej. Najpierw zdominuj to, potem bierz więcej.

Niska ego: „Nic nie jest poniżej mojej godności”

Rajaram dosłownie powiedział sobie: nic nie jest poniżej mojej godności.

Cokolwiek cię poproszą – zawsze uśmiechnięta twarz. Zgłaszaj się na ochotnika do trudnych zadań. Mów: tak, proszę pana. Tak, proszę pani. Mam to. Mam to.

Proś o pomoc. Nie bój się. Nie bądź zbyt dumny, żeby prosić o pomoc.

Masz zespół wokół siebie. Masz menedżera. Masz współpracowników. Proś ich o pomoc. Jak się robi rzeczy tutaj? Jak dodać PRD? Pokaż mi przykłady.

Praktyczne wnioski i listy kontrolne

Lista kontrolna: Czy powinienem wrócić do roli specjalisty?

Perspektywa czasowa kariery:

Zostało mi 15-20+ lat pracy → Poważnie rozważ rolę specjalisty w firmie natywnie opartej na AI
Zostało mi <5 lat → Decyzja opcjonalna, zależy od celów

Luka w kompetencjach AI:

Czy pracowałem z generatywną AI w produkcji? NIE → Rola specjalisty w firmie opartej na AI to konieczność
Czy mam doświadczenie z narzędziami AI i agentami? TAK → Możesz negocjować zarządzanie

Cel długoterminowy:

Chcę wrócić do zarządzania → Rola specjalisty jako 2-letni sprint na rozwijanie umiejętności
Chcę maksymalnej przewagi → Specjalista z agentami AI może dać większy wpływ niż małe zespoły

Lista kontrolna: Na co patrzeć przy wyborze firmy?

Ścieżka rozwoju: Czy firma rośnie i „powiększa tort”, czy znajduje się w stagnacji, co wymusza walkę o zasoby?
Gęstość talentów: Czy proces rekrutacyjny był wyzwaniem? Obecność wybitnych ludzi zwiększa szansę, że w przyszłości stworzą sieć wpływowych założycieli (efekt „mafii PayPala”)
Wiarygodność problemu: Czy wierzysz w ból klienta, który firma rozwiązuje? Niezbędne jest „czucie” tego problemu
Postawa założyciela: Czy założyciel jest konstruktywnie niezadowolony z rzeczywistości i ma odwagę podejmować ryzykowne zakłady?

Sygnały ostrzegawcze: Zatrudnianie Head of Product (dla założycieli)

Zatrudniasz Head of Product mając mniej niż 5 PM

Rozwiązanie: Zatrudnij senior PM z 2-3 letnim doświadczeniem w firmie natywnie opartej na AI. Niech robi pracę jako specjalista przez 6-12 miesięcy. Promuj z wewnątrz gdy urośniesz do 5+ PM.

Kandydat nie ma doświadczenia w środowisku natywnie opartym na AI

Rozwiązanie: Poproś o konkretne przykłady pracy z generatywną AI w produkcji. Nie akceptuj teoretycznej wiedzy. Szukaj ludzi z firm: Cursor, Perplexity, Anthropic, OpenAI, startupów natywnie opartych na AI.

Nie pracowałeś z tą osobą wcześniej jako doradca (Zasada „Advisor First”)

Rozwiązanie: 6-miesięczny okres próbny jako doradca. Obecność na posiedzeniach rady (2-3 przed decyzją). Zobacz, jak myśli, jak wpływa na zespół. To relacja na dekadę, nie podejmuj jej po 2 tygodniach rozmów kwalifikacyjnych.

Nie potrafisz sam zarządzać funkcją produktu

Rozwiązanie: Zarządzaj sam pierwszymi 2-3 PM przez 6+ miesięcy. Naucz się, czego oczekujesz od PM. Zrozum przepływ pracy, wyzwania, wskaźniki. Dopiero potem deleguj zarządzanie.

Pierwsze 60 dni: Plan działania

Tydzień 1-2: Przygotowanie

Zidentyfikuj, co jest na płycie mojego menedżera
Zapytaj: „Jak mogę ci najlepiej pomóc?”
Przeczytaj wszystkie dostępne PRD z ostatnich 6 miesięcy
Porozmawiaj z 5+ klientami (jeśli B2B)
Zidentyfikuj jeden obszar „próżni” (porzuconej odpowiedzialności)

Tydzień 3-4: Pierwsze wkłady

Zaproponuj rozwiązanie dla jednego problemu (mały, ale konkretny)
Napisz pierwszy dokument (PRD, analiza, propozycja)
Weź udział w przeglądzie kodu lub przeglądzie projektu
Znajdź jedno narzędzie AI, które może pomóc zespołowi

Tydzień 5-8: Zabezpiecz szybkie zwycięstwo

Dostarcz coś konkretnego: funkcję, prototyp, analizę
Upewnij się, że interesariusze wiedzą o tym zwycięstwie
Udokumentuj: co zrobiłem, jaki był wpływ, czego się nauczyłem
Zacznij brać na siebie więcej (jeśli główna rzecz idzie dobrze)

Ramy eksperymentów: Rezultaty dla klienta

Przed uruchomieniem funkcji/eksperymentu:

Jasna hipoteza: jakie zachowanie klienta się zmieni?
Dane wspierające: dlaczego tak myślimy?
Mapowanie rezultatu dla klienta → rezultatu biznesowego jest jasne
Napisane na papier (dokument kontekstowy)

Konfiguracja eksperymentu:

Określony % populacji (5-10%, statystycznie istotny)
Grupa kontrolna zdefiniowana
Wskaźniki sukcesu jasno określone
Harmonogram: ile czasu potrzebujemy na wyniki?

Po eksperymencie – jeśli sukces:

Plan wdrożenia (stopniowo, przez dni)
Monitorowanie bieżących wskaźników
Dokumentacja: co zadziałało i dlaczego

Po eksperymencie – jeśli porażka:

Analiza 5x „Dlaczego” (dotarcie do przyczyny źródłowej)
Które założenie było błędne?
Czy iteracja ma sens czy zwrot?
Dokumentacja nauk dla zespołu

Polecane źródła

W trakcie rozmowy pojawiły się odniesienia do:

Ram Charan, „The Leadership Pipeline” – książka o ścieżce kariery (od inżyniera specjalisty → menedżera specjalistów → menedżera wielofunkcyjnego → właściciela P&L/GM → CEO)
Keith Rabois – koncepcja „beczki i amunicji” w organizacjach
Square – studium przypadku doskonałości w rezultatach dla klienta (nieświętowanie wypuszczeń)
DoorDash – punkt odniesienia kultury eksperymentów i analizy zachowań klientów

Kluczowy wgląd

Wypuszczenie funkcji to porażka (dopóki nie udowodnisz zmiany zachowania)

Standardowo myślimy: Wysoka prędkość dostarczania nowych funkcji jest dowodem na efektywność zespołu, a każde wypuszczenie to powód do świętowania. Im więcej wypuszczamy, tym lepiej.

W praktyce okazuje się, że: Wypuszczenie nowej funkcji jest domyślnie działaniem negatywnym – to zwiększanie długu technologicznego i zalewanie klienta bylejakością. Rajaram używa mocnego określenia: „topienie klienta w pomyjach” (slop). Wypuszczenie staje się wartościowe tylko wtedy, gdy udowodnisz zmianę zachowania użytkownika. Według Rajarama, w erze AI, gdy building jest tańsze i szybsze, zespoły shipują za dużo bez tworzenia hipotez. Najlepsze produkty powstają w wyniku usuwania zbędnych funkcji, a nie ich dodawania.

Dlaczego to jest istotne: W momencie, gdy utowarowienie budowania sprawia, że wszyscy mogą szybko wypuszczać, różnicą nie jest to, ile wysyłasz, ale czy to, co wysyłasz, rzeczywiście zmienia zachowanie klienta. Funkcja, która nie zmieniła żadnego zachowania klienta, tak naprawdę się nie wypuściła – jak drzewo w lesie, które spadło, a nikt tego nie usłyszał. Skupienie na „dostarczaniu” bez zrozumienia celu prowadzi do budowania skomplikowanych narzędzi, których nikt nie używa, zamiast rozwiązywania realnych problemów.

Test na jutro: Następnym razem gdy twój zespół chce wypuścić funkcję, zanim zatwierdzisz, zadaj jedno pytanie: „Jakie zachowanie klienta to zmieni?” Jeśli nie ma jasnej odpowiedzi lub hipotezy – zatrzymaj wypuszczanie. Na najbliższym spotkaniu statusowym, gdy zespół zgłosi gotowość do wdrożenia, zapytaj o konkretną, mierzalną zmianę zachowania klienta (nie wynik biznesowy, lecz behawioralny). Ta jedna decyzja o niewypuszczeniu bezużytecznej funkcji będzie warta więcej niż 10 wypuszczonych rzeczy bez rezultatu dla klienta.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, to była rozmowa z Gokulem Rajaramem w podcaście „Product Thinking” (hosty: Mark i Ben).

Rajaram to były product leader w Google (AdSense), Facebook (Ads) i Square, obecnie członek rad nadzorczych w Coinbase, Pinterest i The Trade Desk. Jego perspektywa łączy wieloletnie doświadczenie operacyjne z aktywnym inwestowaniem w firmy natywnie oparte na AI.