2021

2020 to był rok postawienia wszystkiego na głowie. 2021 to rok, w którym ciągle stoimy na głowie i już trochę za dużo krwi nam do niej spłynęło.

Moja pierwsza myśl: to było stracone 12 miesięcy. Nic ciekawego się nie u mnie działo, nic ważnego nie zrobiłem. Ale to nieprawda – spojrzałem w kalendarz, zdjęcia i historię konwersacji i (jak zwykle) okazuje się, że mózg płata mi figle. Zapraszam na podsumowanie 2021 (oraz 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013)

COVID-21

Ja i moja najbliższa rodzina uchroniliśmy się do tej pory przed SARS-CoV2, choć jestem pewien, że to bardziej kwestia szczęścia niż naszej szczególnej umiejętności dystansowania się (choć moje introwertyczne umiejętności wreszcie się przydały).

W podsumowaniu rok temu cytowałem epidemiologów, którzy mówili, że każdy z nas będzie znał kogoś, kto umarł na COVID. Wygląda na to, że mieliśmy farta, bo jedynie znamy innych, którym ktoś znajomy lub bliski zmarł z tego powodu. Choć nawet to brzmi nieludzko źle.

Przyzwyczaiłem się do lockdownów, maseczek w pomieszczeniach, ograniczeń w komunikacji miejskiej. Kolejne fale nie robią już na mnie wrażenia. Mamy rodzinne procedury wbudowane w codzienność – wszystko to, co mnie dziwiło patrząc na zdjęcia z Tajwanu czy Pekinu w czasach SARS-CoV1 stało się teraz dla nas normalne.

COVID-19 już napewno będzie chorobą endemiczną, więc po prostu nauczymy się z nim żyć – co jeszcze rok temu brzmiało abstracyjne.

Giełda

Moja strategia zainspirowana Charliem Mungerem („Buy and sit on ass”) działa już trzeci rok z rzędu. Poprzedni rok eksperymentowania pozostawił mnie jednak z szerokim portfelem, który postanowiłem skonsolidować, aby uprościć sobie życie. Mówiąc krótko: sprzedałem prawie wszystko co było na plusie minimum 6% i wsadziłem w SP500. Efekt?

Rok kończę z 28% skutecznością inwestycyjną- czyli dotarłem do poprzedniego rekordu z tuż sprzed początku pandemii. Nie ma w tym żadnej magii – po prostu cierpliwie dokupuje indeks SP500 i nie sprzedaję.

Końcówkę tego roku przeznaczyłem na eksplorację dużych pozagiełdowych form inwestycji. Jeśli wszystko pójdzie zgodnie z planem to w 2022 mój portfel znów się mocno zdywersyfikuje, ale w zupełnie inny sposób.

Zupełnie przypadkiem zdałem sobie sprawę, że od 180 tygodni co sobotę rano (zanim rodzina się obudzi) siadam sobie z herbatą i wpisuję do tabelki moje wyniki giełdowe. Robię to już zupełnie bezemocjonalnie i mi z tym bardzo dobrze.

Podróżowanie rodzinne…

Zeszłoroczne podróżowanie przez Bieszczady dały nam poczucie, że musimy zmienić samochód. Nie lubiłem jeździć samochodem, więc wydawanie pieniędzy na jego zakup uważałem za wyrzucone w błoto. Z drugiej strony nasze leciwe Volvo psuło się co kilka miesięcy, więc nawet szybkie wypady się do rodziny za miasto stawało się ryzykowne.

Znaleźliśmy rozwiązanie: kupiliśmy sobie campervana – samochód wystarczająco zwinny, żeby jeździć nim po mieście (i parkować pod mieszkaniem), ale wystarczająco duży, aby móc w nim przenocować tak jak to robiliśmy na Islandii w 2019 roku.

Po długim procesie szukania i następnie 4 miesiącach czekania przyjechał do nas przedłużony Citroen Berlingo z dodanym ogrzewaniem postojowym, do którego dokupiliśmy szufladę z rozkładanym łóżkiem.

Otworzył się przed nami zupełnie nowy świat niezaplanowanej wolności. Wybieraliśmy sobie kierunek i tam jechaliśmy – bez rezerwacji hoteli i myślenia o tym co dalej. Nie mamy miejsca do spania? Śpimy w pobliskim lesie (które mają przestrzeń do biwakowania). Czujemy sie brudni i zmęczeni? Skoczymy po drodze do hotelu z basenem i jacuzzi.

W ten sposób zwiedziliśmy województwo świętokrzystkie, następnie dorzecze Narwii i  Puszczę Białowieską (którą mieliśmy w planach w zeszłym roku), a tuż przed końcem sezonu Jurę Krakowsko-Częstochowską. W międzyczasie robiliśmy sobie mikrowyprawy. Trafialiśmy tak na drzewo-pomnik przyrody, zapomniane tamy rzeczne lub porzucone PGRy na bagnach. A czasami na nic i wtedy rozkładaliśmy sobie hamak między dwoma drzewami i patrzyliśmy na to całe nic z zachwytem.

