Jak powstawało Zilo

Ten wpis można czytać także w formie PDFa (35 stron, 8mb) . Do ściągnięcia tutaj

Swoją drogą to tylko jedna z kilku Dekompozycji, które zrobiłem w ciągu ostatnich 8 lat. Wszystkie znajdują sie tutaj

Zamiast wstępu

DobryMechanik.pl (dalej DM) to portal, który agreguje warsztaty samochodowe i prezentuje je kierowcom, którzy potrzebują naprawy. Serwis powstał w 2013 roku, a w 2018 roku zainwestował w niego fundusz  Market One Capital.

O firmie dowiedziałem się od Marcina Kurka z MOCy. Rozmawialiśmy z Marcinem przez ostatnie lata kilkakrotnie o jego spółkach portfelowych, które potrzebują wsparcia produktowego, ale do tej pory timing był niekorzystny. Tym razem było inaczej.

Następnie miałem kilka rozmów z Filipem Goździewiczem (COO) i Krzyśkiem Chudzikiem (CEO i founderem). Sytuacja z jaką zmaga się DM wyglądała interesująco: zdominowali lokalny rynek, rozwiązali jeden (kluczowy) element customer journey, ale mają zbliżający się sufit rozwojowy do przebicia którego potrzebna jest inwestycja w technologię. Firma potrzebowała kogoś, kto wymyśli i wdroży rozwiązania produktowe uniezależniąjace ją od SEO, zwiększając przy tym lojalność warsztatów i kierowców.

Oto kejs rozciągający się na półtora roku mojej pracy dla DM i moje zmagania z tym zadaniem, której finalnym efektem było Zilo, oprogramowanie do zarządzania rezerwacjami w warsztacie samochodowym. Ale zacznijmy od początku

Gdybym był konkurencją…

Na początku kwietnia 2020, po przeprowadzeniu kilkudziesięciu rozmów z kluczowymi pracownikami i warsztatami byłem gotowy do przedstawienia mojej idei rozwoju produktu. Postanowiłem podejść do tematu przybierając rolę potencjalnej konkurencji, która chce zdobyć całkowitą dominację nad rynkiem DM (czego boleśnie doświadczyłem przy PizzaPortal i iTaxi).

Wyobraziłem sobie, że jestem szefem produktu w młodym, dofinansowanym kilkoma milionami $ startupie, bez długu technologicznego, bez zespołu i bez rynku. Jak bym strategicznie podszedł do ataku na DM?

DM to marketplace. Po jednej stronie jest popyt – kierowcy, którzy potrzebują naprawy bądź serwisowania samochodu. Po drugiej podaż – warsztaty, które szukają klientów. Po środku jest platforma technologiczna, która pozwala na łączenie jednych i drugich.

Najsensowniej więc byłoby popatrzeć gdzie są słabe punkty i lewary każdej z części składowych DM.

Slajd z mojej prezentacji strategicznej – kwiecień 2020

Kierowca

DM zbudował swoją pozycję na ogromnym doświadczeniu Krzyśka (twórcę i CEO DM) w SEO. Pod względem ruchu to największy serwis agregujący warsztaty samochodowe w Europie (ma tyle odwiedzin co dwóch największych konkurentów łącznie). To w ten sposób kierowcy się o DM dowiadują.

Znaczenie SEO spada z każdym miesiącem, bo Google coraz mocniej monetyzuje ruch organiczny lub, mówiąc inaczej, spycha go w dół kosztem wyników płatnych. Jak to robi? Przez upodobnianie wyników organicznych i płatnych do siebie:

Oraz przez promowanie tzw. „zero-clicków” czyli dawania odpowiedzi bez wychodzenia ze stron Google’a:

Te dwa trendy powodują, że pozycjonowanie jako strategia zdobywania rynku sięga swojego sufitu, a odpowiednio spreparowane kampanie reklamowe mogą osiągnąć lepszy wynik krótkoterminowy niż SEO. Ergo: będąc konkurencją DM nie trzeba się bić contentowo, wystarczą dobrze targetowane kampanie i duży budżet marketingowy.

Rozwój serwisu zoptymalizowanego na SEO ma także inne konsekwencje: najważniejszym użytkownikiem jest google’owy pająk, a nie biologiczny człowiek. Preferencyjne traktowanie miały funkcje zwiększające pozycje na wynikach wyszukiwania, a te związane z czytelnością dla ludzkich gałek ocznych miały drugorzędne znaczenie. Dlatego na stronie głównej DM jest pełna siatka miast i kategorii usług, a nie te dopasowane do oglądającego kierowcy, a na wizytówkach warsztatów lepiej pokazać wszystkie obsługiwane marki samochodów niż posiadaną przez użytkownika.

Pierwsza rzecz below the fold na stronie głównej DM

Nothing personal, po prostu taka była (skuteczna do tej pory) strategia.

W konsekwencji konwersja (rozumiana jako relacja osób rezerwujących wizytę do wszystkich wchodzących) była bardzo niska: zarówno z powodu tego, że DM zbiera dużo „niskokalorycznego” ruchu, jak i UX daje wiele do życzenia.

Platforma

Drugi obszar to serce każdego marketplace’u: platforma. To miejsce spotkania popytu i podaży. Ta „przestrzeń”, której kuratorem jest startup, może być różnie zaprojektowana w zależności od charakterystyki produktu i usługi. Inaczej wyglądają platformy, z których skorzystasz dwa lub trzy razy w życiu (kupno mieszkania), a inaczej te, z których prawdopodobnie będziesz korzystać raz w miesiącu lub częściej (dostawa jedzenia). Do tego dochodzą kwestie różnicy średnich koszyków czy metod realizacji lub dostarczenia usługi/produktu.

W każdym razie możemy analizować jak rozwinięta jest platforma, odpowiadając sobie na pytania jak daleko sięga jej ingerencja (kontrola) w relację między popytem a podażą:

  • Czy platforma weryfikuje użytkowników po stronie popytu?
  • Czy platforma weryfikuje użytkowników po stronie podaży?
  • Czy platforma dynamicznie optymalizuje łączenie popytu z podażą?
  • Czy platforma uczestniczy w płatnościach za usługę/produkt?
  • Czy platforma stosuje mechanizmy obniżające koszty/czasochłonność transakcji?
  • Czy platforma ułatwia realizację usługi / dostarczanie produktu?
  • Czy platforma kontroluje jakość świadczonych usług / sprzedawanych produktów?

Platformy mają swoje subtelności i nie wszędzie da się przejąć pełną kontrolę nad procesem ze względu na specyfikę rynku. Na przykład OLX zupełnie inaczej wypada w tych odpowiedziach niż Glovo. Niemniej przejście przez te punkty ułatwia sprawdzenie jak bezpieczna jest platforma na wykorzystanie wyłomów w customer journey.

W przypadku DM wcześniej opisana ścieżka rozwoju przez SEO spowodowała, że sam marketplace jest otwarty- nie trzeba zakładać konta, aby podejrzeć wszystkie treści w środku. To znaczy, że wszystkie treści są publiczne, dzięki czemu DM jest wyżej w wynikach wyszukiwania.

Niestety ogromny sukces w SEO spowodował, że ścieżka użytkownika ma dużo dziur, które stały się istotne lata od startu portalu. DM zdobywa klientów przez treści i długi ogon wyników wyszukiwania, następnie użytkownik trafia na listing warsztatów bądź wizytówkę w domenie DM, wybiera usługę i zostawia swoje dane, a DM kontaktuje się z warsztatem i weryfikuje w imieniu klienta dostępność warsztatu. Następnie dochodzi do podstawienia samochodu, naprawy oraz zapłaty (w której DM nie uczestniczy). Na koniec jest ewentualne zostawienie opinii o usłudze przez kierowcę na portalu.

Już na pierwszy rzut oka widać sporo dziur do eksploatacji. Brak kont użytkownika powoduje brak personalizacji, a przez to obniżoną powracalność. Drugą konsekwencją jest brak dynamicznego sortowania warsztatów w zależności od preferencji kierowców (te preferencje DM zna dzięki frazom wpisywanym w Google’u, ale jest to bardzo płytka wiedza). Brak głębszej integracji z warsztatami powoduje, że DM nie może prezentować z dużą dokładnością dat i godzin dostępności warsztatów. Manualne umawianie jest dużym kosztem, który skaluje się liniowo ze wzrostem skali biznesu. Brak pośrednictwa w płatnościach uniemożliwia efektywne stosowanie promocji. Warsztaty rozliczają się płacąc za wyróżnienie swoich usług na listingach więc jest dla warsztatów po prostu kolejnym kanałem marketingowym, a nie istotną częścią biznesu.

Do tego dochodził dług technologiczny (legacy), który nieubłaganie się powiększał z każdym miesiącem. Kod był pełen wyjątków od wyjątków jako konsekwencji doraźnych zmian i dopasowań do dynamiki rynku. Sama struktura i jakość danych także dawały wiele do życzenia. W efekcie jakakolwiek zmiana dotycząca bazy warsztatów, ich dynamicznej agregacji, sortowania bądź filtrowania, była także związana ze sporym dodatkowym narzutem czasu i energii.

Każdy z tych elementów to potencjalny punkt zaczepienia i szukania przewagi konkurencyjnej.

Warsztat

Intensywna dyskusja wśród produktowców zajmujących się marketplace’ami o tym co powinno być pierwsze, popyt czy podaż, została w moim odczuciu ostatecznie rozstrzygnięta przez strategię rozwoju Ubera, Lyfta i fali podobnych startupów: najpierw budujemy podaż, a do niej przychodzi popyt. Więcej na ten temat warto przeczytać w świetnej książce o historii Ubera „Super pumped” Mike’a Isaaca.

W przypadku DM podażą są oczywiście warsztaty oferujące usługi mechaniczne. Dla nich DM jest skutecznym kanałem zdobywania klientów: wizytówka w domenie DM lepiej się pozycjonuje od samodzielnie hostowanej strony, jest łatwiejsza w administracji i zazwyczaj po prostu ładniejsza i łatwiejsza w obsłudze dla klientów. To wszystko jednak nie miałoby znaczenia, gdyby DM nie przynosiło klientów.

