Piotr Sidoruk - Jakie dane analizować w startupie i małej firmie?

Cześć, z tej strony Łukasz Kobyliński. Witam Was w kolejnym odcinku podcastu „Stacja IT”. Dzisiaj porozmawiamy o analizie danych firmowych. Zastanowimy się, jakie dane analizować, w jakim celu, jak i kto może to robić, jakie kompetencje są do tego potrzebne. Skupimy się głównie na mniejszych firmach czy startupach. Dzisiaj porozmawiamy z Piotrem Sidorukiem.

Cześć, Piotr!

Cześć, Łukasz! Bardzo dziękuję za zaproszenie.

Powiedz kilka słów o sobie: czym się zajmujesz i co łączy cię z analizą danych?

Odpowiedzenie na pytanie, czym właściwie się zajmuję, czasami przysparza mi sporo trudności. Ujmując to jednym zdaniem, zajmuję się danymi. Staram się pomagać firmom, głównie startupom, w zarabianiu większej ilości pieniędzy poprzez odpowiednie wykorzystanie danych. Analityką czy też tematami związanymi z IT w różnych rolach zajmuję się od 10 lat, od kilku lat z naciskiem na startupy, a od ponad trzech lat współpracuję z amerykańskim startupem Playbook. Jako pierwszy zająłem się tam tematem danych jako takim. Moja rola była bardzo szeroka, tak jak zwykle bywa w startupach, w których zespoły są nieduże – wszyscy robią wszystko, żeby dowieźć cele. Moja rola polegała na rozmaitych rzeczach, czasami bardzo dalekich od analityki. Głównie skupiała się na tematach związanych z budową analityki zupełnie od zera, inżynierią danych, ich obróbką – wszystko po to, żeby potem je analizować, budować cały system business intelligence, czyli wizualizacja danych, budowanie wokół nich narracji, współpraca z inwestorami, przekonywanie ich do zainwestowania w startup. Kiedy masz przytłaczającą ilość danych, musisz mądrze i selektywnie do tego podejść. Zbudować spójną historię, która opowie, jak dany startup się rozwija, dlaczego warto się nim zainteresować, jakie ma perspektywy na przyszłość.

Tematy, które nie są bezpośrednio związane z analityką, a które takie osoby też często muszą w tym początkowym etapie robić, są rozmaite. Pamiętam, że zajmowałem się zarówno tematami związanymi z marketingiem, np. testowaliśmy różne warianty maili, aby zwiększyć zaangażowanie użytkowników, jak i tematami, którymi w większej firmie zająłby się backendowiec albo frontendowiec. Zatem osoba zajmująca się w startupie danymi ma bardzo dużo obowiązków i często jest tą, która wie najwięcej na temat danych firmy, jest w stanie odpowiedzieć na bardzo wiele pytań odnośnie jej perspektyw.

Jaką drogę musiałeś przejść, żeby zajmować się danymi? Czy twój background był bardziej informatyczny, statystyczny czy biznesowy??

Moja ścieżka była dosyć niestandardowa, podobnie jak niestandardowa jest rola osoby, która zajmuje się tak szerokim zakresem zadań. Z jednej strony studiowałem metody ilościowe na SGH, które dosyć dobrze wpisują w tę rolę, z drugiej – psychologię na UW, co jest dosyć dużym odchyleniem od normy w tej branży. Pracę w branży IT zacząłem ponad 10 lat temu. Te moje role dosyć mocno zmieniały się w czasie, aczkolwiek nieustannie kierowałem się w stronę analizy danych i takiego bardziej praktycznego jej wykonywania, czyli zawsze były na styku z biznesem. Zrealizowałem już kilkadziesiąt różnych projektów analitycznych, skupionych zarówno na inżynierii danych, ich analizie, jak i bardziej zaawansowanych tematach związanych z data science, czyli budową silników rekomendujących, modeli predykcyjnych, startupów. Robiłem kiedyś silnik odpowiadający za ułożenie diety. Gdybyś chciał zautomatyzować pracę dietetyka, to musiałbyś z jednej strony zbudować dosyć kompleksową bazę danych zawierających informacje na temat różnych składników jedzenia, potraw, przepisów, jak i skupić się na tej części data science, czyli na silniku optymalizującym dietę, silniku planującym dietę i silniku rekomendującym potrawy, które jesteś skłonny jeść, i wykluczającym te, których nie jesteś w stanie jeść. Silnik optymalizujący też jest w stanie zapewnić odpowiednią ilość kalorii i mikroskładników.

Moje role były bardzo rozległe. Tak naprawdę nigdy przez dłuższy czas nie skupiałem się na jednej wąskiej dziedzinie. Zawsze interesowałem się poznawaniem jak największej liczby obszarów analitycznych oraz tym, jak to działa od strony biznesu, co dokładnie na tym firma zyskuje, czy naprawdę musimy spędzać zbyt wiele tyle czasu na rozwoju produktu, czy może wartością dla klienta będzie zrobienie minimalnego produktu, który rozwiąże większość problemów. Daje to trochę pogląd na to, jakie doświadczenie miałem.

Branże również były różne. Poczynając od branży finansowej, bankowości, firm pożyczkowych poprzez firmy farmaceutyczne, w których robiłem chociażby system automatycznego generowania treści pomagający technical writerom przygotowywać w sposób zautomatyzowany dokumentację medyczną, branżę bookmacherską, w której analizowałem wyniki mistrzostw świata czy branżę krypto. Doświadczenie w zupełnie różnych branżach, zobaczenie, jak różne podejścia analityczne mogą rozwiązywać pewne problemy, dało mi bardzo duży background do zakładania nowych firm, szukania rozwiązań niestandardowych w startupach. Dzięki temu zacząłem szukać swoich własnych rozwiązań i budować rzeczy zupełnie od podstaw.

Na jakie dane warto na początku zwrócić uwagę szczególnie w mniejszych firmach?

