Jak powstawał nowy serwis mobilny PizzaPortal.pl

Wraz z objęciem roli szefa produktów w PizzaPortal.pl jednym z moich pierwszych zadań było zweryfikowanie stanu obecnych stron i aplikacji oraz przygotowanie planu ich rozwoju.

Zdecydowałem się zacząć od stworzenia zupełnie nowej strony mobilnej. To był wtedy (jeszcze) względnie mały procentowo kanał sprzedaży więc pozwalał na odważniejsze eksperymenty – nawet jeśli efekt finalny okaże się słaby to wpływ na bottom line byłby do przełknięcia. Z drugiej strony miałem przeświadczenie, że mobile web to klucz do odblokowania potencjału tego fragmentu rynku.

W połowie czerwca przejąłem więc kontrolę na rozwojem nowej strony mobilnej PP ustawiając jej powstanie jako podstawowy priorytet na 2015 rok. 21 grudnia, czyli prawie pół roku później, serwis publicznie wystartował i po miesiącu generuje 2.5-3 krotnie więcej zamówień niż poprzednia wersja. Poniżej przeczytacie jak do tego doszło.

Sytuacja zastana

Sam koncept na nową stronę mobilną pojawił się w organizacji jeszcze przed moim przyjściem. Jednak brak jasnej ścieżki spowodował, że kształt produktu wynikał z doraźnych potrzeb zaangażowanych działów. Gdy brakuje faktycznego właściciela filtrującego potrzeby interesariuszy to efektem jest „design by committee”. Prowadziło to do sytuacji, gdy nad jedną dostarczoną grafiką wypowiadało się dziesięć osób z których każda dodawała swoje 3 grosze. Dużo było opinii, mało decyzji.

Screenshot at sty 15 23-30-23
Makiety pierwszych kroków zamawiania jedzenia w PP

Efekt był taki, że strona główna była przeładowana informacjami do tego stopnia, że na smartfonach naszych klientów nie mieściła się cała. Ale za to mamy duże logo! I do tego mówimy jak zamawianie u nas jest proste zamiast pokazać to na faktach.

pizza_portal_red1

 

Pierwszym krokiem jako Product Owner było zrewidowanie tego, co już zostało zrobione z tym, co faktycznie ma być zrobione. Każdy interesariusz dowiedział się, że to ja teraz ponoszę odpowiedzialność za produkt, co też daje mi prawo (i obowiązek) podejmowania decyzji o rozwoju produktu. Stałem się też SPOC (Single Point of Contact) dla wszystkich, którzy w jakikolwiek sposób byli zaangażowani w rozwój nowej strony mobilnej – niezależnie czy chcieli dodać istotną dla nich funkcję czy pytali się jaki ma być kolor przycisku.

W praktyce oznaczało to, że ciągle mówiłem „nie” we wszystkich możliwych odmianach („nie teraz”, „świetny pomysł na future dev”, „nie, dopóki X jest nie zrobione” itd.). Choć brzmiało to czasami oschle to jednak było potrzebne, żeby faktycznie wyklarować co ma faktyczną wartość i musi być zrobione najpierw.

Sprinty i maraton

Rytm pracy wyznaczały tygodniowe sprinty. W każdy poniedziałek kończył się jeden sprint i zaczynał następny. W tym czasie robiliśmy Review – podsumowanie zmian z ostatniego tygodnia oraz Planning czyli określenie pracy na nowy tydzień.

Pół dnia zajmowały nam te dwie czynności, ale dzięki temu reszta tygodnia była spokojna – choć pierwotnie narzut komunikacyjny wydaje się duży to wraz w wejściem w rytm pracy znacznie ułatwia komunikację a mi dawał kontrolę nad losem produktu.

Tygodniowe iteracje mają jeszcze jedną przewagę: jeśli prace idą w złym kierunku to można szybko reagować i robić korektę kursu minimalizując straty czasu i energii.

Każdy członek zespołu miał dostęp do backloga w Pivotal Trackerze, który stanowił nasze główne narzędzie planowania. W czasie tych 6 miesięcy pracy zostało dowiezionych 35 userstories podzielonych na niezliczoną ilość zadań.

Połączyłem Pivotala z naszym firmowym Slackiem więc każdy zainteresowany w organizacji widział od razu jeśli konkretne userstory zostało wzięte na sprint lub zmieniło swoje miejsce w backlogu.

Screenshot at sty 15 22-59-13

Ślepe zaułki

