Te notatki pochodzą z prezentacji Marty Cagana podczas ProductTank Oslo. Wszystkie przemyślenia, obserwacje i wnioski przedstawione poniżej to słowa i doświadczenia eksperta product managementu, a nie autora niniejszego tekstu.

TL;DR

Prawdziwa transformacja oznacza zdolność wykorzystywania nowych możliwości, jak Guardian z aplikacją Eyewitness stworzoną w 7 tygodni
Empowered product teams to fundament sukcesu – zespoły rozwiązujące problemy, nie wdrażające funkcjonalności
Zewnętrzne bariery obejmują command & control, brak wsparcia CEO, outsourcing inżynierów i presję ze strony sprzedaży
Wewnętrzne wyzwania to głównie nadmiar procesów, słabi product managerzy i przytłaczający dług techniczny
Procesy nie zastępują myślenia – skalowanie przez liderów, nie przez SAFE czy inne frameworki
Coaching product managerów to klucz do sukcesu, wymagający inwestycji w rozwój kompetencji
Europa ma szczególny problem z uzależnieniem od procesów kosztem rzeczywistej wartości produktowej

Czym naprawdę jest transformacja produktowa

Cagan rozpoczyna swoją analizę od fundamentalnego pytania, które dowodzi sukcesu transformacji: „Co możecie zrobić teraz, czego nie byliście w stanie zrobić wcześniej?”

Pandemia z kolei posłużyła jako test dla wielu firm twierdzących, że już się transformowały. Część firm zniknęła z rynku. Inne jednak nie tylko przetrwały, ale znacząco zwiększyły swoją wartość.

Historia Guardiana – jak wygląda udana transformacja

Cagan opisuje historię brytyjskiego Guardiana, który prawie upadł przez internet. Firma istniała już 200 lat i przetrwała dwie wojny światowe, jednak internet niszczył jej model biznesowy.

Rada nadzorcza mimo to podjęła kluczową decyzję – powołała Judy Gibbons, byłą dyrektorkę Apple i Microsoft, na przewodniczącą rady. To był pierwszy krok w dobrą stronę.

Gdy pojawił się iPhone, Guardian stworzył aplikację uznaną przez Apple za najlepszą aplikację newsową na świecie. Zespół składał się z zaledwie 5 osób: trzech inżynierów, product managera i designera.

Eyewitness – aplikacja stworzona w 7 tygodni

Jonathan Moore, product manager z tego zespołu, otrzymał telefon z Apple z prośbą o przylot do Cupertino. Apple właśnie przygotowywało się do premiery iPada, a Steve Jobs osobiście zachęcił do stworzenia aplikacji na nowe urządzenie.

Warunki były trudne – tylko 7 tygodni na stworzenie kompletnie nowej aplikacji na nieznane urządzenie. Moore’owi jednak udało się wykorzystać niewykorzystany zasób Guardiana – zdjęcia.

W rezultacie Eyewitness opowiadała wiadomości przez fotografie. Każdego dnia redaktor zdjęć wybierał jedno zdjęcie z wydarzeń na świecie, dziennikarz pisał krótką historię, a czytelnicy mogli zobaczyć szczegóły aparatu użytego do zrobienia zdjęcia.

Steve Jobs zatrzymał się na Eyewitness podczas prezentacji iPada i powiedział: „To jest to, o co chodzi w tym urządzeniu.”

Przez pierwszy rok niemal każda osoba kupująca iPada instalowała Eyewitness. Dla firmy wiszącej na włosku to oznaczało przetrwanie – 600 dziennikarzy do utrzymania to nie bułka z masłem.

Cagan podkreśla skalę tego osiągnięcia: „Większość firm, jakie znam, nawet naprawdę dobre firmy, nawet Google, nawet Amazon, miałyby problem z zrobieniem czegoś takiego w siedem tygodni.”

Fundament transformacji: empowered product teams

Według Cagana sukces Guardiana opierał się na empowered product teams – zespołach, które otrzymują problemy do rozwiązania, a nie funkcjonalności do wdrożenia. To fundamentalne różnica w stosunku do „fabryk ficzerów” (feature teams), które tylko implementują cudze pomysły.

Trzy nierozerwalne filary empowered teams