Na początku, kiedy zaczyna się dopiero przygodę z tego typu tematami, to może się wydawać przytłaczające, ponieważ te możliwości wydają się nieograniczone. W dzisiejszych czasach firmy zbierają bardzo dużo danych. Wyróżniłbym tutaj dwa główne obszary. Przede wszystkim są to dane finansowe, które w twardy sposób pokazują, ile zarabiamy, czy nasze zarobki są powtarzalne, skalowalne. Kluczowym wskaźnikiem, który przychodzi mi do głowy, to przede wszystkim LTV, czyli lifetime value – wartość użytkownika czy też klienta w czasie, koszt jego pozyskania, badanie stosunku kosztu pozyskania takiego użytkownika do tego, ile możemy średnio na nim zarobić. Inną kwestią jest retencja, czyli czy jesteśmy w stanie utrzymać dane przychody, co świadczy o stabilności biznesu.

I trochę też pokrewne tematy, czyli jeśli mamy zarobki zbudowane na modelu subskrypcyjnym, to warto przeanalizować, jakiego typu subskrypcje budują nam przychód. Wiele startupów opierających się na tym modelu ma wyzwania w postaci chociażby zadbania o to, żeby zoptymalizować ten model, czyli dobrze dopasować cenę produktu, żeby jak najwięcej osób chciało z tego korzystać i zostawało jak najdłużej w aplikacji. Czyli jak zrobić, żeby subskrybenci wybrali subskrypcję roczną, nie mając jeszcze styczności z naszym produktem. To kluczowe wyzwania, które przychodzą mi do głowy i w których sporo doświadczenia już mam. Wydawałoby się, że czasami rozwiązania tych problemów są błahe, a wpływ finansowy na to – ogromny. Czasami znaczenie mają proste rzeczy jak zmiana układu strony internetowej, sposobu, w jaki komunikujemy, ile kosztuje subskrypcja roczna.

Prosty przykład, który miał ogromny wpływ na rzeczy, w których pomagałem: w jaki sposób przedstawisz, ile kosztuje subskrypcja miesięczna w kontekście rocznej? Jeśli masz przykładowo cenę roczną, którą porównujesz z miesięczną, wiele osób intuicyjnie stwierdzi: „O, nie, to jest droższe, tego nie wezmę”. Ale firmy najczęściej dają zniżkę na subskrypcję roczną, w związku z czym ten miesiąc wychodzi dużo taniej. Czasami zatem tak prosta zmiana jak zmiana prezentacji ceny – zamiast pokazywania pełnej ceny rocznej, pokazywania, ile ona kosztuje cały miesiąc – potrafi odwrócić całkowicie finanse firmy. I wiele firm nie zdaje sobie z tego sprawy, a to można w prosty sposób zbadać. Są bardzo proste narzędzia do A/B testów, które nie wymagają dużo pracy przy ich wdrażaniu, a dowodzą, że proste zmiany mogą dawać bardzo duże efekty.

Abstrahując od modelu subskrypcyjnego, to tutaj, jak rozumiem, podstawą jest zmierzenie tego, ile przychodu uzyskujemy od konkretnego klienta, ile kosztuje nas jego pozyskanie. Czy możesz podać jakieś proste sposoby liczenia tego? Przychód jest pewnie czymś oczywistym, bo trzeba zliczyć wartości faktur, natomiast czy możesz podać jakieś przykłady odnośnie kosztów pozyskania, jak to można robić, żeby unaocznić, jakie są możliwości?

To zależy od tego, jaki prowadzimy biznes, co dokładnie sprzedajemy i w jaki sposób. Mogę tu opowiedzieć na przykładzie firmy, z którą współpracuję od trzech lat. Jest to amerykański startup z branży fitness. My zajmujemy się aplikacją, która pozwala trenerom na monetyzację ich popularności. To są często trenerzy gwiazd, którzy oferują te same programy co gwiazdom, np. mamy takiego trenera, który trenował Bena Afflecka, zanim zagrał Batmana. On ma program treningowy zachęcający do trenowania przez osiem tygodni i robienia tych samych ćwiczeń co Batman. Problem w jego przypadku i w przypadku wielu innych trenerów polega na tym, że oni takich treningów jeden na jeden są w stanie zrobić bardzo ograniczoną ilość. Nawet nie wiadomo jak wysoko wycenią swoje treningi. Nie są w stanie tego wyskalować. Za pomocą naszej aplikacji są w stanie to zrobić, a jako że mają bardzo duże grono followerów w mediach społecznościowych, to nagle z modelu, w którym do tej pory trenowali 50 osób, są w stanie przejść do takiego, w którym trenują 20 tys. osób. W ich przypadku jest tak, że to oni przyprowadzają nam użytkowników, bo już mają całą bazę swoich fanów. Więc jak określić w takim przypadku, ile kosztuje pozyskanie użytkownika? Możemy zastanowić się: ile kosztuje nas pozyskanie trenera. Rozbijmy sobie go na liczbę nowych użytkowników, którą pozyskaliśmy. W ten bardzo uproszczony sposób ocenimy, że nasz koszt pozyskania użytkownika to koszt pozyskania trenera podzielony przez liczbę użytkowników, których on przyprowadzi. To zależy też od firmy. Możemy policzyć sobie, ile sumarycznie kosztują kampanie w mediach społecznościowych, dzieląc to przez liczbę użytkowników, których jesteśmy w stanie sobie przypisać do tych inicjatyw.

Natomiast oprócz danych finansowych analizy warty jest też obszar związany z zaangażowaniem użytkowników. W zależności od tego, jaki mamy produkt, co dokładnie oferujemy, możemy to sobie w różny sposób określać i śledzić. Dla branży fitness kluczowymi kwestiami, które warto śledzić, jest ilość osób, które rozpoczynają ćwiczenia, i ilość, która je kończy. Jeśli założymy, że fundamentalną korzyścią z takiej aplikacji jest trening, to badajmy te dane behawioralne, starajmy się przeanalizować, jak te realne dane dotyczące zaangażowania użytkowników mają się do danych finansowych, ponieważ długofalowo można założyć, że będą one rzutować również na retencję finansową, lecz po prostu będzie to odwleczone w czasie. Więc jeśli chcemy zwiększyć nasze przychody, musimy inwestować w zaangażowanie użytkowników. Musimy też rozumieć wpływ naszych zmian na aplikacje, które robimy. Wypuszczając nową funkcjonalność, powinniśmy zbadać, czy czas i wysiłek, który poświęcamy na nowe funkcjonalności, w ogóle się opłaca, czy ktoś w ogóle ich używa. Myślę, że to są dwa główne obszary wspólne dla większości startupów.

