W drugiej części wywiadu z Jakubem Uniejewskim porozmawialiśmy o tym jak wygląda tworzenie i rozwijanie produktu w OLX. Kuba zdradził nam trochę  wewnętrznych insightów. Podpytałem również o współpracę PMa z projektantami/badaczami UX, stosowanie Scruma przy testowaniu hipotez i podziale obowiązków w zespole.

Jakub Uniejewski – product manager w międzynarodowym OLX Group (do którego należy polski serwis ogłoszeniowy OLX, wcześniej Tablica.pl). Ma kilkuletnie doświadczenie w pracy jako produktowiec w Wielkiej Brytanii i Berlinie (Skyscanner, Fyber). W Polsce był product managerem Gratka.pl. Współtwórca Podcastu ProdcutVision. Jakuba znajdziesz na Facebooku

To jest 2 z 3 części wywiadu z Jakubem Uniejewskim o tworzeniu i zarządzania produktami cyfrowymi w zachodnich firmach.

1 część: „Na dłuższą metę czujesz, że internet w Polsce jest mały”.

3 część: „Jak znaleźć pracę za granicą jako product manager?”

Całego wywiadu możesz też posłuchać w formie podcastu 🎧.

Tomasz Tomaszewski: Opowiedz o tym, jak tworzycie produkty w OLX? Jak wygląda wasz zespół? Jak dzielicie się kompetencjami?

Jakub Uniejewski: Nie wygląda to pewnie jakoś szalenie inaczej niż w całkiem rozsądnie ułożonej firmie. Co ciekawe OLX-ów jest kilka na świecie. Jest OLX na Amerykę Środkową i to jest osobny duży region. My to region Europa i tu wchodzą OLX-y, które są rozwijane głównie z Poznania, częściowo teraz też z Berlina. Otomoto, Otodom i wszystkie serwisy wertykalne są o dziwo rozwijane z Lizbony.

Jesteśmy zorganizowani w taki sposób, że staramy się przekładać wartość dla użytkownika na konkretny obszar produktowy. Ostatnio przegrupowaliśmy się na podział bardziej na podstawie user journey. Tak naprawdę masz wiele różnych możliwość zorganizowania zespołów produktowych.

W tej chwili mamy zespół, który odpowiada za to jak nowi użytkownicy odnajdują się w serwisie. Jest to tak zwane activation & engagement, czyli jak użytkownikowi korzysta się z serwisu do takiej podstawowej eksploracji.

Jest osobny zespół, który odpowiada za cały experience wyszukiwarki, szukania i znajdowania tego, co chciałbyś odnaleźć. Ja teraz odpowiadam za kolejną część podróży użytkownika, czyli za komunikację i transakcje pomiędzy użytkownikami. I tę część zaczynamy tworzyć w Berlinie. Jest też więcej zespołów, bo wbrew pozorom OLX to spory serwis.

Najczęściej jesteśmy zorganizowani tak, że tworzymy zespoły, które są bardzo cross-funkcjonalne. Czyli tak naprawdę budujemy zespół, który jest w stanie dowieść całość produktu. Nie dzielimy się osobno na np. back-end, front-end, mobile i tego typu rzeczy.

Pracujemy na OKR-ach, więc każdy zespół ma swój cel. Za cele główne odpowiada produktowiec.

Pracujemy na OKR-ach, więc każdy zespół ma swój cel. Za cele główne najczęściej odpowiada produktowiec. Pracuje on z całym zespołem nad zdefiniowaniem tego, jak te cele chcą osiągnąć w danym kwartale. Obejmuje to wszystko – od robienia reaserchu i współpracy z zespołami graficznymi czy projektantami, przez badania rynku, analizy, robienie eksperymentów i weryfikacje, po późniejsze wdrażanie tego, A/B testowanie bądź inne formy testów. Taki jeden zespół ma swoją misję, ma swoją drogę i on nią podąża. A już na poziomie europejskim staramy się, żeby poszczególne zespoły nie rozjeżdżały się w różne strony.

Zespoły są w miarę stałe, czy np. co dwa-trzy miesiące rotujecie ekipą?

W tym momencie zespoły są w miarę stałe. Co parę miesięcy jest okazja do delikatnego przerotowania, ponieważ czasami zmieniają się cele i wtedy też zespoły. Zawsze zespół jest dostosowany do tego, jakie umiejętności są potrzebne żeby osiągnąć dany cel. Bo z założenia zespoł dostaje cel, „tam jest ta góra, wspinajcie się” i musi mieć cały sprzęt, wyposażenie i umiejętności.

