TL;DR:

Primary vs secondary risk – startupy skupiają się na ryzyku finansowym zamiast na tym, czy klienci w ogóle chcą kupić produkt
50-100 iteracji potrzeba do osiągnięcia product-market fit, nie 2-3 jak myśli większość firm
CEO musi być aktywnie zaangażowany w transformację – delegowanie do consultantów oznacza porażkę
Head of product i head of engineering to kluczowe role, które muszą mieć doświadczenie lub intensywny coaching
Prawdziwi product managerowie rozwiązują problemy, nie implementują listy funkcji jak product ownerowie
Pilotaż w małych jednostkach przed skalowaniem pozwala na eksperymenty i budowanie wewnętrznych case studies
80% czasu managera powinno być poświęcone na coaching i rekrutację, nie na procesy

Poniższy tekst to notatki z rozmowy między Marty’m Caganem, autorem kultowych książek o product management, oraz Sohrabem Salimi na temat transformacji organizacyjnych. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od rozmówców, szczególnie od Cagana, który przez dekady obserwował zarówno spektakularne sukcesy, jak i bolesne porażki firm technologicznych.

Brutalna prawda o innowacji: dlaczego transformacja jest konieczna

Wiele firm inwestuje miliony w transformacje, oczekując natychmiastowych wyników. Cagan zwraca jednak uwagę na brutalną prawdę: znalezienie produktu, który rynek pokocha, wymaga od 50 do 100 iteracji.

Matematyka jest bezlitosna. Jeśli jeden cykl rozwojowy w firmie trwa cztery miesiące, przeprowadzenie nawet dwudziestu prób staje się niemożliwe. W rezultacie firma ryzykuje bankructwo lub zarząd traci cierpliwość.

Właśnie dlatego transformacja jest koniecznością. Stare modele pracy, oparte na kilku dużych projektach rocznie, po prostu nie działają w dzisiejszym świecie. Prawdziwa transformacja polega zatem na stworzeniu organizacji zdolnej do szybkiego i taniego eksperymentowania.

Pierwotne vs wtórne ryzyko: gdzie popełniają błąd organizacje

Cagan wprowadza rozróżnienie, które może wydawać się oczywiste, jednak w praktyce jest systematycznie ignorowane. Większość założycieli skupia się bowiem na ryzyku wtórnym – czy produkt będzie rentowny, ile będzie kosztował w budowie, jakie będą marże.

Według eksperta, ryzyko wtórne ma sens tylko wtedy, gdy ludzie kupią produkt. W przeciwnym razie to jedynie arkusz kalkulacyjny i studium biznesowe, na którym nikomu nie zależy, ponieważ nikt tego nie kupuje.

Cagan wprowadza jasne rozróżnienie:

Ryzyko pierwotne (Primary Risk): Czy klienci będą chcieli to kupić? Czy produkt dostarcza im realną wartość? To jest ryzyko wartości (value risk).

Ryzyka wtórne (Secondary Risks): Czy stać nas na zbudowanie tego? Czy to się opłaca? Jak to sprzedamy? To są ryzyka opłacalności, wykonalności itd.

Wiele firm popełnia błąd, koncentrując się na ryzykach wtórnych (np. tworząc szczegółowe studium biznesowe), zanim udowodnią, że ktokolwiek potrzebuje ich produktu.

Cagan wyjaśnia, dlaczego przestał używać starszej taksonomii ze Stanford Design School. W B2B istnieje wielka różnica między kupującym a użytkownikiem – żaden z nich nie mówi o „desirability”. Nie pragną systemu bezpieczeństwa, muszą z nim żyć, to nie jest wybór.

Skutki mylenia priorytetów w korporacjach obejmują:

Miesiące na analizy finansowe dla produktów o nieznanej potrzebie rynkowej
Szczegółowe studium biznesowe bez weryfikacji propozycji wartości
Skupienie na marżach zamiast na adopcji przez klientów
Inwestowanie w viability przed udowodnieniem value

Droga do product-market fit: dlaczego potrzebujesz dziesiątek prób

Jedna z najbardziej szokujących informacji z rozmowy dotyczy liczby iteracji potrzebnych do osiągnięcia product-market fit. Cagan mówi wprost: 50 do 100 prób – nie dla pojedynczych funkcji, ale dla samego produktu.

