Hej,
Tego nie było w moim bingo na 2026 rok → NAGRALIŚMY PODCAST z Ravi Mehta (Tinder, Facebook, Reforge) oraz Michelle Parsons (Spotify, Netflix i Hinge) 🤯
Zapraszam się na kolejny mocny odcinek specjalny 🇬🇧 podcastu „Dodane do Backlogu” (nagrany wspólnie z Productlab Conf). Nasi goście opowiedzieli insiderskie f*ck-upy z ich pracy przy globalnych produktach. Tak, im też zdarzają się błędy ;).
Zaczynamy 👇
lub Apple Podcast.
1️⃣ TripAdvisor - redesign, który kosztował miliony (Ravi Mehta)
2️⃣ TripAdvisor - kiedy lepszy algorytm to za mało (Ravi Mehta)
3️⃣ Netflix - jak presja Disney+ prowadziła do “solutioningu” (Michelle Parsons)
4️⃣ BaseCRM - rok pracy nad feature’em, którego nikt nie policzył (Jakub Tutaj)
5️⃣ Hinge - feature, który userzy nauczyli się hackować (Michelle Parson)
Gamifikacja, która zamieniła apkę randkową w narzędzie dla influencerów
Lightning round z naszymi gośćmi: “Nigdy więcej nie zrobię...”
Jeśli wolisz czytać → poniżej znajdziesz też CASE STUDIES najważniejszych F*CK UPów z tej rozmowy ⤵️
1️⃣ TripAdvisor - redesign, który kosztował miliony (Ravi Mehta)
TripAdvisor w 2013 roku miał 300 milionów użytkowników miesięcznie i wyglądał jak strona z 2001 roku. Bo... był stroną z 2001 roku. Checkboxy, radio buttony, zero designu.
Ravi i jego zespół zdecydowali się na coś, co jest antytezą tego, jak zwykle pracował TripAdvisor - firma, która testowała A/B praktycznie każdą zmianę (ponad tysiąc eksperymentów rocznie) poszła w “zamknij się w pokoju na 9-12 miesięcy, zrób idealny redesign, wypuść wszystko naraz z wielką kampanią marketingową”.
Efekt? Kilka tygodni po launchu revenue zaczęło spadać.
Winowajcą okazał się nowy, super panel filtrów do wyszukiwania hoteli - “personalization bar”, który zastąpił stare, brzydkie, ale znajome checkboxy.
Liczba osób filtrujących listę hoteli spadła o 20%. Rezerwacje spadły proporcjonalnie.
Cały biznes stracił X% revenue 🫢
Musieli odtworzyć starą logikę filtrów - tylko w nowej oprawie wizualnej. Zajęło to kilka miesięcy i kosztowało miliony dolarów utraconego przychodu.
Wniosek Raviego, który wart jest zapamiętania: UI to nie UX.
Amazon nie jest ładny, ale działa świetnie. Gdybyś zrobił dla Amazona redesign “na wzór Airbnb”, prawdopodobnie stracisz na tym pieniądze - bo optymalizujesz UI kosztem UX, która już działa.
Zanim ruszysz z redesignem, rozdziel te dwie rzeczy: co dziś działa strukturalnie dobrze (nawet jeśli brzydko), a co da się podnieść estetycznie bez ruszania mechaniki, która generuje wartość.
2️⃣ TripAdvisor - kiedy lepszy algorytm to za mało (Ravi Mehta)
Druga historia od Raviego, też z TripAdvisor.
Tym razem zespół pracował nad personalizacją rankingu hoteli - bo domyślne sortowanie “od najlepiej ocenianych” pokazywało głównie drogie hotele, które przeciętny użytkownik i tak nie zarezerwuje.
Brzmi jak sensowne strategiczne Opportunity. Podeszli do tego metodycznie:
Najpierw ukryty test na 5-20% ruchu - bez pokazywania userowi, że coś się zmieniło, po prostu inna kolejność hoteli w tle.
Wynik: 10% wzrost revenue. Sygnał był jasny - idziemy z tym dalej.
Kolejny krok - pełny launch “Just for You” jako domyślnej opcji dla wszystkich, z widoczną komunikacją, że lista jest spersonalizowana.
I tu niespodzianka: revenue spadło.
Co się stało? Odpowiedź znaleźli w feedbacku od użytkowników:
Ludzie nie chcieli, żeby TripAdvisor “wiedział, co jest dla nich najlepsze” - mieli wtedy poczucie FOMO, że ukrywa się przed nimi dobre opcje, które mogłyby pasować. Chcieli ZDECYDOWAĆ SAMI.
Framework, który Ravi wyciągnął z tej historii: to, ile kontroli oddać algorytmowi, zależy od ważności tej decyzji:
Przy mało istotnej decyzji (Netflix, TikTok, social media) ludzie chętnie oddają kontrolę - koszt złej rekomendacji jest niski.
Przy ważne decyzji, gdzie błędna decyzja będzie bolała (hotel na wakacje, randka, duży zakup) ludzie chcą czuć, że widzą pełen obraz i sami wybierają.
Ten sam mechanizm, który zadziałał w ukrytym teście, miał inne wyniki tylko dlatego, że zmienił się kontekst - user wiedział, że ktoś filtruje hotele za niego. Czuł, że oddaje decyzyjność w ważnej sprawie.
3️⃣ Netflix - jak presja konkurencji prowadzi do „solutioningu” (Michelle Parsons)
Michelle prowadziła w Netflixie dział Kids & Family - unikalny obszar z własnym contentem, własnym marketingiem i dwoma typami userów (opiekun i dziecko).
Rok przed premierą Disney+ zespół wiedział, że nadchodzi wojna o rynek streamingu dla dzieci, a Disney już wtedy zaczynał dominować tę kategorię.
Zamiast zacząć od discovery - jakie realne problemy mają rodziny korzystające z Netflixa - zespół poszedł prosto w szukanie rozwiązań i skopiowania ich od kolnkrencjie.
Pomysłem było zbudowanie “family profile”, który pozwoli oglądać razem treści z dziećmi i będzie odpowiedzią na na podobna funkcję Disney+. Zespół ruszył pełną parą i zbudował rozwiązanie.
Problem pojawił się później - metryki produktowe nie potwierdzały, że to faktycznie kierunek, który rozwiązuje jakikolwiek realny problem użytkowników.
Zamiast przyznać to na głos, Michelle - chcąca udowodnić swoją wartość w orgnizacji - próbowała zadowolić wszystkich i brnęła dalej w to rozwiąznie i szukała dowodów że ma to sens. W końcu Marketing, Zespół Contentowy, Biznesowy chciał tej funkcji i była ogromna presja żeby dowieźć.
Michelle wyciągnęła z tego dwie lekcje:
JAK WAŻNA JEST ODWAGA - odwaga, żeby powiedzieć “idziemy w złym kierunku, zatrzymajmy to teraz, zanim wsadzimy w to kolejny miesiąc czasu i budżetu” - zamiast kontynuować, bo praca grupy roboczej już wystartowała i nikt nie chce przyznać się do błędu.
KONKURENCJA NIE MA ZAWSZE RACJI - to, że konkurencja robi jakąś rzecz, nie znaczy, że musisz iść w tę samą stronę. Kopiowanie ruchów innej firmy “bo oni to robią” to prosta droga do stosu feature’ów, które nie rozwiązują problemów Twoich konkretnych userów.
4️⃣ BaseCRM - rok pracy nad feature'em, którego nikt nie policzył (Jakub Tutaj)
10 lat temu Kuba pracował jako PM w firmie budującej CRM, która obsługiwała raczej małe organizacji. Aby jeszcze szybciej poznać firma postanowiła ruszyć w górę rynku - w stronę managerów i VP sprzedaży, konkurując z większymi graczami.
Zespół od razy zakochał się w pomyśle:
Założyli że większe firmy potrzebują więcej danych i lepsze raporty oparte na machine learningu (10 lat temu to był jeszcze świeży temat), z korelacjami konwersji i porównaniami parametrów na ścieżce od leada → do klienta.
Przeszli od razu do budowania, miało to zając kilka miesięcy.
Presja rosła - po 6-8 miesięcach w projekcie zespół produktowy czuł, że “nie idzie to wystarczająco szybko”, ale budował dalej, zamiast się zatrzymać.
Pilotaż u jednego z większych klientów wyglądał dobrze, więc sygnał zdawał się potwierdzać kierunek. Finalnie budowanie tego zajęło niemal rok.
Przełomowy moment nastąpił pod koniec pracy:
ktoś podczas strategicznego spotkania w końcu zadał wprost jedno pytanie: Ilu klientów w naszej obecnej bazie w ogóle pasuje do tego segmentu, żeby to się mogło zwrócić - i kiedy zobaczymy z tego ROI?
Odpowiedź brzmiała: prawie żadnych, i nie szybko. Projekt niemal zatopił firmę.
Wniosek Kuby: najpierw zmodeluj biznesowy outcome, zanim zaczniesz coś dużego budować.
Jeśli zamodelujesz cel biznesowy na starcie, zobaczysz od razu, jakie inputy są Ci potrzebne - ilu obecnych klientów musisz mieć za 3 czy 6 miesięcy, ile nowych klientów trzeba w sprzedażowym pipeline, żeby to rozwiązanie w ogóle miała sens ekonomiczny.
No i monitoruj ten model - zbieranie tych danych i pilnowanie ich tempa oszczędza miesiące, nerwy i budżet, który można wydać gdzie indziej.
5️⃣ Hinge - feature, który userzy nauczyli się hackować (Michelle Parson)
Hinge to appka randkowa, która od lat pozycjonuje się inaczej niż konkurencja (np. Tinder). Hasło reklamowe Hinge brzmi wprost: „designed to be deleted: - appka, która ma Ci pomóc znaleźć relację, a nie utrzymać Cię w nieskończonym swipe'owaniu.
Na tym tle Hinge zbudował feature “Standouts” - codzienną sekcję z profilami osób spoza Twojej standardowej strefy rekomendacji, do których mogłeś wysłać płatną “różę” (ograniczoną liczbę miesięcznie, albo dokupioną).
Pomysł wydawał się sensowny:
osoby spoza Twojego naturalnego dopasowania algorytmicznego mają statystycznie niższą szansę na wzajemny match
dlatego traktujemy ich jako “premium opcję”, mnie oczywiste osoby, na które warto “wydać różę”
Miało w teorii to służyć też całemu ekosystemowi, czyli sprawiać że poznajesz mniej oczywiste osobami (w końcu dostał_ś od tej osoby wyjątkową różę) - w przeciwieństwie do appek, w których za pieniądze pokazują Ci najbardziej “oczywiste i algorytmiczne” dopasowania, żeby tylko zwiększyć konwersję zakupu.
Problem w tym, że tej logiki praktycznie nie da się wytłumaczyć zwykłemu użytkownikowi w dwóch zdaniach onboardingu.
Ludzie, przyzwyczajeni do mechaniki Tindera, zaczęli odbierać Standouts jako celowe blokowanie dostępu do “atrakcyjnych” osób za opłatą - mimo że to nie była intencja zespołu. Feature wywołał realny, głośny bunt userów (także medialny), z którym Hinge jako organizacja mierzył się przez długi czas.
Do tego doszło coś, czego nikt nie przewidział:
Użytkownicy zaczęli wierzyć (i rozpowszechniać to jako "hack" w social media), że jeśli X-ują (odrzucają) wszystkie osoby pokazane w danym dniu w sekcji Standouts, to Hinge pokaże im tych samych ludzi ponownie - tym razem w normalnych rekomendacjach.
W rzeczywistości X pod danym profilem to jednoznaczny sygnał "nie jestem zainteresowany", niezależnie od tego, w jakiej sekcji appki go kliknąłeś.
Efekt był odwrotny do zamierzonego: ludzie masowo odrzucali profile, którymi w Standouts akurat mogli być zainteresowani,
Wniosek Michelle: userzy są mądrzejsi, niż większość zespołów produktowych im przyznaje
Jeśli poczują, że produkt coś przed nimi ukrywa albo nimi manipuluje, znajdą sposób, żeby to obejść - często kosztem własnego doświadczenia.
Budowanie zaufania i jasne tłumaczenie mechaniki (nawet jeśli mechanika sama w sobie jest fair) to nie “nice to have”, tylko fundament, na którym w ogóle stoi feature.
🎧 Posłuchaj pełnej rozmowy:
Jest tam dużo więcej niż to, co zmieściło się w tym wydaniu - między innymi:
Jak przygotować się do meetingu z zarządem albo inwestorami, żeby nie wyjść z niego z niczym - konkretne rady Raviego
WeRoad - historia gościa z publiczności, który zmienił model biznesowy i wszedł na 5 rynków jednocześnie. Spoiler: to się nie skończyło dobrze ;)
“What got you here won’t get you there” - Michelle o tym, dlaczego umiejętności, które zrobiły z Ciebie dobrego PM-a, mogą zacząć Cię ograniczać, kiedy awansujesz na leadera
Jak mówić “nie” bez wypalenia się - Michelle o transparentności wobec zespołu w kwestii priorytetów i o tym, dlaczego zgadzanie się na wszystko to prosta droga do burnoutu
Lightning round - na koniec odcinka każdy z uczestników dokończył jedno zdanie: "Jako product leader, nigdy więcej...".
