Founder style leadership to nie licencja na mikromanagement – notatki z prezentacji Marty Cagana #EN291

Poniższe notatki powstały na podstawie prezentacji Marty Cagana z Pride Lean Product Meetup. Wszystkie przemyślenia, obserwacje i wnioski przedstawione w artykule pochodzą od Cagana, partnera Silicon Valley Product Group, który dzielił się swoimi doświadczeniami z roku transformacji produktowych po wydaniu książki „Transform”.

TL;DR

• Founder style leadership to styl zarządzania, nie „tryb” – nie można go włączać i wyłączać jak trybu w programie
• Product sense to nabyta umiejętność – rozwija się przez bezpośredni kontakt z klientami, immersion w danych i pracę z inżynierami
• Coaching jest kluczem do skalowania – procesy nie zastąpią rozwoju ludzi, zwłaszcza w product discovery
• Polityka to meta-temat transformacji – bez zdobycia serc i umysłów liderów transformacja nie ma szans
• „Eksperci prowadzą ekspertów” – menedżerowie muszą rozumieć obszary, którymi zarządzają
• Pilot teams przeważają nad stopniową transformacją – lepiej pokazać rezultaty na małej skali niż zmieniać wszystko po trochu
• Remote work zabija innowacje – ogranicza product discovery i prowadzi do powrotu praktyk waterfall

---

Generative AI zmusiło firmy do przemyślenia sposobu pracy nad produktami. Jak zauważa Cagan, technologia ta spowodowała, że „firmy, które wcześniej nie myślały o transformacji, dostały teraz memo”. Jednocześnie pojawił się temat „founder mode”, który Brian Chesky z Airbnb wywołał swoją wypowiedzią sprzed kilku miesięcy.

Cagan wspomina także podcast „Product Therapy” swojego partnera Christiana Idioti, skupiony na coaching i wyzwaniach transformacji. Najnowszy odcinek dotyczy polityki – meta-tematu dla wszystkiego w transformacji. Bez zdobycia serc i umysłów liderów transformacja po prostu nie może się udać.

Founder mode czy founder style leadership – różnica ma znaczenie

Cagan świadomie redefiniuje popularne pojęcie „founder mode”. Jak wyjaśnia, to nie jest tryb, który można włączać i wyłączać, lecz styl przywództwa. Paul Graham, znany inwestor z Y Combinator, był programistą Lisp – języka, w którym wszystko opiera się na trybach. Founder style leadership to jednak coś więcej.

Drugie kluczowe zastrzeżenie: nie dotyczy tylko założycieli. Według Cagana, founder style leadership staje się ważniejszy w miarę wzrostu firmy, nie mniej ważny. Wszystkie największe firmy produktowe włączyły ten styl do swoich zasad przywództwa.

Leslie Kilgore, jedna z oryginalnych liderek Netflix, rozumiała to od początku. Nazywała to „prowadzenie przez kontekst” – dostarczanie strategicznego kontekstu zamiast command and control. To nie mikromanagement, ale dostarczanie kontekstu potrzebnego do podejmowania decyzji.

Trzy style zarządzania produktem

Cagan identyfikuje trzy podejścia do zarządzania:

Mikromanagement – wszyscy wiedzą, że to zły pomysł. Nie zatrudnia się inżynierów, żeby im mówić co robić, ale żeby pokazali, co jest możliwe.

Profesjonalne zarządzanie – brzmi pięknie: zatrudnij dobrych ludzi i daj im przestrzeń. Jak podkreśla Cagan, brzmi tak miło, ale jest tak nieprzydatne.

Founder style leadership – jedyne rozwiązanie działające w firmach technologicznych.

Steve Jobs zrozumiał to 30 lat temu, kiedy Apple popełnił błąd zatrudniania „profesjonalnych menedżerów”. Przykładem był John Sculley z Pepsi, który nie znał klientów, technologii, produktów ani kultury. W rezultacie firma niemal zbankrutowała.