Inne działania warsztatów w Internecie jak samodzielne tworzenie kampanii Facebooku czy Google’u lub zlecenie tego agencjom reklamowym nie były tak efektywne. Albo trzeba mieć spore kompetencje i dużo czasu, albo liczyć się z dużym narzutem agencji.

Niestety minus takiego podejścia jest niska lojalność. Jeśli DM dla warsztatu jest po prostu jednym z kanałów reklamowych to szybko go porzucą jeśli na horyzoncie pojawi się nowy, nawet na chwilkę skuteczniejszy, mechanizm. Analogicznie do rynku dostaw jedzenia lub transportu gdzie rabaty i promocje były tak duże, że faktyczne usługi były sprzedawane poniżej kosztów. To popularny sposób zdobywania rynku przez startupy z mocnym finansowaniem.

Dziura do eksploatowania na tym polu to niska lojalność warsztatów. Dopóki DM będzie w oczach właścicieli warsztatów po prostu kanałem marketingowym to ich przywiązanie będzie nikłe –  koszt zmiany na inny kanał także jest niski.

Co teraz?

Diagnoza postawiona, a jakie powinno być leczenie?

Do każdej z tych trzech części przygotowałem listę możliwości, układające się w konkretny backlog.

Kierowca

Uznałem, że najważniejsze jest obniżenie kosztu kognitywnego korzystania z DM. Widziałem takie możliwości w trzech polach:

  • UX gdzie znaczenie ma szybkość ładowania, harmonizacja interfejsu, personalizacja, budowanie alternatywnych ścieżek zakupowych,
  • Konwersja: zbudowanie presetów procesów bookingowych, rozdzielenie scieżek w zależności od kohort i motywacji (fast-fit vs. złożone naprawy) oraz automatyzacja bookingu,
  • Lojalność: potrzebujemy kont użytkowników, w których zbierać się bedzie historia napraw na bazie których będziemy mogli w merytoryczny sposób o sobie przypominać („Hej, widzimy, że czas sprawdzić olej!)

Platforma

w tej części widziałem cztery obszary poprawy:

  • Dane gdzie potrzebne jest zapewnie spójności i ustabilizowanie uniwersalnego słownika pojęć (aby odwołanie i anulacja wizyt się żadnemy pracownikowi ani systemowi nie myliła) oraz ostateczne ustalenie, który z systemów jest źródłem prawdy o użytkownikach, naprawach, warsztatach i statusach płatności,
  • Matching czyli mechanizmy usprawniające łączenie popytu i podaży, którego centralnym elementem będzie nowy dynamiczny algorytm promujący lepsze jakościowo warsztaty, 
  • Ruch w którym zależy mi na przyśpieszeniu renderowania strony, ale także serwowania informacji z naszej bazy do naszych wewnętrznych systemów oraz potencjalnie zewnętrzny dostęp do API).
  • Automatyzacja związana z ograniczaniem manualnej pracy wymaganej do procesowania kwestii związanych z wizytami, raportowaniem, księgowością i finansami.

Warsztat

  • w tym wypadku moja odpowiedź jest krótka: potrzebujemy Booksy dla warsztatu. Musimy zbudować narzędzie do zarządzania wizytami, które jest proste w używaniu, ma bazę klientów i pozwala na dodawanie wizyt spoza DM. Z kolei DM będzie z tego systemu dostawać informacje o wolnych terminach w warsztatach więc nasza strona będzie miała dokładniejsze dane.

Wszystkie te klocki pięknie ze sobą grały i były od siebie zależne (np. harmonizacja danych wewnętrznych i szybkie ich przesyłanie do API pozwoli zrobić lepszy algorytm; narzędzie do bookingu zmniejszy manualną pracę naszego BOKu itd) i widzieliśmy w środku kilka pozytywnych sprzężeń zwrotnych (lepszy UX -> większa lojalność -> więcej danych -> lepszy UX).

Wiedziałem, żeby to wszystko zrobić potrzebuje dużego zespołu. Naszkicowałem plan na trzy scrumowe teamy na początek – po jednym na Kierowcę, Platformę i Warsztat. Gdzieś w dalszej przyszłości każdy z nich podzieliłby się wewnętrznie na grupę odpowiedzialną za monetyzacje i za wzrost.

Zaprezentowałem moją diagnozę i wnioski przed managementem, wszystkimi pracownikami firmy i inwestorami. Czułem, że mam ambitne zadanie i mnóstwo pracy przed sobą. Chwilę wcześniej dołączył do nas Kamil Kosiński, nowy CTO i mocne wsparcie po stronie technologicznej. Nie wziąłem pod uwagę tylko jednej sprawy – to była połowa marca 2020.

Przycinanie

I wtedy stał się COVID-19. Zamknęli nam szkoły i przedszkola, musieliśmy nauczyć się pracować zdalnie. W moim przypadku dodatkową komplikacją było to, że spodziewałem się za miesiąc dziecka.

Zarząd zareagował szybko. Nie mieliśmy pojęcia jak lockdown wpłynie na nas biznes, więc założyliśmy najgorszy scenariusz. Szybko wprowadziliśmy cięcia wszystkich niekrytycznych wydatków. A nasz dział Produkt+IT musiał pozbyć się dopiero co zatrudnionego pierwszego nowego programisty.

Drogą eliminacji musiałem odchudzić mój plan o 2/3.

Obszar Kierowca został całkowicie zapauzowany. SEO działa i choć UX wymaga poprawy to obecny strumień klientów sugeruje, że tutaj grunt jeszcze nam nie ucieka spod nóg.

Obszar Platforma także został odłożony na półkę z drobnymi wyjątkami – przy okazji innych projektów robiliśmy małe usprawnienia związane z danymi, automatyzacją i płatnościami

Zdecydowaliśmy się skoncentrować na obszarze Warsztat. Taka inwestycja miał najwyższe koszty inicjalne i najdłuższy time to market, ale za to dawała największe nadzieje na transformację biznesową. Dlaczego? Bo miał…

Unfair advantage

Nasze „Booksy dla warsztatów”, w porównaniu do konkurencyjnych programów w branży warsztatowej, miało mieć zasadniczą przewagę: ogromny marketplace za sobą. Łącząc je uzyskujemy całe spektrum nowych narzędzi i pozytywnych sprzężeń wzrotnych:

  • Poprawiona widoczność wolnych terminów na portalu, co przekłada się na większy i aktualniejszy inwentarz wizyt do wykorzystania dla klientów, to daje lepszy UX, a to daje więcej klientów. Więcej klientów to więcej chętnych warsztatów do skorzystania z naszej oferty. A to daje nam więcej warsztatów korzystających z naszego programu,
  • Więcej warsztatów z naszym softem to skrócony czas obsługi manualnej zleceń, co obniża koszt jednostkowy zlecenia, co pozwala mieć lepszą marżę, co daje większy budżet na zdobywanie nowych warsztatów korzystających z naszego softu,
  • Więcej warsztatów korzystających z naszego systemu do bookingu to mniejsze ryzyko rezygnacji z naszych usług, co oznacza zwiększenie lojalności, a to poprawiony Life Time Value i obniżony średni Customer Aquisition Cost. To z kolei pozwola na większe inwestowanie w skalowalne technologie

Równie ciekawe są też sprzężenia zwrotne po stronie warsztatu: zaczynając od łatwiejszego zbierania danych swoich klientów co pozwala na obniżenie średniego kosztu zdobywania nowego klienta, co daje miejsce na atrakcyjniejsze akcje marketingowe, co zwiększa liczbę klientów.

Poza oczywistym argumentem przesyłania kierowców od naszego marketplace’u do naszego systemu rezerwacji wizyt było kilka dodatkowych argumentów dających nam przewagę nad czystymi narzędziami bookingowymi. Na przykład mamy ogromną bazę historycznych wizyt już zrealizowanych dla warsztatów które są na naszej platformie. Te wszystkie dane, poukładane i łatwo wyszukiwalne, mogą być oddane warsztatom jako ich własna baza klientów. To robi mocny efekt wow.

Do tej pory większość warsztatów zarządza wizytami korzystając z papierowego kalendarza lub ze skomplikowanego systemu warsztatowego, w którym widok kalendarza był dodatkiem (a głównym ekranem to dodawanie zlecenia i zarządzanie magazynem części). Dla tych pierwszych warsztatów wartość będzię wynikać z pokazania się jako nowoczesny przybytek (wiedzieliśmy, że właścicielom dobrych warsztatów trochę wstyd gdy korzystają z papieru) oraz z możliwości szybkiego wyszukiwania historycznych wizyt i powracających klientów i samochodów. Dla tych ze skomplikowanymi systemami wartość będzie leżała w czymś innym: prostocie i elastyczności.

Mieliśmy zupełnie inną sieć wartości niż reszta komercyjnych produktów na polskim rynku. Dla tych najpopularniejszych najważniejsze było sprzedawanie części, a sama obsługa zleceń było dodatkową, a nie centralną funkcją. Inni sprzedawali cały zamknięty ekosystem, który zachowywał się w podejrzanie podobny sposób do programów księgowych. Większość z nich pobierała opłaty za wykorzystane stanowiska pracy bez powiązania z tym jak dużo wizyt przez nie przechodzi (nie mają więc spójnych motywacji ze swoimi klientami). Nasz biznes z kolei opiera się na generowaniu nowych wizyt dla warsztatów, więc nie przeszkadza nam, że nasz program może być oferowane za darmo lub po bardzo niskiej cenie.

Kickoff!

Kamil (CTO) wrócił do roli programisty, nasz CEO Krzysiek pełnił także rolę supportu technicznego, nasz senior developer Paweł był także devopsem i adminem. A ja szefem produktu, product ownerem, scrum masterem, grafikiem, uxowcem i analitykiem jednocześnie. W takim mikroskopijnym zespole, nie widząc się na żywo przez 95% czasu musieliśmy stworzyć nowy produkt i utrzymać te, które już mamy. Jak to zrobić?

Stało przede mną zadanie stworzenia produktu od zupełnego początku. W odróżnieniu od PizzaPortal i iTaxi, gdzie moim głównym zadaniem było stworzenie nowej wersji na bazie już istniejących produktów. Z jednej strony ta sytuacja dawała mi dużo wolności, a z drugiej więcej niepewności i mniej danych na temat tego co już działa, a co nie.