Jeszcze z dwa lata temu mieliśmy osobny zespół mobilny, częściowo zespoły były beckendowo-frontendowe, ale tak naprawdę front-end był trochę oddzielony i to nie działało najlepiej. Teraz każdy zespół ma po prostu swoje poletko, na tym poletku ma swoją misję i do boju.

Współpraca z projektantami i badaczami UX

A kto jest w takim zespole? Są tam pewnie głównie deweloperzy, ale co np. z projektantami i badaczami UX?

W tym momencie UX-owcy czy badacze są w strukturze organizacyjnej poza zespołami produktowymi, pracują w ramach całej organizacji. Badaczy mamy jeszcze niewielu. A właściwie niewiele, bo to w tej chwili są to głównie dziewczyny…  Podobnie mamy z projektantami, którzy też pracują przy zespołach i z zespołami. Ale nie jest tak, że mamy 1:1. Można powiedzieć, że każdy jest jedną nogą w dwóch zespołach jednocześnie.

A jak sobie radzicie, pracując w Scrumie, z zawarciem w celu sprintu pracy produktowej, takiej koncepcyjnej, badawczej. W jednym Sprincie zwykle wszystkiego nie zrobisz. Nie zrobisz badania, nie zrobisz projektu interfejsu, nie zakodujesz tego. A tak teoretycznie w Scrumie powinno być.

Tak, jasne, mamy roczne Sprinty i wszystko się mieści 😉 A serio, to już Ci to wszystko opowiadam.

W produkcie masz obszary discovery i delivery, i tak na to patrzymy. Czyli mamy „szukamy, badamy, weryfikujemy” produkt oraz „dowozimy” produktu.

Czasami dowozimy MVP, czasami wersję mini MVP, żeby jeszcze bardziej zweryfikować. To od zespołu zależy, czy dany Sprint jest bardziej w stronę discovery, czy bardziej w stronę delivery. Najczęściej jest tak, że praca zespołu deweloperskiego to 80%-90% delivery tego, co już zostało wcześniej zweryfikowane. Pozostałe 10-20% to jest albo jakiś „spike”, bo coś testujemy, albo budujemy jakiś prototyp, albo jest dodatkowy test z użytkownikami.

W trakcie sprintu dzieją się też dodatkowe prace, w których przygotowujemy albo weryfikujemy pomysły. I w tym też uczestniczy zespół deweloperski, ale dla nich to jest tylko niewielki procent ich sprintu. Niektóre zespoły, np. zespół wyszukiwarki, często ma dużo bardziej badawcze sprinty. Albo mają wręcz, że jeden/dwa sprinty to jest prowadzenie tylko i wyłącznie testów AB.

Mój zespół skupia się teraz w dużej mierze na przetwarzaniu tego, co przebadaliśmy ostatnio na Ukrainie. Byliśmy w Kijowie niedawno, robiliśmy badania z użytkownikami, robiliśmy ankiety. Było tego mnóstwo. Sporo się nauczyliśmy, teraz wnioski trzeba dowieźć. Zespół deweloperski skupia się nad „delivery”, ale częściowo product z UX-owcami i designerami patrzy dalej na kolejny kwartał.

W Scrumie jest coś takiego jak cel Sprintu. Najlepiej jakby był jeden konkretny cel. No i to też często kłóci się z pracą badawczą. Nad czymś innym pracujemy w obszarze discovery, co innego robimy w obszarze delivery. Jak Ty do tego podchodzisz? Masz stricte sprinty badawcze i delivery, czy mieszacie zadania w sprincie?

To jest dobre pytanie. Gdy cały zespół był w Kijowie, to był to zdecydowanie Sprint badawczy. Najczęściej sprinty mamy tygodniowe, teraz na pewien czas mamy dwutygodniowe. Nasze Sprinty mają 1-2 poboczne cele i 1 cel główny – najczęściej związany z delivery. To jest gro pracy tych ludzi. W zespole są przecież głównie deweloperzy, oni muszą zbudować dobrej jakości soft, który będzie działał w skali.

Oprócz tego częściowo ich pracą jest też dowiezienie tematów z discovery. Na przykład, odpalamy ankietę, trzeba ją podpiąć, przetestować i tak dalej. Taka historyjka też jest na Sprincie. Rzadko kiedy takie tematy są celem sprintu.

Jak OLX wykorzystuje dane do podejmowania decyzji?

Jak często wdrażacie zmiany na produkcji?

Chodzi Ci o to, jak często wprowadzamy zmiany kodu na platformę?