Co czyni założycieli wyjątkowymi

Założyciele mają coś, czego nie da się łatwo powielić. Byli tam od początku, tworzyli wizję produktu i prezentowali ją tysiące razy. Znają każdą interakcję z klientem, każdy deal, każdy eksperyment. Dosłownie żyli i oddychali tym rynkiem.

Product sense nie jest wrodzoną cechą – to kluczowa obserwacja Cagana. Wielu ludzi myśli, że albo ma się product sense, albo nie. To nieprawda. Product sense zdobywa się przez robienie wszystkich tych rzeczy, które robią założyciele.

Dlaczego „product intuition” to błędne pojęcie

W części Q&A Cagan zdecydowanie odrzuca koncepcję „product intuition”. Uważa to za zwodniczy trop. Zamiast tego mówi o product judgment – dobrej ocenie sytuacji opartej na wiedzy.

Ludzie, którzy mają dobre product judgment? Jaki zbieg okoliczności – oni też rozwinęli product sense. To nie jest „w brzuchu”, jak często się mówi, ale w mózgu. To efekt rozmów z wieloma klientami, asymilacji różnych informacji i budowania głębokiego zrozumienia.

Podobnie Cagan odrzuca czyste podejście oparte na danych. Dane powiedzą ci, co się dzieje, ale nie powiedzą ci dlaczego ani co robić. Dane to tylko punkt danych, który musi być interpretowany przez osąd.

Jak rozwijać product sense

Cagan opisuje konkretne kroki, które każdy product leader powinien podjąć w pierwszych trzech miesiącach. W eBay jego pierwszym zadaniem było „wyciągnięcie z mózgu” współzałożyciela Pierre’a Omidyara wszystkich możliwych informacji.

Spotkania z użytkownikami i klientami – na każdym poziomie organizacji. W eBay Cagan spędził niezliczone godziny z kupującymi i sprzedającymi, poznając ich problemy.

Czas z inżynierami – zaleca skip-level meetings z individual contributorów. To buduje morale, a jednocześnie daje krytyczne zrozumienie. W firmach wdrażających generative AI to właśnie inżynierowie są źródłem większości innowacyjnych pomysłów.

Zanurzenie się w dane produktowe – dane o tym, jak ludzie używają produktów, jak je kupują, jak te wzorce zmieniają się w czasie.

Zdobycie zaufania interesariuszy – przez bezpośrednie, szczere rozmowy jeden na jeden. W eBay Cagan musiał nauczyć się skomplikowanych ustaleń prawnych i podatkowych, które wpływały na całą ekonomikę firmy.

Opisując sytuację z prawnikiem Robem Chestnutem, Cagan wspomina: gdy cokolwiek było blisko szarej strefy, szedł do niego i prosił o szybkie spojrzenie na prototyp. Prawnik od razu dziękował, bo lepiej było zobaczyć prototyp wcześniej niż radzić sobie z problemem później.

Połączenie z założycielem (jeśli możliwe) – nawet jeśli założyciel już się wycofał, warto poprosić członka zarządu lub CEO o wprowadzenie. Sesja „brain dump” z oryginalnym założycielem może być bezcenna.

✅ Checklista pierwszych 3 miesięcy product leadera

Poznaj użytkowników i klientów

□ Zaplanuj regularne spotkania z użytkownikami końcowymi
□ Poznaj ich prawdziwe problemy i sposób używania produktu
□ Zrozum różnicę między tym, co mówią a tym, co robią

Zbuduj relacje z zespołem

□ Zaplanuj skip-level meetings z individual contributorów
□ Spędź czas z zespołem, żeby zrozumieć techniczne ograniczenia
□ Dowiedz się, skąd pochodzą najlepsze pomysły produktowe

Zanurz się w danych

□ Przeanalizuj dane usage i behavioral patterns
□ Sprawdź dane sprzedażowe i pipeline
□ Zbadaj trendy – jak wzorce zmieniają się w czasie

