Jak powstawał Autobooking

Ten tekst jest dodatkiem do tekstu „Jak powstawało Zilo” – najpierw przeczytaj o Zilo zanim zabierzesz się za Autobooking :)

To co robimy dalej?

Po wdrożeniu Zilo zrobiliśmy półtoramiesięczny refactor, aby po sobie posprzątać. To była praca dla programistów, ale mi dała czas na zastanowienie się, co powinniśmy robić przez następne kwartały.

Od początku wiedzieliśmy, że Zilo nie jest celem samym w sobie. To fundament, na bazie którego możemy budować kolejne nowe rzeczy.

Bogatszy o wnioski po starcie Zilo przedstawiłem w połowie czerwca 2021 cztery najważniejsze kierunki rozwoju. Każdy z nich w różny sposób wpływał na naszą skalowalność, jakość obsługi, UX i lojalność klientów. Wśród moich propozycji największą popularnością cieszył się Autobooking – system automatycznego i natychmiastowego zapisywania się na wizyty.

Podsumowanie dyskusji w naszym managemencie o kierunkach rozwoju

Poniższy wpis opisuje nasze zmagania z jego stworzeniem i wdrożeniem.

Ps. Jeszcze mała uwaga zanim zaczniemy: ten wpis to ekstremalnie szczegółowy opis fragmentu większego ekosystemu produktowego, Przez swoją egzotykę może się okazać, że nie jest wprost aplikowalny na Wasze produkty. Rozważałem jego skrócenie, aby był łatwiejszy w konsumpcji, ale uznałem, że w ten sposób straci na wiarygodności. Zostaliście ostrzeżeni!

Proces rezerwacji wizyty

Tak jak wspominałem w kejsie Zilo, „pod spodem” Dobrego Mechanika jest Biuro Obsługi Klientów. Każdy do tej pory wypełniony formularz wizyty na naszym portalu trafiał do panelu, w którym pracownik BOKu przypisuje zlecenie do siebie. Później dzwoni do warsztatu, aby upewnić się, że termin wskazany przez kierowcę jest wolny. Jeśli tak, to kierowca dostaje potwierdzenie wizyty. Jeśli nie, to BOK szuka alternatywnego warsztatu i/lub terminu.

Ten proces ma swoje oczywiste wady:

  • Nie mamy faktycznego podglądu na to, kiedy warsztat ma wolny czas na nowych klientów. BOK rozmawia z mechanikami, ale nasza wiedza jest pobieżna i szybko się dezaktualizuje,
  • W związku z tym proponowane terminy wizyt to nasza ogólna sugestia, a w czasie szczytów (wymiana opon, klimatyzacja) pobożne życzenia,
  • Negocjowanie między kierowcą a warsztatem wymaga czasu i nadprogramowej komunikacji. Czasami potrzeba kilku godzin lub doby, aby kierowca dostał potwierdzenie wizyty,
  • W konsekwencji bywało tak, że wszyscy pracownicy zajmowali się dzwonieniem do warsztatów i klientów, aby obsłużyć zlecenia lub badania satysfakcji z usług,
  • Komunikacja statusu zlecenia potrafi być źle zrozumiana: nasze potwierdzenie zarejestrowania polecenia umówienia od kierowcy może być brana za potwierdzenie, że doszło do faktycznego umówienia wizyty. Wszyscy się frustrują: kierowcy są zagubieni, warsztatom trafiają się niezapowiedziani kierowcy, a nam przysparza to dodatkowej pracy i obniża zaufanie do marki

Wprowadzaliśmy mechanizmy usprawniające prace nad umówieniem wizyty, ale wszystkie ostatecznie rozbijały się o konieczność dodzwonienia się do warsztatu (co w sezonie potrafi być bardzo trudne). Dopóki nie wyeliminujemy etapu rozmowy nie uda nam się wprowadzić prawdziwej zmiany.

Zilo i Autobooking

Wprowadzenie Zilo wszystko zmieniło. Jego głównym celem było łatwiejsze zarządzanie wizytami w warsztacie, ale przy okazji dawało nam wiedzę o tym gdzie i kiedy warsztaty mają puste przebiegi, a więc czas na obsługę naszych klientów.

Skoro widzimy kalendarze warsztatów to możemy też je przetworzyć na sloty czasowe, wrzucić na portal DM a co najważniejsze: w czasie rzeczywistym aktualizować dostępność czasów i usług warsztatu. Pytanie tylko jak to zrobić, aby dać duży wybór slotów czasowych dla kierowców nie rezygnując z prostoty korzystania z systemu dla warsztatów.

Gdy zacząłem rozważać ten projekt pojawiły mi się dwa fundamentalne problemy:

1. Nie mamy pewności, czy to, co mechanicy ustawią w Zilo, odpowiada rzeczywistości (np. czy mają tyle samo stanowisk w Zilo co w rzeczywistości?)

2. Różne usługi mechaniczne mają różne charakterystyki. Do niektórych potrzebne są części zamienne, niektóre wymagają oddzielnego stanowiska, niektóre da się zrobić od ręki, inne trwają dniami.

