Rynek serwisów z ogłoszeniami IT jest w Polsce już dość okrzepnięty – funkcjonują na nim od kilku lat produkty, które wyrobiły sobie grono odbiorców, markę, styl działania. Z jakim celem zaczynaliście pracę w the:protocol?
Mam to szczęście, że „przyszedłem na gotowe”, czyli już po starcie projektu. Mój poprzednik na tym stanowisku razem z product designerem Mateuszem Martynem wraz zespołem the:protocol wykonali tytaniczną pracę, analizując konkurencję, nasze słabości, ale też przewagi. Zauważyli, że na rynku jest miejsce dla wyspecjalizowanego jobboardu z niebanalnym layoutem, którego główne przewagi mają łączyć efekt skali Grupy Pracuj z doskonałym User Experience kandydata. To na nim był główny focus od samego początku. Dlatego już na starcie dostępne były takie funkcje, jak wiadomość do pracodawcy oraz opisy projektu, który przyszły pracownik miałby rozwijać.
Zadaniem, które przede mną postawiono, było wykorzystanie mojego ecommerce’owego doświadczenia w dalszym rozwijaniu serwisu. Zastałem zespół świetnych inżynierów, zaangażowanych product designerów, stale monitorującą użytkowników badaczkę i współpracujący blisko biznes, z marketingiem i obsługą klienta na czele. Brzmi jak raj dla PO. I tak dokładnie jest. Fajna, profesjonalna ekipa. Zaczęliśmy rozmawiać o dalszych kierunkach rozwoju. Podzieliłem się z nimi moim fanatycznym podejściem do oszczędzania czasu użytkownika, zdejmowania mu przeszkód z drogi. Przecież konwersja to świętość w e-commerce! W odpowiedzi product designerzy Mateusz Martyn i Bartosz Walter, który dołączył do the:protocol razem ze mną, zarazili mnie ideą MLP, czyli Minimum Loveable Product.
Przyznaję, że była to miłość od pierwszego wejrzenia. Wychowany w kulcie MVP (Minimum Viable Product) wielokrotnie przekonywałem się, jak nieprzyjazne dla użytkowników jest to myślenie. Kiedy opracowuje się MVP – chociażby w startupach czy w firmach usługowych w branży IT – tworzy się jak najtaniej działającą funkcję, którą następnie się testuje. Wynika to z prozaicznej przyczyny: zbudowanie czegokolwiek jest kosztem finansowym oraz ryzykiem. Dlatego tworzy się mały element, który pozwoli nam zwalidować dany pomysł biznesowy.
Kiedy tworzy się MVP, bardzo często zaniedbuje się kwestię wyglądu funkcji. Tego nigdy nie chcieliśmy, dlatego w the:protocol podchodzimy do tematu inaczej. Przykład: tworzymy jobboard metodą MVP. Wszystkie funkcje działają, ale są bardzo ograniczone, wyglądają surowo, zdarzają się problemy z wydajnością.
Tymczasem w metodzie MLP, kiedy dodajemy jakieś funkcje, nie musimy projektować dużej liczby opcji. Nadal koszt i ryzyko są ważne. Natomiast staramy się, żeby tam, gdzie użytkownik się porusza, wszystko działało perfekcyjnie, a funkcja była wykonana bardzo dobrze jakościowo (Pixel Perfect) i łatwa w obsłudze.
Przy tworzeniu the:protocol determinuje nas jeden kluczowy faktor i on ustawia nam priorytety: jest to czas użytkowniczki i użytkownika. Czas, który ta osoba poświęca na podjęcie decyzji, czy chce z nami zostać. Dążymy do sytuacji optymalnej: człowiek trafia do nas jak najszybciej i jak najskuteczniej spełnia swoją potrzebę. Nie musi przebywać w serwisie długo, ale chcemy dać poczucie satysfakcji z jakościowych poszukiwań.
Co było punktem wyjściowym dla Waszego MLP? Jaka potrzeba?
Oszczędność czasu po stronie użytkowników i użytkowniczek. Podczas badań z nimi czynnik czasu pojawił się jako kluczowy przy wyborze jobboardu oraz w ogóle na etapie decyzji przystąpienia do procesu rekrutacji. Zwłaszcza w gronie midów i seniorów, którzy ze względu na swoje dotychczasowe doświadczenia oraz etap życia biorą pod uwagę kryterium czasu przy wchodzeniu w jakiekolwiek relacje z firmami.
Osoba, która wchodzi na stronę, trafia do nas z Google lub reklamy, być może też zobaczyła nas na konferencji. Mamy tylko kilka sekund na to, żeby ją przekonać, że to właśnie my jesteśmy tym miejscem, w którym może znaleźć pracę. Dlatego każde utrudnienie w wykonaniu kolejnego kroku i każdy niepotrzebny fajerwerk powoduje, że tracimy ten czas i jej uwagę. Chcemy, żeby użytkownik trafił do nas w minimalnej liczbie kroków – mógł szybko znaleźć ofertę, błyskawicznie aplikować i żeby ten proces zakończył się jak najszybciej. Nie zależy nam, żeby odbiorca czy odbiorczyni spędzała w serwisie dużo czasu. Zależy nam na tym, żeby ludzie chcieli do nas wrócić i polecić serwis z przekonaniem, że the:protocol to skuteczne narzędzie. W ten sposób jesteśmy w stanie od 2 lat rozwijać się organicznie. Dodatkowo im więcej dobrych kandydatów – takich, którzy niosą ze sobą wartość – tym lepiej także dla rekruterów i rekruterek, którzy do nas trafiają. I w ten sposób kółko się zamyka.
Jak umocowanie w Grupie Pracuj wpływa na kształt Waszego zespołu? Zakładam, że są cienie i blaski tej zależności.
Blaski są oczywiste – wsparcie potężnej i dobrze naoliwionej maszynerii Grupy Pracuj. Zespoły specjalistów (analityków, cyber security czy sprzedaży) to mniej obowiązków i wsparcie fachowe dla członków zespołu. Do tego kultura firmy nastawiona na odwagę, zachęcanie do eksperymentowania – to także potężne wzmocnienie.
Wyzwaniem są za to oczywiste zmiany zachodzące w firmie. Musimy reagować na zmiany technologiczne czy biznesowe całej grupy. Nie zawsze możemy i nie zawsze chcemy być we wszystkim niezależni. Takie elementy, jak choćby konto użytkownika, musi być stworzone według standardów całej firmy. Oznacza to obowiązek działania według ściśle określonych ram.
Rozwijaliście i nadal rozwijacie produkt the:protocol metodą Continuous Discovery. Dla wielu zespołów praca w tej metodzie to marzenie. Zwłaszcza, jeśli jest realizowana zgodnie ze sztuką, a nie jak szwedzki stół, z którego możesz sobie wziąć jakieś wyniki badań w momencie, w którym akurat ci pasują. Jak to wygląda u Was?
Wiedza o użytkownikach jest absolutnie kluczowa. Sam mam zawodowe doświadczenia, kiedy na pytanie o to, kim są nasi użytkownicy, uzyskałem kiedyś odpowiedź: „defaultowo aspiracyjni”. I to miało mi wystarczyć w rozwijaniu produktu o milionowym budżecie! Takie oszczędności na badaniach lubią się mścić na etapie developmentu aplikacji.
Continous Discovery to narzędzie, które pokochałem, bo w the:protocol realizowane jest zgodnie ze sztuką od początku trwania serwisu. Wspiera nas i szkoli w tym obszarze Michał Reda i Product Discovery Pro.
W Continous Discovery kluczem jest to, żeby cały czas badać użytkowników, weryfikować czy nasze pomysły odpowiadają ich potrzebom. Nie chodzi o to, żeby taką akcję badawczą realizować raz na pół roku, kiedy jest już gotowych do wdrożenia kilka funkcji albo planuje się zrealizowanie nowej.
Nie można wtedy nagle zacząć badać użytkowniczek, zatrudniać zewnętrzną firmę badawczą czy realizować jednorazowe badanie podczas konferencji branżowej. A następnie wykorzystywać zgromadzone dane raz na jakiś czas i używać ich pod tezę.
W the:protocol przeprowadzamy badania pogłębione na użytkownikach w cyklach tygodniowych lub dwutygodniowych. Mamy więc wiedzę praktycznie na bieżąco. I w takim samym trybie realizujemy pomysły, które pojawiają się w firmie: zarówno te, które pochodzą z zespołu sprzedaży, marketingu czy osób programujących. Jeśli pomysł ma potencjał, inwestujemy w przebadanie go na ludziach – pokazujemy im, jak mogłaby wyglądać funkcje albo nawet działające mockupy. W badaniu obserwujemy zachowania, dzielimy też osoby na segmenty, co w przypadku branży IT jest kluczowym filtrem: juniorzy, midzi, seniorzy.
W ten sposób pozyskujemy bieżący feedback z rynku – wiemy co się zmienia, w którą stronę idzie i czy nasze pomysły mogłyby się przyjąć. Dodatkowo wykorzystujemy także obecność na konferencjach branżowych – nasze stoisko jest zwykle na tyle duże, że mamy możliwość przeprowadzania badań w konkretnym obszarze. Wtedy badamy funkcję, która dojrzała do przygotowania mockupów i pokazania jej reprezentatywnej grupie osób.
Wspomniałeś o badaniach, do których się odwołujecie przy pracy nad produktem. Czy na przestrzeni 2 lat „życia” produktu pojawiło się w badaniach coś zaskakującego, co było w kontrze do początkowego zamysłu?
Elementem, który badania zweryfikowały, był minimalizm w liczbie funkcji. Założyliśmy, że ograniczona ich liczba jest tym, czego ludzie potrzebują. Okazało się, że jest odwrotnie: dojrzali użytkownicy, a takich właśnie mamy, wolą wiele opcji do wyboru, ale logicznie ułożonych. Pogłębiliśmy więc badania z kandydatami i na ich podstawie przebudowaliśmy nawigację pod kątem zainwestowanego czasu – jak najszybszej drogi do znalezienia wstępnie przefiltrowanych ofert.
To ostatnie stało się też przyczynkiem małej rewolucji w projekcie. Zebraliśmy dane, przebadaliśmy użytkowników i uznaliśmy, że zgodnie z Minimum Lovable Product musimy przeprowadzić ograniczony redesign. Redesign w serwisie, który jest od roku na rynku! Sami siebie też musieliśmy do tego przekonać Zgoda na taką inwestycję ze strony zarządu firmy chyba najlepiej pokazuje kulturę Grupy Pracuj. Ciężko się zawraca z raz powziętej drogi, ale w naszym przypadku efekt był dokładnie taki, jak powinien. Teraz praktycznie z tygodnia na tydzień zmieniamy: elementy nawigacji, formę tego, jak wygląda oferta, stopki czy filtry po to, żeby dostosować się do zmiennych realiów tej branży.
Zaczynając duży projekt, nie wszystko da się idealnie przewidzieć. A już na pewno sposobu, w jaki użytkownicy będą się po nim poruszać. Dzięki temu, że reagujemy na bieżąco, wdrażane poprawki przynoszą konkretne efekty, a my mamy coraz wyższą konwersję.
the:protocol nie jest dużym zespołem, ale jednocześnie w jego skład wchodzą ludzie z różnorodnymi kompetencjami, które są potrzebne, żeby wprowadzić produkt cyfrowy na rynek. Wiem, że tak było od początku: działał marketing, doświadczony zespół produktowy itd. To rzadkość w startupach. Jednocześnie wymaga umiejętnej komunikacji pomiędzy osobami w różnych rolach. Jaką macie na to metodę?
Płaska struktura, duża swoboda, regularne retro, otwartość na pomysły każdej zainteresowanej osoby. Nie tracimy czasu na samodzielne wynajdywanie koła. Produkty działają najlepiej, kiedy cały zespół i użytkownicy mają wpływ na ich kształt.
Najgorsza możliwa sytuacja to taka, kiedy poszczególne zespoły mają inne cele. Kluczem do uniknięcia tego scenariusza jest zaangażowanie w tworzenie produktu wszystkich osób, które pracują w firmie. Kiedy organizujemy review, moją rolą jest gromadzenie na nim ludzi z marketingu, SEO, reklamy, sprzedaży. Oni muszą wiedzieć, co się dzieje w zespole produktowym, jakie funkcje się pojawiają i dlaczego. Jeśli cały zespół wie, jaki mamy priorytet i który cel aktualnie realizujemy, to podświadomie członkinie i członkowie sami zaczynają myśleć przez jego pryzmat i łatwiej im dokładać swoje pomysły związane ściśle z kontekstem, w jakim aktualnie działa produkt. Są w stanie także lokalizować błędy, których my z zespołu produktowego, z racji innej perspektywy, po prostu nie znaleźliśmy. Każdy, kto doświadczył zgłaszania błędów na produkcji wie, jak dużą wartość ma znajdowanie ich przez własny zespół, zanim coś zostanie oddane użytkownikom.
Na poziomie wartości w zespole, na pewno scala nas nie tylko świadomość wspólnego celu i działanie drużynowe. Także poczucie zaangażowania, które buduje w nas otwartość na dzielenie się pomysłem i pewność, że ten pomysł nie trafi w próżnię, tylko będzie wzięty pod uwagę i bardzo często przebadany.
Ciekawi mnie Twoja perspektywa w temacie budowania the:protocol przez Grupę Pracuj. Jak udaje Wam się wyważyć zwinne podejście i kulturę w zasadzie startupową, z obiektywnymi strukturami, które narzuca Wam korporacja?
Pracuj.pl wywodzi się ze startupu, który grupa młodych ludzi zaczęła budować około roku 2000. Dlatego dzisiejsza Grupa Pracuj ma bardzo otwartą kulturę i nie chodzi mi tylko o wspomnianą życzliwość dla pomysłów innych czy na budowanie wspólnego kontekstu dla wszystkich w zespole. Chodzi też o przyzwolenie na eksperymenty, popełnianie błędów i wyciąganie z nich wniosków. W Grupie Pracuj i w the:protocol wykorzystujemy metodę After Action Review (chodzi o to, żeby szybko i efektywnie wnioskować po zakończonym eksperymencie i taką syntezę wykorzystywać w przyszłości przy kolejnych działaniach). Po dużym projekcie, niezależnie czy udanym, czy nie, organizujemy spotkanie AAR i zastanawiamy się, które elementy zadziałały dobrze, a które nie. Uczestniczą w tym interesariusze, patrzy się dość szeroko na projekt i planuje działania, które pomogą nam uniknąć potknięć w innych podobnych projektach.
Wracając do relacji the:protocol i Grupy Pracuj, myślę, że wzięliśmy co najlepsze z korporacji, jeśli chodzi o kulturę, czy metody działania, ale też część infrastruktury technicznej, co uwalnia nam sporo czasu. Do tego mamy finansowy komfort, bo skalowalność biznesu jest w rękach doświadczonych osób, którzy dobrze rozumieją rynek. Cały zespół the:protocol, który jest grupą ludzi o komplementarnych dla biznesu kompetencjach, tworzy de facto startup w dużej firmie – firmie, która działa w polskim kontekście, a jej wypracowane mechanizmy nie są oderwane od naszej kultury.
W tej chwili jako product owner jestem w wymarzonej sytuacji – mam swobodę i decyzyjność, w którą stronę idą działania nad produktem. Dołączyłem do zespołu w trakcie jego działania i zastałem pracę zrealizowaną przez mojego poprzednika na najwyższym poziomie. Współpracuję z zespołem doświadczonych managerów, z których wiedzy mogę korzystać. Mam pod opieką żyjący organizm i całą społeczność, która obserwuje, czy wdrażane zmiany działają i mają sens. To daje nam wszystkim podstawowe paliwo, czyli satysfakcję, że jesteśmy sprawczy i możemy mierzyć to, co robimy.
the:protocol będzie się zmieniał?
Będzie. Chcemy m.in. zrobić ukłon w stronę rekruterek i rekruterów. Kiedy wystartowaliśmy, najważniejsze było dla nas to, żeby kandydat mogła dobrze się czuć w serwisie. Osoby, które rekrutują, nie mają jeszcze wszystkich funkcji, jakie chcielibyśmy im zaproponować. Na początkowym etapie mocno skupiliśmy się na tym, aby odpowiedzieć na ich potrzeby pierwszego rzędu – zapewniając im przede wszystkim kontakt z wartościowymi kandydatami. Plan na przyszłość: chcemy umożliwić dwóm wspomnianym grupom dialog i ułatwić nawiązanie długofalowej współpracy. To wszystko za pomocą najskuteczniejszego na rynku narzędzia.
