Notatki z wywiadu w Lenny’s Podcast z Itamarem Giladem, byłym Product Managerem Google (Gmail, YouTube) i autorem książki „Evidence Guided”. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od rozmówcy.

TL;DR

Google+ to przykład opinion-based failure – zespół 1000 osób, lata pracy, miliardy dolarów zmarnowane na produkt, którego nikt nie potrzebował
Gmail tabs pokazują siłę evidence-guided development – od małego pomysłu przez systematyczne testowanie do 1.8 miliarda użytkowników
Framework GIST dzieli product development na 4 warstwy: Goals (cele), Ideas (pomysły), Steps (kroki walidacji), Tasks (zadania)
Confidence meter pomaga ocenić pewność wobec pomysłów na skali 0-10 z konkretnymi przykładami dowodów
GIST board zastępuje tradycyjne roadmapy – fokus na outcomes zamiast outputs
Fake door testing pozwala walidować pomysły bez pisania kodu
Metrics trees tworzą matematyczną formułę sukcesu produktu łącząc North Star metric z business KPI

Miliardowy błąd Google+ kontra sukces Gmail tabs

Itamar Gilad opisuje dwa skrajnie różne projekty z jego czasu w Google, które ilustrują różnicę między opinion-based a evidence-guided product development.

Google+ – gdy opinie prowadzą w przepaść

W szczytowym momencie nad Google+ pracowało około 1000 osób – zespół wielkości całego Androida czy Google Docs. Projekt wydawał się logiczny, ponieważ Facebook rósł dynamicznie, a ludzie spędzali tam godziny. To naprawdę przestraszyło Google, dlatego rozwiązanie wydawało się oczywiste – uruchomić własną sieć społecznościową.

Charakterystyka projektu Google+:

Nieograniczone zasoby i pełne wsparcie kierownictwa
Logiczne uzasadnienie biznesowe – konkurencja z rosnącym Facebookiem
Wszyscy wierzyli w pomysł, wczesne testy były obiecujące
Efekt: całkowita porażka – zamknięty w 2018 roku, integracje wycofane wcześniej

Problem polegał na tym, że ludzie nie potrzebowali kolejnej sieci społecznościowej. Mimo logicznych przesłanek i ogromnych zasobów, projekt nie odpowiadał na rzeczywistą potrzebę użytkowników.

Gmail tabs – gdy evidence prowadzi do sukcesu

Zupełnie inaczej przebiegał projekt Gmail tabs. Zaczął się jako mały pomysł, w który nikt szczególnie nie wierzył. Gilad zauważył problem z chaosem w skrzynkach odbiorczych – większość użytkowników (około 85-88%) to „pasywni” zarządcy emaili, którzy nie organizują skrzynek.

Kluczową różnicą było podejście zespołu. Zamiast od razu budować rozwiązanie, zespół rozpoczął od research. Zadawano pytania: jaki jest rzeczywisty problem? Dla kogo? Jak można to zmierzyć?

Następnie systematycznie testowano pomysły. Jak wspomina Gilad: „To była tylko fasada HTML, a za kulisami niektórzy z nas ręcznie przenosili tematy i nadawców we właściwe miejsca.”

Zespół prowadził usability studies, budował zespoły machine learning do kategoryzacji, testował najpierw na własnych skrzynkach, potem na innych pracownikach Google, wreszcie na użytkownikach zewnętrznych.

Rezultat: funkcja używana przez większość z 1.8 miliarda aktywnych użytkowników Gmail.

Framework GIST – systematyczne podejście do product development

Na podstawie tych doświadczeń Gilad opracował framework GIST, który dzieli pracę nad produktem na cztery warstwy.

Goals – jasne cele zamiast planowania

Według Gilada większość firm myli cele z planowaniem. Zamiast definiować „gdzie chcemy dotrzeć”, skupiają się na „co będziemy budować i kiedy”.

Evidence nie pomoże, jeśli nie wiadomo, gdzie się chce iść. Dlatego pierwszy krok to jasne zdefiniowanie celów organizacyjnych.