W tej sytuacji zbudowanie prostego w konfiguracji systemu zarówno po stronie warsztatu jak i prostego w bookingu po stronie kierowcy graniczyło z cudem. Rozwiązaniem było, jak zwykle, rozpoczęcie od wykrojenia ze wszystkich wymagań najmniejszej możliwej działającej wersji.

MVP1: Opony

Co byłoby najmniejszą działającą wersją Autobookingu? Co moglibyśmy obciąć jako pierwsze? Postanowiłem spojrzeć na jakie usługi w ogóle umawiają się kierowcy i pokategoryzować je pod względem trudności w wymodelowaniu biznesowo-technicznym. Wytypowałem trzy grupy:

  • wymiana opon,
  • usługi fast-fit (olej, klocki hamulcowe, klimatyzacja itp.)
  • cała reszta (usługi złożone, wieloetapowe bądź nie-wiadomo-o-co-chodzi)

Wymiana opon teoretycznie powinna wpadać w kategorię fast-fit, ale praktycznie stanowi kategorię samą dla siebie. Przede wszystkim to rutynowa usługa: przyjeżdża się na konkretną godzinę i wyjeżdża kilkadziesiąt minut później z załatwioną sprawą. To powoduje, że jest najbardziej podobna do wizyty u fryzjera czy lekarza, które wiemy, że są łatwe do umawiania online – czego przykładem jest Booksy czy ZnanyLekarz.

Zdecydowane: pierwsza wersja Autobookingu skupi się na oponach.

Co jeszcze możemy wyciąć? W każdym systemie rezerwacyjnym i kalendarzowym problemem jest odpowiednie wyważenie relacji między dokładnością ustawień a poziomem kontroli nad sytuacją. Przykład: Jak duże „skoki” czasowe są możliwe w systemie (co 1 minutę, co 15? Co 30?), czy ustawiewienia są globalne czy dopuszczają wyjątki (święta, urlopy, nieoczekiwane sytuacje)? Im więcej reguł do reguł (lub wyjątków od wyjątków) dodane do systemu tym potencjalnie lepsze dopasowanie do specyficznych wymagań użytkownika… ale także coraz większe ryzyko, że nie odnajdzie się w gąszczu możliwości i ucieknie zdezorientowany.

Posprawdzałem znane mi systemy bookingowe z różnych branż, popytałem znajomych którzy siędzą w podobnych tematach. Ostatecznie postanowiłem  rozpocząć z bardzo kontrowersyjną wersją minimum:

  • Nie było możliwości ustawiania urlopów, a ustawione godziny dotyczyły każdego dnia tygodnia
  • ustawienia godzin dostępności były aplikowalne uniwersalnie na każdy dzień tygodnia: jeśli ktoś ustawił 9:00-16:00, to w każdy dzień gdy warsztat był otwarty obowiązywała 9:00-16:00
  • nie było możliwości ustawiania dwóch przedziałów czasowych w ciągu jednego dnia, np. 9:00-12:00 i 14-16:00

W ten sposób maksymalnie uprościliśmy interfejs konfiguracji w Zilo. Warsztat nie musiał konfigurować dostępności różnych usług oddzielnie (bo miał tylko jedną opcję – opony). Każde stanowisko mogło być ustawiane oddzielnie. Po przełączeniu dostępności pojawiały się proste dropdowny z godzinami „od” i „do” i już.

Pierwszy szkic Ustawień – wystarczy przycisk ON/OFF i godziny widoczności

W trakcie prac developerskich nad ustawieniami okazało się, że dobudowanie różnych godzin w różne dni nie będzie trudne, a da dużą wartość warsztatom, więc szybko wprowadziliśmy taką opcję:

Gęstość informacji zaczyna być wysoka

Tak skonfigurowana dostępność była wizualnie reprezentowana na ekranie głównym kalendarza – niebieskie pola oznaczają czas, który DobryMechanik uzna za dostępny dla klientów portalu.

Niebieskie pola to czas widoczny dla DM na zmianę opon

Stał przed nami jeszcze jeden problem: skąd będziemy wiedzieć jak godziny dostępności pokazywane przez warsztat będą przeliczać się na „sloty” na które umawia się kierowca? Inaczej mówiąc: czy warsztat, który zaznaczy, że przyjmuje naszych kierowców codziennie od 9:00 do 13:00 jest w stanie przyjąć 4 wizyty co godzinę, 8 godzin co pół godziny czy jeszcze inaczej?

Do tego dochodzi fakt, że wymiana opon wymianie opon nierówna. Są takie, które da się załatwić przy pomyślnych wiatrach w 25 minut i takie, które trwają 45 minut i więcej. Tutaj miałem najtrudniejszą decyzję do podjęcia:

  • mogłem dać warsztatom opcję konfigurowania czasu każdego typu usług oponiarskich oddzielnie,
  • mogłem zrównać wszystkie usługi do jednego wspólnego czasu

Opcja pierwsza byłaby niezgodna z ideą tworzenia MVP więc znów zaryzykowałem i ustawiliśmy globalnie każdą usługę na 30 minutowy slot czasowy. Wiedziałem, że część wizyt potrwa dłużej (nie wiedziałem tylko jak duży to będzie procent) ale ufałem, że warsztaty mimo wszystko sobie z tym poradzą.