Cross-functional zespół kompetentnych ludzi z niezbędnym zakresem umiejętności – product manager, designer i inżynierowie pokrywający wszystkie aspekty produktu
Problemy do rozwiązania, nie funkcjonalności z roadmapy – zespół dostaje jasny problem i sam wymyśla najlepsze rozwiązanie
Odpowiedzialność za rezultaty biznesowe – nie wystarczy dostarczyć feature, liczą się realne wyniki dla firmy

Trzy praktyczne oznaki dobrego zespołu produktowego

Adresowanie ryzyka przed kodowaniem – zespół odpowiada na cztery pytania: czy wartościowe, czy użytkowalne, czy możliwe do zbudowania, czy biznesowo opłacalne
Kolaboracyjne rozwiązywanie problemów – product manager (wartość/opłacalność), designer (użyteczność) i inżynierowie (wykonalność) pracują razem od początku
Mierzenie rezultatami, nie dostarczaniem – celebration następuje po osiągnięciu biznesowego wyniku, nie po wypuszczeniu feature’a

Złe zespoły natomiast pracują sekwencyjnie – product manager definiuje wymagania, następnie przekazuje je designerowi, ten tworzy wireframes, a dopiero potem inżynierowie dostają wszystko na sprint planning. To doskonały przykład waterfall ukryty za agile ceremonies.

Zespoły otrzymują problemy do rozwiązania, bo jak wyjaśnia Cagan: „Dlaczego empowered team? Bo inżynierowie pracują z najnowszą technologią każdego dnia i testują to z prawdziwymi użytkownikami każdego tygodnia. Są w najlepszej pozycji, żeby wymyślić najlepsze rozwiązanie.”

Kluczowa prawda: innowacje nie pochodzą od klientów ani product managerów. Pochodzą od inżynierów. Jeśli inżynierowie nie są obecni od początku przy tworzeniu pomysłów, marnujesz ich potencjał.

Dlaczego klienci nie mogą mówić co budować

Kluczowy problem z sales-driven czy marketing-driven product: klienci i nasze własne dyrekcje nie wiedzą, co właśnie stało się możliwe do zrobienia.

To dlatego focus groups nie działają. To również dlatego marketing-driven product nie działa. Jak mówi Jeff Bezos: „Wasza praca to wymyślać świetne rozwiązania w imieniu naszych klientów.”

Żaden z nas nie wie naprawdę czego chce, nawet my sami, dopóki tego nie zobaczymy. Dlatego dobre firmy robią tyle prototypowania. Muszą to zobaczyć zanim zdecydują, czego naprawdę chcą.

Cagan jest w tym kontekście kategoryczny: „Jeśli nie robisz ciągłego prototypowania, mogę ci powiedzieć tylko jedno – nie robisz dobrego produktu.”

Zewnętrzne bariery transformacji – główne czerwone flagi

Command and control – liderzy podejmują decyzje i przekazują instrukcje w dół, różnica między tym a „lead with context, not control”
CEO deleguje transformację na chief digital officer – znak, że lider nie chce brać odpowiedzialności za zmiany
Zatrudnianie McKinsey/Bain/BCG – expensive „cover your ass” bez rzeczywistego zrozumienia produktowych firm
Sales-driven roadmapa – sprzedaż dyktuje co budować, rozwiązanie to reference customers
Marketing-driven product – starzy CMO myślą, że powinni rozmawiać z klientami i mówić produktowi co budować
Project-based funding przez CFO – wymaganie business cases z dokładnymi prognozami, których nie można znać
Predictability addiction – skupienie na „kiedy” zamiast na „czy będzie wartościowe”
CIO zamiast CTO – różnica między cost center a profit center w podejściu do technologii
Outsourcing inżynierów – najgorszy możliwy błąd, bo innowacje pochodzą od inżynierów, nie od product managerów
Przytłaczający tech debt – zabija firmy, szczególnie te zarządzane przez CIO zamiast CTO

Reference customer to ktoś, kto używa produktu w produkcji, zapłacił za niego prawdziwą cenę i kocha go na tyle, żeby polecać innym. To główny sposób na rozwiązanie problemu sales-driven roadmap.