W trakcie prac wpadliśmy na wiele pułapek. Dla mnie największa z nich to myślenie o zamawianiu jak o jednorodnym i jednokierunkowym procesie – tak jak przyzwyczaiły mnie do tego aplikacje mobilne. Jednak strona rządzi się swoimi prawami – użytkownik może pojawić się na niej w innym miejscu niż tylko strona główna – na przykład po wpisaniu w wyszukiwarce „Bobby Burger Kabaty” trafia na stronę tej restauracji w naszym systemie. Witryna wtedy musi w sprytny sposób przeprowadzić użytkownika przez proces uwzględniając, że wcześniej nie podał istotnych dla nas informacji.

Problem polegał na tym, że nie mieliśmy jego adresu więc nie mogliśmy mu powiedzieć czy może z niej zamówić – trzeba było przemyśleć jak obsłużyć taką sytuację, żeby nie zamknął strony wkurzony. W aplikacji jest to prostsze: nie zobaczysz listy restauracji jeśli nie wpiszesz swojego adresu.

To zbudowało w nas potrzebę myślenia „nieliniowego” przy korzystaniu z serwisu. Rozpisaliśmy jeszcze raz poszczególne etapy i podstawową logikę zamawiania uzupełniając ją o „zewnętrzny” ruch, który wchodzi na stronę gdzieś w trakcie zaprojektowanego procesu. Na to nanieśliśmy możliwość skakania między etapami i nasze możliwości przenoszenia danych wraz z użytkownikiem.

IMG_3586
Czerwone linie: potencjalne wejścia z wyszukiwarki. Zielone linie: niestandardowe skakanie użytkownika między ekranami

Taka wizualizacja była ważna, abyśmy wiedzieli gdzie powinniśmy utrzymywać zawartość koszyka użytkownika a gdzie możemy go już wyczyścić. Lub też, tak jak opisałem wyżej, kiedy wymagać podania adresu – przed pokazaniem restauracji czy dopiero przy próbie dodania jedzenia do koszyka. Długo się spieraliśmy co go wkurzy bardziej: brak możliwości sprawdzenia menu bez podania adresu czy poczucie straconego czasu po wybraniu dania gdy okazuje się, że restauracja nie dowozi do miejsca zamieszkania użytkownika.

Takich dyskusji mieliśmy mnóstwo – na przykład czy pozwalać usuwać produkty w checkoucie lub jaką ikona powinna przedstawiać filtrowanie.

Dodawanie, usuwanie i kompromisy

Każdy Planning to zderzanie priorytetów: czy lepiej poprawić design czy popracować nad SEO? Czy ulepszyć obsługę błędów, a może dodać filtrowanie? A może sortowanie wcześniej?

Dyskusje na ten temat długo ciągnęły się podczas naszych poniedziałkowych spotkań. Czasami ich efekty były sprzeczne z intuicją. Na przykład zdecydowaliśmy się wystartować stronę bez jakiejkolwiek opcji sortowania i filtrowania listy restauracji. O wiele ważniejsze było dla nas uruchomienie nowego serwisu, który już przy inicjalnych testach dawał lepsze wyniki niż zwlekanie aż dojedzie nowa funkcja.

I wiecie co się okazało? Nikt nie narzekał na brak filtrowania.

Staraliśmy się sprytnie przyśpieszać cały proces zamawiania. Jedna z największych trudności to wpisywanie adresu na klawiaturze telefonu. Dlatego zawsze pokazujemy podpowiedzi miast i ulic na bazie wpisanych liter.

Teraz jednak poszliśmy krok dalej i nawet bez żadnego wpisywania (wystarczy, że znacznik pokaże się w polu wpisywania, tzw. „focus na inpucie”:) pokazujemy pięć miast z największą liczbą zamówień w naszym systemie. Jest bowiem ponad 75% szansa, że zamówienie będzie pochodzić właśnie z jednego z tych miejsc.

Screenshot at sty 20 10-18-24

Podczas prac nad mobile webem przeprowadzaliśmy znany z Google Ventures Design Sprint (książka na ten temat) zupełnie innego produktu. Jednym z wniosków, których się nie spodziewaliśmy (takie są najlepsze) było to, że użytkownicy często boją się zamawiać, jeśli nie mogą podać swojego numeru mieszkania na samym początku. Mają bowiem przypuszczenie, że nikt się ich o to nie zapyta w dalszym procesie zamawiania, więc ostatecznie ich jedzenie trafi do sąsiada albo na inne piętro.

92DE9349-8ABD-4B09-AEA5-A7961137AB0B
Głosowanie na najciekawsze funkcje przyszłego produktu podczas Design Sprintu

Intuicja podpowiada, że im mniej pól do wypełnienia tym lepiej, ale nasi użytkownicy dali nam do zrozumienia, że jest pewna granica, po przekroczeniu użytkownik której traci kontrolę, a w efekcie zaufanie do procesu. Rozwiązaniem tego dylematu było dla nas dodanie nieobowiązkowego pola „nr mieszkania” na pierwszym ekranie.