Zupełnie oddzielnym tematem jest jeszcze wykorzystanie danych stanowiących nieodłączną część produktu, jak chociażby w przypadku Netfliksa, którego fundamentalny model biznesowy opiera się na tym, że jest świetny silnik rekomendujący, który cały czas zapewnia, że ta retencja użytkownika jest na wysokim poziomie i że ten użytkownik rzeczywiście dostaje treści, których jest skłonny używać. Podobnie jest z Airbnb, gdzie nie tylko chodzi o silnik rekomendujący, ale też o poziom cen. Było tak też z przykładami, które ja podawałem, chociażby produkt polegający na ucyfrowieniu roli dietetyka. Myślę, że to takie dodatkowe pole, które nie dotyczy wszystkich startupów, ale może być kluczowe. I wtedy trochę w innym wymiarze patrzymy na to, jak te dane są wykorzystywane i kto powinien się nimi zajmować.

Odchodząc od modelu subskrypcyjnego czy od sytuacji, w której mamy użytkowników korzystających z naszej aplikacji, to można przełożyć to na kwestie tego, czy klienci wracają, czy drugi raz kupują od nas usługę. Jeśli nie jesteśmy startupem, który ma usługę online, gdzie to zaangażowanie mierzymy korzystaniem z aplikacji czy z innych rodzajów usług, to w przypadku bardziej klasycznego biznesu byłby to powrót klienta, powtórny zakup czy też – jak w przypadku naszej firmy szkoleniowo-konsultacyjnej – poziom zadowolenia z usług i osiągnięcia zamierzonych efektów.

Myślę, że analiza kohortowa może mieć różne wymiary. Jako kohortę rozumiemy grupę użytkowników czy klientów, którzy dołączyli do naszego produktu w określonym czasie, czy to będzie ten sam tydzień, miesiąc, kwartał. I to już od nas zależy, co dokładnie będziemy analizować. W klasycznym podejściu w modelu subskrypcyjnym analizujemy ciągłość trwania danej subskrypcji. W przypadku danych dotyczących zaangażowania eventem, który będziemy uwzględniać w analizie kohortowej, będzie zaangażowanie użytkownika definiowane przez nas w zależności od tego, co jest kluczową funkcjonalnością produktu. A w modelu, który ty podajesz, niesubskrypcyjnym, to będzie chociażby ten event stanowiący zaangażowanie, czyli kolejny zakup. Czyli powrót po jakimś czasie, ale w każdej z tych rzeczy tak naprawdę opieramy się na analizie kohortowej, patrzymy, jak wygląda ta retencja – na to też patrzą w wielu przypadkach inwestorzy, kiedy podejmują decyzję, czy w twoją firmę zainwestować, czy nie. Jest to takie absolutne abecadło, jeśli chodzi o monitorowanie tego, czy firma się rozwija, czy robi postępy.

Kto w ogóle może skorzystać z tych danych i ich interpretacji? Dla kogo one tak naprawdę są?

Myślę, że większość osób w firmie oraz wszystkie osoby na zewnątrz niej, którym chcemy takie dane pokazać. Różnica będzie taka, że te osoby z różnych powodów i w różny sposób będą te dane analizować i interpretować. Natomiast wewnątrz firmy wiele startupów, większych firm też, jak najbardziej zainwestowałoby w odpowiednie narzędzia do analityki produktu, żeby każdy mógł sobie samoobsługowo z takich danych korzystać, czy to będzie Mixpanel, Amplitude czy CleverTap – jest cała masa narzędzi, które można zaimplementować i te dane jak najszerzej udostępniać. Jeśli chodzi o inwestorów, to może niekoniecznie chcemy dawać im dostęp do wewnętrznych informacji i bardzo szczegółowych analiz dostępnych w wewnętrznych narzędziach, ale na pewno chcielibyśmy budować narrację tłumacząca kontekst. W takim przypadku inwestorowi lepiej nie jest moim zdaniem udostępniać dane bez kontekstu. Trzeba przede wszystkim popatrzeć na to, kim jest taki inwestor, z jakim backgroundem do nas przychodzi, na jakie rzeczy będzie zwracał uwagę, i dopasować tę narrację do jego potrzeb. Jeśli te nasze dane pokazują jakąś dużą, niestandardową zmienność, to powinniśmy zawsze to wytłumaczyć. Jeśli mamy nagłe wzrosty, to warto podać kontekst.

W przypadku ekonomii twórców, influencerów mających setki tysięcy followersów, którzy przyprowadzą nagle taką kohortę, która będzie niestandardowo wysoko zaangażowana, to nie znaczy wcale, że my nagle wprowadziliśmy rewolucyjną zmianę w produkcie, po prostu dołączyliśmy zupełnie inny segment użytkowników. I warto jest takie rzeczy wytłumaczyć, ponieważ wielu inwestorów, patrząc na analizę kohortową, z uproszczenia założy, że skoro wskaźniki retencji rosną, to znaczy, że co do zasady produkt jest coraz lepszy, ponieważ coraz to nowe grupy użytkowników przychodzą i coraz mniejsza ich liczba odpada przez to, że produkt nie spełnia ich oczekiwań. Myślę, że to jest jedna z kluczowych kwestii, od których inwestorzy zaczynają analizę tego typu danych.