Gdzieś godzinę od Warszawy

Zdaliśmy sobie z Pauliną sprawę, że lubimy takie pełne spektrum doświadczeń – równie dobrze nam jest ze spaniem na pilśniowej płycie w samochodzie jak i w 4 gwiazdkowym hotelu. Nie mówiąc już o naszych dzieciach, które generalnie są hardkorami i dopasowują się do wszystkiego co nam przyjdzie do głowy – nie mają po prostu w głowie tych barier mentalnych które my (z powodu bycia dorosłymi) sobie niepotrzebnie wkładamy.

Zrobiliśmy w 8 miesięcy 20 tysięcy kilometrów i jeszcze nie mamy dość.

… oraz podróżowanie związkowe

2020 rok pełny był zaburzeń naszych standardowych rutyn. Nam  przywaliło podwójnie, bo nie dość, że pandemia to jeszcze urodziła nam się córka – co oznacza powrót do pieluch, nieprzespanych nocy, lekarzy, szczepień i żonglowaniem rodzinnymi kryzysami. Hania jednak ma już półtora roku, więc po raz wtóry wykorzystaliśmy fantastyczną instytucję dziadków po obydwu stronach rodziny (dziękuję!).

Dzięki temu odzyskaliśmy trochę czasu i przestrzeni tylko dla siebie. Udało nam się wyskoczyć bez dzieci na ślub znajomych i podróż do Poznania, aby doświadczyć nowej sceny kulinarnej, odrodzonej po pierwszym lockdownie. A na jesień odwiedziliśmy znajomych w Sztokholmie. Udało nam się nawet trafić na koncert Hani Rani!

Próbowaliśmy wykroić jak najwięcej czasu, aby spędzać czas ze sobą i tylko z sobą – aby na chwilę zapomnieć o byciu rodzicami, a przypomnieć sobie o tym, że jesteśmy parą i przyjaciółmi.

Wprowadziliśmy sobie wolne wieczory: co wtorek spędzaliśmy czas ze sobą na randkach, w środy Paulina miała wieczory dla siebie a ja siedziałem z dzieciakami a w czwartek odwrotnie. 

Ten wspólny czas dał nam możliwość spojrzenia na siebie nowymi oczami – a raczej starymi, o których zapomnieliśmy. Objawiało się to w nieoczywistych miejscach – na przykład czy wiecie, że można przejść przez basenową przebieralnię w 5 minut jak nie ma się dzieci ze sobą? Szok!

Cel: bez celu

Mam w tygodniu jeden wieczór tylko dla siebie. Na początku nie wiedziałem co z nim robić, jak go efektywnie zapełnić. Zdałem sobie sprawę, że w sumie nie muszę. Przez większość czasu decyduje, optymalizuje i wyciskam z każdej godziny najwięcej jak umiem. Ale teraz mam moment na to, aby przestać. Uczyłem się więc wybierać najdłuższe trasy i najwolniejsze środki lokomocji. Potrafiłem przejść z mojego biura przy Filtrach na Powiśle na piechotę i posiedzieć nad brzegiem, tak bez celu.

Kilka tygodni później zauważyłem jednak, że brakuje mi stymulacji intelektualnej. Wtedy postanowiłem zapisać się na studia według klucza: co mi da najmniej wartości biznesowej, a będzie tak po ludzku ciekawe. W ten sposób trafiłem na studia o geopolityce Azji Centralnej w ramach Uniwersytetu Otwartego UW. Czy coś z nich wyniosłem? Fajne rzeczy, które nigdy mi się nie przydadzą, ale to całkowicie w porządku.

W tym roku bowiem nauczyłem się (dzięki mojej Żonie), że nie posiadanie celu jest OK – nie wszystko musi być częścią wielkiego masterplanu, który prowadzi to jakiegoś finiszu gdzie czeka szczęście i sukces. Ten mityczny finisz nie istnieje, bo po osiągnięciu jednego pojawi się następny. Szczęście nie jest policzalne z definicji – a jeśli próbujesz swoje skwantyfikować to raczej szczęśliwa/y nie jesteś. Tak samo prokrastynacja: to nie oznaka lenistwa a naturalna obrona przed robieniem nieciekawych lub nieistotnych rzeczy (nikt nie będzie prokrastynował podczas pożaru domu)

Więc lepiej dać sobie na luz i zapomnieć o tych wszystkich ludziach, którzy nam wmawiają, że trzeba być co dzień 1% lepszym, tak jakby bycie sobą tu i teraz było w jakiś sposób niewystarczające. Wychodzi mi na to, że ci, którzy  ciągle szukają poprawy nigdy nie będą szczęśliwi.

Rodzeństwo