Różnica między CIO a CTO jest fundamentalna – CIO prowadzi cost center, CTO prowadzi profit center. To kompletnie różne nastawienie do technologii.

Wewnętrzne wyzwania – problemy w zespołach

Obsesja na punkcie procesów – szczególnie w Europie, where process becomes substitute for thinking
Product owners zamiast product managerów – błędne oczekiwanie, że praca to administrowanie backlogiem w Jira
SAFE i pseudo-agile frameworki – powrót do waterfall i kwartalnych release’ów pod przykrywką agile
Niewystarczający poziom product managerów – brak prawdziwych kompetencji w product managemencie
Inżynierowie „którzy chcą tylko kodować” – tracisz połowę ich wartości
Za dużo keep-the-lights-on pracy – ponad 20-30% czasu zespołu na drobne rzeczy
Za dużo równoczesnych inicjatyw – brak focus, 50 projektów jednocześnie
Tech debt wewnątrz zespołów – wszystko co normalnie zajmuje dni, teraz zajmuje tygodnie
Za duża presja empowered teams – więcej odpowiedzialności i stresu niż feature teams
Outcomes są trudne – ale to właśnie jest istotą dobrych zespołów produktowych

Balans pracy w każdym zespole

Każdy zespół produktowy, nawet świetny empowered team, ma jednak pewną ilość „keep the lights on” pracy – implementowanie GDPR, poprawki błędów, performance work.

Cagan zaleca monitoring: jeśli tego typu prace przekraczają 20-30% czasu zespołu, prawdopodobnie zespół potrzebuje dodatkowego inżyniera dla lepszego balansu.

Tech debt z kolei jest łatwy do rozpoznania – wszystko co normalnie zajmuje kilka dni, teraz zajmuje kilka tygodni. To znak, że tech debt wymknął się spod kontroli.

Ukryta prawda o presji w empowered teams

To bardzo ważny punkt, który Cagan szczerze omawia. Empowered product team to znacznie większa presja niż feature team.

W feature teams dostajesz roadmapę funkcjonalności i wykonujesz zadania. Jeśli funkcjonalności nie działają, prawdopodobnie i tak nie miałeś wielkich nadziei – nie ty je wybierałeś.

Ale gdy dostajesz problemy do rozwiązania, czujesz odpowiedzialność: „Dali mi możliwość wymyślenia tego, więc chyba muszę to wymyślić.”

To znacznie więcej pracy i więcej stresu. Nie przekłada się to bezpośrednio na więcej godzin, ale definitywnie więcej odpowiedzialności.

Cagan przyznaje szczerze: „Między pracą a presją, myślę że uczciwie można powiedzieć – to więcej stresu. I czasami ludzie po prostu tego nie chcą.”

Odpowiedzialność za rzeczy poza bezpośrednią kontrolą

Zespoły martwią się podpisywaniem pod wyniki, które mogą zależeć od zmian w sprzedaży czy marketingu. Jednak Andy Grove, twórca OKRs, zaprojektował je właśnie w ten sposób.

Jego argument: kto ma większą zdolność wpływania na rzeczy niż zespoły produktowe? Jeśli produkt się nie sprzedaje, product manager powinien iść z salesami i dowiedzieć się dlaczego.

Cagan tłumaczy: „Wyobraź sobie, że jesteś w sprzedaży – co możesz zrobić, jeśli produkt nie jest dobry? Wciąż masz kwotę do wypełnienia.”

Europa i problem z procesami

Cagan ma szczególnie mocne zdanie o problemie europejskim: „Europa wydaje się być zakochana w procesów. To mnie zabija.”

Cytuje Elona Muska: „Problem z procesami polega na tym, że stają się substytutem myślenia.” Steve Jobs ostrzegał przed „process people” – jeśli process people zostają szefami, firma ma problem.

SAFE nie jest agile w żaden sposób – to czysta marketing. Cagan nie potrafi wskazać ani jednej dobrej produktowej firmy używającej SAFE. To powrót do waterfall i kwartalnych release’ów.

Zapytał niedawno SAFE coach’a: „Czy widziałeś jakąkolwiek firmę, która wdrożyła to z sukcesem?” Odpowiedź: „Nie, nie widziałem. Ale to jest źródło całego mojego przychodu.”