Tak.

Szczerze mówiąc nie wiem tak do końca, bo wdrażamy cały czas, nie jest to jakieś wielkie wydarzenie. Ja tylko o tym słyszę gdy coś nie działa albo wprowadziliśmy coś nowego. Mamy w tej chwili około 10 zespołów, więc zmiany wchodzą na produkcję co najmniej kilka razy dziennie. Ale to też nie jest tak, że każdy zespół codziennie coś wypycha. Nie mamy takiego super continuous delivery, że codziennie każdy komit leci od razu na produkcję… Zmiany widoczne dla użytkowników wchodzą prawie w każdym Sprincie, apki wychodzą chyba raz na dwa tygodnie, czasami raz na trzy tygodnie, dość regularnie.

Każda zmiana musi być opomiarowana? Czy to na razie tylko taki ideał, do którego dążycie?

Oczywiście ;). Wiesz, jak to jest… Możesz wrzucać po prostu rzeczy na produkcję i patrzeć po pół roku, czy ci coś urosło. Jeśli tak, to będziesz twierdził, że to dzięki temu co zrobiłeś. Nie wiem jak przy mniejszych produktach, ale przy OLX tyle się dzieje i jest tak duża sezonowość, że jeżeli nie zrobisz solidnego A/B testu to nie będziesz miał pojęcia, czy twoja zmiana wpłynęła na produkt. Chyba że wprowadzasz coś, co generuje kolosalną zmianę albo na plus, albo na minus. Ale takich zmian nie ma aż tyle. Każda zmiana, która trafia na produkcję, ma mierzony realny wpływ na produkt.

Ostatnio wyszukiwarka zakończyła 10 równoległych A/B testów. 3 przeszły do wdrożenia, a 7 do zakopania.

A jak się nie poprawia to wycofujecie, usuwacie nowe funkcje?

Tak. Ostatnio wyszukiwarka zakończyła 10 A/B testów puszczonych równolegle. 3 przeszły do wdrożenia w skali, a 7 do zakopania. To też pokazuje, że niektóre rzeczy warto weryfikować dużo wcześniej, zanim wdrożysz kod i zrobisz AB test, bo to jest dość droga metoda. Teraz tak naprawdę staramy się coraz częściej robić prototyp, makietę, może jakiś test z użytkownikami, żeby więcej rzeczy przetestować. Tak by ten lejek badawczy poszerzyć na tym poziomie, kiedy przetwarzamy pomysły, a do developmentu wchodziło już trochę mniej. Development to po prostu bardziej kosztowna metoda testowania, czy hipoteza produktowca miała sens.

Product Manager vs Product Owner

Czy product manager jest u Was również product ownerem?

W tym momecie jest to zwykle jedna rola – mamy bardzo płaską strukturę. Chociaż ja od ponad roku jestem product managerem, który nie pracuje bezpośrednio z zespołem jako product owner, ale wspiera innych produktowców. Odpowiadam po prostu za jakiś obszar. Nie wprowadzamy wielkiej hierarchii. Ciągle mamy wszyscy jednego szefa.

Generalnie jednak produktowiec pracuje jako product owner z zespołem. I chyba tak jest w większości przypadków. Czasem mamy odstępstwa. Na przykład jak ktoś wchodzi do zespołu jako junior, to zostaje PO tylko na poziomie sprintu przez pierwsze 2-3 miesięcy. Współpracuje z produktowcem, który jest product managerem i który odpowiada już mniej za same historyjki, a bardziej za to, co ten zespół w ciągu najbliższych 2-3 miesięcy ma zrealizować.

W niemieckich firmach jest też takie stanowisko jak market product manager. Są to ludzie odpowiedzialni za rynek, np. jakiegoś kraju.

Na rynkach, na których działamy, mamy osoby, które u nas też się nazywają product managerami. To są tak naprawdę faktycznie albo market managerowie, albo, tak jak my ich nazywamy, local product managerowie. Rzeczywiście było jeszcze jakiś czas temu tak, że te osoby funkcjonowały bardziej jako źrodło wymagań i ticketów do centralnego backlogu. Produktowiec po prostu przemielał i traktował ich jako stricte stakeholderów.

Teraz bardziej działamy tak, że product manager, który pracuje nad danym obszarem, ma po prostu swój cel i to on kieruje inicjatywą, współpracuje z lokalnymi market managerami. Oni bardzo często dobrze znają rynek, wspierają też badania rynkowe, pracują nad tłumaczeniami. Jeżeli robimy jakieś badania, na przykład UX-owe, to oni pracują z lokalną agencją, która nam dostarcza wyniki.