Plusy natomiast były oczywiste: znów nie trzeba nic konfigurować, a każda godzina dostępności to po prostu dwa sloty na portalu widoczne dla kierowcy.

Zastanawiałem się ciągle czy dobrze robimy. Czy warsztaty nie uznają tego za wylewanie dziecka z kąpielą? Opinie były podzielone, ale wiedziałem, że łatwiej skomplikować prosty system niż uprościć już złożony.

Kalendarz zagłady

Kalendarze bookingowe, konfiguratory podróży, formularze rejestracyjne – wszystko to systemy wydają się tak oczywiste, że wręcz nudne. Co tam może być ciekawego? Też tak myślałem, do czasu aż zostałem zmuszony do zaprojektowania własnego.

Na tym etapie mamy określone dwie kwestie:

  • preferencji warsztatu co do godzin jego dostępności na usługi z DM
  • Typ usługi oraz czas jej trwania (30 minut) 

W efekcie każda godzina dostępności była szatkowana na 30 minutowe przestrzenie. To stanowi fundament naszej logiki:

Pojawia się pytanie: Co powinno być w miejscu, które wskazuje strzałka?

Następny etap to określenie tego, co powinno być po prawej stronie tej strzałki, czyli prezentacja dla kierowcy siatki godzin do wybrania.

Miałem przekonanie, że nie chcemy wymyślać koła na nowo: wykorzystamy to, do czego użytkownicy Internetu są przyzwyczajeni od lat: tabelkę z siatką przycisków, a każdy przycisk reprezentował 30 minutowy slot.

Gdy kierowca wybierze jeden z tak zaprezentowanych slotów (i wypełni resztę wymaganych danych) to rezerwuje wizytę. Pod spodem następuje komunikacja między Autobookingiem a Zilo. Wizyta zostaje „przesłana” do kalendarza Zilo (punkt 4), a ten potwierdza, że dane kierowcy są prawidłowe* i dodaje wizytę do kalendarza warsztatu.

* Notka architektoniczna. W dużym skrócie ta weryfikacja danych to nie tylko kwestia bezpieczeństwa. Problem jaki mieliśmy to różne wymogi wobec tego jakie dane potrzebuje DobryMechanik, a jakie Zilo. Na przykład w DM nie był wymagany nr rejestracyjny samochodu a w Zilo już tak. Dzięki niemu możemy zweryfikować (nie)powtarzalność samochodu w bazie. Na tej podstawie wiemy, czy mamy do czynienia z powracającym kierowcą z tym samym samochodem, powracajacym kierowcą z nowym samochodem lub zupełnie nowym kierowcą. W zależności od tego, który z tych scenariuszy zostanie wybrany inaczej dopisujemy dane do bazy klientów warsztatu

Po dodaniu wizyty Zilo musi jeszcze poinformować Autobooking, że jedno miejsce wypada z listy wszystkich możliwości (punkt 5). To oznacza, że Autobooking uniemożliwia zapisanie się na ten slot innym kierowcom.

Gdy poradziliśmy sobie z fundamentami naszej logiki zaczęły pojawiać się pytania natury UXowej:

  • Jeśli dany slot jest zajęty to ma być wyszarzony czy powinien zniknąć z listy? A jesli zniknąć to od razu, czy dopiero po odświeżeniu strony?
  • Czy jeśli w danym dniu warsztat nie pracuje (święto, urlop) to czy powinniśmy ten dzień pokazywać ze wszystkimi slotami zajętymi czy też z informacją, że nie przyjmuje? A może powinniśmy te dzień ukrywać?
  • Czy jeśli warsztat ma pełny dzień zleceń i więcej od nas nie przyjmie to powinniśmy pokazywać wszystkie kratki z tego dnia jako pełne czy tylko jedną z informacją, że jest „pełne”?
Fragment moich notatek o metodach notacji kalendarza

Tutaj znów nie chciałem wymyślać koła na nowo i popatrzyłem jak robią to lepsi od nas. Moje wnioski: wygląda na to, że robią to inaczej niż moja pierwsza intuicja. Wiedziałem, że ma to swoje (jeszcze ukryte przede mną) powody. Postanowiłem wiec pójść za moją intuicją i na żywym organizmie przekonać się co robimy nie tak.

Moja intuicja mówiła mi, że kluczowe znaczenie będzie miała „stabilność” siatki terminów. Rozumiem przez to przewidywalność zachowania i ciągłość dat, jakiej ludzie spodziewają się po fizycznym kalendarzu. Jeśli widzimy klamkę do drzwi to wiemy, że powinniśmy ją nacisnąć, a nie na przykład popchnąć*.

* Notka UXowa. Nasze doświadczenia korzystania z fizycznych i cyfrowych obiektów są przez nas zapamiętywane i dodawane do modeli mentalnych skatalogowanych w głowie. Jeśli zachowanie przedmiotu nie zgadza się z modelem mentalnym (np. gdy po przekręceniu pokrętła z ciepłą wodą leci zimna) to mózg dostaje zgrzytu. Te małe pomoce – kształt klamki pasujący do dłoni naciskającej w dół, kolorowe oznaczenia temperatury wody itp. to tak zwane afordancje. Więcej o tym w książce Dana Normana „Design of everyday things”.

