Od zajawki z dzieciństwa do roli CPO we własnej firmie

Początki i Edukacja

Jak wyglądały Twoje początki w zawodzie i dlaczego akurat temat programowania był dla Ciebie interesujący?

Z wykształcenia jestem finansistą, ale pierwsze przygody z programowaniem zacząłem bardzo wcześnie, bo już w “turbo pascal” na moim niesamowitym Pentium 200MMX, który dostałem na komunię. 

Jak jesteś dzieckiem to jarasz się kalkulatorem, a nagle w domu pojawia się komputer, który potrafi znacznie więcej. Nawet nie masz pojęcia jak to działa, ale chcesz to poznać - wydaje mi się, że wtedy zacząłem mocno eksperymentować z rozkładaniem i składaniem komputera, wymienianiem części (miałem starszego brata, który głównie przewodził w tych operacjach). 

Później wraz ze wzrostem liczby komputerów na osiedlu, pojawiały się pierwsze “branże”. Tworzenie sieci osiedlowych, aby grać w gry multiplayer, kafejki internetowe, pierwsze nagrywarki i powszechne piractwo. Wspaniały czas, dużo radości, wszyscy żyli wtedy komputerami. 

Kod turbo pascala przemycało się na dyskietkach ze szkoły, czy od starszych znajomych, którzy mieli jakieś początki programowania w szkołach i wyszli już z fazy logo komeniusza. 

Oczywiście, nie było to prawdziwe “programowanie” a raczej bawienie się w “programowanie”, które dawało dużo zabawy, bo z umysłem 11-latka raczej jest mała szansa, że można coś sensownego zrobić - bardziej zabawy w kierunku tworzenia pranków typu odpalasz aplikację a ona udaje, że formatuje dysk. 

W czasach bez internetu, ciężko było o jakieś sensowne źródła, żeby to miało ręce i nogi, dlatego traktowałem to raczej w formie zabawy. Tak zacząłem w późniejszym czasie robić strony dla szkoły w której się uczyłem, proste boty pod gadu-gadu czy inne phpowe skrypty. I tak powoli wnikałem w temat. 

Jak już udało się uzyskać pierwsze łącze internetowe, poznawało się technologie internetu - dużo czasu spędzonego na IRC, dało początki w eksperymentowaniu z linuksami, sieciami i jakiemuś podejściu do innych języków programowania. Nadal powiedziałbym, że to było bardziej zbieranie różnych kodów i próbowanie wydedukowania z nich czegokolwiek ale już z lekką konsultacją ze strony społeczności IRCowej niż świadome działanie. 

Po tych czasach miałem sporą przerwę z IT, poszedłem na studia - finansowe, później praca w sektorze bankowym - gdzie miałem możliwość stworzenia już pierwszego systemu “produkcyjnego” - takie mini CRM. 

Tam zmieniła mi się optyka związana z programowaniem i podjąłem decyzje o przebranżowieniu. W momencie, kiedy udało się znaleźć pracę jako programista php, zacząłem poważniej o tym myśleć. Ta przygoda trwała bardzo krótko, zostałem finalnie przy JavaScript i do dziś jestem z nim na co dzień. 

Także, zainteresowanie programowaniem to raczej ciekawość świata IT ;-)

Skąd najlepiej czerpać wiedzę jako Chief Product Officer: zarówno dla tych osób, które zaczynaja swoja przygode w tej branży, jak i tych już nieco bardziej zaawansowanych?

Z rozmów, interakcji, konkurencji, obserwacji rynku. Generalnie wynikiem każdej myśli, “a może by tak” czy “a dlaczego to aktualnie tak wygląda” często powstaje produkt. Nawet nie zdajemy sobie z tego sprawy, ale obserwując otoczenie bardzo łatwo jest znaleźć niszę na rynku czy zaobserwować pewne “mody”, które się pojawiają. Zarówno, jeżeli to dotyczy rynku usług czy sprzedaży produktów. 