Natomiast o ile mamy wzrosty, mogą być też spadki. I takich spadków bez komentarza lepiej nie zostawiać, zawsze lepiej jest to wyjaśnić. Spadki nie muszą wynikać z tego, że mieliśmy jakiegoś wielkiego buga, który sprawił, że aplikacja nam nie działała przez kilka dni i ludzie odeszli. Bardzo często to wynika z naturalnej sezonowości. Jako przykład w branży fitness mogę podać końcówkę roku. Najczęściej w okresie świąt Bożego Narodzenia spada zaangażowanie użytkowników, bo wszyscy jadą do rodzin, mniej trenują. Natomiast zaraz potem z okazji Nowego Roku są postanowienia noworoczne. Mamy zatem niestandardowy spadek i potem bardzo dynamiczny wzrost. W branży fitness jest to zazwyczaj najwyższy wzrost w skali całego roku. Ludzie zaczynają te swoje postanowienia noworoczne, są zdecydowanie bardziej zaangażowani i skłonni do zakupów niż kiedykolwiek w trakcie roku.

Czy są jakieś inne wskaźniki, na które inwestorzy najczęściej zwracają uwagę? Jakie dane są brane pod uwagę?

Wszystko zależy od sytuacji na rynku. Dwa lata temu w branży fitness inwestorzy bardzo chętnie inwestowali w tego typu startupy, dawali wysokie wyceny. Znam firmy, które inwestowały w kilka podobnych startupów naraz, licząc na to, że którykolwiek z nich wypali w czasie pandemii, kiedy to siłownie były pozamykane, a ludzie ćwiczyli w domu. Wówczas stopy procentowe były niskie, więc zwiększyła się chęć do inwestycji, również tych ryzykownych. Natomiast po dwóch latach sytuacja się diametralnie zmieniła. Większość startupów powinna zwracać uwagę na skłonność do generowania realnych przychodów, czyli czy nasz model biznesowy jest w stanie na siebie zarabiać w niedługiej perspektywie, co nie było takie oczywiste jeszcze rok czy dwa lata temu, kiedy to wielu inwestorów liczyło na to, że startupy będą miały dużą perspektywę wzrostu – one nie musiały na siebie zarabiać w najbliższym czasie, ale miały szybko rosnąć. Natomiast obecnie ta sytuacja wygląda zgoła odmiennie, być może nie dotyczy to niektórych branż, jak chociażby tej związanej ze sztuczną inteligencją, która teraz jest bardzo mocno finansowana, czy niektórymi startupami związanymi z wojskowością. Poza tym myślę, że nastroje rynkowe bardzo mocno się zmieniły i trzeba kłaść nacisk na coś zupełnie innego, kiedy próbuje się przekonać inwestora do wejścia w nasz startup. I te wyceny też będą średnio niższe niż jakiś czas temu.

Natomiast jeśli chodzi o metryki, ciekawym przykładem, który mogę przytoczyć, jest to, w jaki sposób inwestorzy interpretują wskaźniki LTV i CAC, czyli koszty pozyskania użytkownika. Oni porównują do siebie ten stosunek na przestrzeni czasu. Czyli jak na przestrzeni czasu, kiedy nasza firma się rozwijała, prezentował się stosunek wartości, jaką przynosi nam klient, do kosztów, które musimy ponieść, żeby go pozyskać. Pytanie brzmi: ile ten wskaźnik tak właściwie powinien wynosić, żeby było dobrze? Wiele osób stwierdzi: im wyżej, tym lepiej. Jak będzie dwa do jednego, to zarabiamy dwa razy tyle, ile nas kosztował użytkownik. Jak będzie cztery razy tyle, to super. Jak będzie 10 razy tyle, to wspaniale. Ale niekoniecznie tak jest. Kiedy inwestorzy zobaczą, że przez dłuższy czas utrzymujemy na bardzo wysokim poziomie stosunek przychodu do kosztów, to mogą wyjść z założenia, że „nie podejmujecie ryzykowniejszych decyzji i nie pozyskujecie klientów, którzy są po prostu drożsi”, „przecież jesteście startupem, macie rosnąć”, „nie rośniecie, bo jesteście zbyt zachowawczy”.

Czym innym jest, kiedy mamy ten niestandardowy stosunek LTV do CAC przez miesiąc, dwa pod rząd, a czym innym – przez sześć miesięcy pod rząd. Gdybym miał tak uśrednić i powiedzieć, jaki mniej więcej stosunek jest dobry, to trzy do jednego. Kiedy przez dłuższy czas notujemy ten wyższy poziom niż trzy do jednego, to powinniśmy raczej skupić się na inicjatywach, które mają na celu pozyskanie droższych użytkowników w celu zwiększenia bazy firmy i doprowadzenia do szybkiego wzrostu. Wiadomo, że ten szybki wzrost będzie miał prawdopodobnie też szereg swoich pozytywnych możliwości dla firmy. Czyli będziemy mogli zrobić cross-selling, nowy typ produktów dedykujemy dla droższych klientów, zmienimy strategię cenową. Chodzi o to, żeby ten startup jak najszybciej się rozwijał, jak najszybciej zwiększał bazę swoich użytkowników, a niekoniecznie maksymalizował ten stosunek przychodu do kosztu pozyskania użytkownika.

Głównie chodzi o tempo wzrostu, żeby nie być zbyt konserwatywnym i zapewnić sobie w przyszłości odpowiednią bazę klientów.

Zazwyczaj nie jesteśmy jedyni na rynku, jest konkurencja, która może podejmować bardziej ryzykowne decyzje niż my, bo mogą sobie na to pozwolić. Tu jest więc kwestia tego, że możemy sobie na coś pozwolić, ale tego nie robimy.

Powiedziałeś też o kwestii odpowiedniej interpretacji tych danych i tego, jaki sposób je przedstawiamy inwestorom. Czy więcej czasu zajmuje ci samo zbieranie danych, przygotowanie techniczne i przeprowadzenie analiz, czy raczej zdefiniowanie bądź zrozumienie tych danych, zderzenie tego z odpowiednimi osobami w firmie lub działami i na tej podstawie przedstawienie właściwej interpretacji danych? Czy traktujesz to równorzędnie, czy jednak te aspekty techniczne są trudniejsze?