Gilad proponuje model value exchange loop – organizacja dostarcza wartość rynkowi i przejmuje wartość z powrotem. Te dwa elementy należy mierzyć:

North Star metric – mierzy wartość dostarczaną użytkownikom (np. wysłane wiadomości w WhatsApp, zarezerwowane noce w Airbnb)
Top business KPI – mierzy wartość przejętą przez firmę (revenue, market share)

Ideas – systematyczna priorytetyzacja zamiast polityki

Firmy są zalewane pomysłami pochodzącymi od founderów, managerów, zespołów, research czy analizy konkurencji. Zazwyczaj wygrywa „bitwa opinii” lub HIPPO (Highest Paid Person’s Opinion).

Gilad proponuje framework ICE (Impact, Confidence, Ease) do obiektywnej oceny pomysłów. Framework stworzył Sean Ellis – ojciec growth movement, który ukuł termin „growth hacking” i spopularyzował koncepcję product-market fit.

Impact – jak bardzo wpłynie na cele
Ease – jak łatwy będzie do zrealizowania
Confidence – jak pewni jesteśmy naszych szacunków

Steps – od fake door do eksperymentów

Większość firm uważa, że do uczenia się potrzeba „elaborate MVP”, który w rzeczywistości to stary dobry Beta z nową nazwą.

Gilad pokazuje spektrum walidacji od najtańszych do najdroższych metod:

1. Assessment – sprawdzenie zgodności z celami, analiza biznesowa, ICE analysis

2. Fact-finding – analiza danych, wywiady z użytkownikami, competitive analysis

3. Tests – fake door tests, smoke tests, wizard of Oz tests, prototypy

Na tym etapie można wprowadzić rozróżnienie między fish food (testowanie na własnym zespole) a dog food (testowanie wewnątrz organizacji). Jak wspomina Gilad z doświadczeń w Microsofcie: „Wszyscy dogfoodowali kolejną wersję Outlooka, która była bardzo buggy.”

4. Experiments – A/B testy z grupami kontrolnymi

5. Release – staged rollouts, percent launches, holdback experiments

Kluczowe spostrzeżenie: nie trzeba zaczynać od prawej strony (drogie eksperymenty). Można rozpocząć od lewej i szybko eliminować słabe pomysły.

Time to outcomes, nie time to delivery

Kluczowy insight Gilada: „Gdy jest uncertainty, nie chodzi o to, jak szybko dostarczyć kod do produkcji. Chodzi o dostarczenie WŁAŚCIWEGO kodu do produkcji. Metryka to time to outcomes, nie time to delivery.”

Evidence-guided approach jest paradoksalnie szybszy i bardziej resource-efficient niż opinion-based, ponieważ pozwala uczyć się wcześniej i unikać budowania niepotrzebnych funkcji.

Tasks – GIST board zamiast roadmap

Gilad identyfikuje fundamentalny problem „dwóch światów” w organizacjach.

Z jednej strony Planning world – managerowie i stakeholderzy zajmujący się strategiami i roadmapami. Z drugiej Agile world – zespoły skupione na moving tickets i burning story points. Między nimi przepaść – nie rozumieją się nawzajem, nie widzą wspólnych celów, buduje się nieufność.

Typowe „rozwiązanie”: wstawić PM w środku. PM ma dostarczać zgodnie z roadmapą jak project manager i karmić Agile machine perfectly prioritized backlogs. Jednak to nie działa. PMs są zmęczeni, spędzają czas na planowaniu i roadmap discussions, nie mają czasu na research czy testowanie pomysłów.

Rozwiązaniem jest GIST board – narzędzie łączące te perspektywy z trzema warstwami:

Goals – maksymalnie 4 key results na zespół
Ideas – pomysły z ICE scores
Steps – kolejne kroki walidacji z ownership

Kluczowe: to nie engineering milestone czy design milestone – to learning milestone. Brakuje tej środkowej warstwy dyskusji – roadmap level i task level istnieją, ale middle layer (co właściwie próbujemy osiągnąć) nie.