Mi bliżej do takiego modelu, że jednak w tym zespole produktowym jest sporo decyzyjności.

To chyba bardzo zależy od tego czy jesteś w stanie na każdym rynku mieć osoby, które działają na tym samym poziomie produktowym. Bo my mamy takie rynki, gdzie lokalni produktowcy są super partnerami. Jeśli przychodzą do nas z jakimś pomysłem, to nie jest to luźny pomysł-hipoteza, tylko poparty już sprawdzonymi danymi i weryfikacją z użytkownikami.

Pytanie o Twoją współpracę z działem marketingu. Trochę już opowiedziałeś na ten temat, ale możesz jeszcze trzy słowa dopowiedzieć :). Czy ludzie z marketingu są też blisko zespołów produktowych, czy to raczej osobny dział?

W każdym kraju jest lokalny zespół marketingowy, który ma swój kierunek i odpowiada za brand, postrzeganie marki, edukację, za kampanie telewizyjne, PR.

OLX jest rozwijany w jednym miejscu, ale w każdym kraju jest lokalny zespół marketingowy, który ma swój kierunek i odpowiada za brand, postrzeganie marki, edukację, za kampanie telewizyjne, PR o tego typu rzeczy. Z nimi raczej mamy uzgodnienia tylko odnośnie kierunku i wspólnego języka.

Ale jeżeli pojawiają się sytuacje, w których wprowadzamy jakieś duże zmiany na serwisie, które zwłaszcza mogą być źle odebrane przez użytkowników, albo są rewolucyjne – to mocno współpracujemy z nimi, żeby przygotować dobrą komunikację. Ale to jest bardziej komunikacja go-to-market i wprowadzenie czegoś na rynek.

Jak zagranicą rozwinięty jest rynek, jeśli chodzi o analizę biznesową? Jak liczne są zespoły analityków biznesowych przy konkretnym projekcie?

My mamy rolę, którą nazywamy analitykiem produktowy. To jest osoba, która pracuje w każdym zespole produktowym. Odpowiada ona za pomoc w zweryfikowaniu pomysłów i przesiewaniu danych, by zweryfikować na ile ludzie czegoś używają, na ile mamy rynek albo grupę, segment użytkowników, dla których funkcjonalnosć miałaby sens. Wspiera zespół podczas przygotowania odpowiedniego trackowania danych, żeby wszystko odpowiednio pomierzyć i mieć potem jednoznaczny wynik.

Także jest to osoba, która pracuje bardzo blisko z produktowcem, dostarcza danych, dostarcza analiz, pomaga zweryfikować pomysły, no i pracuje bezpośrednio w zespole deweloperskim. Każda historyjka, która wchodzi ma wręcz w tickecie wpisane, jak będziemy ją mierzyć, Czy wysyłamy dodatkowe eventy czy będziemy mierzyć coś na bazie.

Mamy też jeszcze, ale to już bardziej w zespołach biznesowych, analityków biznesowych. Odpowiadają oni za weryfikację nowych pomysłów stritce biznesowych, np. wprowadzenie jakiejś oferty. Oni rzeczywiście przemielają rynek, robią symulacje i mierzą tego typu rzeczy. Jak wprowadzamy zmiany w cennikach, to oni przygotowują nowe modele cen, puszczają testy cenowe, analizują, jak to wpłynęło na wolumeny albo przygotowują segmenty, które byłyby wartościowe do jakiejś akcji z partnerami.

Trzecia część wywiadu: „Jak znaleźć pracę za granicą jako product manager?” Całego wywiadu możesz też posłuchać w formie podcastu 🎧.

➔ Rozpoczynasz przygodę z tworzeniem produktów? Przygotowaliśmy dla Ciebie eBooka „Product Guide - podręcznik product managera”.

Dołącz do naszych czytelników

Dołącz do 1 700+ subskrybentów otrzymujących nasz cotygodniowy newsletter z inspiracjami do tworzenia coraz lepszych produktów i rozwoju swojej kariery.
Product manager, konsultant i wiceprezes Rocket Studio, współwłaściciel Komijo.pl. Od 5 lat pomaga zwinnie zarządzać oraz tworzyć onlineowe produkty zarówno korporacjom jak i startupom. Specjalizuje się w agile product development (certyfikowany Scrum Masterem oraz AgilePM), lean startup i customer development. Tworząc produkty opiera się na liczbach, z silną pasją do UX i myślenia projektowego.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.