To mocno zależy od konkretnej sytuacji. W kontekście pracy w niedużych organizacjach jest szereg narzędzi, które są w stanie pomóc w tym, żeby za dużo czasu jednak nie poświęcać na te stricte techniczne aspekty związane z inżynierią danych. Rozwijanych jest coraz więcej narzędzi automatyzujących pracę inżyniera danych. One oczywiście trochę kosztują, ale w przypadku gdy jesteśmy w startupie, decyzje podejmuje się dynamicznie. Czasami z dnia na dzień zmieniamy całkowicie strategię odnośnie tego, czy wykorzystujemy to źródło danych czy tamto, do których normalnie musielibyśmy zatrudnić jednego dedykowanego inżyniera, żeby zbudował pod to infrastrukturę i utrzymywał te źródła. Więc w sytuacji, w której korzystamy z narzędzia, jesteśmy w stanie usunąć kilka data pipeline’ów, które są automatycznie generowane, i nie mamy problemu, co zrobić z tym człowiekiem, którego dopiero co zatrudniliśmy. Wychodzę z takiego założenia, że im więcej jesteśmy w stanie zautomatyzować za pomocą narzędzi, tym lepiej. Czasami warto jest też współpracować z zewnętrznymi firmami, do których możemy pewne zadania wydelegować, ale to zależy od indywidualnej sytuacji, potrzeb firmy, możliwości finansowych, dynamiki zmian, wielkości zespołu, a nawet charakterów osób zarządzających firmą – to wszystko ma znaczenie.

Jest pięć głównych kroków odnośnie podejmowania decyzji na podstawie analizy danych. Po pierwsze zdefiniowanie celu oraz metryk. Jeśli przeprowadzimy całą inicjatywę, zainwestujemy w budowę danego rozwiązania i nasza metryka będzie wynosiła X albo Y, my w tym momencie już nie wiemy, jaką podejmiemy decyzję w oparciu o X lub Y, to znaczy, że prawdopodobnie ta inicjatywa nie ma za bardzo sensu, bo zainwestujemy masę czasu i poza tym, że zyskamy większą wiedzę kontekstową, to w dalszym ciągu nie podejmiemy decyzji na podstawie danych. Więc dopiero gdy będziemy przekonani co do tego, że te metryki są dobre i użyteczne, wtedy zacznijmy inwestować w zbieranie danych, ich analizę i interpretację wyników. Na końcu zdobędziemy wiedzę, która pozwoli nam podjąć decyzję w zależności od tego, jak te dane będą się kształtowały. Myślę, że to jest zasada numer jeden. Jeśli na samym początku nie wiesz, jak wykorzystać wyniki, to nie rób tego. Warto zająć się czymś innym.

Cały czas nasza rozmowa dotyczy startupów. Stwierdziłeś, że jest ograniczona liczba ludzi w organizacji, więc zajmowałeś się tym jako pierwszy, samodzielnie. Jak do tego podchodziłeś? Jakie kompetencje, narzędzia, wiedza są tu potrzebne, żeby taki proces uruchomić i móc na bieżąco na takie dane patrzeć?

Na pewno pomogło mi to, że w przeszłości robiłem bardzo dużo zupełnie różnych projektów, które dotykały większości tych obszarów, które w firmie w ogóle istnieją. Poczynając od inżynierii danych poprzez analizę, data science, dobór narzędzi do analityki produktu, business intelligence czy chociażby współpracę z innymi podmiotami i delegowanie niektórych zadań. Znajomość realiów biznesowych oraz praca jako konsultant w firmach konsultingowych pozwoliły mi zrozumieć biznes.

W roli, w której się znalazłem, umiejętnością numer jeden jest zrozumienie biznesu, realiów, dopasowania priorytetów do konkretnych korzyści dla biznesu z tego, że pewnymi rzeczami się zajmiemy. I przede wszystkim umiejętność rozwiązywania problemów. To, co może czasami w takiej roli przeszkadzać, to przesada w robieniu rzeczy wg podręcznika, czyli wszelkie dobre praktyki, testy, przestrzeganie procesów zbierania wymagań. W startupie rzeczywistość jest dużo bardziej złożona i dynamiczna. Czasami bardzo pomaga następujące podejście: zróbmy na szybko bardzo minimalną wersję, zobaczmy, czy zadziała. Wiele inicjatyw nie zadziała. Czyli zróbmy coś, co jesteśmy w stanie szybko przetestować. To powinna być zasada w wielu startupach.

W pracy analityka danych ważne są dwie kwestie. Pierwsza to komunikacja: to, co robimy i dlaczego, musi być jasno komunikowane. Druga: stałe wpasowywanie się w długookresowe cele firmy. Czyli wszyscy powinni generalnie wiedzieć, co w danym momencie jest dla nas najważniejsze. Jeśli do osoby zajmującej się danymi przychodzi kilkadziesiąt osób z różnymi problemami, pytaniami, to zawsze warto ocenić, jak istotne jest to zadanie w kontekście strategii danej firmy. Jeśli to się nie wpisuje, ale problem jest mały – jesteśmy w stanie z nim żyć; jeśli nie da nam dużo wiedzy, nie zwiększy nam przychodów – jest to niższy priorytet. Nie ma jednej uniwersalnej zasady, której należałoby przestrzegać. To zawsze trzeba dopasować do potrzeb firmy, również do charakteru ludzi, z którymi pracujesz. Myślę, że regularne spotkania, na których omawiamy cele długofalowe, są ważne zawsze, a potem regularna komunikacja, nawet codzienna. Jeśli używacie Slacka lub innych narzędzi do komunikowania się wewnątrz firmy, codziennie napiszcie: dzisiaj zrobiłem to i to, jutro robię to i to. Wtedy dużo łatwiej sprawić, czy ludzie rozumieją, co robimy, dlaczego to robimy i dlaczego nie robimy rzeczy, o które nas prosili.

Powiedzmy kilka słów o relacji między analizą danych i strategią. Jeśli naszą strategią w danym okresie jest pozyskanie jak największej liczby klientów albo zwiększenie zaangażowania użytkowników w aplikację, to wówczas kluczowe będą dla nas wskaźniki z tym powiązane. Czy w związku z tym priorytetem osoby, która te dane analizuje, jest zbieranie tego rodzaju danych, a nie zajmowanie się chwilowo czymś innym?