W związku tym mój pierwszy pomysł zakładał, że:

  • Wszystkie dni będzie widoczny, także te bez wolnych terminów. Dzięki temu unikniemy sytuacji, w których po poniedziałku będzie piątek (bałem się, że ludzie z góry zakładają, że następny dzień po poniedziałku to będzie wtorek, a skoro go wytniemy z braku terminów to wprowadzimy kierowców w błąd, bo bez świadomości zapisać się na piątek, ale ze względu na wizualną odległość od poniedziałku pomyślą, że to wtorek)
  • Sloty już zajęte będą się pokazywać, ale wyszarzone, aby uniknąć sytuacji, w których na różnych wysokościach siatki będą różne godziny (bałem się, że ktoś widząc na górze listy pierwszy wolny termin na 8:30 to założny z góry, że w kolejnym dniu też pierwszy wolny termin to będzie 8:30)

Te dwa założenia brzmią dobrze w teorii, ale szybko zostały zweryfikowane przez rzeczywistość. Warsztaty po prostu zdecydowały się zachowawczo podejść do Autbookingu i ustawiać np. tylko jeden dzień w tygodniu z dostępnością – co powodowało, że na kalendarzu Autobookingu były ogromne sześciodniowe dziury. Trzeba było dużo klikania, aby doszukać się pierwszego wolnego terminu. Wtedy zdecydowałem, że trzeba puste dni pochować.

Następnie okazało się, że warsztaty postanowiły poustawiać różne godziny dostępności w różne dni. I w ten sposób za okno wyleciała moja idea pokazywania tych samych godzin na tych samych wysokościach kalendarza.