Na powierzchni taki system rezerwacyjny wydaje się prosty. Mogłem go sobie rozrysować z głowy na podstawie doświadczeń użytkownika Booksy, czy ZnanegoLekarza.

Zacząłem od podstaw wspólnych dla każdego systemu bookingowego:

  1. Fundamentalnym klockiem jest wizyta – czas w którym zrealizowana jest usługa,
  2. Wizyty dzieją się na przecięciu dwóch osi: czasu i stanowisk (foteli fryzjerskich, gabinetów, podnośników samochodowych, itp.),
  3. Obydwie osie mają swoje ograniczenia: godziny dostępności i liczbę stanowisk. Im więc większa liczba wykonanych usług w ramach tych ograniczeń tym większa efektywność.
Wstęp do idei SaaSa dla DM nagrany tuż przed moim urlopem ojcowskim

Mam więc swoje wymagania graniczne. Co pod to pasuje?

Oczywiście kalendarz. Ten jednak jest zazwyczaj tworzony z perspektywy jednego użytkownika (który jest jedynym zasobem). Oś czasu więc zajmuje całość. A co z osią zasobów (stanowisk)? Co powinien mieć każdy taki system? Zarządzanie stanowiskami, zarządzanie pracownikami i zarządzanie klientami. Później konto użytkownika, pod którym ukryte są ustawienia.

Z tego wszystkiego najważniejsze będzie zarządzanie stanowiskami. To ten ekran będzie główny, to ten będą warsztaty codziennie (miałem wtedy nadzieję) otwierać zaraz po włączeniu komputera i przeglądarki.  I tutaj pierwsza decyzja: muszę zrezygnować z poziomej osi dni/tygodni/miesięcy i w to miejsce wstawię stanowiska. 

Wolne szkicowanie, bez zastanawiania się nad szczegółami pozwala poukładać myśli lepiej niż dowolny brief czy specyfikacja.

Pierwsze makieta. Widok jednego dnia. W pionie godziny, w poziomie stanowiska (zasoby). Na przecięciu wizyty

Ten ekran dał początek reszcie i ustawił strukturę, którą kaskadowo dziedziczyły kolejne ekrany i funkcje.

Po niecałych trzech miesiącach, w połowie lipca 2020 mieliśmy fundamenty architektury, prostą frontendową skórkę kupioną na ThemeForest oraz renderowanie kalendarza dzięki bibliotece FullCalendar

Absolutnie pierwsza wersja naszego kalendarza w oparciu o FullCalendar

Pierwsza wersja miała ogromne ograniczenia. Nie pozwalała na dodawanie nowych wizyt ani oglądanie ich szczegółów, a każda wizyta musiała trwać dokładnie godzinę. Ale ważne było to, że wreszcie mieliśmy coś, co zaczyna wyglądać jak początek realizacji naszej wizji.

Biorąc pod uwagę tempo i wielkość zespołu zdawaliśmy sobie sprawę, że to co robimy to proof of concept. Lepimy wszystko na taśmę i gdzieś w przyszłości czeka nas czas spłacania ogromnego długu technologicznego. Kamil powtarzał to dosadniej co jakiś czas:

Marcin, ale pamiętasz, że to wszystko trzeba wywalić i napisać kiedyś jeszcze raz?

Tak, pamiętałem. Ta myśl wisiała nade mną przez całe półtora roku projektu.

Jednak nie kalendarz?

W sierpniu 2020 doszliśmy do wniosku, że idea oparcia zarządzania warsztatem o kalendarz jest błędna. Dopiero po przetestowaniu naszego prototypu zrozumieliśmy, że nie oddaje on istoty problemu z jak zmagają się warsztaty. Okazało się, że analogia do Booksy i DocPlannera jest niewystarczająca z kilku powodów:

  • Kierowca planuje wizytę nie dla siebie, a dla swojego samochodu. W odróżnieniu od fryzjera czy lekarza klient nie uczestniczy w kluczowej części świadczenia usługi,
  • Wizyty w warsztatach dzielą się na dwa diametralnie różne typy: szybkie powtarzalne usługi (tzw. fast fit tak jak zmiana opon) i długotrwałe, wieloetapowe naprawy (np. naprawa rozrządu)
  • Dla kierowcy termin wizyty jest równy terminowi podstawienia samochodu do warsztatu (tak jak termin wizyty do dentysty jest równy wykonaniu terminowi wykonania usługi dentystycznej). Faktycznie jednak warsztat może długo zwlekać z usługą –  na przykład przez brak części.

Jak sobie z tym poradzić? Statusy. Bardzo długo zwlekałem z ideą ich wprowadzenia, bo bałem się, że podwyższy kognitywny i organizacyjny koszt korzystania z naszego softu. Poza tym nie wiedziałem do końca w jakim celu warsztaty miałyby dbać o to, aby zmieniać statusy zleceń zgodnie z rzeczywistością. Udawało im się przeżyć bez tego do tej pory więc po co mają pamiętać dodatkowo, aby coś przestawić w naszym narzędziu? Jaki mają mieć w tym interes?

Pierwsze eksperymenty ze statusami reprezentowanymi przez kolory

Wtedy do mnie dotarło: co warsztaty lubią robić? Naprawiać samochody. Czego warsztaty nie lubią robić? Rozmawiać z klientami. Powiązaliśmy więc zmianę statusu z wysyłką powiadomień do klientów. Dzięki temu jeśli w naszym systemie wizyta zmienia status na „Naprawione” to właściciel zostanie o tym poinformowany przez SMSa i maila. To powinno pomóc w przekonaniu warsztatów do korzystania ze statusów.

Druga rzecz to nasze bardzo liberalne podejście. Intencjonalnie mamy tylko cztery: „nowe”, „przyjęte”, „naprawione” i „zakończone”. Jak widać nie ma, wydawać by się mogło, oczywistego statusu „w trakcie naprawy”. Wiedzieliśmy, że nie możemy zbyt mocno narzucać warsztatom procesu. Nam, z zewnątrz, wydaje się on logiczny, ale jesteśmy teoretykami. A praktyka lubi płatać figle teorii. Zostaliśmy więc przy absolutnym minimum – poczekamy i zobaczymy jak się przyjmą.

Trzecia rzecz, która do nas dotarła, że ustawianie wizyty w kalendarzu to tylko część procesu. Powinniśmy mieć też dwa dodatkowe worki: jeden dla wizyt, które jeszcze nie mają swojego terminu i stanowiska. Oraz drugi na samochody czekające na odbiór po wizycie. Jak to dodać do obecnego paradygmatu kalendarza? To zupełnie nie pasuje, bo wizyty niezaplanowane z natury nie mają swojego miejsca w kalendarzu, ale powinny być widoczne, aby móc je do kalendarza przenieść. Z kolei samochody naprawione nie powinny być w ogóle widoczne w kalendarzu – muszą mieć oddzielną sekcje, aby nie mieszały się z tymi w trakcie napraw.

W ten sposób powstała kolumna niezaplanowanych na lewo od kalendarza i zakładka „Do odbioru” w głównym menu.

Dochodzi kolumna niezaplanowane

Sprawy zaczynają się komplikować. Było widać początki końca radosnej twórczości, a w jej miejsce wyłaniał się wewnętrzny zestaw zasad determinujący logikę kolejnych funkcji.

Zaczęło do mnie docierać jak dużo pierwotnych założeń musiałem zrewidować. Przechodziłem przez ten proces już wiele razy przez ostatnie (ponad!) 10 lat, ale za każdym razem mnie to zaskakuje. Choć przecież to najbardziej oczywista rzecz w tej robocie.

Upraszczanie przez komplikowanie

Moja niechęć do komplikowania szybko stopniała, gdy okazało się, że komplikując system „podskórnie” możemy upraszczać interakcję z użytkownikiem.

Tak jak się spodziewałem wprowadzenie wymiaru statusów wprowadziło dodatkowy poziom złożoności. Czy wizyta może zmieniać status z dowolnego na dowolny? No nie, to by było generowało dużo problemów. A więc może progresja może być tylko w jedną stronę: od „Nowe” do „Zakończone”? Ok, a co z przypadkami, kiedy warsztat naprawił, a klient przychodzi z reklamacją? Ah, to pozwolimy na możliwość cofnięcia się z „Naprawione” na „Przyjęte”…  i tym podobne wewnętrzne dialogi nurtowały mnie przez większość trwania projektu.

Mamy już kalendarz i statusy. Zajmijmy się dodawaniem wizyty – podstawowego procesu w tego typu systemach. Weźmy na warsztat prostą historyjkę i zobaczmy jak szybko wszystko się komplikuje:

Kierowcy psuje się coś w samochodzie. Dzwoni do warsztatu, aby umówić się na wizytę. Doradca klienta spisuje szybko jego dane do (naszego) systemu wraz z opisem usterki i ustalają termin podstawienia przyjazdu.

Proste prawda? To pogrzebmy trochę.

Czy ten kierowca był już kiedyś w naszym warsztacie? Jeśli tak, to powinniśmy szybko móc go odnaleźć i wstawić jego dane w formularz. To ważne, bo jeśli dodamy go jako „nowego” mimo, że już u nas był, to będziemy mieć duplikacje danych, która w dłuższym okresie generuje straszne problemy organizacyjne, nie mówiąc o marketingowych.

Z drugiej strony: jeśli klient jest u nas po raz pierwszy to musimy mieć flow z mocną walidacją danych, aby uchronić bazę klientów przed drugim problemem: szumem i brakiem struktury. Trzeba to jednak zrobić tak, aby zachować balans między jakością danych, a szybkością ich wpisywania. Zbyt dużo przeszkadzajek spowoduje, że doradca w warsztacie przestanie używać systemu, bo uzna go za zbyt trudny. Trzeba pamiętać, że te dane będą dodawane w trakcie rozmowy telefonicznej.

Mamy więc dwie różne userflows w zależności od tego czy klient jest nowy czy powracający… ale czy możemy ufać ludziom, że dobrze wybiorą? Możliwe, że klient nieomyślnie wprowadza doradce w błąd: mówi, że już był/ nie był w warsztacie, ale warsztaty mu się pomyliły. Dlatego system w userflow nowego użytkownika weryfikuje po wpisywanych danych istnienie użytkownika i w przypadku znalezienia przenosi do flow „Powracającego” – i odwrotnie: w przypadku braku danych użytkownika powracającego można szybko przenieść się do flow „Nowego”.