Między innymi tak. Problemy wewnątrz firmy będą rozmaite. Trzeba wziąć pod uwagę, że jeśli mamy jedną osobę, która odpowiada za dane, to tak naprawdę ludzie ze wszystkich innych pozycji w tej firmie będą mieli do niej prośby, pytania, ponieważ to jedyna osoba, która może na nie odpowiedzieć. To nie będzie się wiązało tylko ze strategią. Jeżeli jakieś dane z jakiegoś powodu się nie zgadzają, ktoś to musi przeanalizować. Czasami nawet już na oko można określić, czy te dane mają sens. Każdy ma jakiś interes w tym, żeby czegoś się od ciebie dowiedzieć, np. backend przychodzi do ciebie z pytaniem: „Wydaje nam się, że coś nie działa, tylko nie wiemy co. Jesteś w stanie mi w tym pomóc”, dziewczyna, która zajmuje się finansami w firmie, zapyta cię, jak to i to działa, sprzedawcy, ludzie, którzy zajmują się najważniejszymi klientami w firmie, CTO, CIO. Również w tym kontekście masz całą masę codziennych zadań, których nawet nie zaplanujesz, one po prostu się wydarzają. Pytanie, jak do tego podejść.

Jeśli w kontekście strategii firmy podejmujemy decyzję, że inwestujemy w jakiś obszar, to musimy monitorować, czy osiągamy sukcesy. Jeżeli wyznaczamy konkretny cel na koniec kwartału, np. mamy dojść do liczby X użytkowników na platformie, zwiększyć zaangażowanie o 10%, to wcześniej musimy przygotować metryki, które będą nam to określały na koniec kwartału i pomagały monitorować postępy z tygodnia na tydzień. I rzeczywiście osoba, która się tym zajmuje, jest kluczowa też w kontekście tego, jak zdefiniować te zmienne. Jeśli badamy zaangażowanie, to czy powinniśmy je odnosić do całej platformy czy może tylko do określonego typu użytkowników, np. do tych, którzy mają aktualnie ważną płatną subskrypcję. Ponieważ te wyniki będą zupełnie inne, gdy skupimy się również na osobach, które mają tygodniową próbną subskrypcję za darmo, albo tych, które z jakiegoś innego powodu mają dostęp do aplikacji. To wszystko zależy od tego, jakiego typu produkty oferujesz i jak zdefiniujesz cele.

Czy analizę danych, które zamierzasz monitorować w sposób stały, dzielisz organizacyjnie i technicznie? Na przykład co miesiąc chcemy wiedzieć, ile przyszło nowych użytkowników, i co by się nie działo, nas to interesuje. Ale zdarzają się analizy jednorazowe, np. przyjdzie nam do głowy, żeby sprawdzić, jaki jest średni wiek użytkowników, jakie kolory lubią. Czy dla ciebie ma znaczenie, że jest to bardziej ad hoc?

Tak, jak najbardziej. Jeśli chcemy mieć coś na stałe i są to rzeczy ważne dla firmy, to wiadomo, że postanowimy to zautomatyzować, żeby nie angażować do tego żadnej manualnej pracy. Ale tak jak mówisz, są to zadania zupełnie ad hoc. Firma działa w sposób dynamiczny. Często zmieniany jest w niej model biznesowy, np. w zależności od tego, co robi konkurencja. Wówczas dochodzi do typowej analizy ad hoc. Wodze fantazji mogą nas ponieść daleko, gdy zrobimy model symulacyjny, w którym postaramy się przeanalizować różne zmiany w aplikacji. Możemy mieć hipotezy, zrobić research odnośnie działań konkurencji, a metryki i cele zdefiniować w oparciu o konkurentów, a nie nasze wewnętrzne dane. Natomiast to nie są rzeczy, które będą nam potrzebne za pół roku, być może nawet za miesiąc, aczkolwiek zupełnie inaczej się do tego podchodzi. Możesz skorzystać z zupełnie innych narzędzi, niż robiłbyś to dla takich dashboardów, które regularnie muszą być odświeżane. Tu można skupić się na ciekawszych narzędziach, np. zbudować model predykcyjny, który pomoże w ocenie sytuacji.

Kiedy już zbudujemy sobie infrastrukturę danych, to SQL jest jednym z przydatnych narzędzi codziennej pracy. Natomiast w analizach adhocowych lub bardziej związanych z data science bardzo pomagają Python czy R. Jest bardzo dużo takich rzeczy, które można w ciekawy sposób przedstawić, np. jeśli mamy już dużą bazę użytkowników, to chociażby badanie powiązań sieci społecznych w aplikacji. Te powiązania pomiędzy poszczególnymi twórcami, influencerami a followersami to bardzo ciekawe tematy do analizy. Bardziej zaawansowane są już systemy rekomendujące i elementy, które będziemy mogli potem wdrożyć jako część aplikacji.

Z jakich narzędzi warto korzystać? Czy to bardziej narzędzia programistyczne wykorzystywane samodzielnie, kawałki kodu pisane samodzielnie, SQL, czy bardziej narzędzia komercyjne, pakiety BI-owe, korzystanie z firm zewnętrznych? Jakie podejścia się sprawdzają, kiedy i z których korzystasz samodzielnie?

Rozwiązania chmurowe przede wszystkim, które pozwolą nam na budowę tej infrastruktury analitycznej. Ja obecnie dużo korzystam z chmury googlowej, trochę też z AWS-a, ponieważ pod kątem innych potrzeb to się wydaje czasami przydatne. Jestem zwolennikiem podejścia no-code, jeśli chodzi o budowę tych data pipeline’ów, które w startupie warto zbudować. Jest sporo startupów, jak chociażby taki, który został finansowany jakiś czas temu – Sequoia Capital, czyli jednej z największych firm PC na świecie, która wcześniej inwestowała, chociażby w Apple’a.