Przez „środkowe” miesiące naszej pracy niewiele zmieniało się wizualnie. Ja sam jako Product Owner zaczynałem się frustrować jak zadawano mi pytania jak idzie projekt i jedyne co mogłem powiedzieć to, że dobrze – „programiści programują”. Tymczasem ja nie miałem co pokazać – zmiany wizualne w prototypie nie odzwierciedlają ogromnej pracy wykonanej na poziomie logiki systemu co daje poczucie, że nic nie posuwa się do przodu.

Ostatecznie jednak, gdy przyszła pora na łączenie ze sobą elementów widocznych dla użytkownika z faktycznych silnikiem to szybkość zmian była więcej niż satysfakcjonująca.

Jednym z naszych wąskich gardeł jest ekran konfiguracji dania. Ze względów logiki systemu, zaszłości technologicznych a przede wszystkim liczby możliwych konfiguracji  jedzenia ten ekran potrafił się ładować i przesyłać dane z opóźnieniem. To, z perspektywy użytkownika, mogło oznaczać, że strona nie działa. Aby zniwelować takie poczucie dodaliśmy… cóż, dodaliśmy to co wszyscy lubią najbardziej – GIFy:)

preloader_pizza_2x
Ładowanie opcji konfiguracji jedzenia
Dodawanie do koszyka
Dodawanie do koszyka

 

Jedną z głównych motywacji zmiany strony mobilnej była jej niska czytelność dla crawlerów wyszukiwarek przez co musieliśmy zwiększać nasze nakłady na SEM, aby nadrobić niską skuteczność SEO. Faktyczny problem powstał jednak, gdy Google ogłosił w kwietniu 2015 zmiany w swoim algorytmie, czego efektem było stawianie w wynikach wyszukiwania wyżej stron, które mają wersje mobilne. Branża SEO nazwała to „mobilegeddonem”. Dlatego tworząc nową stronę od samego początku myśleliśmy o transparentnej strukturze danych, łatwej do przyswojenia przez Google’a.

Testowanie

Nawet jeśli mobile web nie jest najważniejszym kanałem sprzedaży w PP to jednak proces podmiany starego serwisu na nowy musi być przeprowadzany w przewidywalny i bezpieczny sposób.

9 grudnia rozpoczęliśmy współpracę z zespołem A/B testów z naszego berlińskiego biura. Do tej pory ten zespół zajmował się optymalizacją poszczególnych elementów, aby małymi krokami podwyższać konwersję (np. przez zmianę koloru przycisków albo wielkości zdjęć). My natomiast postawiliśmy przed nimi zadanie na zupełnie nowym poziomie: a co jeśli chcemy zrobić split testy dwóch zupełnie różnych stron, aby sprawdzić czy to, co stworzyliśmy faktycznie działa w dużej skali?

To było poważne wyzwanie, które wymagało naukowego badania i skoordynowania kilku systemów (Visual Website Optimizer i Advanced Segmentation w Google Analytics) do badania efektów statystycznych z uwzględnieniem odpowiedniej wielkości próbki i poziomu istotności. Postawiliśmy na środowisku produkcyjnym alternatywną stronę z przedrostkiem beta i codziennie patrzyliśmy na raport z fluktuującymi wynikami % Delta eCom CVR.

Zrzut_ekranu_15.01.2016__22_23
Raport ze split testów

Chcieliśmy nasze testy wykonywać w jak najmniej inwazyjny sposób więc zaczynaliśmy z niskiego pułapu i zwiększaliśmy z czasem próbkę. Na samym początku z całego ruchu wyznaczyliśmy i oflagowaliśmy 10% użytkowników, którzy zobaczą nową stronę mobilną. Następne 10% zobaczy starą stronę ale także zostanie oflagowana – jako grupa kontrolna. Pozostałe 80% ruchu nie uczestniczyło w badaniu.

Wraz z pozytywnymi efektami zwiększaliśmy obciążenie na 20% – 20% i ostatecznie 50% – 50%. To było przydatne także dla naszego zespołu developerskiego, który mógł badań w kontrolowanym środowisku obciążenie i szukać błędów, które mogą stawać się widoczne dopiero przy większej grupie realnych użytkowników.

Ship it!

Efekty testów przeszły całkowicie nasze przypuszczenia. Lech (CEO PizzaPortal.pl) gdy zobaczył wyniki testów zapytał się, ile tracimy dziennie pieniędzy nie mając już zaimplementowanej nowej strony. Gdy to obliczyłem to trochę pobladłem.

Co zrozumiałe, Lech mocno argumentował, abyśmy nie czekali już dłużej i upublicznili stronę jak najszybciej. Ja chciałem jeszcze dać sobie i zespołowi trochę czasu na następne poprawki i resztę funkcji, ale ostatecznie przyśpieszyłem start z 28.12 na 21.12.