Product owner to rola w procesie, nie stanowisko pracy – radzi usunąć to z profilu LinkedIn. Ludzie myślą, że ich praca to administrowanie backlogiem w Jira. To może 10% zadań product managera.

Narzędzia jako backdoor dla procesów

Bądź ostrożny z narzędziami – one dyktują konkretne procesy i to podstępny sposób ich wprowadzenia.

Jeśli zgadzasz się z procesem, który narzędzie narzuca – świetnie. Ale wiele osób mówi: „Weźmy narzędzie do OKRs” czy „roadmap tool”, nie zdając sobie sprawy, że są różne sposoby robienia OKRs i różne sposoby roadmaps.

Najlepsze zespoły używają Google Docs, bo nie chcą być ograniczane. Wiele roadmap tools po prostu liczy ile osób prosi o każdą funkcjonalność i pozwala priorytetyzować w ten sposób.

Cagan ostrzega: „Dobre zespoły powiedzą ci, że to dokładnie odwrotny sposób pracy.”

Continuous delivery i celebrowanie wyników

Większość dobrych zespołów produktowych robi coś, co nazywa się continuous delivery – wiele małych release’ów każdego dnia.

Dawniej wypuszczaliśmy co rok, czasem co 18 miesięcy. Potem co kilka miesięcy. Teraz codziennie.

„Nie robisz imprezy za każdym razem gdy wypuszczasz release. Czekasz aż naprawdę coś osiągniesz – outcome – i wtedy to świętujesz.”

Cagan dzieli się osobistym wyznaniem: „Nigdy nie miałem satysfakcji z samego dostarczenia deliverable. To nie ma znaczenia, szczególnie dzisiaj.”

Outcomes są trudne – ale o to właśnie chodzi

Wiele zespołów się tego boi, ale outcomes są trudne właśnie dlatego, że o tym są dobre zespoły produktowe – wymyślanie sposobu na osiągnięcie tego wyniku.

Na pytanie o quantified outcomes, Cagan wyjaśnia różnicę: „Zwykle objective jest jakościowe, ale key results są kwantytatywne.”

Objective: „Zostać dominującym dostawcą w Norwegii” (jakościowe) Key Result: „Dla nas to oznacza 10 milionów pobrań” (kwantytatywne)

Problem pojawia się, gdy ludzie skupiają się tylko na liczbach bez zrozumienia prawdziwego celu.

Skalowanie przez liderów, nie procesy

Istnieją tylko dwa sposoby skalowania firm: przez procesy albo przez liderów. Dobre firmy produktowe zawsze wybierają liderów.

W empowered organizacji nie potrzebujesz mniej przywództwa – potrzebujesz lepszego przywództwa. Znacznie łatwiej jest command and control.

Netflix stawia „empowerment” na najwyższy poziom. Reed Hastings w „No Rules Rules” opisuje przekazywanie decyzji zespołom przez dostarczanie strategicznego kontekstu: product vision, product strategy, team topology i objectives.

Żeby to działało z 50+ zespołami produktowymi, musisz mieć pewność, że nie idziesz w 50 różnych kierunków. Tu właśnie przywództwo odgrywa aktywną rolę.

Skalowanie a motywacja – różnica Europa vs USA

Na pytanie o motywację w Europie vs USA, Cagan zwraca uwagę na różnice w strukturze własności. Bezos mówi, że kluczem sukcesu Amazonu jest zatrudnianie ludzi, którzy myślą jak właściciele, nie jak pracownicy.

„Najłatwiejszym sposobem na osiągnięcie tego jest uczynienie ich właścicielami” – wszyscy w Amazon dostają akcje firmy. W USA wiele osób kupiło domy dzięki akcjom firm technologicznych.

Venture capitalists pytają Cagana: jak poprawić poziom motywacji w europejskich inwestycjach? „Musicie znaleźć sposób, żeby jeśli zespoły robią dobrze, oni na tym skorzystali.”

Hardware vs software – wyzwania discovery

Na pytanie o produkty hardware’owe, Cagan podkreśla różnice w skali ryzyka. W software można zawsze zrobić patch jutro. W hardware błąd może zabić firmę.

