TL;DR

Google+ pochłonął 1000 osób przez kilka lat – całą dywizję wielkości Androida, by stworzyć produkt, którego nikt nie potrzebował
Gmail tabbed inbox rozpoczął się od pozorowanych testów – pierwsze wersje to HTML-owa fasada bez linijki kodu
GIST – struktura dzieli product development na 4 warstwy: Goals, Ideas, Steps, Tasks
Confidence meter wizualnie pokazuje siłę dowodów – od opinii (0-0.1) do pełnych testów (do 10)
Metrics trees łączą North Star z business KPI – wartość dla użytkownika vs wartość dla firmy
GIST board zastępuje tradycyjne roadmapy – fokus na learning milestones zamiast delivery milestones
Transformacja zaczyna się od diagnozy – niejasne cele, brak eksperymentów czy zespoły skupione tylko na dostarczaniu

Dwie historie z Google – lekcja o evidence-guided development

Itamar Gilad dołączył do Gmail w sierpniu 2011 roku. Pierwszym zadaniem było połączenie Gmail z Google+. Facebook dynamicznie rósł, dlatego Google postanowił stworzyć własną sieć społecznościową. Rozwiązanie wydawało się oczywiste.

Google nie oszczędzał środków. Jak wspomina Gilad, firma stworzyła całą nową dywizję wielkości Androida i Docs. Na szczycie projekt angażował około 1000 osób. Przez kilka lat zespoły łączyły Gmail, YouTube i wyszukiwarkę z Google+, by uczynić je bardziej społecznościowymi.

Rezultat? Żaden. Ludzie nie potrzebowali kolejnej sieci społecznościowej. Google+ został zamknięty w 2018 roku. Tymczasem tuż obok siedziby Google rozwijał się WhatsApp – niewielka firma, która rzeczywiście zagroziła Facebookowi.

Google był pierwotnie evidence-guided firmą z DNA „Fail Fast”. W pierwszej dekadzie kładł nacisk na skupienie się na klientach, generowanie wielu pomysłów oraz analizę danych. Firma oczekiwała zabijania projektów, które nie działały. Gdyby zachowano tę mentalność, Google+ prawdopodobnie zostałby zamknięty znacznie wcześniej.

Tabbed inbox – historia sukcesu

Kolejny projekt Gilada w Gmail miał odwrotny przebieg. Tabbed inbox rozpoczął się jako mały pomysł, w który nikt nie wierzył. Zespół chciał pomóc użytkownikom w organizacji skrzynek zaśmieconych powiadomieniami społecznościowymi i promocjami.

Jednak koledzy Gilada nie byli przekonani. Argumentowali, że Google już próbował pomagać w organizacji inbox. Użytkownicy tych funkcji nie używali. Dlaczego tym razem miałoby być inaczej?

To zmusiło zespół do głębszych badań. Zamiast planować i wykonywać, zaczęli testować. Jedną z pierwszych wersji był pozorowany test – HTML-owa fasada, która wyglądała jak Gmail, ale nie była nim. Podczas gdy badacz odwracał uwagę użytkownika, zespół ręcznie sortował 50 najnowszych wiadomości do odpowiednich kategorii.

Reakcje były entuzjastyczne. Użytkownicy mówili: „Wow, to naprawdę fajne!”. To dało zespołowi dowody, by kontynuować rozwój. Okazało się, że około 85-88% populacji uwielbia to rozwiązanie, podczas gdy większość kolegów Gilada uważa dzielenie promocji i social media za głupią ideę. Dziś Gmail ma 1,8 miliarda aktywnych użytkowników. Według firmy, większość z nich korzysta z tabbed inbox.

GIST – struktura czterech warstw skutecznego product managementu

Na podstawie doświadczeń w Google Gilad opracował strukturę GIST. Jak wyjaśnia, to meta-rama łącząca lean startup, design thinking i growth hacking w jeden system.

GIST to akronim składający się z czterech warstw:

Goals – definiowanie końcowego stanu, do którego dążymy
Ideas – hipotetyczne sposoby osiągnięcia celów
Steps – sposoby implementacji i walidacji pomysłów jednocześnie
Tasks – rzeczy zarządzane w Kanban i Jira, na których skupiają się zespoły deweloperskie

Każdy element można wprowadzać stopniowo, bez rewolucjonizowania całej organizacji naraz.

Goals – cele które naprawdę prowadzą

Według Gilada, w większości firm „cele” to sesje planowania. Jednak dyskutuje się, co zbudować i kiedy, zamiast definiować docelowy stan. Evidence-guided firmy używają modeli do konstruowania nadrzędnych celów dla całej organizacji.

Jednym z takich modeli jest value exchange loop. Organizacja dostarcza jak najwięcej wartości rynkowi i przechwytuje jak najwięcej wartości z powrotem. Tworząc pętlę sprzężenia zwrotnego między nimi, firma może rosnąć bardzo szybko.

Gilad proponuje mierzenie obu stron. North Star metric mierzy wartość dostarczaną użytkownikom. W WhatsApp były to wysłane wiadomości – każda to przyrost wartości dla nadawcy. Z kolei w Airbnb – nights booked.

Top business KPI mierzy wartość przechwytywaną przez firmę. Zwykle to przychody lub udział w rynku. Te dwie metryki połączone tworzą metrics trees – drzewa pokazujące, jak różne wskaźniki wpływają na główne cele.

Metrics trees pomagają też w określeniu struktury zespołów. W wielu organizacjach topologia zespołów odzwierciedla strukturę oprogramowania lub hierarchiczny model organizacyjny. Jeśli zaczniesz od metrics tree, możesz ułożyć topologię wokół celów – czasem wymaga to reorganizacji, gdy cele się zmieniają.

Ideas – jak obiektywnie oceniać pomysły

Firmy są bombardowane pomysłami. Pochodzą od założycieli, menedżerów, zespołów, z badań oraz od konkurencji. Zazwyczaj jednak wygrywa polityka lub opinia najwyżej płatnej osoby.

Dlatego Gilad sugeruje strukturę ICE autorstwa Seana Ellisa: Impact, Confidence, Ease. Impact ocenia wpływ na cele, Ease to przeciwność wysiłku, a Confidence określa pewność pierwszych dwóch szacunków.

Mimo to Confidence to kluczowy element. Ludzie mają tendencję do dawania sobie wysokiej pewności przy pomysłach opartych na intuicji. To jednak podważa cały system.

Confidence meter – wizualne narzędnie oceny

Gilad stworzył confidence meter – narzędzie przypominające termometr. Skala od 0 do 10, gdzie 0 to bardzo niska pewność, a 10 to pełna pewność.

Poziomy pewności w confidence meter:

Niebieska strefa (0-0.1) – opinie: własne przekonanie, pitch decki, tematy jak AI, strategia firmy
Żółta strefa – przeglądy: oceny kolegów, menedżerów, szacunki zespołu
Zielona strefa – dane: anegdotyczne punkty, badania rynku, analiza konkurencji
Czerwona strefa – testy: od pozorowanych testów po pełne eksperymenty A/B

Jak zauważa Gilad, za każdym okropnym pomysłem ktoś uważał go za świetny. Nie każdy pomysł wymaga dotarcia do końca skali. Czasem opinia eksperta wystarczy. Kluczowe jest jednak wiedzenie, kiedy przestać, a kiedy inwestować w więcej dowodów.

Steps – nauka i budowanie jednocześnie

Wiele organizacji wierzy, że musi zbudować rozbudowane MVP, by się czegoś nauczyć. Jednak Gilad proponuje gamut metod walidacji od najmniej do najbardziej kosztownych:

Etapy walidacji pomysłów:

Assessment – sprawdzenie zgodności z celami, modelowanie biznesowe, analiza ICE
Fact-finding – kopanie w danych, badania konkurencji, wywiady z użytkownikami
Tests – pozorowane testy, rough wersje dla early adopters, fish fooding, dog fooding, bety
Experiments – testy z elementem kontrolnym: A/B testy, testy wielowariantowe
Release – staged rollouts, holdbacks jako kolejna okazja do nauki

Fish fooding to testowanie na własnym zespole (googleowe określenie), podczas gdy dog fooding to testowanie na całej firmie. Tabbed inbox to przykład pozorowanego testu – zespół pokazał działającą funkcję bez pisania kodu. Każdy etap pozwala na parkowanie słabych pomysłów i inwestowanie większego wysiłku w te, które generują pozytywne dowody.

Kluczowa zmiana myślenia: zamiast mierzyć „time to delivery” (jak szybko dostarczamy features), należy mierzyć „time to outcomes” (jak szybko osiągamy właściwe rezultaty). Evidence-guided method jest szybszy i bardziej resource-efficient niż opinion-based, bo uczy wcześniej i pozwala unikać budowania złych rzeczy.

Dobra zespoły wiedzą, jak budować i uczyć się jednocześnie – to nie jest wybór między szybkością dostarczania a szybkością uczenia się. Można prowadzić „sekretne eksperymenty” i przyjść z danymi – reakcja będzie albo bardzo negatywna (czas na CV), albo pozytywne zaskoczenie.

Tasks – GIST board zamiast tradycyjnych roadmap

W wielu organizacjach istnieją dwa światy. Świat planowania, gdzie menedżerowie tworzą strategie i roadmapy. I świat agile, gdzie deweloperzy przenoszą tickety do „done”. Między nimi jest przepaść.

W rezultacie PM ma być pomostem, ale często staje się wąskim gardłem. Dlatego Gilad proponuje wyprowadzenie deweloperów z „agile cage” i pozwolenie im na discovery.

GIST board to narzędzie łączące trzy górne warstwy. Cele (key results) po prawej, maksymalnie 4 na zespół. Pomysły z ICE scores pośrodku. Kroki walidacji po lewej. To żywe narzędzie – zespół spotyka się co dwa tygodnie, by omawiać postępy.

Kroki to learning milestones, nie engineering milestones. Zespół buduje i uczy się jednocześnie, stopniowo zwiększając scope tego, co buduje.

GIST board konkuruje z release roadmaps, gdzie mówisz „do Q3 chcemy to uruchomić”. Jeśli ludzie wiedzą, że celem jest uruchomienie konkretnej rzeczy do października, można zapomnieć o uczeniu się. Gilad zaleca outcome roadmaps: „do października chcemy osiągnąć ten rezultat, do Q4 chcemy wejść do trzech nowych krajów”. Sposób osiągnięcia pozostaje otwarty, chyba że masz już wysoką pewność po testach.

Jak zacząć transformację w swojej firmie

Gilad nie zaleca wprowadzania wszystkiego naraz. Zbyt duża transformacja prowadzi do zmęczenia i rezygnacji po kwartale.

Symptomy opinion-based development:

Niejasne cele – wiele celów lub bardzo ogólne, skupione na output zamiast outcome
Brak metryk skierowanych do użytkowników – tylko revenue i business metrics
Dużo czasu na planowanie – tworzenie „idealnych” roadmap pochłania czas managementu
Mało eksperymentów – a jeśli są, to bez wyciągania wniosków
Zespół skupiony na dostarczaniu – deweloperzy mierzeni outputem, zdystansowani od użytkowników

W rezultacie diagnoza problemu wskazuje, od której warstwy zacząć. Niejasne cele to powód, by skupić się na Goals. Z kolei ciągłe debaty o pomysłach – na Ideas. Za dużo budowania, za mało nauki – Steps. Zdystansowany zespół – Tasks.

