Poniższe notatki pochodzą z prezentacji Marty’ego Cagana na Lean Product Meetup, podczas której przedstawiał swoją książkę „Transformed”. Wszystkie przemyślenia, obserwacje i wnioski prezentowane w tekście to poglądy i doświadczenia Cagana oraz opisywanych przez niego firm.

Najważniejsze wnioski:

Product operating model oznacza przejście od output do outcomes – firmy przestają skupiać się na dostarczaniu funkcji, a zaczynają rozwiązywać problemy
Trzy kluczowe zmiany: sposób decydowania nad czym pracować (strategia), sposób rozwiązywania problemów (discovery) oraz sposób budowania rozwiązań (continuous delivery)
Jedynie 20% funkcji rzeczywiście rozwiązuje leżący u podstaw problem – większość firm marnuje zasoby na projekty bez efektów
Cztery kompetencje niezbędne do transformacji: product designer, tech lead, prawdziwy product manager oraz product leader
Pilot teams stanowią klucz do transformacji – proces zaczyna się małymi zespołami i stopniowo buduje zaufanie organizacji
Przykłady udanych transformacji z całego świata pokazują możliwość zmiany poza Doliną Krzemową
Praca zdalna spowalnia innowacje, szczególnie w fazie discovery i współpracy między różnymi kompetencjami

Geneza książki „Transformed”

Cagan wyjaśnił motywację stojącą za napisaniem kolejnej książki. Po wydaniu pozycji „Inspired” i „Empowered” najczęstszą reakcją czytelników było przekonanie, że praca według opisywanych zasad jest niemożliwa poza Doliną Krzemową. Ludzie twierdzili, że w ich firmach transformacja nie może się udać.

Dlatego też w „Transformed” autor świadomie nie umieścił ani jednego przykładu z Doliny Krzemowej. Wszystkie case studies pochodzą z firm z różnych branż i regionów świata. Celem było ostateczne obalenie mitu o niemożliwości transformacji.

Podczas prezentacji Cagan przyznał, że znajduje się na etapie kariery, gdzie nie martwi się już tym, czy kogoś rozezłości, jeśli pomoże ludziom. Widzi zbyt wielu product managerów, którzy są sfrustrowani swoją pracą i mówią: „Na to się nie pisałem.” Głównym problemem jest sprowadzenie ich roli do bycia „odbiorcami zamówień” (order takers) w tradycyjnych feature teams – faktycznie „fabrykach ficzerów” zamiast motorów innowacji.

Product operating model – trzy wymiary transformacji

Cagan definiuje product operating model jako koncepcyjny framework oparty na zasadach, a nie sztywny proces. Najlepsze firmy technologiczne – Amazon, Netflix, Stripe, Google, Spotify czy Apple – mają różne kultury i metody pracy, jednak wspólne są im podstawowe zasady produktowe.

Model koncentruje się na trzech fundamentalnych pytaniach dotyczących funkcjonowania organizacji:

Sposób decydowania nad czym pracować

W tradycyjnym modelu firmy nie podejmują rzeczywistych decyzji strategicznych. Zamiast tego alokują zasoby różnym stakeholderom, z których każdy ma własną listę funkcji do realizacji. Według Cagana nie jest to strategia produktowa, lecz jedynie delegowanie odpowiedzialności.

Prawdziwa product strategy wymaga holistycznego spojrzenia na najważniejsze szanse i największe zagrożenia. Musi być procesem ciągłym – mimo że aktualizacje następują zazwyczaj co kwartał, strategia otrzymuje nowe dane nieustannie. Gdy zespół w fazie discovery odkryje istotną informację, natychmiast wpływa ona na kolejną iterację strategii.

Sposób rozwiązywania problemów

Większość organizacji nawet nie próbuje rzeczywiście rozwiązywać problemów. Stakeholderowie przekazują gotowe rozwiązania – funkcje wymyślone przez zespół sprzedaży, inne działy czy CEO. Zespoły otrzymują spriorytetyzowane listy funkcji, nazywają je roadmapą i skupiają się na implementacji.

Cagan przywołuje statystyki branżowe pokazujące, że około 20% takich funkcji rzeczywiście rozwiązuje leżący u podstaw problem. Transformacja oznacza dawanie zespołom problemów do rozwiązania zamiast gotowych specyfikacji funkcji.

Sposób budowania rozwiązań

Cagan krytykuje firmy twierdzące, że są „agile”, podczas gdy wypuszczają wersje co miesiąc lub kwartalnie. Jego zdaniem to nie jest prawdziwe podejście agile. Bez możliwości szybkiego reagowania na problemy klientów w ciągu minut czy godzin firma nie może skutecznie konkurować.