Ekspert ostrzega, że jeśli iteracja trwa cztery miesiące, nie ma szans na zrobienie 50, nie ma szans nawet na 20. W rezultacie skończą się pieniądze, czas lub cierpliwość zarządu.

To oznacza konieczność radykalnego przyspieszenia cykli uczenia się. Firmy muszą zatem nauczyć się iterować na wielu poziomach: problem, podejście do rozwiązania, doświadczenie użytkownika, technologia i propozycja wartości.

Spotify jako przykład kultury eksperymentowania utrzymuje swoją pozycję, konkurując z Apple i Amazon – dwoma najlepszymi firmami produktowymi na świecie. Ich siła leży w kulturze discovery i ciągłego eksperymentowania.

Cztery filary udanej transformacji organizacyjnej

Cagan i jego partnerzy przeanalizowali udane transformacje, identyfikując wzorce wspólne dla wszystkich sukcesów. Jednocześnie podkreśla brutalną rzeczywistość: większość transformacji kończy się porażką. Wszyscy widzieliśmy te wielomilionowe transformacje. Sprowadzasz wielkie agencje, wielkie firmy consultingowe, które spędzają cały ten czas i pieniądze, a na końcu dnia są równie złe, jeśli nie gorsze niż wcześniej.

Mimo to wyodrębnili kilka krytycznych elementów, bez których transformacja kończy się niepowodzeniem.

Filar pierwszy: aktywne zaangażowanie CEO

W każdym udanym przykładzie CEO naprawdę odgrywał aktywną rolę. Problem tkwi w tym, że transformacja wpływa na finanse, HR, marketing i sprzedaż. Jeśli CEO nie jest zaangażowany, te działy po prostu nie współpracują.

Tony Fadell w książce „Built” opisuje, jak Steve Jobs osobiście usuwał przeszkody dla zespołu iPoda, dzwoniąc do innych zespołów i zapewniając wsparcie. Wszyscy w Apple wiedzieli – jeśli nie pomożesz zespołowi iPoda, dostaniesz telefon od Jobsa. Nikt nie chciał takiego telefonu.

Filar drugi: właściwi liderzy produktowi

Head of product i head of engineering to role krytyczne, jednak większość firm ma w tych pozycjach ludzi bez odpowiedniego doświadczenia. Cagan wyjaśnia, że w starym modelu funkcji zespołów rola technologiczna i szczególnie rola lidera produktu to coś zupełnie innego.

Są dwie opcje: zastąpić tych ludzi doświadczonymi lub zapewnić im intensywny coaching. Bez tego transformacja nie ma szans powodzenia.

Filar trzeci: prawdziwi product managerowie

Cagan mówi kategorycznie: potrzebujesz prawdziwych product managerów. Nie product ownerów, nie analityków biznesowych, nie project managerów.

Product owner (stary model):

Dostaje listę funkcji do zbudowania
Implementuje wymagania interesariuszy
Skupia się na delivery i harmonogramie

Product manager (nowy model):

Dostaje problemy do rozwiązania
Ma głęboką wiedzę o klientach i danych
Rozumie działanie biznesu i trendy branżowe
Odpowiada za viability i value
Współpracuje z designerami (usability) i inżynierami (feasibility)

Kluczowe jest przypisanie jednego product managera na zespół, nie na produkt. Nie jest niczym niezwykłym mieć dziś jeden produkt obsługiwany przez 100 zespołów produktowych. Jest bardzo rzadko, żeby zespół produktowy miał tylko jeden produkt – to byłby bardzo mały produkt.

Filar czwarty: umiejętności product discovery

Zespoły muszą nauczyć się skupiać na outcomes zamiast outputs, ustanowić właściwe relacje z interesariuszami i opanować techniki product discovery.

W prawdziwej firmie produktowej jesteś tylko tak dobry, jak Twoje rezultaty. Musisz dostarczać wyniki.

Najemnicy vs misjonarze