Myślę, że tutaj nie ma poziomu zaawansowania. Bardziej ująłbym to tym jak bardzo ktoś “wsiąkł” w konkretną dziedzinę, czy jest ekspertem tej dziedziny. 

Inaczej na samochód spojrzy inżynier, projektujący je od 20 lat, a inaczej, ktoś, kto np. tankuje pierwszy raz i mu przeszkadza jakiś detal. Zarówno pierwsza jak i druga osoba, mogą mieć taki sam wpływ na rozwój tego pojazdu, bo mamy kilka punktów widzenia. 

Oczywiście, ta mniej doświadczona może wpadać na pomysły, które już od 20 lat są znane, ale nie opłaca się ich implementować z jakieś przyczyny, czy to aerodynamika, czy po prostu skomplikowany proces produkcji. 

Często jednak też jest tak, że ktoś ma na tyle świeże spojrzenie na dany temat, że może oświecić te osoby, które są od kilkunastu lat w branży. 

Wydaje mi się, że to dobry obraz tego, jak funkcjonuje rozwój produktu. Także moje metodologie, to “słuchać”, “rozmawiać”, “obserwować”. Wszystko, z wszystkimi i o wszystkich😉

W jaki sposób szukałeś swojej pierwszej pracy? 

Kupiłem gazetę, zadzwoniłem, wydrukowałem CV wraz z listem motywacyjnym i je zaniosłem. Później odbyłem rozmowę i już - chyba tak jak każdy dzisiaj z pominięciem 3-pierwszych kroków, internet dużo ułatwił w tej kwestii.

Moją pierwszą pracą była obsługa klienta w firmie kurierskiej, później byłem dyspozytorem. Później znów obsługa klienta na słuchawce, później helpdesk, specjalista consumer finance. Dzisiaj programuje i współtworzę PushPushGo.

Dlaczego zdecydowałeś się na stworzenie własnego produktu i czy PushPushGo było pierwszą próbą?

Zawsze chciałem mieć jakiś biznes, pomysłów było mnóstwo, niekoniecznie związanych z IT. Były pomysły na restauracje, sklepy, usługi, później różne rozwiązania od strony technologicznej. Wkręciliśmy się w świat startupów, imprezy ala startup stage ale to wymagało mocniejszej wiedzy IT, więc nie było nigdy szansy, aby coś zrobić. Moje otoczenie było mocno nietechniczne.

Minął jakiś czas, spróbowaliśmy sił i była pierwsza próba utworzenia usługi do rezerwacji wizyt. Mieliśmy już nawet ledwo działający prototyp - ale odpadliśmy na ostatnich etapach inwestycji (akcelerator studencki). 

Potem już było PushPushGo - pojawiła się nowa technologia, która naszym zdaniem miała duży potencjał, pojawiały się już pierwsze implementacje na świecie, więc spróbowaliśmy swoich sił.

Praca i Rozwój

Jakie Twoim zdaniem kluczowe KPI powinny być mierzone w pracy Product Developera? Jak mierzysz efekty swojej pracy, aby uzyskać informacje, że jest ona efektywna zarówno dla Ciebie jaki i dla firmy?

Moimi KPI są KPI firmowe: jest sprzedaż - jest dobrze, jest churn - jest źle. Produkt odzwierciedla sytuację całej firmy, bo tworzymy i sprzedajemy a później obsługujemy właśnie ten produkt. 

Czy możesz opisać w liczbach skalę działania w jakiej na co dzień się obracasz? 

W skrócie, to: 600 mln wysłanych notyfikacji, blisko 100 mln subskrybentów na całym świecie,  15 mln scenariuszy automatycznych, 20 tys. kampanii, do 20 tys. req/s i czasami kilka deploymentów dziennie. 

To są nasze produktowe statystyki, tym żyjemy my jako cała firma i dbamy o to, aby wszystko działało i powoli rosło. Takie są liczby ogólne. 

Dziennie generujemy kilka, czasem kilkanaście commitów, które wylatują na produkcję. 