Szczególnie krytyczny jest wobec SAFe (Scaled Agile Framework), nazywając go „wodospadem w przebraniu” i „czystym marketingiem”. „To nie jest agile w żadnej formie – to dosłownie waterfall” – mówi. Firmy używające SAFe świadomie priorytetowo traktują przewidywalność nad innowacją, co doskonale ilustruje zasada Spotify: „Stuprocentowa przewidywalność oznacza zero innowacji.”

Model projektowy tworzy również ogromne ilości „osieroconych aplikacji” – oprogramowania, którego nikt nie utrzymuje po zakończeniu projektu. Cagan nazywa to maszyną do tworzenia długu technicznego.

Cztery kluczowe kompetencje

Każdy empowered product team potrzebuje ludzi z określonymi umiejętnościami:

Product designer – osoba znająca service design, interaction design, visual design oraz user research z holistycznym podejściem do projektowania
Tech lead – inżynier dbający nie tylko o to, jak budować, ale również o to, co budować
Product manager – osoba rozumiejąca wartość dla klienta i business viability, znająca dane, klientów oraz wszystkie wymiary biznesu
Product leader – rozwijający ludzi przez coaching i tworzący poważną strategię produktową

Największa różnica dotyczy roli product managera. W feature teams osoba z tym tytułem zajmuje się głównie komunikacją, koordynacją i dostarczaniem – jest to praca project managera. Cagan ostrzega, że wielu CEO zastanawia się, czy product managerzy w feature teams są w ogóle potrzebni, skoro designerzy i inżynierowie mogliby równie dobrze zarządzać projektami.

Problem polega na tym, że większość ludzi trafia na niewłaściwą ścieżkę edukacyjną. Gdy nowy product manager szuka informacji w Google, najprawdopodobniej trafi na materiały o pracy w feature teams. Generative AI tylko pogarsza tę sytuację, ponieważ opiera się na przeważających treściach w internecie.

Jednak przejście od feature team PM do empowered team PM zajmuje około trzech miesięcy, pod warunkiem że osoba chce się uczyć i ma kogoś, kto ją nauczy.

Pięć filarów product operating model

Product culture określa sposób podejmowania decyzji oraz rolę innowacji w stosunku do przewidywalności. Spotify stosuje zasadę: „100% przewidywalności równa się 0% innowacji.”

Product strategy koncentruje się na focus, strategiach opartych na insights oraz myśleniu w kategoriach zakładów. To jedna z najważniejszych rzeczy, które robią product leaders.

Product teams są empowered i accountable, skupiają się na minimalizowaniu marnotrawstwa. Otrzymują problemy do rozwiązania, nie gotowe funkcje do implementacji.

Discovery i delivery – gdzie discovery stanowi proces rozwiązywania problemów, natomiast delivery wymaga małych, częstych, niezawodnych wydań z pełną instrumentacją.

Strategic context – zespoły potrzebują kontekstu do podejmowania dobrych decyzji: product vision, team topology, product strategy oraz konkretne objectives.

Przykłady transformacji spoza Doliny Krzemowej

Cagan przedstawił firmy, które udowodniły możliwość transformacji w różnych regionach świata:

Kaiser Permanente stworzył rozwiązanie „get care now” na tyle imponujące, że Cagan początkowo nie wierzył w jego skuteczność. CarMax przetrwał 85% spadek przychodów podczas pandemii i wyszedł silniejszy niż kiedykolwiek. Trainline z Wielkiej Brytanii osiąga wyższą ocenę w App Store niż Uber w dni powszednie. Gympass z Brazylii zrealizował innowacje, które Cagan określa jako niesamowite.

Każda z tych firm po transformacji mogła realizować projekty, o których wcześniej nie marzyła. Właśnie to stanowi cel transformacji – nie sam proces, lecz nowe możliwości.

Proces rozpoczynania transformacji

Pilot teams – etapowy rozwój

Cagan porównuje transformację do gry wielopoziomowej. Na pierwszym poziomie zespół rozwija podstawowe umiejętności, następnie po wykazaniu się nimi uzyskuje dostęp do kolejnego poziomu:

Poziom 1: Jeden pilot team
Poziom 2: Grupa zespołów
Poziom 3: Jednostka biznesowa
Poziom 4: Cała firma

Autor zachęca do myślenia z perspektywy CEO: czy powinna zaufać, że organizacja produktowa wie, jak pracować w nowym modelu? To odpowiedzialne ze strony CEO sprawdzenie, czy ludzie potrafią to robić dla jednego zespołu, zanim pozwoli im działać w większej skali.