Apple robi więcej prototypów niż ktokolwiek inny, bo wiedzą o tym ryzyku. Discovery dla pierwszego iPhone’a trwało 3,5 roku – normalnie dla software może to być 3 miesiące lub 3 tygodnie.

Newton Apple’a upadł, bo było za trudno wprowadzać tekst. Właśnie dlatego zespół iPhone’a był najbardziej zdenerwowany wprowadzaniem tekstu – to było ich największe ryzyko.

Agencies i consulting – czy można zachować ownership?

Na pytanie o agencje, Cagan zauważa, że wiele z nich próbuje przejść „upstream” i dostarczać więcej wartości. Projektanci w agencjach są często sfrustrowani implementowaniem złych projektów od osób, które naprawdę nie są product people.

Tylko kilka agencji udowodniło, że może zdobyć to zaufanie – IDEO był jedną z pierwszych. To wymaga relacji z klientem, gdzie można powiedzieć: „Możemy to zrobić, ale tak naprawdę nie tego chcesz. Chcesz, żebyśmy rozwiązali ten problem.”

Tender-based business models

Na pytanie o firmy działające przez przetargi (tenders/RFPs), Cagan wyjaśnia podstawową różnicę między product companies a custom solution companies.

Product companies robią jedno, sprzedają tysiącom lub milionom. Custom solution companies (jak Accenture) są przygotowane do jednorazowych, customowych rozwiązań.

Prawdziwe pytanie: czy klienci chcą jednorazowego custom rozwiązania, czy naprawdę chcą generalnego rozwiązania? Wiele firm telco myśli, że są wyjątkowe, ale tak naprawdę nie są.

W HP Dave Packard wprowadził zasadę: „Nie robimy przetargów. Jeśli chcesz kupić jeden z naszych produktów z półki, chętnie ci sprzedamy. Ale nie będziemy robić custom solutions.” Powiedział to nawet rządowi USA.

Znaczenie coachingu w rozwoju

Ben Horowitz argumentuje, że najważniejszą non-C-level rolą w tech produktowej firmie jest manager product managerów. Produkty są tylko tak dobre, jak zespoły produktowe. Ale zespoły są tylko tak dobre, jak ich product manager.

Cagan ostrzega liderów produktu: „Będziesz oceniany przez swojego najsłabszego product managera.” CEO powinni znać swoich product managerów po imieniu i wierzyć, że każdy ma potencjał zostać przyszłym liderem firmy.

Przykład rozwoju product managera – historia z HP

Cagan dzieli się własnym doświadczeniem przejścia z inżyniera na product managera w HP. Jego mentor postawił jasne warunki: „Nie będziesz mógł podjąć ani jednej decyzji dla swojego zespołu, dopóki nie odwiedzisz 30 klientów – 15 w USA, 15 w Europie.”

Ta podróż zmieniła jego perspektywę. Dowiedział się jednak, że deweloperzy w HP to nie to samo co deweloperzy w Walmart, FedEx czy Deutsche Telekom.

Mentor zidentyfikował trzy główne braki w wiedzy:

Znajomość prawdziwych klientów – trzeba rozumieć rzeczywistych użytkowników, nie tylko założenia o nich.

Zrozumienie go-to-market – jak produkty docierają od zespołu do rąk prawdziwych klientów, współpraca z sales, marketing, tech sales.

Analityka finansowa – od podstaw księgowości po KPI konkretnego produktu, rozumienie kosztów i contribution margins.

Cały proces z kolei zajął około trzech miesięcy intensywnego uczenia się z mentorem i osobami z działu finansów.

Praktyczne checklisty

Checklist empowered product teams

Struktura i ludzie □ Ma product managera (nie product ownera)
□ Ma prawdziwego product designera
□ Ma co najmniej jednego seniora inżyniera zaangażowanego w product discovery
□ Wszyscy są kompetentni w swoich obszarach

Sposób pracy □ Dostaje problemy do rozwiązania, nie features do implementacji
□ Adresuje wszystkie 4 ryzyka przed kodowaniem (value, usability, feasibility, viability)
□ Pracuje kolaboracyjnie nad rozwiązaniami
□ Robi regularnie product discovery z rzeczywistymi użytkownikami