A personalnie to dużo rozmów głosowych na slacku / discordzie tzw. bieżączki, kilka interakcji na discourse, kilka e-maili, zero telefonów, dwa koty😸😸.

Jak rozwijasz strategię produktu/ roadmap?

Nie robię tego samodzielnie, robimy to całym zespołem. W proces jest zarówno zaangażowany programista, designer, product manager, sales, jak i dział customer support. 

To nie jest tak, że siedzi jedna osoba i wymyśla. Może kiedyś, bo jakoś trzeba było zacząć i nadać pierwotną formę. Dzisiaj pamiętajmy, że to już praca zespołowa - ktoś zbierze feedback od klienta, ktoś inny zwróci uwagę na zły UX. Tak naprawdę produkt rozwijają wszyscy i wszyscy ustalają roadmap. Po mojej stronie jest raczej nadanie temu formy i utrzymanie w ryzach, abyśmy za daleko nie odpłynęli z pewnymi zmianami. 

Klienci również mają i lepsze i gorsze pomysły czy obserwacje. Jedne są super i bardzo globalne, drugie są po prostu lokalne i musimy je dopieścić albo odrzucić. Musimy dobrze to sortować, ubierać buty klienta i weryfikować czy to co zostało zaproponowane ma sens, czy warto, co to zmieni, jak wpłynie na resztę, jak bardzo wzrośnie nam obciążenie, czy bardzo zwiększy koszta operacyjne, czy wpisuje się w naszą główną strategię, etc.

Można powiedzieć, że w całym procesie rozwoju produktu są równolegle dwie ścieżki:

• Jedna to ulepszenie obecnego produktu - tutaj jest mocna inicjatywa oddolna, konsultowana odgórnie.

• Druga to szukanie nowych szans - inicjatywa zaczyna się odgórnie i schodzi do dołu, członków zespołu, klienta.

Z jakich narzędzi korzystasz w swojej pracy?

Jeżeli chodzi o hardware, to jest to oczywiście laptop - bez fajerwerków ;-). 

A narzędzia softwarowe to głównie po prostu przeglądarka internetowa w której dziś jest wszystko i po prostu programistyczne IDE. 

Wszystko co potrzebujemy do zbudowania produktu, znajduje się w umysłach całego zespołu i danych, które trzeba zebrać i przeanalizować. Później tylko ustalić i działać. Reszta to już żmudna praca projektowa gdzie od czasu do czasu pojawi się jakiś ciekawszy problem.

Co oceniasz jako największy sukces w dotychczasowej pracy/ jakie było największe wyzwanie i jak udało Ci się z nim poradzić?

Nasz sukces to zdecydowanie cały zespół, to, że żyjemy jako firma, wszyscy mają pracę i mają się dobrze. Klienci nas lubią, chętnie z nami współpracują.

A przy tym wszystkim jesteśmy po prostu sobą.

Największym dotychczasowym wyzwaniem było to, żeby nie zrezygnować z tego wszystkiego. Bywały lepsze i gorsze momenty w życiu firmy, w naszym życiu. Myślę, że przy takich wyzwaniach i ciężkich momentach warto poczekać z jakąkolwiek decyzją i po prostu się z tym mocno przespać i to nie jedną noc. To jest całkowicie normalne, że przy takim tempie pracy, zmianach, rozwoju, człowiek chce po prostu - uciec, w te magiczne Bieszczady. ;-)

O technicznych wyzwaniach nie wspominam, bo tego jest codziennie dużo, okres skalowania to była istna męka, bardzo dużo musieliśmy się uczyć i w bardzo szybkim tempie jednocześnie implementując zmiany, ale jak widać daliśmy radę. Celowo mówię daliśmy, bo to nie było wyzwanie, z którym na pewno samodzielnie bym sobie poradził - to zasługa całego zespołu.

Co na co dzień czytasz, aby rozwijać swoje umiejętności odnośnie pracy?

Mało czytam, raczej słucham, czy to podcasty czy audiobooki, jedno i drugie jest bardziej przyswajalną formą przyjęcia przeze mnie wiedzy, niż suchy tekst. On zawsze był ciężki. 