I dobrze, że dałem się przekonać. Dopiero presja Lecha pozwoliła mi zauważyć, że mógłbym cyzelować produkt dodając „jeszcze jeden ostatni feature” w nieskończoność. Zreszta, mam takie tendencje patrząc po doświadczeniach z Play24.

Dzień deploymentu – poniedziałek 21.12-  to jednocześnie czas naszej firmowej wigilii w firmie. Gdy inni się bawili my nerwowo zerkaliśmy na telefony pod stołem obserwując na żywo, czy wszystko idzie dobrze, koordynując warszawski zespół developerski, szwedzki dział backendowy oraz nasz łódzko-berliński dział marketingu.

Screenshot at sty 20 10-15-08
Wersja finalna

Tutaj jeszcze jedna nauczka: produkt to nie tylko produkt, ale także jego infrastruktura. Nie doceniliśmy ile zamieszania może wywołać podmiana klucza API, podmiana domen i rekonfiguracja usług trzecich w nowym produkcie. Najgorsze jest to, że za każdym razem jest to niezwykle indywidualna sprawa i tak rzadko wykonywana, że brakuje uniwersalnej formuły, dzięki której wszystkie kroki w odpowiedniej kolejności zostaną wykonane.

Efekty

Screenshot at sty 10 14-05-30
21 grudnia – premiera nowej strony

Efekt możecie sprawdzić  tutaj.

Minął już miesiąc od startu tej strony – historycznie jest to dla nas zarówno najgorszy (Gwiazdka) jak i najlepszy czas (1-2 stycznia) jeśli chodzi o zamówienia. Mieliśmy więc możliwość przetestować skrajne sytuacje działania strony. I co się okazało?

Z najgorzej działającego kanału nowy Mobile Web awansuje bardzo szybko w naszym wewnętrznym zestawieniu liczby zamówień na dzień – od razu wyprzedził iOSa a teraz, wraz ze wzmacnianiem się SEO, wyrównuje się już z Androidem. Konsekwentnie, dzień za dniem generuje 2.5-3x lepszą konwersję od poprzedniej wersji. Jest jeszcze jedna wyjątkowa rzecz: nowy Mobile Web ma też najlepszy średni koszyk ze wszystkich kanałów – 40,5 zł. Te dwa fakty powodują, że nowy mobile web nagle stał się zauważalną częścią strumienia przychodów.

I choć pod względem optymalizacji czasu ładowania jeszcze długa droga przed nami to bardzo miło się patrzy na wyniki automatycznych testów Google’a które pokazuję maksymalną liczbę punktów w zakresie wygody użytkowników.

Screenshot at sty 13 13-17-56

Mój pierwotny plan zakładał stworzenie nowej strony mobilnej w trzy miesiące. Ostatecznie zajęło to prawie dwa razy więcej czasu, co też przekłada się na znacznie wyższe koszty. To jednak jest jeszcze akceptowalne biorąc pod uwagę, że w międzyczasie zespół developerski nam się rozpadł (z pierwotnych czterech osób została tylko jedna) i należało go odbudować niemal od początku – i to w połowie prac. W większości przypadków taka sytuacja prowadzi do zabicia produktu i konieczności rozpoczęcia od nowa. Na szczęście Scrum i transparentność procesu pozwoliły, że nowy zespół szybko wdrożył się w produkt i w znacznym stopniu zniwelował opóźnienia.

Co dalej

Mam silne poczucie, że udało nam się zbudować dobre fundamenty do dalszej pracy a z każdą nową funkcją otwierają się także nowe możliwości. I choć przez te pół roku zrealizowaliśmy 35 userstories to mamy jeszcze 32 następne do wykonania (i ciągle przybywają nowe!). Jednocześnie doświadczenia zebrane przy tworzeniu nowego Mobile Web są dla nas podstawą do prac nad następnymi projektami – tym razem o skalę wielkości większymi. Trzymajcie kciuki!

Dziękuję obydwu teamom dzięki którym ten projekt był możliwy oraz za wiarę Lecha i całej PizzyPortal.pl w moje metody.

ps. w 2013 roku napisałem podobny tekst, ale o powstawaniu innego mojego projektu – Play24.

2015

Zgodnie z tradycją czas podsumować ostatni rok – w ten sam sposób jak zrobiłem to z 2014 i 2013. Ostatnie dwanaście miesięcy to, raz jeszcze, czas zmian – tych, na które zbierało się już od dawna i tych, które nadejdą w zbliżającym się roku.

Czytając moje podsumowania z poprzednich lat zauważyłem jak wtedy podejmowane decyzje mają wpływ na obecną sytuację – jaki robię progres w myśleniu i robieniu. Jak do pewnych rzeczy trzeba dojrzewać latami a inne, pierwotnie nierealne, są możliwe dopiero po długich przygotowaniach.