Odpowiedzialność □ Jest accountable za business outcomes, nie tylko delivery
□ Ma jasne objectives i key results
□ Może wpływać na czynniki potrzebne do sukcesu
□ Świętuje achievementy biznesowe, nie release dates

Checklist czerwonych flag transformacji

Zewnętrzne sygnały ostrzegawcze: □ CEO delegował transformację na chief digital officer
□ Zatrudniono McKinsey/Bain/BCG do „pomocy” w transformacji
□ Sales dyktuje roadmapę na podstawie prospectów
□ CFO wymaga detailed business cases dla każdego projektu
□ Inżynieria jest outsource’owana
□ Organizacja jest obsessed predictability ponad value

Wewnętrzne sygnały ostrzegawcze: □ Ludzie mają tytuły „product owner” zamiast „product manager”
□ Zespoły używają SAFE lub podobnych „scaled agile” frameworków
□ Process coaches trenują product managerów
□ Inżynierowie „chcą tylko kodować”
□ Ponad 30% czasu zespołu to keep-the-lights-on work
□ Narzędzia dyktują sposób pracy zespołów

Checklist oceny transformacji (podział strategiczny)

Poziom strategiczny – czy jesteśmy na dobrej drodze? □ CEO osobiście prowadzi i wspiera transformację
□ Nasze zespoły otrzymują problemy do rozwiązania, a nie gotowe roadmapy
□ Rozliczamy zespoły z wyników biznesowych (outcomes), a nie z dostarczonych funkcji (output)
□ Nasi inżynierowie są partnerami w wymyślaniu rozwiązań, a nie tylko „fabryką kodu”
□ Myślimy o technologii jak o centrum zysków (CTO), a nie centrum kosztów (CIO)
□ Nasi liderzy skupiają się na dostarczaniu kontekstu i coachingu, a nie na mikrozarządzaniu

Poziom zespołu – czy nasz zespół jest naprawdę „empowered”? □ Jako zespół mamy bezpośredni kontakt z klientami i użytkownikami co tydzień
□ Wspólnie (PM, projektant, inżynierowie) pracujemy nad rozwiązaniami od samego początku
□ Regularnie prototypujemy i testujemy nasze pomysły przed ich wdrożeniem
□ Mamy jasno zdefiniowane cele biznesowe (outcomes), do których dążymy w tym kwartale
□ Co najmniej 80% naszego czasu poświęcamy na pracę nad tymi celami, a nie na zadania utrzymaniowe
□ Nasi menedżerowie pomagają nam się rozwijać, zamiast mówić nam co mamy robić

Polecane książki

W transkrypcie Cagan wspomina kilka kluczowych książek:

„Inspired” – dla zespołów produktowych, product managerów, designerów i inżynierów
„Empowered” – dla liderów produktu, designu, product managementu i inżynierii
„No Rules Rules” Reeda Hastingsa – o kulturze empowerment w Netflix

Kluczowy insight

Innowacje pochodzą od inżynierów

Standardowo myślimy: Product managerowie analizują rynek, rozmawiają z klientami, definiują requirements i przekazują je inżynierom do implementacji. Inżynierowie to „wykonawcy” pomysłów innych.

W praktyce okazuje się, że: Jak mówi Cagan – „Innowacje nie pochodzą od klientów. Nie pochodzą od product managerów. Pochodzą od inżynierów.” To inżynierowie wiedzą co właśnie stało się technologicznie możliwe i mogą zaproponować rozwiązania, o których nikt inny nawet nie pomyślał.

Dlaczego to jest istotne: Jeśli traktujesz inżynierów tylko jako implementatorów, tracisz połowę ich wartości i blokujesz źródło prawdziwych innowacji w swojej firmie.

Test na jutro: Następnym razem gdy planujesz nowy feature, zamiast definiować szczegółowe requirements spróbuj przedstawić inżynierom problem biznesowy i zapytać „co jest teraz możliwe?” – sprawdź czy pojawią się pomysły, o których nie myślałeś.

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: Common Transformation Pitfalls (and Q&A), Marty Cagan, ProductTank Oslo

Tag: Transformacja Agile

Dlaczego większość transformacji produktowych kończy się niepowodzeniem – analiza Marty Cagana #EN261