Warunki sukcesu i pułapka user research

Najgorsze, co można zrobić, to stworzyć pilot team z ludźmi nieznającymi pracy w product operating model. Zespół musi składać się z osób już znających ten sposób pracy, mieć managera potrafiącego ich tego nauczyć lub korzystać z zewnętrznego coacha.

Cagan ostrzega przed częstym błędem pilot teams – pułapką user research. Empowered team często chce zacząć od user research, aby sprawdzić, czy problem rzeczywiście istnieje. To jednak polityczna katastrofa.

Firma prawdopodobnie już wie, że to prawdziwy problem po latach rozmów z klientami. Gdy zespół mówi „zrobimy własny research, możecie się mylić”, marnuje swój kapitał polityczny i cenny czas. Z perspektywy CEO wygląda to tak: dajemy problem do rozwiązania, a zespół chce dwa miesiące na research, żeby dowiedzieć się tego, co już wiemy. Potem zostaje tydzień na znalezienie rozwiązania.

Polityka stakeholderów i zdobywanie zaufania

Jeden z największych wyzwań transformacji to zmiana relacji ze stakeholderami. W starym modelu stakeholderowie są w pozycji decyzyjnej – określają, co ma być zrobione. W nowym modelu nie oznacza to, że product team przejmuje kierownictwo – znaczy, że wszystkie strony współpracują.

Transformacja to przede wszystkim wyzwanie dotyczące ludzi. Product leaders muszą systematycznie zdobywać „hearts and minds” stakeholderów, jeden po drugim. Cagan wspomina swojego partnera Christiana Idiotiego jako mistrza w tej dziedzinie – najbardziej utalentowanego product leadera, jakiego spotkał. Potrafi sprawić, że stakeholderowie czują się prawdziwymi partnerami zespołu produktowego.

Kluczowe jest zrozumienie, że klienci nie kupują problemów – kupują rozwiązania. Jeśli rozwiązanie nie jest wyraźnie lepsze od alternatyw, klienci nie będą kupować. Dlatego koncentracja na jakości rozwiązań ma kluczowe znaczenie.

Współczesne wyzwania product teams

Problem pracy zdalnej

Cagan szczerze przyznaje: Prawie wszystkie firmy, z którymi współpracuję, są remote. To jest znacznie wolniejsze i znacznie mniej innowacyjne. Problem nie dotyczy delivery, lecz discovery – rzeczywistej współpracy między różnymi kompetencjami.

Steve Jobs nazywał to „necessary friction”. Pokazywanie pomysłów na Zoom czy przez Slack po prostu nie działa. Ludzie unikają konfliktów, ponieważ w pracy zdalnej konflikty wyglądają inaczej. Psychological safety szybko się rozpada – albo unikają trudnych rozmów, albo budują urazy.

Jeśli kolokalizacja całego zespołu nie jest możliwa, Cagan preferuje przynajmniej współlokalizowane zespoły w różnych miastach na świecie – dostęp do talentów globalnie przy lokalnej współpracy.

Wpływ sztucznej inteligencji

Cagan jest entuzjastycznie nastawiony do wpływu AI na inżynierów i designerów, jednak najbardziej martwi się o product managerów. Najważniejszą rzeczą, której naucza product managerów, jest myślenie, natomiast generative AI stanowi prawdopodobnie największy przeciwnik w nauce myślenia product managerów.

Dlatego też zmienił swoje rekomendacje dotyczące AI. Wcześniej mówił: „Zacznij od ChatGPT, potem poprawiaj.” Teraz, widząc jak ludzie przynoszą surowe wyniki z ChatGPT, radzi odwrotnie: „Najpierw myśl, potem używaj ChatGPT do sprawdzenia i ewentualnego znalezienia dziur w rozumowaniu.”

Product ownerowie i project managerzy w feature teams są najbardziej zagrożeni – to jedne z najłatwiejszych ról do zautomatyzowania.

Praktyczne wskazówki

Rozpoznawanie product operating model podczas rekrutacji

W wywiadach łatwo rozpoznać, czy firma pracuje w product operating model. Różnice między feature teams a empowered teams nie są subtelne – to fundamentalne różnice.

Pytania diagnostyczne:

Jak wygląda proces tworzenia roadmapy?
Skąd pochodzą daty na roadmapie?
Kto decyduje, nad czym zespół pracuje?
Jak zespół otrzymuje nowe zadania?
Czy zespół może wpływać na priorytety?
Jak mierzone są sukcesy zespołów?
Ile czasu zajmuje wydanie nowych funkcjonalności?