Counterintuitive insight: zespół powinien sam wybierać pomysły do testowania, używając ICE process. Managerowie i stakeholderzy mogą proponować idee, ale to zespół decyduje, które testować pierwsze. To tworzy ownership i engagement.

GIST board versus tradycyjne roadmapy

Release roadmaps („do Q3 uruchom to”, „do października launch tamto”) konkurują z GIST approach. Jeśli ludzie wiedzą, że cel to launch konkretnej rzeczy do października – zapominają o learning i evidence-guided thinking.

Gilad rekomenduje outcome roadmaps – „do października osiągnij ten outcome”, „do Q4 zwiększ usage w Indiach o określony procent”. Roadmapy mogą zdusić cały proces, jeśli z góry zdecyduje się z niską confidence, że konkretny pomysł musi być uruchomiony.

Confidence meter – jak mierzyć pewność wobec pomysłów

Jednym z najbardziej praktycznych narzędzi Gilada jest confidence meter – wizualna skala od 0 do 10 pokazująca różne typy dowodów.

Poziomy pewności w praktyce

Niska pewność (0-3): opinie i przekonania

0-1 – własne przekonanie, gut feeling
1-2 – shiny pitch deck, szczegółowa dokumentacja
2-3 – połączenie z trendem (AI) lub strategią firmy

Jak zauważa Gilad: „Za każdym okropnym pomysłem, który kiedykolwiek powstał, ktoś uważał, że to wspaniały pomysł.”

Średnia pewność (3-7): dane i analizy

3-4 – opinie kolegów i managerów (uwaga: grupy mają własne biases, group think, mogą podejmować gorsze decyzje niż jednostki – research to potwierdza)
4-5 – szacunki, back-of-envelope calculations
5-7 – anegdotyczne dane, wywiady z klientami, analiza konkurencji (nigdy nie zakładaj, że konkurent wie lepiej co robi)

Wysoka pewność (7-10): testy i eksperymenty

7-8 – fake door tests, usability studies, prototypy
8-9 – early adopter programs, A/B testy
9-10 – wielokrotne walidacje, high confidence

Kluczowa obserwacja: ludzie mają tendencję do dawania sobie wysokiej pewności opartej na gut instinct. To sabotuje cały system.

Metrics trees – matematyczna formuła sukcesu

Gilad proponuje budowanie metrics trees – wizualnych reprezentacji tego, jak różne metryki wpływają na North Star i business KPIs.

Metrics trees pomagają w trzech kluczowych obszarach. Po pierwsze, impact assessment – jeśli poprawi się activation rate o 10%, jak wpłynie to na North Star? Po drugie, organizational alignment – cała organizacja pracuje nad tymi samymi metrykami. Po trzecie, team topology – można organizować zespoły wokół najważniejszych części drzewa.

Jak obrazowo wyjaśnia Gilad: „Jeśli nie masz jasnego poczucia, jaka jest matematyczna formuła twojego North Star metric lub revenue, powinieneś nad tym popracować.”

North Star versus Business KPIs w praktyce:

WhatsApp: wysłane wiadomości (każda = wartość dla nadawcy) vs revenue
Airbnb: zarezerwowane noce vs booking revenue
Amplitude: active learning users (sharing insights) vs subscription revenue

Diagnoza i pierwsze kroki transformacji

Oznaki opinion-based development

Gilad wymienia charakterystyczne symptomy organizacji opartych na opiniach:

Cele niejasne, za dużo lub dotyczą outputu zamiast outcomes
Brak user-facing metrics – tylko revenue i business metrics
Dużo czasu poświęconego na planowanie „idealnej roadmapy”
Mało eksperymentowania lub mało uczenia się z eksperymentów
Zespół zdisengażowany, skupiony tylko na delivery
Misalignment między zespołami

Jak zacząć transformację

Diagnoza największego problemu:

Niejasne cele → rozpocznij od Goals layer (North Star + metrics trees)
Ciągłe debaty → rozpocznij od Ideas layer (ICE + confidence meter)
Za dużo budowania → rozpocznij od Steps layer (spektrum walidacji)
Zespół zdisengażowany → rozpocznij od Tasks layer (GIST board)

Gilad przestrzega: „Jeśli transformacja jest zbyt duża, zmęczysz się, stworzysz dużo procesów i nie zobaczysz rezultatów.”

Praktyczna alternatywa dla delivery-focused teams: zamiast product backlog stwórz step backlog – listę kroków walidacji (betas, previews, testy) zamiast features do zbudowania. To znacząco zmienia dynamikę zespołu.

Evidence-guided jako filozofia value-first

Podejście Gilada idealnie podsumowuje motto Alberta Einsteina, które go prowadzi: „Staraj się nie być sukcesem, ale być wartościowy.”

To bezpośrednio łączy się z koncepcją value exchange loop – organizacje, które skupiają się na dostarczaniu maksymalnej wartości użytkownikom, naturalnie osiągają sukces biznesowy. Evidence-guided development to praktyczny sposób na realizację tej filozofii.

Evidence-guided w różnych kontekstach

Startups versus established companies

W early stage firma może nie wiedzieć, jak tworzy wartość. Jej cel to znalezienie product-market fit. Budowanie całych metrics trees może być przesadą.

W scale-up pojawiają się setki ludzi i miliony dolarów – wtedy potrzebny jest porządek systematycznej oceny pomysłów.

Established companies często mają dwa problemy: dopiero uczą się modern product development lub kiedyś były evidence-guided, ale cofnęły się (zmiana managementu, kultury).

Founders i opinion-based decisions

Gilad nie proponuje ignorowania founderów. Przeciwnie – ich pomysły są kluczowe. Jednak środowisko powinno pozwalać na pytanie „gdzie są dowody?”

Przykład Steve’a Jobsa – popularny mit głosi, że wymyślił iPhone w kuchni i kazał zespołowi go zbudować. Rzeczywistość była inna: lata projektów z multitouch i telefonami, większość z nich nie powiodła się. Jobs był architektem łączącym kropki, ale nie jedynym kreatorem.

Jak zauważa Gilad: „Nawet Steve Jobs, gdy pokazano mu dowody, był gotów zmienić zdanie. Był przeciwko telefonom, ale potem ludzie pokazali mu dowody, że Apple może zrobić telefon.”

Polecane książki

Gilad rekomenduje dwie serie książek, które uważa za fundamentalne:

SVPG Series (Marty Cagan):

Inspired
Empowered
Transformed

Lean Series:

The Lean Startup
Lean Enterprise
Lean Analytics
Lean UX
Running Lean

Jak podkreśla: „To książki ze złotem w środku. Uważam, że nie są doceniane tak, jak powinny.”

Kluczowy insight

Fake validation beats real coding

Standardowo myśli się: Żeby przetestować pomysł, trzeba zbudować MVP, napisać kod, stworzyć działający prototyp.

W praktyce okazuje się, że: Najcenniejsze insights można zdobyć bez pisania jednej linii kodu. Gmail tabs – funkcja używana przez 1.8 miliarda ludzi – została pierwotnie „przetestowana” jako HTML mockup, gdzie ludzie ręcznie przenosili emaile w odpowiednie miejsca za kulisami.

Dlaczego to jest istotne: Większość zespołów marnuje tygodnie lub miesiące na budowanie „minimalnych” MVP, które wcale nie są minimalne. Tymczasem kluczowe pytania o user value można odpowiedzieć w ciągu dni, używając fake door tests, wizard of Oz experiments czy smoke tests.

Test na jutro: Następnym razem gdy chcesz przetestować nowy feature, zamiast planować development sprint spróbuj stworzyć przekonujący mockup lub manual process i sprawdź, czy users rzeczywiście przejmują się problemem, który próbujesz rozwiązać.

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 – Becoming evidence-guided | Itamar Gilad

Tag: Gmail Tabs

Framework GIST – jak budować produkty evidence-guided#EN155