Gdy patrzę na swój pojedynczy dzień czy nawet miesiąc to wydają się zamkniętymi, statycznymi całościami. Jednak z perspektywy kilku lat widać, jak wszystko jest płynne, zmienia się i ewoluuje. W związku z tym drzwi, które wydają się zamknięte w 2013 teraz są otwarte, a idee wtedy oczywiste stają się anachronizmem.

Poglądy

Ten rok to pewna moja osobista zmiana poglądowa – z rynkowego libertarianina-merytokraty na bardziej lewicowe, choć ciężkie do nazwania. Ogólnie można to nazwać intelektualnym i emocjonalnym dorastaniem.

W pewnym momencie dotknęło mnie osobiście uczucie, że to nie jest tak, że każdy dochodzi tam gdzie jest tylko dzięki własnej pracy (choć to mi zawsze mówiło moje młodzieńcze superbohaterstwo), ale jest możliwe także dzięki sumie starań wszystkich dookoła. Pamiętam, że siedząc na ławce w Pier 41 w San Francisco, próbowałem wypisać wszystkich bliskich mi ludzi, którzy w pośredni i bezpośredni sposób pomogli mi w wyjeździe do SF. To była całkiem długa lista, choć ja jak na egoistę przystało widziałem tylko to, co dla mnie wygodne i myślę, że moje decyzje należą tylko do mnie. Uznałem to za ogromną niesprawiedliwość, wynikającą głównie ze światopoglądu, który świadomie wyznawałem przez ostatnie lata.

Z kolei na poziomie makro ferment rozpoczął się od wpisu jeszcze z 2014 roku pt. „Bomba socjalna„. Czysto racjonalnie nie widzę możliwości, aby liberalny kapitalizm pozwoliłby nam jako globalnemu społeczeństwu przetrwać zawrotnie szybki wzrost automatyzacji i sztucznej inteligencji jaki nas niedługo czeka.

To mnie pcha w stronę centrum lub nawet lewicy – w kierunku większej empatii wobec ludzi i zauważania innych niż tylko finansowe aspekty rozwoju ludzi.

Więcej książek

2015 to rok czytania i słuchania książek. Moją nową ulubioną siecią społecznościową stał się Goodreads – to, co czytają znajomi interesuje mnie bardziej to, co piszą na fejsie czy wrzucają na instagramie.

Z planowanych 10 książek na rok udało mi się już przeczytać 14 (tutaj lista). Wyzwanie na 2016 to 20. Czytam bardzo wolno bo lubię sprawdzać wszystkie przypisy i obrócać wszystkie idee w głowie zanim przejdę do następnej strony. Przez co czytanie fascynującej „Sapiens” zajęło mi ponad 3 miesiące.

O ile w zeszłym roku słuchałem dużo audiobooków tak teraz coraz częściej wracam do papierowych wydań. Skorzystałem z rady Szymona, który zauważył, że czytanie na papierze dobrze „odszumia” mózg i ułatwia zasypianie (w przeciwieństwie od elektroniki). Papier ułatwia skupienie bo nie jest interaktywny.

Medytacja

W pewien wyjątkowo stresujący i chaotyczny dzień pracy w 2014 roku wyszedłem szturmem z firmy, aby się przejść i oczyścić głowę. Chodząc tak wokół warszawskich osiedli zacząłem sprawdzać czy są może na smartfony aplikacje, które mogą pomóc mi się uspokoić. W ten sposób trafiłem na Headspace, które zaczęło mnie powoli wprowadzać w świat medytacji i (tfu!) mindfulness.

Tak, mnie też odrzucał ten cały newage’owy posmak, ale jeśli oddzieli się miękkie sekciarskie mumbo-jumbo od faktycznych technik obserwacji własnych myśli to otrzymuje się narzędzie, które dało mi większą kontrolę nad emocjami i zmniejszyło stres. Okazało się w międzyczasie, że to nie tylko moje anegdotyczne doświadczenia, ale efekty potwierdzone naukowo.

U mnie działa – niezależnie czy medytuję codziennie (trochę ciężkie logistycznie) czy raz na miesiąc.

Zegarmistrz

FullSizeRender

Rok temu na gwiazdkę otrzymałem prezent w postaci lekcji u prawdziwego zegarmistrza. Tak mi się spodobało, że teraz 1-2 razy w miesiącu jeżdżę do mojej rodzinnej miejscowości, aby sobotnie poranki spędzać na rozkładaniu i składaniu najróżniejszych mechanizmów.

Jest coś pięknego w dobrze działającym mechanizmie. Nauka horologii to dla mnie sposób na wyciszenie głowy, ale też uczestnictwo w budowaniu i naprawianiu małych dzieł sztuki. Moje myślenie o zegarmistrzostwie opisywałem już wcześniej.