Ostatecznie odwróciłem pierwotny pomysł o 180 stopni: pokazujemy tylko faktycznie dostępne terminy. `Teraz już wiem, dlaczego Znanylekarz i Booksy tak robią.

Na sam koniec nałożyliśmy na logikę dodatkowe zasady wpływające na widoczność terminów: w końcu nie powinno być możliwości na zapisanie się w dniach, które już minęły, lub nawet dzisiaj, ale godzinę temu. Następnie dołączyliśmy informację o urlopach, świętach i innych wydarzeniach, które pauzują działalność warsztatu. 

Autobooking na portalu DM

Skoro uporaliśmy się z konfiguracją po stronie Zilo to czas zająć się portalem i tym, co powinien widzieć kierowca chcący zmienić opony.

Na portalu DM są (upraszając) trzy miejsca, z których można przejść proces rezerwacji wizyty:

  • Listing warsztatów, gdzie box warsztatu pokazuje kilka promowanych usług
  • Wizytówka: cennik w głównej części wizytówki warsztatu
  • Wizytówka: formularz po prawej stronie wizytówki
Listing z wyróżnionymi usługami
Umawianie przez cennik i formularz

Autobooking powinien być dostępny we wszystkich trzech. Była jednak zasadnicza różnica między tymi ścieżkami: w przypadku listy warsztatów z wyróżnionymi usługami oraz cennika usługa była od razu widoczna. Kliknięcie w „Umów wizytę” niosło ze sobą na następny etap formularza informację o tym, na jaką usługę chce się umówić kierowca.

Formularz natomiast jest uniwersalny – można umówić się na dowolną usługę po prostu opisując to, co jest zepsute. Nie mamy więc tutaj strukturalnej metody określenia czy usługa ma dotyczyć opon czy czegoś innego.

W przypadku listy i cenników postanowiliśmy w miejsce „umów wizytę” wstawić mini siatkę godzin, gdzie kliknięcie na dowolny kafelek przenosi do kolejnego etapu bookingu. W przypadku formularza zastosowaliśmy taby: w jednym będzie stary formularz a w drugim nowy, tylko dla opon. Dzięki temu nie zamykaliśmy użytkownikom drogi do starego systemu oraz do usług, które nie sa bezpośrednio związane z Autobookingiem. Poza tym postanowiliśmy chwalić się kluczową przewagą systemu: godziny dostępności były aktualizowane w czasie rzeczywistym a nie jako sugetowany termin jak we wcześniejszym rozwiązaniu.

Standardowy booking po lewej, Autobooking po prawej

Unowocześniony formularz dawał nam także nowe możliwości – na przykład lepsze ustrukturyzowanie danych. W starej wersji informacje o samochodzie wpisywało się w ramach jednego ciągu znaków. To powodowało, że mieliśmy w bazie duży chaos – nie uwierzylibyście na przykład na ile różnych sposobów można wpisać markę Renault… Aby temu zaradzić w nowej wersji zastosowaliśmy dropdowny z podpowiedziami dla marki, modelu i usługi. Dzięki temu mieliśmy większą kontrolę nad jakością danych.

Zapewniliśmy sobie też fallback na wszelki wypadek. Gdyby tylko okazało się, że coś jest nie tak z Autobookingiem (np. Zilo nie odpowiada więc nie można dać potwierdzenia, że wizyta jest umówiona) system automatycznie przełącza się na stary proces, więc zlecenie wpada do ręcznej obsługi przez nasz BOK.

Startujemy

Przebrnęliśmy przez zmiany w Zilo, stworzyliśmy logikę zapisywania się na sloty, mamy przygotowane formularze do nowego sposobu umawiania się. Wiedziałem, że tak duże, jednoczesne i wielopunktowe wdrożenie niesie ze sobą zwiększone ryzyko*. Jak zwykle, mimo naszych starań, pozostały rzeczy, których nie wiemy, że nie wiemy.

*Notka o zarządzaniu ryzykiem. Nassim Nicholas Taleb wielokrotnie udowodnił, że ryzyko wymyka się ludzkiej percepcji i nie potrafimy go odpowiednio szacować (nie słuchajcie szarlatanów, którzy uważają, że potrafią). Jak więc nim zarządzać skoro nie można go policzyć? Trzeba oddzielić ryzyko od potencjalnej szkody. Zamiast zastanawiać się jak duża jest szansa, że błąd wystapi należy wyobrazić się sytuację, w której to już się stało i zrozumieć jego konsekwencje. Na tej bazie przygotować środki zaradcze ZANIM błąd zaistnieje. Więcej o ryzyku w czworoksięgu Incerto NN Taleba. Dodatkowo polecam zapoznać się z modelem mentalnym pomagający myśleć o ryzyku w przyszłości: Pre-mortem.

Dlatego zależało mi, żeby przed startem mieć killswitch. Jedną flagę, którą można szybko przestawić w wypadku pokazania się krytycznego błędu, na który nie byliśmy gotowi.  Moja polityka zakładała, że jeśli, na przykład, siatka godzin nie wyświetli się na portalu podczas szczytu sezonu to lepiej od razu wyłączyć całość autobookingu, cofnąć się do starego systemu i dopiero wtedy zastanawiać się, co poszło nie tak. Przy tej strategii jakoś lepiej mi się spało w nocy.

Po dwóch dniach testów, wdrożeniu analityki oraz killswitcha, wreszcie poczuliśmy, że jesteśmy gotowi. W nocy między 18 a 19 października 2021 rozpoczęliśmy wdrożenie w pierwszych 6 warsztatach wytypowanych przez nasz BOK. Już rano po wdrożeniu mieliśmy pierwsze bookingi z nowego systemu!

Na początku po jednym dziennie. Dodawaliśmy kolejne warsztaty do systemu, więc tych wizyt robiło się już po kilka na dobę. Sezon (zamarkowy pierwszym dużym poniedziałkowym skokiem) zaczął się 25 października 2021, czyli tydzień po naszym releasie i tydzień przed dniem Wszystkich Świętych. Autobooking był już technicznie dostępny, ale liczba wdrożonych warsztatów była zbyt mała, aby faktycznie zobaczyć realną zmianę. Na to potrzebowaliśmy prawie miesiąca.

Kiedy finalnie Autobooking osiągnął odpowiednią skalę to przyćmił nasze pierwotne oczekiwania. W pewnym momencie wizyty z Autobookingu stanowiły prawie 30% wszystkich zarejestrowanych wizyt.

Było coś magicznego w obserwowaniu jak siatka godzin dynamicznie się zmienia wyszarzając rezerwowane wizyty, a do naszego panelu wpadają wizyty z flagą „Autobooking”.

Efekty

W połowie grudnia, gdy już kurz trochę opadł, mieliśmy czas, aby zanalizować wyniki.

Konwersja urosła nam tak mocno, że nawet biorąc pod uwagę małą skalę,  specyficzną grupę najlepszych warsztatów oraz prostą usługę, wydawała się podejrzanie wysoka. Długo szukałem jakiegoś błędu w agregacji danych, bo nie mogłem uwierzyć temu co widzę. Te wyniki były tak dobre, że każdy postronny racjonalny człowiek by je kwestionował. Żaden analityk biznesowy by ich apriori nie założył szacując potencjalny wpływ tego rozwiązania na naszą firmę.

Wolne sloty rozeszły się jak ciepłe bułeczki

Warsztaty, które zaufały nam w pełni i zgodziły sie na faktyczną implementację autobookingu szybko poczuły niesamowity efekt. Najlepszy z nich tylko jednego dnia miał do obsługi 30 wizyt z czego 27 pochodziło z naszego Autobookingu.

Klęska urodzaju

Tak jak się spodziewaliśmy Autobooking też w sporym stopniu odciążył nasze Biuro Obsługi Klientów, wtedy, kiedy tego najbardziej potrzebował.

Przykładowa wizyta umawiana manualnie. Realizacja zajęła prawie godzinę
Przykładowa wizyta umawiana automatycznie. Realizacja w tej samej sekundzie

Różnica jest dramatyczna. Przy standardowym umawianiu, czas realizacji (odległość czasowa między „datą zgłoszenia” a datą potwierdzenia terminu z warsztatem, która w naszej nomenklaturze nazywa się „datą zakończenia”) może trwać kilkanaście minut, a czasami nawet kilka godzin. Przy automatycznym umawianiu to dosłownie sekunda.

Finał naszej analizy powdrożeniowej można podsumować tak: znaleźliśmy naszą żyłę złota. Ale czy to co zrobiliśmy jest wystarczające? Skoro działa dobrze teraz to może tego nie ruszać i zająć się gaszeniem pożarów w (wielu) innych miejscach czy może wręcz przeciwnie: iść za ciosem i zwiększyć swoją inwestycję. Prowadziliśmy o tym dyskusje w managmencie i ostatecznie wygrał pomysł stworzenia kolejnej wersji Autobookingu. Argumentów „za” było dużo:

  • Przyśpieszenie procesu rezerwacji to najczęściej powtarzająca się potrzeba kierowców w naszych ankietach i NPSach,
  • Dobrze zrobiony Autobooking i wynikający z tego dobry UX spowoduje, że kierowcy będą do nas wracać w następnym sezonie, co zwiększy retencję a w konsekwencji wartość całego marketplace’u
  • Ostatecznie to realna innowacja, która stanowi przewagę i strategiczną „fosę” do pokonania dla konkurencji 

Zapadła więc jednomyślna decyzja: przesuwamy na później inne kluczowe projekty i skupiamy się całkowicie na następnej wersji Autobookingu z myślą o kolejnym sezonie. Później zrobiliśmy sobie długą przerwę regeneracyjną na święta i Sylwestra. Wraz z nowym rokiem przyszedł czas na Autobooking MVP2.

MVP2

Po ustabilizowaniu kodu i naprawie błędów zgłoszonych po premierze zaczęliśmy zastanawiać się co powinniśmy robić dalej.

Jeśli chodzi o definicje zakresu to nie było trudne zadanie: wystarczyło spojrzeć na długą listę funkcji, które wrzuciłem do worka „nie na teraz”. Czyli te, które zostały odrzucone na bok jako zbyt problematyczne, ale popularne wśród interesariuszy i zgłaszane przez użytkowników (kierowców i mechaników).

Najczęściej powtarzane było wymaganie: „obsługa innych usług oprócz wymiany opon”. Tak jak wspominałem na początku, opony były idealnym kandydatem na pierwszą wersję systemu – to usługi rutynowe, które umawia się na konkretną godzinę, a więc łatwe do wymodelowania i wpasowania w kalendarz Zilo. Wybraliśmy więc z historii portalu najpopularniejsze typy usług i szukaliśmy sposobu, aby dołączyć je do Autobookingu.

Co ciekawe, nowe usługi nie nastręczały większych problemów na etapie interakcji użytkownika z portalem – wystarczyło rozszerzyć formularz o nowe kategorie.

Stary i nowy Autobooking

Problemy rozpoczęły się jednak na etapie obsługi zleceń przez warsztat. O ile zmiana opon odbywa się w tym samym momencie, co podstawienie samochodu, tak przy innych usługach te godziny mogą być różne.

Już podczas tworzenia Zilo natrafiliśmy na ten problem: mechanicy mówili nam, że kalendarz jest fajny, ale nie trafia w ich ulubiony tryb pracy, czyli:

  • Każą wszystkim przyjechać „jutro rano”,
  • O 8-10:00 rano patrzą jakie samochody stoją na parkingu,
  • Decydują w jakiej kolejności najlogiczniej jest je zrobić biorąc pod uwagę części, intesywność pracy, zajętość stanowisk i to, kto najdłużej może poczekać.

W efekcie ktoś, kto podjechał o 8:30 może mieć naprawiony samochód o 13:00, inny, który podjechał o 9:00 wyjedzie o 16:00 a jeszcze inny podjeżdząc o 10:00 będzie miał wszystko załatwione o 12:00. Nie było jasnej reguły, wszystko było płynne i zależało od sytuacji w danej chwili.

Jak to problem rozwiązać?

Odliczanie do drugiej fali

Ścigaliśmy się z czasem. Firmowe OITy  (to taka nasza wersja OKRów) na Q1 2022 zakładały, że na wiosenny sezon* wymiany opon będziemy mieć 3 razy więcej warsztatów z aktywnym nowym autobookingiem niż przy pierwszej wersji i sezonie zimowym. Biorąc pod uwagę uśrednione tempo dotychczasowych wdrożeń Autobookingu to oznaczało, że potrzebujemy 6 tygodni, a więc półtora miesiąca kalendarzowego, aby tego dokonać.

* Notka biznesowa. Sezony we wszystkich marketplace’ach to zawsze największa szansa i zagrożenie jednocześnie. W przypadku biznesu mechanicznego sezony są dwa: wiosenny i zimowy. Obydwa napędzane są zmianami opon. Wiosenny zazwyczaj jest dłuższy i ma łagodniejszy szczyt (na zimówkach da się jeździć także gdy jest ciepło). Sezon zazwyczaj zaczyna się z pierwszą falą ciepła i powoli rośnie wraz z sekwencją świąt (Wielkanoc), długich weekendów i wakacji, które łączą się ze wzmożonym przemieszczaniem się. Zimowy szczyt jest krótszy, bardzo agresywny –  zaczyna się z pierwszymi przymrozkami z kulminacją zaraz przed Świętem Zmarłych.

Nauczeni doświadczeniem z poprzedniego sezonu wiedzieliśmy, że wszystkie te wdrożenia muszą odbyć się przed rozpoczęciem fali wznoszącej, bo jak tylko mechanicy zauważą ruch w warsztatach to będą znacznie mniej skłonni słuchać o naszych nowościach. To wszystko oznaczało, że złożone elementy tych puzzli (nowe Zilo oraz nowy Autobooking) muszą być gotowe w pierwszej połowie lutego.

To oznacza, że mamy miesiąc, aby rozwiązać nasz problem z modelowaniem nowych usług.

Czas i wyporność

Już latem 2021, gdy kładliśmy podwaliny pod ideę Autobookingu, zadawaliśmy sobie to pytanie: jak procesowo rozwiązać dystans czasowy między godziną podstawienia samochodu a, wydawać by się mogło, losowym czasem jego naprawy.

Jednym z pomysłów było zaadaptowanie „wyporności”: rezygnujemy z określania godziny naprawy, zamiast tego sprawdzamy tylko, jak dużo usług w danym dniu może wziąć na siebie warsztat. Tak samo jak statek ma określoną górną granicę ciężaru ładunku, który może transportować, tak warsztat ma określoną liczbę usług, które może wykonać w ciągu dnia – niezależnie od tego kiedy w ciągu dnia każdą z nich wykona. Co nam to daje taka zmiana myślenia?

Przede wszystkim zdejmuje z mechaników sztywny gorset określania z góry godziny naprawy. Wprowadzamy natomiast „godzinę podstawienia” dla kierowcy, ale nie zmuszamy mechanika do „godziny naprawy”.

Przy pierwszej wersji zdecydowaliśmy się skupić tylko na oponach, więc koncept wyporności odstawiliśmy na dalszy plan. Teraz czas go odkurzyć, bo brzmi jak idealne rozwiązanie naszego problemu.

Wyporność brzmiała świetne w teorii, ale generowała inną zagadkę: jak ją dobudować do Zilo? Jak na siatkę kalendarza dodać wizyty, które nie mają ustalonej godziny startu? Nic sensownego nie wpadło nam do głowy, więc zaczęliśmy rozważać całkowite wyrzucenie kalendarza.

To była szalona idea…wyrzucić cały silnik kalendarzowy, na bazie którego układa się cała siatka Zilo i zamiast tego postawić coś nowego, co obsłuży obydwie logiki (czasu i wyporności) jednocześnie. Tak, dawno już chcieliśmy zastąpić czymś FullCalendar, bo czuliśmy się przez niego mocno ograniczeni, ale to było coś o wiele bardziej ambitnego.

Na początku byłem sceptyczny. Liczyłem dni… czy my w ogóle mamy szanse, aby się wyrobić mając tylko miesiąc pracy developerskiej? Tak dużo wyrywania wraz korzeniami… czy w ogóle wiemy jak dużo rzeczy musi się zmienić? Czy obsłużymy wszystkie scenariusze?

Musiałem jednak przyznać, że stworzenie zupełnie nowego kodu to najsensowniejsza ścieżka – to już czas na pozbycie się ograniczeń zewnętrznego rozwiązania. Nawet jeśli pierwsza nowa wersja będzie koślawa, to przynajmniej otworzymy przed sobą dużo nowych możliwości rozwoju.

Przyzwyczaiłem się już do startowania rzeczy, które nie są jeszcze dobre. Różnica polegała jednak na tym, że tym razem mieliśmy znacznie więcej do stracenia.

Nowe Zilo

Dzień po tej dycyzji miałem naszkicowane pierwsze makiety. Następnie rozpoczęliśmy dwutorową pracę nad logiką wyporności i nowym frontem do Zilo.

Pierwsza makieta nowego widoku głównego Zilo
Stare Zilo (2021)

Różnica polega na tym, że w starym Zilo wszystkie stanowiska musiały działać zgodnie z takim samym godzinowym kalendarzem. W nowym Zilo każde stanowisko jest rozdzielone i ma swoją wewnętrzną logikę: może być albo czasowe (wtedy ma swoje godziny „wewnątrz”) lub wypornościowe (wtedy godziny nie mają znaczenia)

Tak rozbudowana logika wymagała też rozbudowanych ustawień. Wyciągnęliśmy je do oddzielnego ekranu ze wględu na mnogość opcji. Stanowisko może być czasowe (czyli takie jak w 2021) albo ilościowe (czyli wypornościowe). Dodatkowo, ustawienie „widoczności w DM” odsłaniało dodatkowe opcje z ustawieniem dni i godzin tej widoczności oraz typy usług jakich dotyczy. Nasz` system później tłumaczył to na siatkę godzin, którą widać na formularzu rezerwacji wizyty.