Generalnie staram się słuchać wszystkiego co dotyka technologii, życia, społeczności, nie kierunkuje się na “konkretne branże”. Dalej jak wcześniej wspomniałem kierując się jak najszerszym polem widzenia tak, aby mieć jak najszerszy obraz rzeczywistości, problemów, meta problemów i opinii osób, które są ekspertami, amatorami lub hobbystami. 

Raczej jestem taki “zajawkowy”. Zobaczę coś fajnego u kogoś, porozmawiam o czyimś hobby i wsiąknę. Za tydzień, dwa, dowiem się ile mogę - ile mi wystarczy i idę dalej. 

Także jeden tydzień będą dowiadywał się o budowie silnika wankla, drugi sprawdzał co porabiają krótkofalowcy na świecie, następnie analizował różnice w finansach społecznych Azji i Europy, a później sprawdzę jak się piecze chleb.

Panuje powszechne przeświadczenie, że skille techniczne są ważniejsze od umiejętności miękkich w działach IT. Które z nich uważasz, za ważniejsze w swojej pracy? Określiłbyś siebie jako osobę stricte techniczną czy może wręcz przeciwnie?

Kilka osób mnie określiło kiedyś jako “T-shape” person. I raczej się z tym identyfikuje. 

Jestem trochę techniczny, ale na pewno nie jestem inżynierem. Lubię rozmawiać, lubię pracę koncepcyjną, pracę zespołową, lubię wymyślać nowe rzeczy, pomagać innym i wyobrażać sobie jak będzie rynek wyglądał za X lat, jakie będą potrzeby, jakie będą zachowania konsumenckie. 

Doświadczenia zawodowe jednak w większej części mojego życia były związane z obsługą klienta, sprzedażą, usprawnianiem procesów, finansami. W tym mam największe doświadczenie. A ostatnie 4 lata stricte techniczne. Dzisiaj wydaje mi się, że znów zaczynam wracać do tych pierwszych. 

Jakie są Twoje hacki produktywności?

Nie mam takich, męczę się jak inni, jak przegnę to odsypiam. 

Jestem zdeterminowany, kiedy coś robię, bardzo pomaga mi zakończyć “pewien” etap jaki mam zaplanowany, zanim pójdę “odpocząć”. Brzmi jak błędne koło, ale nie umiem odpocząć jak czegoś nie domknę, myśli ciągle błądzą po jakimś problemie. 

Jeżeli chodzi o produktywność to staram się robić jeden temat w jednym czasie i nie zmieniać za często kontekstu w jakim pracuje. Bardzo podnosi to jakość pracy.

Przy łóżku mam notes, jak idę spać i na coś wpadnę to notuje i szybko zapominam. Niby proste ale uratowało to dużo potencjalnie nieprzespanych nocy.

Jakie widzisz trendy obecne oraz na przyszłość w programowaniu?

Ciężko przewidywać przyszłość, na pewno popularność będą zdobywały usługi takie jak co-pilot, które będą ułatwiały klepanie kodu. Na pewno rynek otworzy się mocniej na juniorów, bo jest bardzo duże zapotrzebowanie. Po tym jako społeczność programistyczna pewnie wyniesiemy wyższe abstrakcje, aby ułatwić wejście na ten rynek i usprawnić dostarczanie kodu. 

Duże zapotrzebowanie jest też na usługi “no-code”, dla osób, które są digital native, chcą robić projekty a niekoniecznie posiadają “coding skills”. Myślę, że to naturalnie przerodzi się właśnie w te “wyższe abstrakcje”, które będą ułatwiały wejście w rynek technologii i tworzenia nowych biznesów.

Co poleciłbyś osobom, które dopiero zaczynają swoją ścieżkę kariery w tej dziedzinie?

Jeżeli chodzi o programowanie to dużo cierpliwości, to jest trudna działka. 

Jeżeli chodzi o budowanie produktu, to bycie otwartym na innych.