PizzaPortal

W połowie roku zmieniłem pracę. Z członka zarządu odpowiedzialnego za business development w Senfino zamieniłem się na head of product w PizzaPortal. Ta zmiana pozwoliła mi się w pełni skupić na rozwoju jednego produktu – coś co zawsze chciałem robić.

To jednak niosło za sobą spory narzut emocjonalny – zespół Senfino traktowałem jako moich najbliższych znajomych, a firmę jako coś, co budowałem niemal od początku. Wciąż ze sobą pracujemy (teraz jestem klientem swojej byłem firmy), ale nostalgia zostaje.

Tymczasem PizzaPortal to moja nowa ambicja – jest co robić kierując rozwojem produktów u największego dostawcy jedzenia w Polsce (i części DeliveryHero – największego gracza na światowym rynku). Wyzwań jest mnóstwo, w skali ciężkiej do wyobrażenia sobie w innych polskich startupach.

MDM

IMG_2835

W maju tego roku miała premierę moja książka – Mobile dla Menedżerów. To był kawał ciężkiej pracy. Jestem dumny z efektów, ale 9 miesięcy pracy po godzinach i weekendach spowodowały, że przez następne pół roku nie miałem ochoty napisać nic dłuższego niż notkę na bloga.

Idea napisania książki zrodziła się podczas urlopu, frustracji jakością właśnie przeczytanego artykułu branżowego i mojej potrzeby robienia czegokolwiek jak leżałem plackiem przy basenie. Zacząłem więc spisywać tematy na blogowe wpisy, które same ułożyły się całkiem sensowny spis treści.

Mam zazwyczaj słomiany zapał więc byłem poważnie zaskoczony moją motywacją i systematycznością. Możliwe, że po prostu ten temat jest dla mnie osobiście ważny i pisałem ją z własnego doświadczenia. To nie jest tak, że ja chciałem napisać książkę i szukałem sobie tematu. Po prostu musiałem znaleźć temat, który był dla mnie osobiście wart poświęcenia wolnego czasu.

W sumie sprzedało przez pół roku od premiery około 600 sztuk papierowych, 100 sztuk ebooka plus 800 sztuk w ramach pakietu w Bookrage. Dużo, mało? Ciężko mi określić. Nie pisałem jej żeby zarobić (ledwo co dotarłem do prowizji, która pokrywa moją zaliczkę:). Ale osobista satysfakcja jest wielka. Wnioski z pisania MDM opublikowałem tutaj.

San Francisco

IMG_3099

Chwilę po tym, jak domknęliśmy kwestię zmiany mojej pracy dzięki uprzejmości Google’a, miałem możliwość pojechania do San Francisco na konferencję Google I/O. Była to moja pierwsza wizyta w Stanach i od razu z takim przytupem.

Podczas ponadtygodniowego wyjazdu razem z Filipem mieliśmy nie tylko okazję pogadać z topowymi ludzi z Google’a i okolic, ale także zwiedzić całe miasto na piechotę (ścigaliśmy się komu Apple Health pokaże więcej kroków – robiliśmy dziennie po 20km przez miasto obgadując wszystkie możliwe branżowe ploty).

Zwiedzając SF miałem poczucie jakbym był na planie filmowym a dialogi ludzi na ulicach są wyreżyserowane. Z drugiej strony spodziewałem się większych niespodzianek – amerykańskie filmy katastroficzne spowodowały że krajobraz miasta nie był dla mnie niczym nowym. Mam osobistą satysfakcję, że przeżyliśmy z Filipem mieszkanie i funkcjonowanie w najgorszej dzielnicy SF czyli Tenderloin.

Wspinaczka

IMG_3745

Mało miałem  aktywności fizycznych w tym roku. Paulina chcą nas trochę rozruszać zaproponowała wspinaczkę. Już kiedyś miałem okazję jej spróbować (jeszcze mieszkając we Wrocławiu), ale wtedy zupełnie mi się nie podobała – nikt mi nie powiedział, że wspina się z nóg a nie rąk. Przy odpowiednim wsparciu bardziej doświadczonych wspinaczy małymi kroczkami uczyliśmy się tej sztuki.

Wspinanie się daje wielki zastrzyk adrenaliny. Nawet teraz pisząc te słowa czuję jak pocą mi się ręce. Będąc na ścianie miałem poczucie bliskiego kontaktu z biologicznym niebezpieczeństwem. Mózg mi mówi, żeby tego nie robić, jest wysoko, a co jak spadniesz, czy ta lina wytrzyma? Miałem ogromną satysfakcję wchodzenia mimo to, sprzeciwianiu się samemu sobie. 3 godzinna sesja na ścianie mijała jak 15 minut.