Zmiana w Zilo była masywna. Choć stała za nią potrzeby związane z Autobookingiem to musiała być wdrożona także warsztatom, które Autobookingu jeszcze nie znały, albo nie chciały. Koszt utrzymywania dwóch wersji Zilo były dla nas zbyt wysokie.

Z tego powodu wieczorem 7 lutego 2022 (kilka dni przed deadlinem) przeprowadziliśmy release nowego Zilo dla wszystkich warsztatów.

Wystartowaliśmy w naszym standardowym już stylu – najszybciej jak się dało. Aby to się udało przesunąłem na późniejszy release kilka niekrytycznych ficzerów – takich jak chociażby widok listy i widok miesiąca.  Okazuje się jednak, że globalnie one były niekrytyczne, ale niektóre z warsztatów właśnie na tych widokach oparły swój workflow zamiast na widoku dnia – więc dla nich to było krytyczne. Zaiste nigdy nie wiadomo jak bardzo coś jest ważne dopóki się tego komuś nie zabierze.

Po dwóch dobach zebraliśmy feedback przekazany bezpośrednio i przez nasz BOK. W sumie mieliśmy 18 różnych błędów i braków do poprawki. Naprawianie tego zajęło nam kolejny tydzień więc finalnie 14 lutego (dokładnie w nasz deadline) nowe Zilo uznaliaśmy za ustabilizowane.