Wspomniałeś o narzędziach, z których korzystasz przy analizie danych. Wyobrażam sobie, że można korzystać z takich bardziej programistycznych narzędzi, samodzielnie pisząc jakiś kawałek kodu w Pythonie czy korzystając z SQL-a. Można korzystać z jakichś istniejących narzędzi, czy to opensource’owych, czy komercyjnych pakietów typu business intelligence, z firm zewnętrznych. Co wg ciebie sprawdza się najlepiej i w jakiej sytuacji? Z czego osobiście korzystasz?

Myślę, że to jest połączenie tego, co wywnioskujemy z wywiadu wewnątrz firmy, z tym, co nam odpowiada. To nie jest tak, że zrobimy wszystko tak, jak sobie to wymyślimy. Tego typu rzeczy trzeba konsultować wewnątrz firmy, a zwłaszcza jeśli chodzi o narzędzia do wizualizacji danych, do analityki produktu. Warto zrozumieć, co osoby, które korzystają z tych narzędzi, dokładnie będą robić. Jeśli chodzi o analitykę produktu, to chociażby product managerowie. Oni mają już jakąś historię doświadczeń z różnymi narzędziami i są w stanie sporo podpowiedzieć. Oprócz technicznych aspektów, które my z naszej pespektywy możemy oceniać jako lepsze bądź gorsze, trzeba brać pod uwagę też doświadczenie użytkownika końcowego. Znam wielu product managerów, którzy są wielkimi fanami Mixpanela. Wtedy pytanie brzmi: czy do analityki produktów warto wdrożyć Google Analytics jako narzędzie, które jest darmowe i powszechnie znane, czy jednak wyłożyć większe pieniądze na Mixpanel, Amplitude czy CleverTap itp. Myślę, że to musi wynikać z jakiegoś konsensusu wewnątrz firmy. Tak samo jest z narzędziami do business intelligence, czy to będzie Looker, Tableau, Power BI czy Metabase.

Natomiast ja jestem zwolennikiem narzędzi typu no-code do inżynierii danych. Sam z takich korzystałem. Wydaje mi się, że w przypadku niedużego startupu takim optymalnym rozwiązaniem jest testowanie wielu różnych narzędzi. Zamiast poświęcać wiele czasu na jakąś szczególną analizę porównawczą narzędzi, wypróbować sobie jedno, drugie, trzecie narzędzie. Zobaczyć, jak się z tego korzysta, jak to wygląda pod kątem efektywności kosztowej. Wiadomo, że te narzędzia same z siebie nie działają, lecz w określonym ekosystemie. Czyli zbudujesz w no-code data pipeline, który będzie korzystał z różnych źródeł danych, czy to będzie relacyjna baza danych, czy baza NoSQL-owa, Google Analytics, Bucket na Google Cloud – tego typu narzędzia działają w specyficzny sposób. Same z siebie kosztują, ale kosztuje również używanie tych źródeł, kiedy współdziałają z tymi narzędziami. Czasami mogą wydarzyć się rzeczy zupełnie nieoczywiste, kiedy odkryjesz, że twoje narzędzie działa wspaniale z pięcioma źródłami danych, jest bardzo tanie, a na szóstym źródle nagle kosztuje ogromne pieniądze i ty nie wiesz dlaczego. Okazuje się, że to startup, który jeszcze nie dopracował tego źródła danych, a twój pomysł nagle legł w gruzach i musisz szukać alternatywy. Myślę, że chodzi o ciągłe testowanie, a z upływem czasu wyklaruje się, co działa najlepiej na twoje potrzeby, źródła danych i analizy. Sam zintegrowałem się z niektórymi źródłami danych, ale od długiego czasu nikt nie poprosił mnie o żadną analizę, która ich wymaga. Więc kiedy mam narzędzie, które działa bez kodu, mogę sobie kliknąć pauzę, nie martwiąc się zupełnie o to, nie potrzebuję inżyniera, który to utrzyma.

Czy uważasz, że to jest OK, jeśli korzystamy z różnych narzędzi, część danych analizujemy w jeden sposób, część w inny? Czy powinniśmy dążyć do tego, żeby wszystko było w jednym miejscu, w jednym dashboardzie, w jednym systemie?

Myślę, że w jednym dashboardzie to jest niemożliwe. Oczywiście trzeba dążyć do tego, żeby dane były w jednym miejscu długoterminowo. Bo krótkoterminowo, zwłaszcza gdy jesteśmy na początkowym etapie rozwoju firmy, kiedy mamy jedną bazę danych dla backendu, nawet nie mamy jeszcze repliki, z której możemy korzystać, wiadomo, że nie mamy wszystkiego, co byśmy chcieli, a jakieś dane trzeba inwestorom pokazać, ponieważ walczymy o to, żeby firma przetrwała. Natomiast długoterminowo jestem zwolennikiem podejścia, w którym jest jedno źródło danych, do którego wrzucamy dane z różnych źródeł. Możemy je wrzucać różnymi narzędziami. Nie ma z tym problemu. Natomiast zdecydowanie jakiś data lake, który pozwala na trzymanie wszystkich danych w jednym miejscu, potem łączenie ich, budowanie modeli, podpinanie tego pod narzędzie do wizualizacji danych. Oczywiście nie spotkałem się jeszcze z podejściem, że zmieścimy wszystko w jednym dashboardzie, ponieważ tych zapytań, obszarów analitycznych jest tak dużo, że zanim się obejrzysz, minie rok, masz już 50 dashboardów.

Czy bardziej jesteś zwolennikiem podejścia, w którym wszyscy w firmie lub sam zarząd ma dostęp do pewnych dashboardów i cały czas może sobie na nie patrzeć, samodzielnie na bieżąco je analizować, czy dopiero po wykonaniu takiej analizy przez ciebie, przedstawianie wyników na spotkaniach odbywających się raz na jakiś czas? Czyli kontrast między takim stałym monitorowaniem danych bardziej surowych lub w postaci dashboardu dostępnego dla wszystkich i w dowolnym momencie versus spotkajmy się raz na miesiąc, żeby popatrzeć na dane dokładnie i z interpretacją.