Wietnam

IMG_4370Tak się w ogóle ciekawie stało, że choć uważam siebie za całkiem nieźle oblatanego podróżniczo gościa to po raz pierwszy w tym roku byłem poza Europą – po raz pierwszy w Stanach i drugi raz – w Wietnamie.

W ciągu niemal 3 tygodni udało nam się zwiedzić trochę centralnej i południowej części tego fascynującego kraju. Naszą bazą i punktem wypadowym był Sajgon. Miasto, które polubiliśmy dopiero za trzecią wizytą. Dopiero wtedy zauważyliśmy, że to nie tylko niemiłosierny harmider i mentalny pustostan backpackerskiej dzielnicy, ale także wiele ukrytych przed przewodnikami skarbów.

Reszta kraju jest ciężka do opisania, bo to pokaz skrajności: kurorty dla obcokrajowców i jadłodalnie z Pho dla lokalsów. Fantastycznie świeże, dobre i tanie jedzenie i plastykowe krzesełka. Sztandary komunistyczne obok sklepu Louis Vuitton.

Zdecydowanie chcę tam wrócić.

30

12065978_10208040308355533_8561584252206234839_n

W dniu moich urodzin byliśmy z Pauliną w Can Tho na Delcie Mekongu, w drodze na wyspę Phu Quoc. To był dzień jak każdy inny, poza tym, że właścicielka naszego pensjonatu przygotowała dla mnie mini tort (podejrzała w moim paszporcie datę urodzin) i że dostałem maila, który sam od siebie napisałęm pięciu lat wcześniej. Próbowałem w nim zgadnąć co się u mnie będzie działo jak stuknie mi trzydziestka. I choć ruchy, które wykonywałem wtedy powodują, że właśnie tutaj dotarłem to żadne z moich przewidywań z maila się nie sprawdziły. Ciekawe jak będzie za następne pięć lat.

Dziecko

stas

Największą i najważniejszą rzecz zostawiłem na koniec. Spodziewamy się z Pauliną dziecka! I choć faktyczne oczekiwanie skończy się dopiero w maju przyszłego roku to już po malutku do tego przygotowujemy emocjonalnie i logistycznie. Jedno jest pewne: przyszły rok będzie należał do naszego synka.

Czuję przyjemny wewnętrzny spokój na koniec tego roku. Wiele się wydarzyło, ale czuję, że jestem w dobrym miejscu, a przyszłość wygląda jeszcze ciekawiej niż przez poprzednie lata.

I’m excited.

Jak odróżnić?

Wczoraj wieczorem zostało mi zadane pytanie (parafrazując):

 

Jak odróżniamy to, co wydaje nam się, że potrzebują użytkownicy od tego, czego naprawdę potrzebują?
Do pytania był jeszcze dodany cytat:

 

„Gdybym pytał klientów, czego chcą, powiedzieliby, że szybszego konia!” – Henry Ford
Wiedziałem, że nie dam rady zasnąć dopóki nie odpowiem, bo to pytanie z kategorii tych kluczowych – szczególnie jeśli tworzy się produkty technologiczne. A jednocześnie jeden z moich ulubionych tematów dyskusji. Poniżej moja odpowiedź – rozszerzona, poprawiona stylistycznie i z pewnymi zmianami natury biznesowej.

 


 

Ten temat można rozważać na na kilku płaszczyznach. To co my mówimy, że chcemy a to, co chcą użytkownicy to dwa różne worki. Ten pierwszy (my) zawsze powinien być wystarczająco większy niż ten drugi (użytkownicy), abyśmy mogli testować jak najwięcej rozwiązań. Dlatego zawsze opłaca się mieć jak najszybsze cykle wdrażania i testowania (temu sprzyjają  jednotygodniowe sprinty developerskie), aby sprawdzać czy to, co my chcemy jest także też tym, co chcą użytkownicy. Każdy taki pozytywny test to jeden krok bliżej optymalnego produktu. Ten proces jest jednak niebezpieczny, bo efektem finalnym może być właśnie „szybszy koń” o którym mówił Ford.

 

Dzieje się tak, bo każda iteracyjna poprawa oparta jest na myśleniu wstecznym – patrzymy o ile lepiej działa produkt teraz w stosunku do tego jak działał dzień, tydzień, miesiąc temu. Tak samo jak patrzymy na dane z systemów analitycznych, które zawsze opierają się z danych z przeszłości. Gdy zamiast tego powinniśmy próbować przewidywać przyszłość.

 

Dla mnie to droga iteracyjna – wyciskanie ile można z zastanej sytuacji. Tak jak podkręcanie procesora czy silnika – zawsze trafia się na sufit ograniczeń technicznych, fizycznych i logistycznych. Natomiast coś, co przychodzi z zupełnie innego rynku, jest budowane od zera, bez legacy code i istniejącej struktury jest szybsze i ma lepszą trakcję – i w ten sposób wkrótce będzie miało przewagę nie do pokonania przez starszych rynkowo konkurentów z bagażem.

 