Pauza

W połowie lutego byliśmy po wdrożeniu – nowe Zilo i zmodernizowany formularz Autobookingu trafiły na produkcję. Teraz pałeczkę od nas przejął BOK z misją wdrożenia jak największej grupy warsztatów przed rozpoczęciem sezonu.

Raz na tydzień zbieraliśmy wnioski ze wdrożeń, aby usłyszeć co postronne warsztaty sądzą o naszych nowych rozwiązaniach. W większości przypadków, jak już udało właścicieli namówić na współpracę, to wszystko szło sprawnie. Idea „wyporności” była dla nich oczywista, co mnie bardzo uspokoiło. Czasami wręcz nie czekali na instrukcje i sami konfigurowali stanowiska, tryby i czas dostępności. Z jednej strony było to irytujące, ale z drugiej oznaczało, że system jest zrozumiały bez wyjaśnień.

Dzięki temu kolejne sprinty mogliśmy z czystym sumieniem przeznaczyć na inne przygotowania do sezonu (mieliśmy ambicję wpakować w ten kwartał jeszcze jeden duży projekt, ale to temat na inny wpis). 

Druga fala

Pierwsze zlecenia na nowe usługi zaczęły już wpływać w trzecim tygodniu marca. Ruch powoli rósł zgodnie z prognozami, ale później się załamał ze względu na nagły atak zimy na początku kwietnia.