Różne fazy rozwoju firmy wymagają różnego podejścia. Early stage często nie wie jeszcze, jak tworzy wartość – ich cel to znalezienie product-market fit. Po osiągnięciu PMF firmy muszą zbudować business model. Dopiero w fazie scale potrzebują pełnego porządku w ocenie pomysłów, bo mają dużo ludzi, pieniędzy i wszystko dzieje się jednocześnie.

Checklist: Od czego zacząć evidence-guided development

Jeśli problem to niejasne cele:

Zdefiniuj North Star metric (wartość dla użytkowników)
Określ top business KPI (wartość dla firmy)
Stwórz metrics tree łączące oba wskaźniki
Przypisz zespołom maksymalnie 4 key results na kwartał

Jeśli problem to ciągłe debaty o pomysłach:

Wprowadź strukturę ICE (Impact, Confidence, Ease)
Użyj confidence meter do oceny siły dowodów
Stwórz przejrzysty proces priorytetyzacji
Wymagaj evidence przed dużymi inwestycjami

Jeśli problem to za dużo budowania, za mało nauki:

Zacznij od pozorowanych testów zamiast od MVP
Wprowadź etapy: Assessment → Fact-finding → Tests → Experiments → Release
Testuj założenia, nie tylko funkcjonalności
Pozwól na „zabijanie” pomysłów na wczesnym etapie

Jeśli problem to zdystansowany zespół:

Stwórz GIST board z celami, pomysłami i krokami
Spotykajcie się co 2 tygodnie wokół tablicy
Skupcie się na learning milestones, nie delivery milestones
Pozwólcie zespołowi wybrać pomysły do testowania

Evidence-guided to nie eliminacja ludzkiej intuicji. To jej wzmocnienie dowodami. Jak zauważa Gilad, nawet Steve Jobs, wbrew legendzie, podejmował decyzje w oparciu o evidence. iPhone to nie był pomysł z kuchni Jobsa – to historia discovery i prób i błędów. Było wiele projektów z multitouch i telefonami, większość zakończyła się niepowodzeniem. Jobs początkowo był przeciwny telefonom, ale zmienił zdanie w oparciu o dowody.

Evidence jest niezwykle empowering dla mniejszych ludzi w organizacji – pozwala menedżerom średniego szczebla skutecznie kwestionować opinie seniorów. Gdy przychodzisz z danymi, zazwyczaj otrzymujesz jedną z dwóch reakcji: albo ktoś się wkurza i każe ci wrócić do roboty (czas na polowanie CV), albo jest mile zaskoczony.

Dwa typy firm najbardziej korzystają z tego podejścia: te które przechodzą na nowoczesny product development (mają PM-ów, OKR-y, agile, ale nie potrafią tego połączyć) oraz te które były evidence-guided, ale zregresowały przez zmianę managementu lub kultury.

Kluczowy insight

Symulacja przed MVP

Standardowo myślimy: Żeby przetestować pomysł, musimy zbudować działającą wersję produktu (MVP), uruchomić ją i zmierzyć reakcje użytkowników.

W praktyce okazuje się, że: Można uzyskać równie wartościowe dane bez pisania ani linijki kodu – poprzez HTML-owe fasady, makiety czy ręczne symulacje funkcjonalności.

Dlaczego to jest istotne: Gmail tabbed inbox najpierw przetestowano jako pozorowany test – zespół ręcznie sortował maile w HTML-owej fasadzie, która tylko wyglądała jak Gmail. To dało wystarczające dowody, by kontynuować, oszczędzając tygodnie programowania na złym pomyśle.

Test na jutro: Następnym razem gdy chcesz przetestować nową funkcjonalność, zamiast planować MVP spróbuj stworzyć pozorowaną wersję (nawet PowerPoint slides) i przeprowadź test z prawdziwymi użytkownikami, sprawdzając ich reakcje na „działający” prototyp.

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: Lenny’s Podcast – wywiad z Itamar Gilad

Tag: Google Product Management

Jak Google zmarnowało 1000 osób na Google+ – przewodnik po GIST framework #EN149