The Innovator’s Dilemma” Claytona Christensena dokładnie opisuje zagrożenia iteracyjnego podejścia opartego na optymalizacji obecnych rozwiązań. Autor nazywa efekt takich działań sustaining innovation.

 

F1.large
Christensen mówi wręcz, że firmy za bardzo słuchają swoich klientów. Ci bowiem zawsze będą opisywać przyszłość słowami teraźniejszości: „To samo, ale szybsze”. To naturalna pułapka myślenia, bo przecież nie da się chcieć czegoś o czym się nie wie. I gdy firmy spełniają potrzeby swoich obecnych klientów to w tym czasie w jakimś garażu powstaje firma, która klientów jeszcze nie ma, tworzy na początku tańsze, mniej stabilne rozwiązanie, bez jasnej ścieżki rozwoju, ale z ogromnym potencjałem zmiany zasad rynku. AirBnB nigdy by nie powstało w Hiltonie, Uber nigdy by nie powstał w korporacji taksówkarskiej – klienci Hiltona i taksówek po prostu nie wiedzą, że potrzebują tak radykalnie innych sposobów zaspokojenia swojej potrzeby.

 

Dlatego odpowiadając na pytanie widzę dwie metody sprawdzania: po jednej stronie mamy iteracyjną, a po drugiej skokową. Pierwszą opisałem na początku – druga to sposób, aby disruptować się samemu, zanim zrobi to ktoś z zewnątrz.

 

Ta druga ścieżka to podejście jakościowe. Opiera się na hipotezach, które są znacznie odważniejsze niż iteracyjne zmiany – bo disruptive innovation nigdy nie pojawi się dzięki A/B testom. Znów jednak opieram się na  Christensenie – tym razem teorii „Jobs To Be Done„.

 

JBTD zakłada, że każdą rzecz, którą mamy „zatrudniamy” do wykonania pracy – zaspokojenia potrzeby. Nie jest jednak dla nas zawsze jasne, skąd bierze się wybór konkretnego sposobu zaspokojenia. Zawsze mamy te same potrzeby (sen, jedzenie, przynależność, komunikacja itd), zawsze chcemy je zaspokajać coraz lepiej, ale nie potrafimy tego racjonalnie zakomunikować (dla zainteresowanych polecam film poniżej). Aby sięgnąć do tych insightów trzeba próbować pobudzać emocje, nostalgie i zmysły – tam gdzie racjonalny umysł nam mniej przeszkadza.

 

Dlatego stosuje się w takich przypadkach m.in. techniki generatywne, które pomagają dotrzeć do tzw. wiedzy ukrytej czyli tego, co ludzie czują i o czym marzą. Na marginesie – pionierami w robieniu takich badań na polskim rynku znów jest Senfino, polecam ich o to zapytać.

 

sleeswijk-visser1

 

Wyniki badań pokazują przypadki skrajne, które zazwyczaj się wypłaszczają i znikają przy badaniach ilościowych – ale dają lepsze odpowiedzi na pytania „dlaczego” a nie tylko „jak” ludzie podejmują decyzje. Dzięki temu próbujemy poznać faktyczne motywacje, które oderwane są od naszego produktu. A więc zamiast tworzyć lepszy produkt szukamy lepszego zaspokojenia potrzeby przez dokładniejsze jej zrozumienie.

 

Jeden poziom dalej od tego podejścia jest Apple, które nie tylko tworzy lepszy produkt, ale popycha użytkowników tam, gdzie uważa, że ma większe możliwości zaspokajania potrzeb. Na przykład nowy iPhone 6s. Ten telefon mógłby być spokojnie kilka milimetrów grubszy i dzięki temu oferować dwa razy dłuższy czas pracy baterii – każdy napotkany użytkownik by o to prosił.

 

Ale Apple się upiera, że chce pchać użytkowników do jak najcieńszych urządzeń bo chce przekraczać wszystkie bariery dając swoim użytkownikom poczucie, że korzystają z czegoś magicznego (a to jest faktyczna potrzeba za którą kupujący chcą płacić premium).

 

Reasumując: nigdy nie wiemy do końca czego chcą użytkownicy. Dlatego, że sami tego jednoznacznie nie wiedzą. To, co możemy robić do być jak najbliżej ich i raz ufać ich opiniom, a za drugim razem intencjonalnie nie ufać; robić odmienne rzeczy licząc, że otworzymy im w głowie nową klapkę o której sobie nawet nie zdawali sprawy.

 

Ważne, aby nie pomylić jednego z drugim.