Cagan wprowadza kluczowe rozróżnienie między dwoma typami zespołów. Reszta to po prostu najemnicy. Zbudują to, co im każesz, a jeśli nie działa, to nie ich wina. Jednak w prawdziwej firmie produktowej jesteś tylko tak dobry, jak Twoje rezultaty.

To fundamentalna zmiana mindset – od wykonywania poleceń do brania odpowiedzialności za outcomes. Transformacja nie może się udać, jeśli zespoły pozostają w trybie najemników.

Pilotaż jako strategia redukcji ryzyka transformacji

Cagan zaleca rozpoczynanie transformacji od 1-3 pilotowych zespołów produktowych w ramach jednej jednostki biznesowej. To pozwala na szybkie eksperymentowanie i wypracowanie rozwiązań działających w konkretnej kulturze organizacji.

Nie chcesz robić tego w całej wielotysięcznej firmie naraz. Chcesz zrobić to, gdy jest małe i łatwe.

Dodatkową korzyścią jest wykorzystanie technology adoption curve. W każdej organizacji są pracownicy kochający zmiany, nienawidzący ich oraz większość, która chce zobaczyć działające rozwiązanie przed zmianą. Pilotaż pozwala przekonać sceptyków konkretnymi rezultatami.

Skalowanie przez ludzi, nie procesy: dlaczego coaching wygrywa z instrukcjami

Jedna z najbardziej kontrowersyjnych części rozmowy dotyczy różnicy między skalowaniem przez procesy a skalowanie przez coaching.

Google przeprowadził badania nad cechami najlepszych managerów. Wynik numer jeden: są uważani za dobrych coachów przez swoje zespoły. Z kolei numer dwa: są postrzegani jako empowering managerowie, nie micromanagerowie.

Cagan podaje konkretną metrykę: menedżerowie pierwszego szczebla powinni spędzać około 80% czasu na coaching i rekrutację. To oznacza cztery dni w tygodniu.

Jeśli miałeś do czynienia z wieloma otwartymi pozycjami, wiesz że rekrutacja zajmuje bardzo dużo czasu. Wiesz również, że rekrutacja jest bardzo powiązana z coachingiem. Im lepszą robotę zrobisz w rekrutacji, tym łatwiejszy jest coaching.

Gdy dajesz ludziom podręcznik procedur mówiący „to jest to, co robisz”, rozwijasz roboty. Gdy ich coachujesz, rozwijasz liderów.

Krytyka powierzchownego coachingu

Cagan nie ukrywa frustracji wobec International Coaching Federation i powierzchownego podejścia do coachingu. Ludzie zatrudniają coachów, płacą za tych coachów, a ci coachowie nie są w stanie im pomóc. Potrafią sprawić, że poczują się lepiej przez kilka minut, jednak nie potrafią pomóc im faktycznie rozwiązać problemów.

Kluczowa różnica polega na tym, że prawdziwy coach ma „skin in the game”. Jeśli jesteś liderem w organizacji, masz udział w grze – coach nie ma. Coach może zostać zwolniony z jednego zadania. Prawdziwy coach, jak trener reprezentacji Argentyny, absolutnie ma udział w grze. Jeśli przegra, prawdopodobnie zostanie zwolniony.

Prawdziwy coaching w kontekście produktowym wymaga głębokiej znajomości materii. Tak jak trenerzy piłkarscy muszą doskonale znać piłkę nożną, coach produktowy musi rozumieć team topology, product discovery i wszystkie aspekty tworzenia produktów.

Większość agile coachów ma jakieś doświadczenie inżynieryjne, ale nie ma doświadczenia w product management ani product design. Próbują coachować w product discovery i nie mają pojęcia.

Praktyczne wnioski dla organizacji

Checklist: Ocena gotowności do transformacji

Zaangażowanie leadership:

CEO jest gotowy na aktywne zaangażowanie (nie tylko delegowanie)
CEO rozumie wpływ transformacji na finanse, HR, marketing i sprzedaż
Leadership ma cierpliwość na 1-2 lata procesu

Kluczowe role:

Head of product ma doświadczenie lub dostęp do intensywnego coachingu
Head of engineering ma doświadczenie lub dostęp do intensywnego coachingu
Każdy zespół produktowy ma przypisanego prawdziwego product managera

Kultura i mindset:

Organizacja jest gotowa na dziesiątki iteracji zamiast kilku
Menedżerowie pierwszego szczebla mogą spędzać 80% czasu na coaching i rekrutację

Czerwone flagi porażki transformacji

Podejście organizacyjne: delegowanie transformacji do external consultants, mianowanie CDO odpowiedzialnym za zmianę, skupianie się wyłącznie na procesach Agile bez zmian w kulturze.

Braki kompetencyjne: brak prawdziwych product managerów w zespołach, agile coaches bez doświadczenia w product management, process people kontrolują organizację zamiast product people.

Symptomy w praktyce: wydłużające się cykle release (raz na kwartał = nie jesteś agile), coaching oparty tylko na „miękkich” umiejętnościach bez znajomości domeny.

Harmonogram transformacji

Pilotaż (1-3 zespoły produktowe): 3-6 miesięcy na uruchomienie i pierwsze rezultaty, identyfikację tego co działa w konkretnej kulturze organizacyjnej.

Jednostka biznesowa: 6-12 miesięcy na pełne wdrożenie, skalowanie wzorców z pilotażu, rozwój kompetencji coachingowych u managerów.

Duża firma (wielotysięczna): 1-2 lata na organizację, transformacja jednostka po jednostce. Realnie może się nie udać bez spełnienia kluczowych warunków.

Kluczowe insighty

Paradoks odwróconego skalowania

Standardowo myślimy: Im większa transformacja, tym większy effort i zasięg potrzebny na start. Duże zmiany wymagają dużych akcji.

W praktyce okazuje się, że: Im większą transformację chcesz przeprowadzić, tym mniejszy pilotaż musisz rozpocząć. Cagan podkreśla: nie chcesz robić tego w całej wielotysięcznej firmie naraz. Chcesz zrobić to, gdy jest małe i łatwe.

Dlaczego to jest istotne: Ten paradoks wynika z technology adoption curve – większość ludzi nie chce zmian, dopóki nie zobaczy działającego przykładu. Wielkie starty generują wielki opór, małe pilotaże budują przekonanie.

Test na jutro: Następnym razem gdy planujesz dużą zmianę organizacyjną, zamiast prezentować plan dla całej firmy spróbuj zidentyfikować najmniejszy możliwy pilotaż (1-3 zespoły) i sprawdź czy możesz uzyskać pierwsze rezultaty w ciągu miesiąca.

Paradoks biznesplanu innowacji

Standardowo myślimy: Każdy nowy projekt musi zacząć się od solidnego studium biznesowego, które udowodni jego opłacalność (ryzyko wtórne).

W praktyce okazuje się, że: Studium biznesowe dla prawdziwej innowacji jest fikcją, dopóki nie udowodnimy, że klienci w ogóle tego chcą. Kluczowe jest jak najszybsze zwalidowanie pierwotnego ryzyka – ryzyka wartości.

Dlaczego to jest istotne: Zespoły tracą miesiące na tworzenie arkuszy kalkulacyjnych dla produktów, których nikt nie potrzebuje, zamiast poświęcić ten czas na rozmowy z klientami i realne eksperymenty.

Test na jutro: Następnym razem gdy pojawi się nowy pomysł na produkt, zamiast pytać „jak na tym zarobimy?”, spróbuj zapytać „jaki jest najsilniejszy dowód na to, że ktokolwiek ma problem, który próbujemy rozwiązać?” i poświęć dzień na znalezienie odpowiedzi.

Polecane książki

Na podstawie rozmowy, oto książki polecane przez Cagana:

„Built” Tony Fadella – ulubiona książka Cagana dla CEO, pokazująca jak tworzyć kultury produktowe
„High Output Management” Andy Grove’a – o tym, dlaczego teaching i coaching to zadanie szefa
„Creativity Inc.” Eda Catmulla – o tworzeniu kultury kreatywności w Pixar
„Inspired” i „Empowered” Marty’ego Cagana – podstawy product management i leadership

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: Transformation – (Marty Cagan in conversation with Sohrab Salimi)

Tag: Sohrab Salimi

Transformacja organizacyjna według Marty’ego Cagana: dlaczego większość prób kończy się niepowodzeniem #EN262