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
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.