Szybko zaczęły się pojawiać nowe komplikacje. Jak szybko wyszukać już istniejącego klienta? Baza klientów w warsztacie nie jest duża – te najlepiej posperujące mogą liczyć na 1-2-3 tysiące rekordów. Można więc zastosować uniwersalną wyszukiwarkę po wszystkich polach (a nie jeden inputfield na imię i nazwisko, drugi na nr telefonu, trzeci na nr rejestracyjny itd.

Dzięki uniwersalnej wyszukiwarce doradca wpisując „Ford” powinien znaleźć wszystkie samochody Ford w swojej bazie jak i Ferdynanda Forda, jeśli ten się akurat w tym warsztacie serwisował.

Gdy już to rozłożyliśmy na części pierwsze to Kamil, dał mi nową historyjkę:

Wyobraźmy sobie, że jestem powracającym klientem tego warsztatu, ale przyjeżdżam nowym samochodem.

Doradcy w warsztatach najszybciej wyszukują po numerach rejestracyjnych więc gdy tak spróbują to baza będzie pusta, ale klient przecież już jest więc tworząc nowego mielibyśmy duplikat.

Co teraz?

Na tego typu problemy logiczne trafialiśmy ciągle i radziliśmy sobie na dwa sposoby:

  1. Rozwiązywaliśmy w sposób, który w naszej ocenie będzie najprostszy dla użytkownika systemu,
  2. Ignorowaliśmy jeśli problem wydawał nam się mało istotny, tj. oddalony od podstawowej funkcji systemu. Tutaj trafiło większość problemów.

Aby więc ułatwiać procesy z perspektywy użytkownika systemy mocno go komplikowaliśmy wewnętrznie. Logika się rozrastała, ale interfejs nie. Najważniejsze, aby trzymać w ryzach narzut kognitywny.

Oto Zilo

Równoległe do rozwoju funkcji systemu trwały dyskusje o tym jak pozycjonować nasz nowy produkt. Czy to ma być samodzielny system, niezależny od DM, a może dodatkowa marka pod wspólnym parasolem? Od tych decyzji zależy czy:

  • produkt który ma mieć własną nazwę, być „powered by” czy też traktujemy go bardziej jak funkcję DM,
  • uwzględniamy go w cenniku DM, sprzedajemy w pakiecie, czy też niezależnie,
  • czy ma mieć własną nazwę i branding

Aby ustrukturyzować dyskusję zdecydowałem się skorzystać z uproszczonej wersji Impact Estimation Table jako narzędzia do podejmowania decyzji. Wypisaliśmy tam 7 najlepszych ścieżek, takiej jak:

  • System bezpłatny, dostępny dla wszystkich warsztatów,
  • Fremium dla wszystkich,
  • Płatny tylko dla nowych kierowców (wpisów w bazie),

Oraz 9 najważniejszych wartości, które mają znaczenie dla naszego biznesu. Między innymi:

  • Łatwe wprowadzenie systemu do warsztatu,
  • Zwiększenie przychodu warsztatu,
  • Wzmocnienie efektu sieciowego,

Następnie wspólnie ustaliliśmy jaki wpływ każdy z modeli ma na nasze wartości. Na początku września 2020 dostaliśmy wynik: na początek najlepszy model to pakietowa sprzedaż, w którą wchodzą dwa produkty: Wizytówka na DM oraz dostęp do systemu bookingowego, który jest niezależnym bytem.

Zdecydowaliśmy się nazwać nas system „Zilo”, co w sumie nic konkretnego nie znaczy (dla ciekawskich to „niebieski” po łotewsku), ale jest krótkie, proste do wymówienia nie tylko w języku polskim, a do tego ma wolną domenę .co. Marcin Jodłowski, nasz szef marketingu testował odbiór  nazwy Zilo wśród warsztatów pracowników i wykluczył jej negatywne konotacje, które mogły być dla nas nieoczywiste. Następnie do nazwy doszusował branding i paleta kolorystyczna, czekająca aż do początku 2021 na wdrożenie.

Fragment brandbooka przygotowanego przez nasz dział marketingu

MVP1

Pierwsza minimalna wersja Zilo miała konkretny cel: grupa dwóch pierwszych warsztatów przejdzie przez nasze wdrożenie i zacznie korzystać z systemu . W tym czasie my zbierzemy ich odczucia i wyciągniemy wnioski co robić dalej.

W połowie listopada 2020 stanęliśmy przed decyzją: startować jeszcze w 2020 roku czy przeczekać okres świąteczny i wystartować na początku stycznia 2021?

Wysłałem wtedy maila o takiej treści (z delikatną redakcją)

Hej,
Jesteśmy teraz w połowie sprintu 20. Sprint 21 zaczyna się 24 listopada i kończy 8 grudnia. Uważam, ze jest szansa, że moglibyśmy wystartować 1-2 chętne warsztaty 8 grudnia lub kilka dni później. Chciałbym jednak żebyśmy się wspólnie zastanowili, czy to już odpowiedni moment. Jestem zainwestowany w rozwój SaaSa, wiec potrzebuje zewnętrznej opinii. Poniżej moje myśli na ten temat, dajcie znać co uważacie:

Argumenty za startem 8 grudnia:
1. szybko zaczniemy testować i zdobywać pierwszy rynkowy feedback
2. grudzień będzię spokojnym miesiącem więc będzie więcej czasu na testy po stronie warsztatu (i mniejsza strata jak coś się mocno popsuje)
3. Po stronie BOKu DM też będzie spokojnie więc narzut dodatkowej pracy obsługi SaaSa będzie łatwiej akceptowalny

Argumenty przeciw:

1. wystartujemy z produktem z dużymi niedoborami w zakresie integracji między Adminem i SaaS (obsługa bookingów online)
2. wystartujemy z produktem, któremu brakuje wielu istotnych funkcji więc możemy do siebie zrazić pierwszych użytkowników
3. wystartujemy w momencie ograniczonego dostępu do supportu IT po tygodniu od startu – święta i sylwester.

Co o tym sądzicie?

Irytowała mnie wizja startowania z tak okrojonym produktem. Coś mi w środku mówiło, że to będzie wstyd pokazać taką poczwarkę i liczyć na to, że ktoś zacznie z tego korzystać. Lista braków była… stresująca.

Wyobrażacie sobie wodować produkt w kategorii zbliżonej do CRMa bez przeglądania bazy klientów? Ba, bez możliwości dodawania nowego klienta (jeśli nie idzie w parze z nowym zleceniem). W samym kalendarzu nie było opcji zmiany długości wizyty – każda musiała trwać dokładnie 30 minut. Nie mówiąc już o tym, że nie istniało automatyczne tworzenie i konfigurowanie nowych kont (musieliśmy to pod spodem robić ręcznie, łącznie z dodowaniem logotypów warsztatów i ustawianiem liczby stanowisk). Albo tym, że ze względu na brak czasu nawet jeszcze nie wdrożylismy brandingu ani nowej nazwy systemu… No cóż, nie da się nie wstydzić pierwszej wersji swojego produktu.

Konsensus zapytanych w mailu osób był taki, że nie możemy czekać całego miesiąca zanim zdobędziemy pierwsze reakcje. Musimy zderzyć się z rynkiem i wyciągać szybko wnioski. To, co już mamy jest wystarczające do zwalidowania podstawowej idei, a to czego nie mamy będziemy dorabiać w następnych sprintach albo robić manualnie.

Bałem się takiej odpowiedzi, ale wiedziałem, że to słuszna rekomendacja.

9 grudnia 2020 wdrożyliśmy pierwszy prawdziwy warsztat w Zilo. Rafał – opiekun naszych najlepszych warsztatów – pojechał do warsztatu i wraz z doradcą klienta połączył się ze mną na Google Meet. Zestresowany poprosiłem o to, żeby udostępnił mi swój ekran i kliknął na link ze wcześniej przygotowaną dla niego wersją Zilo. Obok miałem otwarte okno z Kamilem, który w nocy dogrywał ostatnie rzeczy oraz Moniką (szefową obsługi klienta), na wypadek gdyby coś nie zadziałało.

Ale zadziałało! Przez ponad 30 minut przeprowadzałem przez poszczególne elementy naszego rozwiązania. W międzyczasie przyszedł do warsztatu kierowca i mój rozmówca obsłużył go korzystając z Zilo, a ja patrzyłem na pierwsze prawdziwe zlecenie na żywo. Dla takich momentów warto być produktowcem.

Tydzień później zrobiliśmy drugie wdrożenie. Później jeszcze kilka razy rozmawialiśmy z testerami i pytaliśmy o wrażenia. Tuż przed świętami mieliśmy pewność, że to, nad czym pracowaliśmy przez ostatnie pół roku faktycznie działa i na ten moment jest wystarczająco dobre mimo mojego pierwotnego sceptycyzmu. Ten wstyd siedział tylko mi w głowie.

Etap MVP1 uznałem za zakończony. Między świętami a sylwestrem rozpocząłem układanie backlogu kolejnej wersji.

MVP2

Pierwsze zetknięcie produktu z prawdziwym użytkownikiem zawsze jest otrzeźwiające: tam gdzie my myślimy o górnolotnych ideach, oni sprowadzają nas na ziemie wymagając, oczywistych z perspektywy czasu, funkcji. Zebrałem je wszystkie w jednym miejscu po starcie MVP1 i zderzyłem z moim wewnętrznym planem rozwoju Zilo.

Cel MVP2 był równie konkretny co pierwszej wersji: dowolny warsztat może zacząć korzystać z Zilo. Kluczowe tutaj słowo to „dowolny” – to znaczy, nie tylko taki, który jest nam przychylny i zainwestuje trochę czasu bo nas lubi, ale także ten „z ulicy”. Zilo ma się bronić samo. Styczeń, luty i marzec to czas aby to osiągnąć.

Zacząłem z całej góry funkcji usuwać nie pasujące do celu. Po eliminacji zostało pięć zadań, które nas do tego doprowadzą i byłem pewien, że damy radę je dowieźć w Q1:

  • Mamy ekran Klientów
  • Mamy ekran Statystyk
  • Mamy wdrożony nowy branding i design Zilo 
  • Mamy wdrożone prawdziwe konta użytkowników
  • Mamy zautomatyzowany onboarding warsztatów

Dodawanie nowych ekranów poszło nam względnie bezproblemowo, więc pierwsza część kwartału była spokojna. Aby jeszcze przyśpieszyć zdecydowałem, aby wykorzystać konkurs na 99designs w celu wyłonienia grafika do stworzenia wyglądu Zilo spójnego z brandingiem. Cały proces poszedł sprawnie i wybraliśmy najlepszą propozycję, ale ostatecznie osoba, na którą się zdecydowaliśmy nie była wystarczająco responsywna. Z mojego doświadczenia 99designs nadaje się dobrze na szybkie i proste projekty, które nie wymagają długiego procesu nauki i iteracji na żywym organizmie (jak ulotki, wizytówki, logosy). Zdecydowałem się zacząć od początku, tym razem samodzielnie.

Nowy design, podejście pierwsze

Uznaliśmy więc, że czas znów szukać. Po zebraniu rekomendacji z mojej siatki znajomych i pierwszych kontaktach miałem 16 chętnych. Do finału dotarły cztery. Ostatecznie zdecydowałem się na współpracę z Rewire Studio.

Ich propozycja mnie przekonała, bo była przemyślana pod dalszy rozwój produktu. Nie skupiała się jedynie na ładniejszej interpretacji status quo, ale antycypowała wprowadzanie wersji mobilnej, następnych funkcji, innych stanów i statusów już istniejących obiektów. Słowem wiedziałem, że stoją za tym ludzie, którzy mają doświadczenie, a więc rozumieją, jakie ich designerskie decyzje mają konsekwencje w przyszłości.

Za ich namową zrezygnowaliśmy z popupu z dodawaniem/szczegółami wizyty na rzecz sidebara. To spowodowało, że aktywne okno nie zasłania całego kalendarza i o wiele łatwiej jest całość złamać po wersję mobilną. Polecam, wysokiej klasy specjaliści.

Nasz finalny design – już wdrożony na produkcji

Największym problemem ze wszystkich zadań okazały się konta użytkowników. Do tej pory tworzyliśmy nowe instancje Zilo manualnie, ale teraz, jeśli chcemy być gotowi do skalowania i udostępniania naszego systemu wszystkim warsztatom to musieliśmy przygotować się do głębszej integracji z panelem BOKu, wdrożenia bezpiecznych procesów rejestracji, logowania, nadawania i wysyłki haseł. Choć są to znane wzorce to jednak liczba scenariuszy była długa. Do tego dochodzi klasyczny problem integracji między silosowymi systemami: różniące sie wewnętrzne definicje oraz niemapujące się stany generowały dużo wyjątków i potrzebę translacji i mediacji zarówno na poziomie biznesowym jak i developerskim.

Z drugiej strony widzieliśmy, że względnie mało wizyt dodawanych jest do Zilo mimo naszych działań aktywizacyjnych. Rozmowy z testującymi warsztatami dały odpowiedź: „my tak nie rozmawiamy z klientami”. Nasz formularz dodawania wizyty, choć wydawał się prosty z obsłudze dzięki podpowiedziom i walidacjom, nie odzwierciedlał tego jak doradca klienta rozmawia z kierowcą: nikt nie chce podawać mnóstwa alfanumerycznych danych przez telefon. Dotarło do nas, że możemy to uprościć dzieląc formularz na dwie części: minimum informacji na początku (numer telefonu i powód wizyty) i uzupełnienie reszty jak już kierowca przyjedzie do warsztatu (marka, model, adres mailowy, cena itp). Dzięki temu rozmowy bardziej naturalny przepływ, a obsługa klientów szybsza.

Zmiana procesu umawiania wizyty po konsultacji z testerami

W między czasie zwiększyliśmy liczbę testerów Zilo do 25 warsztatów. To pozwoliło rozszerzyć różnorodność warsztatów na te, które były niedoświadczone z podobnymi systemami, przez te które mają rozwiązania all-in-one dla całego biznesu. Mieliśmy także większe spektrum reakcji: od tych, którzy od raz odrzucili Zilo, przez tych, którzy mieli mieszane uczucia, ale korzystali, aż do poweruserów.

Sesja z jednym z testujących warsztatów. Znaleźli błąd, który pozwalał tworzyć dwie wizyty w tej samej godzinie na tym samym stanowisku

Niezależnie jednak od kontekstu właściciele warsztatów mieli mnóstwo pomysłów na kolejne funkcje – nazbieraliśmy ich ponad 60. Finalnie do wersji MVP2 weszło 8 z tej listy.

Ostatnia prosta

W styczniu 2021 założyłem, że jesteśmy w stanie zrobić cały pakiet do końca kwartału. Na początku marca jednak okazało się, że klocków do poukładania, jak zwykle, jest więcej niż pierwotnie zakładałem: z początkowych 5 zrobiło się 16 o różnej skali wielkości. Produkt to zawsze więcej niż sam <produkt> – to także całe jego otoczenie.

Stan projektów na przełomie lutego i marca 2021

Wiedziałem już, że na wyrobienie się w na koniec kwartału nie ma szans. Ale gdybyśmy zwodowali projekt dwa tygodnie później, 13 kwietnia 2021, to wciąż będzie dobry wynik… Aby jednak to się udało musiałem znów okroić cały projekt.

Nic z tych rzeczy nie było trudne; problem polegał na tym, że były pracochłonne i wymagały ciągłego zmieniania kontekstu. Zacząłem od wycięcia wszystkiego co było nice to haves jak wersja demo. Kwestie prawne wydelegowałem poza mój zespół, landing page zdecydowaliśmy się zrobić w landingi.com zamiast samodzielnie kodować, obsługę multikont usunęliśmy całkiem, dodatkowe maile informujące przerzuciliśmy na sprint po starcie…

W ten sposób lawirując między tym, co konieczne, a tym co tylko się wydaje że konieczne, po jeszcze jednym przesunięciu startu ze względu na odkryte w testach problemy z integracją między systemami, udało nam się wreszcie zbudować finalną paczkę MVP2.

20 kwietnia 2021 późnym wieczorem zrobiliśmy release łączący ostatecznie Zilo z resztą naszych systemów a ja napiłem się wreszcie symbolicznej szklaneczki whisky, która czekała na ten moment już od miesiąca. Dzień później, gdy byłem już pewny, że nic nie wybuchło, wysłałem maila do całej firmy, że wreszcie, po ponad roku, osiągnęliśmy nasz cel.

Jak pracowaliśmy

Zanim pojawiłem się w DM, osobą która zarządzała backlogiem był CEO. Wymagania były trzymane w Github Board, w kilku niezależnych tabelkach Google Sheets i w ustaleniach mailowych.

Pierwszą moją decyzją było postawienie podstawowej wersji Jira Cloud oraz skonsolidowanie wszystkich wymagań w jednym miejscu.  Pierwszy ticket dodałem jeszcze w lutym 2020. Założyliśmy tam konta dla całego IT+Produkt i najważniejszych interesariuszy oraz przenieśliśmy wszystkie aktualne zadania do backlogu w Jirze. Standardowo też ogłosiliśmy, że od tej pory ja staje się SPOC (Single Point of Contact) jeśli chodzi o zmiany w produkcie. Ticket numer 1000 świętowaliśmy 20 kwietnia 2021, trochę ponad 14 miesięcy później. To daje średnio 14 nowych ticketów dziennie (licząc dni robocze).

Czarny odcinek wskazuje moment od kiedy zaczeliśmy zderzać nasz produkt z użytkownikami. Liczba todosów przez to wzrosła. I ciągle rośnie szybciej niż liczba zrobionych zadań

Szybko dotarłem do porozumienia z CTO i określiliśmy wspólnie podział obowiązków: ja mówię „co”, Kamil mówi „jak”. Oznaczało to, że ja jestem warstwą pośrednią między wymaganiami pochodzącymi z zewnątrz działu IT/Produkt i decyduję, co powinno być na górze backlogu. Kamil z kolei ma na swojej głowie, które wybrać technologie i architekturę, jakie mamy procesy produkcyjne, jak releasujemy i tym podobne procesowe kwestie.

To był pierwszy projekt, który w praktyce w całości przeprowadziłem zdalnie. Raz siedząc w lesie, do którego uciekliśmy z rodziną przed pandemią, raz w warszawskim mieszkaniu. Codzienne żonglowanie obowiazkami domowymi, rodzinnymi i zawodowymi było cholernie trudne: zdarzało się, że przed kamerką pojawiałem się z młodszym dzieckiem w nosidle, a inne odbywałem pchając wózek przez park.

Generalnie dzieciom było wszystko jedno, że miałem ważny projekt na głowie więc starałem się układać dzień tak, aby jak najwięcej zrobić gdy śpią lub gdy starsze jest w przedszkolu (jeśli akurat nie ma kwarantanny bądź lockdownu)

To była ciągła walka z wiatrakami i puzzle których rozwiązanie zmieniało się każdego dnia: czasami dzieci nie spały do późnej nocy więc wieczorna praca odpadała, a za krótko spałem, aby wstać bladym świtem i głęboko popracować (wolałem się wyspać – polecam, to dobry lifehack). Czasami nam zamykali przedszkole więc znów trzeba zmieniać rozkład dnia… Nic tak nie uczy fundamentalnej zasady inspect&adapt jak dzieciaki podczas pandemii.

Po ponad 20 wspólnych sprintach poczułem, że wreszcie wypracowaliśmy sobie dobre rutyny:

  • Zawsze o 10:15 mieliśmy daily meeting. Na pytanie „dlaczego tak późno?” odpowiadam: bo ludzie mają dzieci, które trzeba odstawić do szkół i przedszkól i jeszcze zjeść spokojnie śniadanie,
  • Zaraz po daily robiliśmy jednogodzinny Refinement. W zależności od sytuacji między dwa a pięć razy na dwutygodniowy sprint. Idealnie byłoby omawiać na nich zadania na kolejny sprint, ale rzadko nam się udawało. Zazwyczaj na tapecie były niedokoładnie przeze mnie opisane tickety, które właśnie mieliśmy developować,
  • W co drugie wtorki mieliśmy Review i Planning. Pierwotnie Retro mieliśmy w poniedziałki przed startem nowego sprintu, ale ostatecznie zdecydowaliśmy się je robić w środy, dzień po starcie sprintu – wyszło nam, że na koniec sprintu wszyscy są zbyt skupieni na zakończeniu swoich zadań, aby przestawić swoje głowy na myślenie o tym jak zespół może działać lepiej,
  • Wprowadziliśmy system wyceny złożoności zadań oparty na  potęgach dwójki (1, 2, 4, 8, 16, 32 punkty) gdzie każde następne zadanie to skala wielkości wyżej. Niestety po jakimś czasie okazało się, że mamy bardzo duże wahania liczby punktów robionych na sprint więc po kolei ścinaliśmy skalę: na początku nie przyjmowaliśmy zadań za 32 punkty, następnie 16, później 8, aż Kamil zasugerował limit 4 punktów jako maksimum, aby już nigdy nie usłyszeć stwierdzenia na daily: „ja dzisiaj kontuuje wczorajsze zadania”. Pierwotnie byłem sceptyczny, ale okazało się, że to działa perfekcyjnie. Jedyny minus jest taki, że pojawia się na sprint backlogu tak dużo zadań, że ciężko je ogarnąć jednym spojrzeniem,
  • Releasy zazwyczaj robiliśmy zaraz po zakończonym sprincie, około 21:00. To idealna pora: warsztaty już nie pracują, a dzieci śpią.

Tak ułożyliśmy pracę zespołową, natomiast ja jeszcze miałem dodatkowe punkty:

  • Gdy miałem na sobie natężoną pracę koncepcyjną lub analityczną – na przykład projektując nowe ekrany lub planując nastepne sprinty-wstawałem o 6:30, aby móc w ciszy stworzyć nowe makiety i tickety.
  • Spotkania z interesariuszami, które nie wymagały oglądania siebie w kamerkach, ustawiałem na 12-13:00 – tak, aby móc rozmawiając jednocześnie pchając wózek z dzieckiem przez park

Kilka dodatkowych przemyśleń:

  • Tickety w Jirze przez cały projekt nie trzymały wysokiego standardu jakościowego. To był ciągły „work in progress” – odkrywaliśmy na bieżąco nowe wymagania oraz drugie dna i modyfikowaliśmy zadania z dnia na dzień. Niemniej nieporozumienia zdażały się niezwykle rzadko – to przywilej pracy z prawdziwie doświadczonymi programistami w małym zespole,
  • Bardzo trudno jest przeprowadzić dobrą Retrospekcję zdalnie. Dopiero gdy Żona pokazała mi Mural służący do wspólnej pracy kreatywnej udało nam się odtworzyć atmosferę panującą podczas dobrego retro, gdy ludzie faktycznie zastanawiają się co mogą jako zespół robić lepiej.
Przykład naszego Retro na Muralu

Naszym podstawowym narzędziem była Google Meet. W większości przypadków w trakcie telekonferencji miałem otwartą Jirę – zespół pracował na wersji webowej a ja naprzemiennie w aplikacji iOS na iPhonie i iPadzie. Makiety, standardowo już, robiłem w Goodnotes a później łączyłem w klikalne wersje w Marvelu.

Gdy opadł kurz

Nasz release miał duże konsekwencje dla innych działów: sprzedaż musiała wdrożyć nowy cennik (w którym Zilo ma kluczowe miejsce) oraz nauczyć się nowych skryptów; dział obsługi klienta nauczyć się Zilo i pomagać warsztatom, które korzystają z niego po raz pierwszy.  Zmiany tych procesów i cenników zajęły nam kolejny miesiąc.

Raz na jakiś czas robiłem sobie odsłuchy rozmów wdrożeniowych Zilo i to co mniej najbardziej ucieszyło to fakt, że udawało się przeprowadzić warsztat przez cały proces podczas normalnej rozmowy telefonicznej, czasami nawet bez screensharingu (przypomnijcie sobie ile frustracji wywołuje instruowanie własnych rodziców co mają kliknąć rozmawiając przez telefon…).

Dwa miesiące po starcie do Zilo zostało dodanych 1000 wizyt. Bez ani jednego krytycznego błędu i z mikroskopijną listą błędów technicznych.

Wszystko wyglądalo na to, że dobiegliśmy do mety. Z tym, że dobrze wiedzieliśmy, że ta meta jest symboliczna. Praca nad produktem nigdy się nie kończy.

Już pukała do nas nasza kancelaria z listą rzeczy, które muszą być wdrożone, aby zapewnić nam zgodność z prawem w następnych etapach roadmapy. Backlog puchł od nowych możliwości otwartych przez start Zilo i integrację z DM. 

Tymczasem dała o sobie znać inna nienasycona hydra. Pozwolę sobie znów zacytować Kamila:

Marcin, ale pamiętasz, że to wszystko trzeba wywalić i napisać kiedyś jeszcze raz?

Postawiłem sobie za punkt honoru, że gdy już dostarczymy używalną wersją systemu zatrzymamy się, odetchniemy i zrobimy prawdziwy refactor. To wreszcie był ten moment. Moment spłacania długów.

Na szczęście to dług, który spłaca się z przyjemnością widząc jak pierwszy publiczny release sobie radzi na wolności.

Podziękowania

Dziękuję wszystkim, którzy dzielili się swoimi krytycznymi opiniami na temat tego tekstu. Dzięki Wam (mam nadzięję) udało się utrzymać moje ego w ryzach. Szczególnie dziękuję Krzysztofowi Chudzikowi, Filipowi Goździewiczowi i Kamilowi Kosińskiemu, którzy przeżywali to wszystko na własnej skórze razem ze mną.

Dalsze podziękowania należą się nieocenionej loży produktowców, którzy pomogli mi zredagować ten tekst, tak, aby był jednocześnie zrozumiały i merytoryczny. Najwięcej napracowali się nad tym Kasia Małecka, Michał Jaskólski, Kasia Wódka i Kamil Zych. Dzięki!

W obronie frustrujących produktów

HBO Go ma gorszą aplikację od Netfliksa – to raczej nie jest zbyt kontrowersyjne stwierdzenie. Wszystko w HBO Go jest jakieś takie koślawe, wolniejsze, mniej intuicyjne. Do tego czasami zachowuje się bez sensu – potrafi wylogować bez powodu, a później trzeba się zastanawiać czy się jest subskrybentem czy abonentem.

Pewnie też nie raz się zastanawiałaś dlaczego to tak słabo działa? Czemu nikt tego nie poprawił, nie uprościł, nie wywrócił do góry nogami mając użytkownika w centrum uwagi?

Czy nie ma w tej firmie PMa który powinien czuwać nad takimi sprawami? Czy nie ma tam dyrektora od produktów, który walnie pięścią w stół i powie „tak być k$%#@ nie może?”

Otóż w HBO, Microsofcie (hello MS Teams!), Cisco, Nokii i tym podobnych firmach jest mnóstwo świetnych ludzi od produktów, którzy te wszystkie problemy widzą, co więcej, jestem pewien, że mają je całkiem dobrze przeanalizowane. I bardzo by chcieli te problemy rozwiązać, ale nie mogą. Stopuje ich wielka niewidoczna siła, z której my, użytkownicy, nie zdajemy sobie sprawy.

Ta siła powoduje, że rzeczy, które wydają się oczywiste do naprawienia są ciągle na dole backlogów. To siła, która kładzie na kolana najlepiej poukładane zespoły z ogromnymi zasobami, ale nie znajdziesz o niej wzmianki w case studies i success stories.

Mówię o Value Network (w nomenklaturze teorii przełomowej innowacji) lub Value Stack (w nomenklaturze teorii agregacji). Czym jest najlepiej jest pokazać na przykładzie.

Zoom

Zoom to program do telekonferencji. Jego CEO i founder nazywa się Eric Yuan. Eric zaczął swoją pracę w WebEx, która także tworzyła oprogramowanie do telekonferencji. WebEx został kupiony przez Cisco i wcielony do portfolio giganta, a Eric został VP of Engineering u nowego właściciela.

Eric nie był zadowolony z tego jak (nie) idzie rozwój WebExa i przez wiele lat lobbował, aby przekonać organizację do walki o ten kawałek tortu. Mimo to nie udało się – WebEx był w stagnacji.

Ostatecznie Eric odszedł z Cisco i stworzył konkurencję dla swojego własnego produktu – czyli właśnie Zoom. Zoom pojawia się na giełdzie w 2019 roku i obecnie (na dzień 20.10.2020) jest wart 157 mld dolarów, Cisco jest warte niewiele więcej – 166 mld dolarów. To fascynująca historia.

Powtórzę: VP of Engineering mający pod sobą 800 pracowników, z ogromnym doświadczeniem dziedzinowym nie potrafił poprowadzić swojego produktu w zadowalającą stronę.

Możesz być najlepszą strateżką i egzekutorką produktową, możesz mieć najlepszy insight w potrzeby i rozumieć technologię w swojej niszy, możesz mieć nawet zastępy najlepszych programistów na wyciągnięcie ręki a i tak nic nie zrobisz jeśli Value Network Ci na to nie pozwala.

Jeśli chcesz zrobić coś, co nie wpisuje się w metabolizm firmy to spotka Cię tysiąc formalnych i nieformalnych, otwartych i zawoalowanych przeszkód – zaczynając od niezgodności ze strategią a kończąc na błahych formalizmach.

Wśród nich znajdują się także także kompromisy, niekoniecznie zgniłe. Nagle się okazuje ze pierwotnie odważny plan rozwoju trzeba przyciąć, bo jakaś jego część wpływa negatywnie na relacje z partnerem, inną zapauzować ze względu na niezgodność prawną, a jeszcze inna się przedłuży ze względu na dług technologiczny, którego nikt nie miał motywacji naprawiać. A czasami po prostu dlatego, że trzeba ugasić pożary, które teraz się palą, zamiast inwestować w coś co w sumie niewiadomo czy się zwróci.

Żebyśmy mieli jasność: Cisco nie robi tego na przekór swoim największym gwiazdom – w końcu jednym z głównych powodów skupowania spółek z rynku jest zdobywanie najlepszych ludzi wraz z technologią, którą stworzyli i mogą rozwijać pod nowymi skrzydłami.

Doświadczone firmy są już usadowione wygodnie w swojej pozycji, mają zbudowane relacje z resztą rynku (klienci, partnerzy, dostawcy, inwestorzy, giełda), mają ustabilizowane mechanizmy raportowania, mają warstwę managmentu, których premie są zależne od tego czy te same od lat metryki idą w górę czy nie. Jak widać pojawienie się kogoś, kto próbuje ruszać na boki tą łódką nikomu nie jest na rękę – nawet mimo tego, że firma uważa siebie za miejsce przyjazne innowacji. Wszystkim najbardziej opłaca się utrzymanie status quo i to nawet gdy wiedzą, że to krótkowzroczne.

HBO Go

Wróćmy jednak do naszego HBO Go. Jestem przekonany, że gdybyś miała perfekcyjną wiedzę o mechanizmach i dynamice podejmowania decyzji w HBO to byś zauważyła, że te wszystkie UXowe przeszkadzajki, które Cię tak codziennie wkurzają w ich aplikacji ostatecznie sprowadzają się do Value Network tej organizacji.

Nie mam takiej wiedzy, więc mogę jedynie spekulować, niemniej sądzę, że te wszystkie problemy z jakością odtwarzania mogą mieć coś wspólnego z tym jakiej jakości i jak zaenkodowane są treści, co z kolei może wynikać z tego jakie warunki licencyjne ma HBO na swojej platformie, co zapewne wynika z tego jakie warunki panowały w czasach kablówki. HBO powstało w 1972 roku, więc było dużo czasu na stworzenie procesów, procedur i umów, które zmieniały się wolniej niż otoczenie biznesowe i technologiczne.

Netflix powstał w 1990 roku, w walce z HBO to ten młodszy, zwinniejszy konkurent. Niemniej gdzieś tam, na peryferiach pojawiają się firmy, które to właśnie Netfliksa traktują jako wielkiego ciężkiego molocha, którego można przegonić brakiem długów organizacyjnych i technologicznych. Nie mają zobowiązań więc mogą się szybko poruszać. Ale zaczną budować coraz więcej relacji. Coraz częściej obok pytania o odbieranie użytkownikom konkurencji będzie stawać drugie: jak nie dać sobie podebrać już posiadanych. Zamiast tworzenia nowego softu: jak manewrować między limitami postawionymi przez obecny.

Nie wkurzaj się więc na HBO Go. To jak działa ta aplikacja to nie jest funkcja jakości ludzi w środku a efekt działania Value Network. Oni robią co mogą, na tyle, na ile pozwala im plansza do gry.

Teoria Agregacji

Ten artykuł to kontynuacja wpisu Natura Przełomowej Innowacji. Jeśli jesteś tutaj po raz pierwszy rekomenduje zacząć lekturę od tamtego artykułu.

Teoria Przełomowej Innowacji ma jedną zasadniczą wadę: powstała w 1995 roku, ponad 20 lat temu. 

To były czasy w którym Internet nie był jeszcze społeczną normą. Fala wznosząca już istniała, ale tylko mały procent ludzi wiedział, czym tak naprawdę Internet jest: 

Clayton Christiensen tworząc swoją teorię opierał się na danych o gospodarce “fizycznej” – nie istniał jeszcze rynek muzyki, filmów i seriali online, nie istniały gry MMORPG, płatności online, Bitcoin czy wirtualne przedmioty, ani piractwo internetowe.

Co to faktycznie zmienia? Okazuje się, że dotychczasowe podejście do opisywania dynamiki rynku oparte na teorii przełomowej innowacji, przestaje pasować do pewnej grupy podmiotów, które bardzo szybko zadomowiły się na liście najszybciej rosnących i największych społek na świecie (takie jak FAANG: Facebook, Apple, Amazon, Netflix i Google). Okazuje się, że w niektórych przypadkach teoria Christiensena zawodzi – np. według jej założeń iPod i iPhone nie powinny być aż tak wielkimi sukcesami.

Clayton Christiensen podzielił swoją teorię na dwie części:

  1. “New Market Disruption”
  2. “Low End Disruption”

Pierwsza mówi o tym, że nowe firmy, nie mając sieci wartości ustabilizowanych organizacji, są w stanie zignorować standardy rynkowe i zbudować technologie istotne dla segmentów rynkowych, które nie są zauważane przez najwiekszych graczy. Na tej definicji skupia się mój poprzedni artykuł.

Druga część teorii mówi o tym, że na nowym rynku produkt, który jest “zintegrowany” początkowo wygrywa. Z czasem gdy rynek się stabilizuje powstają standardy i wariacja między produktami maleje. Części produktu się komodytyzują (“modularyzują”) i przewagę na rynku zyskuje podmiot, który oferuje najtańszy “wystarczająco dobry” produkt.

To wszystko było prawdą jeśli analizujemy początkowe elementy łańcucha wartości. Jeśli jednak weźmiemy pod uwagę zmiany biznesowe spowodowane przez Internet to zasady gry się zmieniają. 

Ten problem próbuje rozwiązać nowa teoria, która w mojej ocenie stanowi bardzo dobre uzupełnienie pracy Christensena: Teoria Agregacji.

Ale żeby zrozumieć jej założenia musimy zacząć, jak zwykle, od początku.

Łańcuch wartości

Efektywność każdego przedsiębiorstwa można oceniać w trzech domenach: 

  • skuteczność w pozyskiwaniu surowców
  • sprawność produkcyjna/świadczenia usługi
  • efektywność dystrybucji produktu/usługi

Te trzy elementy tworzą tzw. łańcuch wartości (to moje bardzo duże uproszczenie oryginalnej idei Michela Portera). “Łańcuch”, bo każdy z elementów jest ściśle powiązany z sąsiadami, a “wartości” z każdym następnym krokiem “obrabiania produktu” wartość dla użytkownika (i marża producenta) wzrasta.

Weźmy jako przykład maszynkę do golenia: użytkownik ma niewielką wartość z kawałka plastyku i metalu (surowce) zanim nie stanie się maszynką do golenia. Samo stworzenie maszynki do golenia (produkcja) jeszcze niewiele daje jeśli ta maszynka nie będzie łatwo dostępna do kupienia i wykorzystania (dystrybucja).

Uproszczony łańcuch wartości

Każdy następny krok wnosi większą wartość także ze względu na coraz większą złożoność procesu (który trzeba rozumieć i optymalizować jeśli chce się oferować maszynki do golenia).

Gospodarka analogowa

Przed rewolucją industrialną to, co nazywamy “gospodarką” opierało się głównie na zdobywaniu zasobów, a więc na pierwszym etapie łańcucha wartości. To był najpoważniejszy problem do rozwiązania – kto kontrolował zasoby kontrolował rynek. To jest dalej prawdą w niektórych sektorach (ropa naftowa, diamenty, metale ziem rzadkich), ale im gospodarka jest bardziej rozwinięta tym znaczenie sektora wydobywczego maleje w udziale PKB kraju i regionu.

Surowce naturalne mają jednak to do siebie, że są jednolite: baryłki ropy z Wenezueli, Arabii Saudyjskiej i Rosji są względnie podobne, tam samo jak buszel owsa w Kanadzie czy Australii. Dzięki tej standaryzacji można nimi swobodnie handlować na masową skalę. Ten proces standaryzacji nazywa się komodytyzacją.

Inny efekt komodytyzacji spowodował, że surowiec stał się “anonimowy” – dostawca, które je przywozi do naszej fabryki może być wymieniony w dowolnym momencie na innego i użytkownik końcowy tego nie zauważy. 

W związku z tym “wąskie gardło” zaczęło przesuwać się w dół łańcucha wartości. Teraz najpoważniejszy problem do rozwiązania to skuteczna produkcja. 

To moment, w którym zaczęły pojawiać się pierwsze eksperymenty związane z masową produkcją i ogromny zmianami społecznymi spowodowanymi industrializacją. Rosnąca konsumpcja powodowała zwiększający się popyt, ten wymagał coraz lepszych metod produkcji, to wymagało zwiększenia zatrudnienia co zwiększało dobrobyt społeczeństwa co zwiększało popyt. 

Ten kto potrafił najwięcej i najlepiej (czyli z najmniejszą liczbą defektów) produkować ten wygrywał na rynku. Zaczynają się pierwsze eksperymenty z zarządzaniem opartym na nauce, taśma produkcyjna Forda, harmonogram (którego twórcą był polski teoretyk zarządzania – Karol Adamiecki).

Wiedza o optymalizacji produkcji rozpowszechniała się szybko, innowacje Forda szybko zostały podłapane przez amerykańskich i zagranicznych konkurentów. Dysproporcje w szybkości produkcji wyrównywały się coraz szybciej – a więc coraz trudniej było zdobywać przewagę rynkową na tym polu. Czas na następny etap walki: dystrybucję.

Wraz z upowszechnieniem się konsumpcyjnego stylu życia zbudowały się nowe zwyczaje i rutyny. Zaczęły się pojawiać domy handlowe i specjalistyczne sklepy. Ludzie zaczynają mieć swoje ulubione marki – tzn. zauważyli, że mydło nie jest równe mydłu, nawet jeśli ma taki sam skład i wagę. Reklama i marketing stają się dominującymi siłami rynkowymi, gdy okazało się jak łatwo jest ludźmi manipulować stosując metody znane z propagandy wojennej.

Jednak nic z tych rzeczy nie ma znaczenia, jeśli mojego ulubionego mydła nie ma sklepie, w którym robię zakupy. Najważniejszy problem do rozwiązania to spowodować, żeby to, co produkuje było łatwo dostępne tam, gdzie są moi klienci.

Właściciele sieci sklepowych doskonale zdawali (i zdają!) sobie z tego sprawę i traktują takie pozycjonowanie jako kartę przetargową. Wiedzą, że są wąskim gardłem w całym procesie i korzystają strategicznie ze swojej pozycji. Jednocześnie coraz mocniej zaczynają zdawać sobie sprawę, że bez dostawców ich półki będą puste. 

Integracja i Modularyzacja

Jednym z fragmentów Teorii Przełomowej Innowacji, który opuściłem ostatnio, aby za bardzo nie komplikować sprawy był cykl integracji i modularyzacji rynkowej. Czas to nadrobić bo to konieczny element, aby zrozumieć gdzie Teoria Przełomowej Innowacji zaczyna się kłócić z nową rzeczywistością.

Przy opisywaniu łańcucha wartości użyłem słowa “komodytyzacja” definiując sytuację, gdy surowce potrzebne do wytworzenia produktu standaryzują się – nieważne w którym miejscu kuli ziemskiej zapytacie stal eutektoidalna będzie wyglądać, działać i kosztować w miarę podobnie – i każdy będzie rozumiał i oczekiwał tego samego.

Okazuje się, że nie tylko surowce się komodytyzują. Wraz z rozwojem gospodarki i rynków komodytyzują się także półprodukty – na przykład żyletki używane w maszynkach do golenia, ale także ekrany, procesory i baterie wykorzystywane w Waszych smartfonach czy klocki hamulcowe w Waszych samochodach.

Rynkowa dostępność podzespołów powoduje, że można, na przykład, zbudować smartfona z części dostępnych na półce z sklepie i będzie on działał wystarczająco dobrze. 

Odwrotnym procesem jest integracja. Gdy rynek jeszcze nie jest wystarczająco dorosły brakuje na nim dostawców podzespołów a więc jeśli chcesz wyprodukować zupełnie nowy produkt na zupełnie nowym rynku to Twoja fabryka musi tworzyć wszystkie części od zera. Z racji tego, że produkujesz tylko dla siebie to Twoje podzespoły są dostosowane tylko do Twoich potrzeb, wiec Twój finalny produkt jest wewnętrznie zintegrowany.

Gracze rynkowi są zamknięci w cyklu ciągłej walki między tym kto kogo zmodularyzuje i kto będzie miał wystarczająco dużo zasobów, żeby się zintegrować.

W swojej ostatniej książce “Prosperity Paradox” Christensen opisuje mnóstwo przypadków firm, które integrują się z górę i w dół, aby zagwarantować sobie zbyt na zupełnie nowym rynku. Jednym z najlepszych przykładów jest Celtel – pierwszy pan-afrykański dostawca telefonii komórkowej. Aby osiągnąć sukces Celtel sam musiał stawiać swoje maszty nadawcze, co często wiązało się z budowaniem własnych dróg i wewnętrznej organizacji do naprawy infrastruktury. To jest integracja w “dół”, czyli obejmowanie w swoją kontrolę wcześniejsze etapy łańcucha wartości.

Jest też integracja w górę. Na przykład gdy producent stwierdza, że nie chce być na łasce dystrybutorów i sam buduje swój sklep: jak Apple i ich własna sieć sklepów Apple Store.

Patrząc z drugiej strony: niektóre sieci sklepów inwestują w swoje własne marki dostępne na ich półkach (w Biedronce i Lidlu to już odpowiednio 14% i 15% wszystkich produktów) – to jest przykład na integrację w dół.

Modularyzacja i integracja walczyły ze sobą na rynku w niezmienny sposób aż do momentu pojawienia się Internetu i początku gospodarki cyfrowej.

Gospodarka cyfrowa

To, co stopniowo zaczęło się zmieniać po 1995 to wewnętrzna dynamika łańcucha wartości. Po pierwsze Internet spowodował, że krańcowy koszt dystrybucji produktów zaczął gwałtownie spadać (do zera w przypadku produktów łatwych do zdigitalizowania jak muzyka i tekst). Poza tym Internet spowodował, że koszty transakcyjne także spadają do zera, co pozwala producentom integrować się dalej w łańcuchu wartości (np. dając producentom bezpośredni dostęp do klientów z pominięciem dystrybutorów – jak pisarze, którzy publikują online bez konieczności posiadania wydawcy, czy muzycy bez wytwórni).

Przewaga strategiczna zaczyna znów się przesuwać. Dystrybutorzy przestają walczyć przede wszystkim o uwagę dostawców a zaczynają dostrzegać użytkowników końcowych. Najważniejszym problem do rozwiązania jest zbudowanie lojalności, a więc powracalności klientów. 

Dochodzi czwarty element układanki


Na rynku pojawia się nowy typ dystrybutora – Agregator. To podmiot, który na fali zmian zaczyna wykorzystywać technologię aby wcisnąć się miedzy konsumenta a dystrybutora, stając się dystrybutorem dystrybutorów.

Dlaczego to mu się udaje? Bo oferuje swoim użytkownikom ogromną wartość – większy wybór, szersze porównanie oferty z wielu źródeł, wygodniejszą i szybszą konsumpcję, eliminację zbędnych elementów oferty i lepsze dopasowanie.

Szybko okazało się, że agregator posiada obecnie najmocniejszy arsenał jaki można mieć na rynku: uwagę konsumenta. Uwaga to najważniejszy surowiec jakim handlujemy (a przynajmniej dopóki ludzie są dominującą siłą na rynku). Dzięki temu agregator wpycha się między użytkownika a wcześniejsze stadia łańcucha wartości i efektywnie modularyzuje to, co do tej pory modularyzacji się opierało.

Weźmy za przykład sieć społecznościową taką jak Facebook. Co agreguje Facebook? Znajomości między ludźmi, między innymi. Im więcej ma użytkowników tym ma lepszy user experience, gdyż nikt nie czuje się w środku samotny (“moi znajomi już tu są”). To, opierając się na czystej psychologii, powoduje, że częściej na Fejsa zaglądamy, bo chcemy wiedzieć co ciekawego dzieje się w naszym otoczeniu. Skoro już tam jesteśmy to inne mechanizmy psychologiczne (m.in. virtue signaling) powodują, że produkujemy treści, które konsumują nasi inni znajomi, napędzając spiralę niesamowitego wzrostu tej firmy. Zauważcie że jest tutaj jeszcze jedna, mniej widoczna przewaga: Facebook otrzymuje treści za darmo, generowane przez swoich użytkowników ORAZ jest ich ekskluzywnym dostawcą.

Analogowa gazeta jest wydawana w zintegrowanym pakiecie – kupując egzemplarz dostawało się dział wiadomości, ekonomiczny, sportowy, ogłoszeniowy – niezależnie od tego, która część Cię akurat interesowała zawsze trzeba było zapłacić taką samą kwotę. Pojawił się Internet i wraz z nim pierwsze próby przeniesienia treści gazetowych w sieć. Te treści, dzięki wynalezieniu linków zaczęły być między sobą linkowane, z czego skorzystały katalogi linków – protoplaści obecnych portali internetowych. Na bazie tych danych zaczęły powstawać wyszukiwarki, wśród których niepodzielnym liderem dzięki swojemu algorytmowi jest obecnie Google. Google zmodularyzował treści gazet, gdyż doprowadził do sytuacji, w której ochota na przeczytanie jednego artykułu nie wiąże się już z koniecznością kupienia całej gazety. Gazeta została zmodularyzowana na pojedyncze artykuły

W ten sam sposób Apple iTunes wprowadził modę na słuchanie pojedynczych utworów zamiast całych płyt. W iTunes nie trzeba kupować całego albumu ulubionego artysty – można było pojedyncze utwory.

iTaxi z kolei zagregowało korporacje taksówkarskie, powodując, że istotne stało się gdzie jest najbliższa taksówka, a nie to z jakiej jest korporacji.

Pizzaportal zagregowała restauracje, dając większy wybór na wskroś wszystkich menu, modularyzując je. Dodanie do tego własnych dostaw pozwoliłoby na zintegrowanie w górę.

Możecie się w tym momencie zapytać: ok, ale co ma wspólnego agregator i Apple? Czy Apple jest agregatorem?

Teoria Agregacji zaczęła się od udowodnienia, że pewien rodzaj przełomowej innowacji nie działa w każdym przypadku – na przykład przy okazji Apple. To oznacza, że jest jakiś inny czynnik, który powoduje, że Apple utrzymuje się na powierzchni mimo przepowiedni Christensena.

Tak się akurat składa, ze zarówno agregatorzy jak i pionowo zintegrowany Apple, mimo zasadniczych różnic mają jedną cechę wspólną: strategię nastawioną na maksymalizację User Experience.

Era User Experience

To, co obserwujemy od ostatnich kilkunastu lat to samonapędzający się mechanizm:

Christensen przestrzegał, aby nie ufać za mocno temu co mówią klienci, bo oni zawsze będą chcieli więcej i lepiej z tego, co już znają – co spowoduje, że produkt będzie komplikował się i poprawiał szybciej niż rynek tego faktycznie potrzebuje. Tymczasem Teoria Agregacji przewiduje że nowi giganci rynku wyrośli (i wyrastają) na zrozumieniu, że:

  • przewaga biznesowa polega na budowaniu jak najlepszego doświadczenia interakcji z produktem,
  • użytkownicy są w stanie zapłacić więcej za lepsze doświadczenie

Naczelny wniosek Teorii Agregacji zakłada, że ten, kto ma lepszy UX wygrywa walkę o rynek, gdyż to, co jest najważniejsze to nie jest cena produktu, a doświadczenie jakie daje na interakcja z zakupionym produktem. Stało się to szczególnie istotne, gdy faktycznymi klientami technologii stali się klienci prywatni a nie biznesowi. Tym drugim bardziej zależy na racjonalnej i policzalnej efektywności biznesowej a nie trudnych efemerycznym uczuciu spełnienia i obcowania z piękną formą. W ten sposób możemy wyjaśnić niesłabnąca popularność i efektywność rynkowa iPhone’a – mimo tego, że ten produkt Apple jest zintegrowany i walczy na zmodularyzowanym rynku. 

Kiedyś, przed Internetem, gdy największymi problemami było zdobycie surowców, masowa produkcja bądź dystrybucja, doświadczenie było jedynie efektem ubocznym. Wraz ze zwiększaniem się świadomości konsumenckiej i działań marketingowych produkt przestawał być produktem. Lub patrząc inaczej: to co nazywamy produktem jest definiowane przez to jak użytkownik czuje się korzystając z tego produktu.

Najciekawsze jest to, że ze względu na swoją biologię i psychologię nigdy nie będziemy w pełni usatysfakcjonowani, nasz apetyt będzie rósł w miarę jedzenia.

Więc jeśli zastanawiacie się skąd pojawiło się tak ogromne ssanie na specjalistów od UX to jest właśnie powód: weszli w erę User Experience. Erę definiowaną przez wyścig zbrojeń nad kontrolą ostatniego niezmodularyzowanego element łańcucha wartości: interakcję konsumenta z produktem.