Nasze młodsze dziecko weszło w etap, w którym potrafi wskazać a czasami nawet powiedzieć czego chce. W większości przypadków jest to oczywiście rzecz, którą teraz ma jej starszy brat. Widzimy na własne oczy jak kształtuje się od początku więź między rodzeństwem – czego ani ja ani moja żona nie widzieliśmy wcześniej z tej perspektywy.

To ciekawa relacja: ich zupełnie przeciwne charaktery mieszają się z różną kognicją i umiejętnościami. Jedno próbuje naśladować drugie. Drugie próbuje opiekować sie pierwszym. Walczą ze sobą o te same zabawki i chwilę później wspólnie określają swoje granice.

Ciekawe jak to będzie wyglądać dalej.

Książki

Ten rok kończę z 16 przeczytanymi książkami, czyli trochę ponad połowę zakładanego planu. Tym razem postanowiłem nie dawać mojego tytułu książki roku – nie było jednej, która wybiła się znacząco poza resztę. Chciałbym się jednak skupić na pewnym temacie, który przewijał się przez większość z nich: brak wyjątkowości.

Nasze mózgi starają nam się mówić, jacy to jesteśmy unikatowi, a w gruncie rzeczy nieprawdopodobnie złożone i subtelne problemy związkowe ciągnące sie przez lata ostatecznie u każdego i każdej z nas powtarzają się z zadziwiającą częstotliwością (polecam „Mating in Captivity”).

To samo z problemami zawodowymi czy finansowymi („Psychology of Money”). Tego, jak postrzegami świat („Conscious”), gdzie stawiamy granice („O granicach”) i jak budujemy relacje z innymi („Courage to disliked”).

Nie ma w tym nic dziwnego: wszyscy funkcjonujemy według tych samych zasad fizyki, chemii i biologii a wariacje środowiskowe uwydatniają lub ukrywają części naszych cech przez co wydaje nam się, że jesteśmy inni niż wszyscy. Nie, nie jesteśmy.

Ale to dobrze! Ten brak wyjątkowości jest dla mnie ogromną ulgą. Każdy możliwy problem już kiedyś zaistniał – co oznacza, że nigdy nie byłem, nie jestem i nie będę z swoimi sam. To mi daje poczucie bycia częścią większej społeczności. I jeśli inni dali sobie radę ze swoimi problemami, to wiem, że to możliwe, nawet jeśli ja jeszcze nie potrafię. 

Siła

Pandemia i lockdowny spowodowały, że zapuściłem się fizycznie – zrezygnowałem z chodzenia na siłownię, a bez ciężaru zobowiązania wobec trenera ciężko było mi wytworzyć sobie rutyny.

W tym roku postanowiłem wrócić do formy. W sierpniu wróciłem na ćwiczenia siłowe i pokonałem moje rekordy ciężarowe (100kg w przysiadzie Zercher, 95kg na ławce i moja duma: 160kg w martwym ciągu!).

Siłownia to dla mnie miejsce, w którym naturalnie przestaję myśleć o wszystkim innym – muszę skupić sie na tu i teraz. Im większy ciężar na sztandze tym mniejszy w głowie.

Obcy we własnym kraju

To kolejny rok, w którym czuję się obco we własnym kraju. Teraz jednak to już nie jest zdziwienie czy irytacja a bardziej poczucie obcości wobec tego co mnie otacza i potrzeba budowania rzeczywistości pozbawionej tych wszystkich bezsensownych politycznych decyzji opartych o wsteczne idee, nienaukowe przesłanki i dzielenie ludzi na kategorie. Nie chcę, aby moje dzieci żyły w bogoojczyźnianym środowisku – ani fizycznie, ani mentalnie.

Niestety nie widzę tutaj dobrego wyjścia. Nawet jeśli *** przegra to i tak sprzątanie tego bałagu zajmie kolejne lata, a znając zasady polityki można założyć, że część z tych demotarzy demokracji będzie przydatnych nowej władzy (do zwalczania starej). Do tego wszystkie najpopularniejsze partie w sumie nie wiele mają wspólnego z ideami które sam reprezentuję.

Ręce mi tutaj opadają i nie widzę nic szczególnie pozytywnego na horyzoncie.

Podsumowując

Rok w którym dużo zrobiłem i dużo się zadziało.  Wdrożyłem dwa duże produkty (Zilo, Autobooking) – gdzie ten pierwszy doczekał sie obszernej dekompozycji. Nagraliśmy cztery Otwieracze z Szymonem. Zacząłem studia, wróciłem na siłownię, wdrażam się w świat web3, rozegrałem 1300 partii szachów i dołączyłem (za namową Żony) do fundacji KIDS. A jednak…

A jednak mam poczucie, że to był rok poza czasem. Takie nieprawdziwe, zawieszone 12 miesięcy, po których przyjdzie prawdziwy 2021.

Ten 2021 v2 już za chwilę się zaczyna. Jeśli moje plany wypalą to będzie bardzo, bardzo ciekawie.

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.