Myślę, że to jest połączenie tych dwóch podejść. Na pewno w każdej firmie jest szereg danych, które – jeśli chodzi o definicje zmiennych – wszyscy dobrze znają. W metodologicznym podejściu na samym starcie budowy systemu analitycznego można skupić się na opracowaniu słownika danych. Czyli budujemy leksykon, ustalamy definicje, co rozumiemy jako „subskrybent”, „płatny subskrybent”, „roczny subskrybent”. Dla ułatwienia na samym początku możemy uwspólnić nomenklaturę. Dzięki temu ludzie będą mogli samodzielnie interpretować wiele danych. Odnosząc się do narzędzi takich jak Mixpanel, Google Analytics lub CleverTap, jestem zwolennikiem podejścia, w którym ktokolwiek te dane generuje, jest odpowiedziany za utrzymanie słownika danych w danym obszarze. Czyli powinien istnieć dokument, w którym każdy developer odpowiedzialny za tworzenie danych definiuje, co dokładnie jest śledzone, w jaki sposób. Podaje nawet screenshoty, żeby nie było wątpliwości, co dzieje się w momencie, kiedy gdzieś klikniesz, jaki event jest trigerowany. Umożliwia to sytuację, w której każdy wewnątrz firmy – CTO, CDO, analityk produktu, menedżer – będzie w stanie wejść do takiego dokumentu i zrozumieć definicję. Ty nie musisz wtedy poświęcać dużo czasu na interpretację danych.

Inaczej będzie, kiedy wchodzimy w nowy obszar danych. Wypuściliśmy nową funkcjonalność, która zmienia zasadniczo sposób, w jaki używa się produktu, albo analizujemy adhocowo jakąś możliwość zmiany modelu. Wiadomo, że wtedy trzeba podać ten kontekst, czasami zorganizować spotkanie. Jestem zwolennikiem takiego podejścia, że organizowane jest przynajmniej jedno spotkanie w tygodniu, na którym omawiamy dane, które warte są analizy. Wiadomo, że osoba je analizująca będzie wiedziała najwięcej, czy coś znaczącego się zmieniło w ostatnim tygodniu, czy coś wartego uwagi należy poruszyć, czy są jakieś ciekawe wnioski z takiej analizy adhocowej. I kiedy zadbamy o przejrzystość komunikacji, to z własnego doświadczenia wiem, że jest coraz mniej pytań i to zaczyna się w pewnym momencie samo kręcić. Wątpliwości, problemów, sytuacji, w których ktoś nie wie, że coś jest ważne, co śledzimy, czego nie, jest coraz mniej.

Rola takiej pierwszej osoby od danych wiąże się też z funkcją edukatora. Trzeba wiedzieć, co te dane oznaczają i czasami wyprowadzać z takich pułapek, w które osoby nietechniczne łatwo wpadają, jak chociażby problem mylenia korelacji z przyczynowością – to problem numer jeden w wielu sytuacjach. Załóżmy sobie następującą sytuację: umieszczamy wielki, czerwony przycisk obok przycisku „anuluj subskrypcję”, więc jeśli pomylibyśmy korelację z przyczynowością, doszlibyśmy do wniosku, że wielki, czerwony przycisk powoduje odejście ludzi z aplikacji. CIO mógłby powiedzieć: „Usuńmy ten przycisk, nie będzie problemu. Nikt nie będzie anulował subskrypcji”. Ten przycisk tylko przy okazji jest obok przycisku „anuluj subskrypcję” i nie ma żadnej przyczynowości.

Jak w takim razie sensownie podejmować decyzje biznesowe, żeby ten dane były zrozumiałe? Bo jeśli zmieniamy strategie, bo przez tydzień obserwowaliśmy informacje o tym, że spada nam liczba nowych użytkowników, to być może jest to przedwczesne, natomiast jeśli od miesiąca albo od kwartału obserwujemy spadek, to możliwe, że musimy szybko coś zmienić w strategii. Czasem bez szerszego kontekstu spojrzeliśmy na dane, nie uwzględniwszy okresowości. Czyli twoim zdaniem najlepiej podejść do tego tak, żeby te decyzje były sensowne i faktycznie przekładały się na wzrost firmy, nie były ślepą uliczką w tym wszystkim.

Podałeś ciekawy przykład. Czasami spadki danych mogą wynikać z tego, że jest jakiś bag w kodzie. To może nie mieć związku z rzeczywistością biznesową. Podejście do tego musi być zdroworozsądkowe. Wspierajmy podejmowanie decyzji danymi i analizą, ale to musi być umiejętnie połączone z analizą jakościową, zwłaszcza na wczesnych etapach rozwoju, kiedy dopiero dowiadujemy się, co jest w naszym produkcie stanowi wartość dla klientów, jak oni na niego reagują. Zatem te wywiady z użytkownikami są bardzo ważne. Ważne jest również monitorowanie trendów rynkowych, śledzenie konkurencji. I dopiero na podstawie szeregu takich czynników, intuicji biznesowej oraz skłonności do ryzyka te decyzje są podejmowane. Ważne, żeby nie przesadzić z tą analizą, bo przekonanie o tym, że dane dadzą nam odpowiedzi na temat tego, co się wydarzy w przyszłości, jest dosyć często błędne. 

To było bardzo fajne spojrzenie na to, jak dane wpływają na rzeczywistość w firmach. Myślę, że zainspiruje ono wiele osób rozwijających startupy do zainwestowania w analizę danych, by mieć wgląd w to, co faktycznie dzieje się w firmie. Mam nadzieję, że spotkamy się jeszcze w tym podcaście i pogłębimy tematy, z którymi masz styczność, czyli te dotyczące subskrybentów, użytkowników aplikacji i tego, jak je rozwijać, żeby inwestorzy byli nimi zainteresowani.

Dziękuję serdecznie za zaproszenie. Myślę, że będzie jeszcze niejedna okazja do rozmowy.

Dzięki i do usłyszenia!

Do usłyszenia!