Red flags (oznaki feature teams):

Roadmapa pełna konkretnych funkcjonalności z ustalonymi datami
Product manager spędzający większość czasu na koordynacji i komunikacji
Miesięczne lub rzadsze wydania nowych wersji
Zespoły otrzymują gotowe specyfikacje do implementacji
Sukces mierzony wydanymi funkcjami i dotrzymanymi terminami

Green flags (oznaki empowered teams):

Roadmapa skupiona na problemach i outcomes biznesowych
Regularne rozmowy z klientami i analiza danych
Częste, małe wydania z pełną instrumentacją
Kultura eksperymentowania i A/B testów
Zespoły mają autonomię w sposobie rozwiązywania problemów
Sukces mierzony wpływem na metryki biznesowe

Różnice między modelami

Oznaki feature team: otrzymywanie gotowych specyfikacji funkcji, roadmapa składająca się z listy projektów z datami, PM skupiający się na koordynacji, sukces mierzony wydanymi funkcjami.

Oznaki empowered team: otrzymywanie problemów do rozwiązania, roadmapa zawierająca outcomes, PM znający klientów i biznes, sukces mierzony wpływem na metryki.

Dodatkowe role wspierające

Większość firm potrzebuje też delivery managers, program managers lub project managers do obsługi koordynacji i komunikacji. Cagan radzi product managerom świadome delegowanie zadań związanych z delivery, aby w pełni skupić się na swoim głównym zadaniu: discovery.

Apple stanowi przykład firmy, która nie mogłaby nic wypuścić bez swoich program managers – koordynują złożone systemy jak integracja AirPods ze wszystkimi urządzeniami.

Firmy potrzebują również data analysts (pomagających zespołom podejmować decyzje na podstawie danych) i data scientists (budujących produkty oparte na danych). To różne role z odmiennymi celami.

System motywacyjny

W przeciwieństwie do sprzedaży, product teams nie powinny mieć indywidualnych programów motywacyjnych. Cel to sprawienie, żeby każdy zespół pomagał każdemu innemu zespołowi. Dlatego też equity i stock options działają dobrze – wszyscy mają motywację do sukcesu całej firmy.

Discovery a R&D

Dla współpracy z CFO istotne jest rozróżnienie: discovery to nie research & development – to product development. Ta różnica w nazewnictwie ma znaczenie dla budżetowania i podejścia do kosztów.

Siła prototypów

Zamiast prezentacji PowerPoint pełnych obietnic, warto stworzyć działający prototyp w Figma. Pozwól prototypowi mówić za siebie. Ludzie widzą różnicę między obietnicą a działającą demonstracją.

Lista polecanych książek

Na podstawie prezentacji:

„Transformed” – Marty Cagan (o transformacji organizacyjnej)
„Inspired” – Marty Cagan (podstawy product management)
„Empowered” – Marty Cagan (dla product leaders)
„Creative Selection” – Ken Cosienda (kulisy tworzenia iPhone’a w Apple)
„Loved” – Martina Lauchengco (o product marketing)

Kluczowy insight

Pułapka user research

Standardowo myślimy: Empowered product team powinien zacząć od user research, aby sprawdzić, czy problem rzeczywiście istnieje i czy jest najważniejszy dla użytkowników.

W praktyce okazuje się, że: To najgorsze, co można zrobić politycznie. Firma prawdopodobnie już wie, że to prawdziwy problem po latach rozmów z klientami. Gdy mówisz „zrobimy własny research, możecie się mylić”, marnujesz swój kapitał polityczny i cenny czas.

Dlaczego to jest istotne: W momencie gdy stajesz się empowered team, zegar zaczyna tykać. Jeśli zmarnujesz dwa miesiące na research, aby dowiedzieć się tego, co firma już wie, zostanie tydzień na znalezienie rozwiązania, zanim stracisz zaufanie.

Test na jutro: Następnym razem, gdy dostaniesz problem do rozwiązania, zamiast kwestionować, czy to prawdziwy problem, spróbuj przyjąć, że jest, i skup się na stworzeniu świetnego rozwiązania. W najgorszym przypadku pierwsze testy prototypu pokażą, czy problem rzeczywiście istnieje.

Ten wpis stanowi część kolekcji notatek z wartościowych prezentacji, podcastów i webinarów. Link do oryginalnej prezentacji: https://www.youtube.com/watch?v=jk2ZUP_dM2k

Tag: Silicon Valley Product Group

Product operating model według Marty’ego Cagana – notatki z prezentacji Transformed #EN260