Zdobądź zaufanie interesariuszy

□ Przeprowadź rozmowy jeden na jeden z każdym kluczowym interesariuszem
□ Dowiedz się o ich obawach i ograniczeniach biznesowych
□ Naucz się kluczowych wymagań zgodności z przepisami
□ Ustal proces konsultacji w „szarych obszarach”

Poznaj rynek i branżę

□ Przeanalizuj kluczowe raporty analityczne i research branżowy □ Zbuduj relacje z najlepszymi analitykami w swojej dziedzinie □ Śledź trendy i zmiany w szerszym kontekście rynkowym □ Zrozum pozycję konkurentów i ich strategie

Coaching jako klucz do skalowania

Bill Campbell, trener Steve Jobs, Larry’ego Page’a, Sergey’a Brina i Jeffa Bezosa, miał motto: „Coaching nie jest już specjalnością. Nie można być dobrym menedżerem bez bycia dobrym coachem”.

Startup przed osiągnięciem product-market fit to inna gra. Tam założyciel produktu jest product managerem. Gdy firma rośnie, pojawia się nowy problem: jak umożliwić wielu zespołom produktowym robienie świetnej roboty?

Są dwa możliwe rozwiązania. Pierwszym jest formalizacja procesów – to pułapka, w którą wpadają zwłaszcza nietechniczni założyciele. Steve Jobs nazywał to „chorobą ludzi od procesów”.

Drugi, jedyny działający, to coaching. Jak mówi Cagan: praca polega nie tylko na hands-off empowerment. Trzeba upewnić się, że zespoły mają umiejętności potrzebne do sukcesu.

Eksperci prowadzą ekspertów

To podstawowa zasada, którą Cagan musi „kompletnie obalić” w europejskich firmach. Istnieje tam koncepcja „people-only managera” – menedżera, który nie rozumie obszaru, którym zarządza.

W Apple mają motto: „eksperci prowadzą ekspertów”. Jeśli zarządzasz zespołem inżynierów, musisz być dobrym inżynierem. To wydaje się oczywiste, ale wcale takie nie jest. W Dolinie Krzemowej od zawsze obowiązywał model, że jeśli chciałeś być liderem inżynierskim, lepiej żebyś był całkiem dobrym inżynierem.

Uwaga na pułapkę dogmatyzmu domenowego – różnica między wiedzą domenową a dogmatyzmem. Wiedza domenowa jest częścią product sense i trzeba ją zdobyć, żeby rozumieć klientów. Jednak dogmatyzm to przekonanie, że „zawsze tak robiliśmy” jest jedyną słuszną drogą. Szczególnie widać to w firmach finansowych, gdzie ludzie mylą prawdziwe wymagania prawne z „tradycją” czy „tym, jak zawsze robiliśmy”.

Jak wielkie firmy technologiczne wdrożyły founder style leadership

Zasady przywództwa największych firm technologicznych są zaskakująco spójne:

• Amazon: Dive deep, hire and develop the best, focus on results
• Apple: Deep expertise, scaling through teaching and coaching, experts lead experts
• Google: Substance first, develop others through coaching, empower teams

Jak zauważa Cagan, można argumentować, że to prawdopodobnie wpływ Bill Campbella. Prawdopodobnie dał im początek wielu z tych zasad. Jednak każda z tych firm nauczyła się i zrozumiała te principia przez własne doświadczenie.

Founder style leadership w praktyce

W codziennej pracy oznacza to konkretne działania. Mike Fisher, były CTO Etsy i obecny CEO MyFitnessPal, opowiadał Caganowi o przygotowaniu do każdego one-on-one. Myśli o pytaniach, które pomogą osobie skupić się na właściwych tematach.

Kluczowe elementy:

• Przydzielanie problemów do rozwiązania, nie funkcjonalności do zbudowania
• Świadome przygotowanie do rozmów z zespołem
• Oczekiwanie dobrych odpowiedzi – a jeśli ich nie ma, coaching jak je uzyskać
• Cotygodniowe one-on-one jako „absolutnie nienagotowalne”

Pilot teams vs całościowa transformacja

Większość ludzi myśli, że najlepszy sposób transformacji dużej organizacji to seria małych zmian. Cagan nie zgadza się z tym podejściem.

Moment, gdy zaczynasz transformację, uruchamia się zegar. Jeśli nie pokażesz prawdziwych rezultatów przed jego zatrzymaniem, gra się kończy. Z kolei pilot teams są bezpieczniejsze, szybsze i bardziej odpowiedzialne.

Jeden z coachów Cagana pracował z firmą w Meksyku, która w jeden kwartał zwiększyła przychody o 40%. Nawet najbardziej sceptyczny dyrektor sprzedaży powiedział: „Kocham was, jak szybko możemy to rozwinąć?”

Kluczowe kryteria wyboru pilot teams:

• Autonomia – zespół może działać bez większych zależności
• Ambitne, ale osiągalne cele – wystarczająco trudne, żeby imponować
• Gotowość zespołu – umiejętności lub możliwość ich szybkiego nabycia
• Wymierne rezultaty w rozsądnym czasie

Hardware companies i discovery

Ciekawy wniosek Cagana: firmy hardware’owe robią więcej discovery niż ktokolwiek, właśnie dlatego, że muszą. Koszt błędu jest znacznie wyższy.

Tesla służy jako przykład firmy robiącej samochody „jak Toyota, ale wcale nie jak Toyota”. Ilość nowych części, które projektują w porównaniu do tradycyjnych firm, to rzędy wielkości różnicy.

Wszystko, o czym mówi Cagan w kontekście product discovery i prototypowania, jest nawet ważniejsze w hardware, bo koszt pomylki jest znacznie wyższy.

Wyzwania remote work dla product teams

Cagan przyznaje się do wewnętrznych konfliktów w tej kwestii. Wszystkie firmy, które doradza, są przynajmniej hybrydowe, jeśli nie w pełni zdalne. Jednak nienawidzi tego. Oni tego nienawidzą. Wszyscy w zespołach produktowych tego nienawidzą.

Problem nie dotyczy dostarczania, sprzedaży czy marketingu. Problem dotyczy discovery. Problem dotyczy innowacji.

Steve Jobs mówił o tarciu potrzebnym do stworzenia dobrego produktu. Product design i inżynieria muszą się spierać, ale to wymaga bezpieczeństwa psychologicznego i relacji, które trudno budować zdalnie.

Cagan opisuje typowy scenariusz: ktoś pisze PRD, rzuca przez ścianę inżynierowi i mówi: „ok, oto coś”. To oczywiście nie jest to, co chcemy robić. Zespoły albo wracają do waterfall, albo rezygnują z próby budowania zdrowych relacji.

Jedyne rozwiązanie, które zaleca: „prototype of the day” – 30 minut dziennie, cały zespół rozmawia o prototypie. To prawdopodobnie najużyteczniejsza technika do ułatwienia tego rodzaju dialogu.

SAFe jako przeciwieństwo product model

Cagan jest bardzo krytyczny wobec SAFe. Uważa, że „SAFe nie jest bezpieczne” i że to agile tylko w nazwie marketingowej. Nie ma tam wcale żadnego agile.

SAFe to proces zoptymalizowany pod przewidywalność, jak wszystkie procesy waterfall. Tymczasem firmy produktowe próbują optymalizować pod innowacje lub outcomes. To są kompletnie różne rzeczy.

Spotify ma na ścianach znaki: „100% przewidywalność równa się 0% innowacji”. To jest prawda, choć ironia polega na tym, że przewidywalne podejścia wcale nie są bardzo przewidywalne.

Wpływ generative AI na product management

