Product Operating Model: Szybkie Eksperymentowanie
Wydanie #213
W dzisiejszym wydaniu między innymi:
💜 Wstępniak od Alex Dziewulska
💜 Nowa seria Product Operating Model - wszystko co chcesz wiedzieć o transformacjach produktowych:
Dołącz do Premium, aby uzyskać dostęp do całej zawartości - w tym 2 artykułów eksplorujących tematy produktowe
Przeczytanie tego wydania zajmie Ci prawie godzinę. Mnóstwo treści (lub mięsa)! (Dla wegan - dużo tofu!)
Weź notatnik 📰 i swój ulubiony napój 🍵☕
Wstępniak od Alex 💜
Nie uszczęśliwiaj użytkowników po swojemu: Paradoks Avatara, który kosztuje zespoły produktowe miliony
Oto niewygodna prawda, której nikt w branży produktowej nie chce przyznać: Twoja wizja prawdopodobnie jest błędna, a użytkownicy próbują uratować Cię przed kosztownym błędem.
Obserwuję sagę Avatar: Frontiers of Pandora od dwóch lat i stała się ona idealnym studium przypadku tego, co jest nie tak z naszym podejściem do feedbacku użytkowników w rozwoju produktów. Ubisoft miał jasną wizję twórczą—perspektywę pierwszoosobową dla maksymalnego zanurzenia w świecie Jamesa Camerona. Gracze głośno protestowali od pierwszego dnia. Firma podwoiła stawkę. Gra wyszła z mieszanymi recenzjami i tracąc graczy jak z dziurawego worka. Teraz, dwa lata później, wydają miliony na dodanie widoku trzecioosobowego, o który wszyscy prosili od samego początku.
Brzmi znajomo? Powinno, bo ten wzorzec jest wszędzie w naszej branży i kosztuje nas więcej niż tylko pieniądze—niszczy naszą wiarygodność jako profesjonalistów zorientowanych na użytkownika.
Namalujmy sobie obrazek. Jesteś na spotkaniu planowania produktu, ktoś właśnie przedstawił przekonujące badania użytkowników pokazujące, że ludzie chcą funkcję X, a potem ktoś inny wypowiada magiczne słowa: "Ale to nie pasuje do naszej wizji." Nagle cała rozmowa zmienia kierunek z rozwiązywania problemów użytkowników na obronę decyzji projektowych.
Dokładnie to stało się w Massive Entertainment. Dyrektor gry Ditte Deenfeldt dosłownie powiedziała: "Chcemy, żebyś poczuł się zanurzony i jakbyś naprawdę był na Pandorze. Więc to nigdy nie było dla nas wielką dyskusją." Dyrektor kreatywny Magnus Jansen nazwał ograniczenie do pierwszej osoby "oczywistością" opartą na ich współpracy z zespołem Jamesa Camerona.
Zauważcie, czego brakuje w tych cytatach? Jakiejkolwiek wzmianki o tym, czego rzeczywiście chcieli użytkownicy. Jakiegokolwiek uznania, że może, tylko może, ludzie którzy mieliby grać w tę grę przez setki godzin mogliby mieć warte rozważenia spostrzeżenia.
Wynik? Gra zdobyła mieszane 74/100 na Metacritic, gracze na Steamie często spadali poniżej 200 równocześnie grających, a gra wymagała agresywnych promocji zaledwie miesiące po premierze. Ostateczna zniewaga? Ubisoft spędził prawie dwa lata "przerabiając animacje, sterowanie, dźwięk i systemy kamery", żeby dodać funkcję, której wszyscy chcieli od początku.
Tu robi się naprawdę interesująco z perspektywy nauk behawioralnych. Badania Daniela Kahnemana nad błędami poznawczymi pokazują nam dokładnie, dlaczego mądre zespoły produktowe popełniają te systematyczne błędy. Cierpimy na to, co psychologowie nazywają "przekleństwem wiedzy"—nasze głębokie zapoznanie z naszymi produktami czyni nas kiepskimi sędziami doświadczenia użytkownika.
Ale dzieje się coś jeszcze bardziej podstępnego. Kiedy inwestujemy miesiące lub lata w określony kierunek projektowy, błąd kosztów utopionych uderza mocno. Teoria perspektywy Kahnemana i Tversky'ego pokazuje nam, że strach przed stratą jest dwukrotnie silniejszy niż satysfakcja z zysków. Więc kiedy feedback użytkowników sugeruje, że nasze podejście jest złe, nasze mózgi dosłownie interpretują zmianę kursu jako większe zagrożenie niż kontynuowanie kursu ku oczywistej porażce.
Widziałem to w zespołach produktowych w różnych branżach. Im więcej ekspertyzy rozwijamy, tym bardziej pewni stajemy się naszej zdolności przewidywania zachowań użytkowników. Im bardziej pewni się stajemy, tym bardziej lekceważymy feedback, który przeczy naszym założeniom. To błędne koło, przed którym ostrzega Teresa Torres w "Continuous Discovery Habits"—zaczynamy projektować dla użytkowników zamiast z użytkownikami.
Avatar to nie odosobniony incydent. To część wzorca, który od lat niszczy branżę gier, a implikacje dla zarządzania produktem są ogromne.
DmC: Devil May Cry zignorował protesty fanów przeciwko przeprojektowaniu postaci i zobaczył spadek celów sprzedażowych z 2 milionów do 1,2 miliona kopii. Zawsze-online requirement SimCity 2013, broniony przeciwko powszechnemu sprzeciwowi graczy, doprowadził do zamknięcia studia Maxis Emeryville. Star Wars Battlefront II EA zdobył najgorzej oceniany komentarz w historii Reddita (683 000+ downvotów) za obronę mechanik pay-to-win przeciwko feedbackowi graczy.
Ale oto co jest naprawdę interesujące: No Man's Sky przekształciło się z "Mostly Negative" recenzji na Steamie do "Very Positive" poprzez systematyczne odpowiadanie na krytykę przez 20+ dużych darmowych aktualizacji zawartości. BioWare odpowiedział na kontrowersję zakończenia Mass Effect 3 DLC Extended Cut, które odpowiedziało na konkretne obawy fanów.
Firmy, które się odradzają? Przestają bronić swojej wizji i zaczynają rozwiązywać problemy użytkowników. Jak ujął to Sean Murray z Hello Games: "Jeśli chcieliśmy coś powiedzieć naszym graczom, musieliśmy to umieścić w buildzie, wysłać ten build"—podkreślając działanie nad defensywną komunikacją.
Oto część, która powinna przerazić każdego product managera czytającego to: posiadanie większej ilości badań użytkowników nie rozwiązuje problemu. Branża gier rozwinęła bardziej wyrafinowane praktyki badania użytkowników niż inne sektory technologiczne, rutynowo analizując miliony sesji użytkowników z integracją biometryczną. Firmy jak Riot Games mają 70 badaczy na 2000 pracowników (3,5%)—znacznie więcej niż typowa firma technologiczna.
Jednak wysokiej rangi porażki nadal się zdarzają. Dlaczego? Bo 77% badań użytkowników odbywa się teraz w zespołach produktowych, a nie w dedykowanych działach, a wbudowani badacze często stają się adwokatami z góry określonych kierunków produktowych, a nie potrzeb użytkowników.
Problem nie leży w dostępie do feedbacku użytkowników—to gotowość organizacyjna do działania na podstawie feedbacku, który przeczy wewnętrznym założeniom. Jak pokazują badania Amy Edmondson nad bezpieczeństwem psychologicznym, zespoły muszą tworzyć środowiska, w których kwestionowanie dominującej wizji jest nagradzane, a nie karane.
Porozmawiajmy o liczbach, bo to przyciąga uwagę dyrektorów. Firmy z dobrze zintegrowanymi badaniami użytkowników widzą 30-70% lepsze metryki biznesowe niż te, gdzie badania pozostają w silosach. Porażki branży gier, które wspomniałem, reprezentują setki milionów straconych przychodów i zamkniętych studiów.
Ale ukryty koszt jest jeszcze większy. Za każdym razem, gdy odrzucamy feedback użytkowników na rzecz naszej wizji, uczymy nasze zespoły, że badania użytkowników są doradcze, a nie obowiązkowe. Budujemy kultury, w których "projektowanie zorientowane na użytkownika" staje się buzzwordem, a nie praktyką.
Marty Cagan mówi o tym w "Empowered"—różnica między zespołami funkcji a zespołami produktowymi. Zespoły funkcji budują to, co im się każe budować na podstawie wewnętrznych założeń. Zespoły produktowe rozwiązują problemy użytkowników na podstawie dowodów. Zgadnijcie, które konsekwentnie osiągają lepsze wyniki?
Rozwiązanie nie polega na porzuceniu wizji—polega na uczynieniu wizji odpowiedzialną przed dowodami. Oto jak to wygląda w praktyce:
Traktuj swoją wizję jako hipotezę, nie fakt. Kiedy zespół Spotify miał wizję odkrywania muzyki, nie zakładali, że wiedzą, jak odkrywanie powinno działać. Testowali dziesiątki podejść z prawdziwymi użytkownikami i pozwolili danym kształtować swoje algorytmiczne systemy rekomendacji. Wynik? Discover Weekly stało się jedną z ich najbardziej angażujących funkcji.
Zbuduj systematyczne pętle feedbacku w swoim procesie rozwoju. Firmy, które unikają katastrof w stylu Avatara, nie czekają na metryki po premierze. Tworzą szybkie cykle testowania, gdzie feedback użytkowników może wpłynąć na decyzje, zanim staną się kosztowne do zmiany.
Przewartościuj opór jako cenną inteligencję. Kiedy użytkownicy konsekwentnie opierają się twojemu podejściu, to nie jest problem komunikacyjny—to badanie rynku. Badania BJ Fogga nad zmianą zachowań pokazują, że kiedy ludzie opierają się przyjęciu nowych zachowań, opór zazwyczaj sygnalizuje niedopasowanie między rozwiązaniem a ich rzeczywistymi motywacjami.
Oto moja kontrowersyjna pozycja: Rozwój produktu napędzany wizją to luksus, na który twoja firma prawdopodobnie nie może sobie pozwolić.
Wiem, że brzmi to jak herezja w świecie, gdzie czcimy cytaty Steve'a Jobsa o tym, że użytkownicy nie wiedzą, czego chcą. Ale Jobs odniósł sukces, bo łączył wizję z obsesyjnym testowaniem użytkowników. Nie ignorował feedbacku użytkowników—zintegrował go z każdym aspektem procesu rozwoju Apple.
Społeczność zarządzania produktem błędnie zinterpretowała "wizjonerskie przywództwo" jako "ignorowanie opinii użytkowników". Pomyliliśmy posiadanie silnych opinii z byciem zamkniętym na dowody. Ta błędna interpretacja systematycznie niszczy wartość w naszej branży.
Każdy product manager czytający to ma wybór do podjęcia. Możesz kontynuować wygodną przeciętność rozwoju napędzanego wizją, broniąc decyzji projektowych przeciwko feedbackowi użytkowników, aż twoje metryki wymuszą kosztowne zwroty. Albo możesz przyjąć wymagającą doskonałość wizji napędzanej dowodami, gdzie spostrzeżenia użytkowników kształtują twój kierunek od pierwszego dnia.
Kosztowna lekcja Avatar: Frontiers of Pandora jest jasna: możesz uszczęśliwiać użytkowników po swojemu albo możesz uszczęśliwiać użytkowników po ich sposobie. Tylko jedno z tych podejść buduje zrównoważone produkty.
Pytanie nie brzmi, czy twoja wizja jest genialna—pytanie brzmi, czy jesteś wystarczająco odważny, żeby pozwolić feedbackowi użytkowników ją ulepszyć. Bo w końcu użytkownicy nie kupują twojej wizji. Kupują rozwiązania swoich problemów.
Przestań uszczęśliwiać użytkowników po swojemu. Zacznij rozwiązywać problemy po ich sposobie. Twoje metryki—i twoja kariera—ci podziękują.
Moi Drodzy Produktowcy
Pragniemy Was poinformować, iż zbliża się przerwa urlopowa w zespole Product Art. Dlatego też, mamy małą przerwę i widzimy się za 2 tygodnie.
Do przeczytania 😍
Product Operating Model
Product Operating Model - Szybkie Eksperymentowanie
Podstawowa Zasada (Marty Cagan "Transformed")
"Przyjmij Szybkie Eksperymentowanie" - Jedna z 4 niezbędnych zasad Odkrywania Produktu
Rzeczywistość: 50-75% pomysłów na produkty nie dostarcza oczekiwanej wartości
Cel: Testować pomysły szybko i tanio przed zaangażowaniem zasobów inżynieryjnych
Zadanie: Maksymalizowanie prędkości uczenia, nie wskaźniku sukcesu eksperymentów
Fundament: Traktowanie każdej decyzji produktowej jako hipotezę naukową
Metoda Naukowa Zastosowana do Rozwoju Produktu