4 kwietnia 2022 ¯\_(ツ)_/¯

Następnie były święta, które nie okazały się aż tak dużym motywatorem do zmiany opon jak myśleliśmy – mimo coraz lepszej pogody wszyscy mieli z tyłu głowy opady śniegu sprzed kilku dni. Prawdziwy ruch zauważyliśmy dopiero w maju, przy okazji długiego weekendu.

Autobooking od marca do maja 2022

Do tego czasu mieliśmy już w systemie 4 razy więcej warsztatów z autobookingiem niż przy sezonie zimowym. Wraz ze zwiększoną skalą działania widzieliśmy typowe zachowanie analityki gdzie konwersja rozpoczęła regresję do średniej wartości: skrajnie dobre i złe przypadki miały coraz mniejsze znaczenie przy drastycznie zwiększonej grupie aktywnych użytkowników. Potwierdziło się też moje wcześniejsze przypuszczenie że pierwotnie dobrana grupa testerów skrzywiała odbiór rozwiązania w stronę zdecydowanie bardziej pozytywną niż globalna średnia oraz że sezon zimowy jest znacznie agresywniejszy niż wiosenny

Niemniej, mimo tych wszystkich zastrzeżeń osiągnęliśmy nasze trzy najważniejsze cele:

  • Poprawiliśmy proces rezerwacji, co widać po kilkukrotnie lepszej konwersji w warsztatach po wdrożeniu Autobookingu (uśredniając między sezonami), 
  • Zautomatyzowaliśmy 20%+ bookingów, a więc uwolniliśmy 1/5 czasu naszego Biura Obsługi Klientów, co jest szczególnie istotne podczas sezonów,
  • Udowodniliśmy, że automatyczne rezerwacje w warsztatach jest możliwe, choć mało osób w branży to wierzyło.

Co dalej?

Autobooking potwierdził się jako dobry kierunek rozwoju produktu. Wygraliśmy ten zakład z rzeczywistością, co mnie niezmiernie cieszy. Stworzyliśmy nową jakość, która okazała się wartościowa zarówno dla naszych klientów jak i nas jako organizacji.

Komentarz z pierwszej linii frontu współpracy z warsztatami po wdrożeniu Autobookingu (AB)

Teraz czeka nas dalsza praca nad poprawą tych wskaźników – zwiększając liczbę warsztatów z Autobookingiem, rozszerzając spektrum usług i usprawniając interfejs po stronie kierowcy i warsztatu.

Ale to tylko jeden z zakładów, które wzięliśmy na siebie podczas mojego pierwotnego planu strategicznego z początku 2020 roku. Tamte założenia są ciągle aktualne.

Czas wziąć na warsztat kolejny punkt z listy.

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.