Cagan opublikował niedawno raport „AI Product Management: Two Years In”. Jego obserwacje pokazują podział w branży, potwierdzony przez badanie MIT z nauki o materiałach.

Badanie MIT pokazało, że najwięcej z AI wyciągają ludzie z ekspertyzą – ci, którzy mają osąd i doświadczenie, potrafią najlepiej wykorzystać nowe narzędzia. To samo dotyczy product sense.

Zagrożone role: Product owners („Powodzenia. Nie widzę dla nich przyszłości”) i Associate product managers („To jest po prostu łatwy cel dla ChatGPT”).

Wzmocnione pozycje: prawdziwi product managers mieli wzrost pensji, bo są ważniejsi niż kiedykolwiek. W produktach AI kluczowy jest osąd. Ryzyka są większe, konsekwencje też.

Ta sama zasada dotyczy inżynierów. Juniorzy już to odczuwają, natomiast najbardziej produktywni inżynierowie z nowymi narzędziami są jeszcze bardziej produktywni.

Praktyczne prompty AI inspirowane wykładem Cagana

Poniżej znajduje się lista gotowych do użycia poleceń, które pomogą zastosować w praktyce kluczowe koncepcje z wystąpienia.

1. Coaching i przygotowanie spotkań

Kiedy stosować: Przed cotygodniowym spotkaniem 1:1, aby przygotować przemyślane pytania, które skłaniają do myślenia, a nie dają gotowe odpowiedzi.

2. Budowanie „Product Sense”

Kiedy stosować: Gdy obejmujesz nowy produkt lub obszar i musisz szybko zbudować głęboki kontekst.

3. Myślenie dywergencyjne (generowanie pomysłów)

Kiedy stosować: W fazie poszukiwania rozwiązań danego problemu. AI świetnie nadaje się do generowania szerokiego spektrum opcji.

Praktyczne podsumowanie

Founder style leadership to product sense plus coaching. W startupie przed product-market fit to głównie product sense – nie ma nikogo do trenowania. Gdy firma rośnie, coaching staje się kluczowy.

Jak mówi Cagan: product leaders będą oceniani przez swojego najsłabszego product managera. Zadaniem lidera jest upewnienie się, że każdy product manager ma potrzebną wiedzę i umiejętności.

Książki wspomniane w prezentacji:

• „Transform” – Marty Cagan (najlepszy punkt wejścia do tematyki)
• „Empowered” – dla product leaders
• „Inspired” – dla product managers
• „Trillion Dollar Coach” – o Bill Campbellu

Kluczowy insight

Prawdziwe przeciwieństwo mikrozarządzania

Standardowo myślimy: Aby dać zespołowi autonomię, lider musi „zejść z drogi” i po prostu delegować problemy, unikając wtrącania się w szczegóły.

W praktyce okazuje się, że: Pasywna delegacja jest równie szkodliwa jak mikrozarządzanie, ponieważ pozostawia zespół bez kluczowego kontekstu. Skuteczne przywództwo wymaga głębokiego, merytorycznego zaangażowania, ale w formie coachingu i zadawania pytań, a nie wydawania poleceń.

Dlaczego to jest istotne: Ten wgląd zmienia definicję „empowerment”. Nie jest to brak zaangażowania lidera, ale wysoka jakość tego zaangażowania, która realnie buduje kompetencje zespołu.

Test na jutro: Następnym razem gdy będziesz delegować zadanie zespołowi, zamiast tylko przedstawić problem i zostawić ich samych, spróbuj poświęcić dodatkowe 30 minut na podzielenie się całym strategicznym kontekstem, danymi i swoimi obawami. Zakończ sesją pytań, a nie listą poleceń i zobacz, czy jakość pierwszych propozycji zespołu wzrosła.

---

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, znajdziesz je tutaj: Marty Cagan： Why Your Product Operating Model is Broken (Transformed Author & SVPG Partner)