Podcast

Dobrý den, mé jméno je Jirka Vyšerek. Dobrý den všem, jmenuji se Hinek Valner. Vítáme vás u dalšího dílu Datatolku. Dnes k nám přijel další zahraniční host ze Slovenska. Vzácný host, další legenda a osobnost české datové scény, Matúš Pavlišťák, Analytics lead z Productboardu. Vítej, Matúši.
Čau tě, děkujeme za pozvání.

Matúš působí na československé datové scéně přibližně osm let, ale za tu dobu už v ní dokázal zanechat značnou stopu. Má za sebou velmi zajímavé firmy, od Tralogiku přes Deep Note až po současný návrat do Productboardu na svoji misi.

Asi, Matúši, začněme od začátku. Co tě vlastně přivedlo k datům?
To je velmi dobrá otázka. Když na to dlouhodobě přemýšlím a bavím se s lidmi o tom, co vlastně dělám, co mě baví a proč mě to baví, tak mě vždycky bavila matematika a čísla. Už někdy na střední škole, na gymnáziu, jsem měl rád matematiku, Pythagorea a všechny ty věci. A když jsem vlastně maturoval, řešil jsem, co dál, kam půjdu studovat. A tehdy mě zaujala Vysoká škola ekonomická v Praze, která nabízela kombinaci technické a byznysové části. Vždy mě bavilo programování, takže jsem věděl, že chci programovat, ale ne úplně jako full-time heavy coder. Tak jsem se přihlásil na obor informatika a tam jsem zjistil, že existuje něco jako business intelligence, a tak jsem se nakonec dostal k tomu, že dělám BI už posledních 8–9 let.

A co tvoje první pracovní zkušenost? Už jsi měl během VŠ nějaký model, kdy jsi s něčím koketoval, nebo jsi šel přímo po škole do práce?
Já jsem se vždycky nějak motal okolo startupů. Pamatuji si ten moment, kdy jsem koupil doménu startup.com, a ta byla volná, takže to je asi deset let zpátky. Tak nějak začínaly první startup campy.

Počkej, počkej, startup.com byla volná doména?
Byla, startup tehdy nebylo slovo, které bylo považováno za oficiální.
A ty jsi ji nekoupil, šel jsi dál?
Kdybych ji koupil, asi bychom tady dneska neměli toto povídání, nebo bychom byli někde jinde.

Co bych chtěl říct, byl jsem na několika startup campech, kdy ještě nikdo moc nevěděl, co startup znamená. Tak jsem se dostal k Rockway a úplnou náhodou jsem potkal Vojturočka v Karlíně v mém šálku kávy. Bavili jsme se o tom, že chci dělat data, byznys a technologie, tedy věci, které jsem se naučil ve škole a které mě lákaly.

Počkej, zastavme se. Co znamená náhodně potkat Vojturočka? Sedl si k tvému stolu, nebo jsi mu řekl, že ho znáš z internetu?
Byli jsme v kontaktu, myslím, že jsme se potkali na nějakém Enterprise Data Hackathon v TechSquare, dávno možná na prvním hackathonu, možná i českém, ne jen datovém. Nějak jsme se poznali, já jsem ho poznal a on asi mě ne, a psali jsme si. Přesně když jsem šel jednou na KAU cestou do školy, náhodou jsem ho tam potkal a bavili jsme se o tom, že plánuje odejít z Rockway, z e-commerce holdingu (tehdy před Mall Group), a že zakládá kodutačku. Pozval jsem ho na KAU a já se zajímal o data a o to, jak chci pracovat s těmi „cool“ firmami, které znám – Kiwi nebo Skype – a další. Vojta mi řekl, že plánuje založit kodutačku, která se jmenuje Tralogic, a myslím, že hned další den jsem seděl u něj doma a společně jsme kódili transformace dat a datové modely pro La Premiere.

Takže to byla velmi rychlá cesta a sám jsem neměl plán, jak to dopadne, ale sedli jsme si a byl to pro mě skvělý projekt, úplně první. Nemám rád návody, kdy pracuješ s nějakými sample daty nebo s daty jako bitcoinových pohybů. Toto bylo super v tom, že to byl první projekt, kde jsem skutečně viděl, jak vytvořím model, dashboardy, report a přijdeme s nimi za byznysem, za CEO La Premiere, a ukážeme mu výsledky, například prodeje, které do té doby neviděl.

Takže to byl tvůj skok. Vojta Roček tě vytáhl z kavárny k sobě domů a už jste tam dělali reporty pro La Premiere.

Jak dlouho vlastně trvala éra Tralogic, nebo co to tehdy znamenalo?
Myslím, že to bylo něco přes půl roku pravidelné, někdy intenzivní, někdy méně intenzivní práce. Vlastně jsme se tehdy s Hinkem potkali. Byl to čas, kdy vznikala ještě AI for BI, což jsou vlastně Stories, pokud si dobře pamatuji název. A protože jsem byl u Vojty, řešili jsme tam něco pro LabPremier. Pak mi Vojta řekl, že přijde pár kluků, že budou řešit nějaký projekt a pozval mě na večerní grilovačku, kde jsme se poznali. Vojta přišel s tím, že AI for BI vypadá zajímavě a že asi budou řešit Tralogic. Doporučil mě do několika firem a nakonec jsem skončil v Rockaway, respektive v ECH Group, kde jsem na další den seděl s Eliem a Wolfem na pohovoru.

Bylo to asi v roce 2016, jestli si to dobře pamatuji.
Tralogic byla v letech 2015–2016 a bylo to těsně před velkou akvizicí Mallu, o které jsem tehdy nevěděl, protože jsem ještě neměl podepsanou NDA a nikdo mi o tom nic neřekl. Ale s Hinkem jsme se i trochu potkali na některých projektech. Ten můj úkol byl, že e-commerce holding měl 20–30 e-shopů a Rockaway potřebovalo získat přehled o tom, jak se těm e-shopům daří. Takže klasické ETL, ingestion data na jedno místo, transformace různých ERP systémů typu Pohoda a dalších, které bychom mohli jmenovat dlouho. A nakonec se vytvářel jednotný model e-cross.

Důležité je zmínit, že tam byl taky SAP, tehdy ještě kolonie, předchůdce košíku, a stále si pamatuji, jak jsme hackovali, jak reportovat například váhu lososa. Vývoj té funkce v SAP mohl stát několik milionů verzí, zatímco transformace za dva dny vyšla na pár korun. Takže mám z toho SAPu takové šrámy, ale i flashbacky. Myslím, že všichni, kdo někdy pracovali se SAPem, vědí, co to znamená s ním pracovat nebo s jeho daty.

Takže Mall Group. Jak to tam probíhalo?
Velice rychle jsme narazili na problémy s velkým objemem dat. Asi to nebyla big data, jak je dnes obvyklé, ale tehdy to byl velký boom, kolik kdo má giga nebo tera dat. Tehdy stack v Rockaway byl na Kebule a Redshifte, plus „gooddata“ jako reportingová vrstva. Rychle jsme narazili na problémy se škálováním Redshiftu. V jednu chvíli jsme museli koupit velký virtuální server, ale už to nedávalo smysl, protože jsme nemohli data refreshovat. Přicházeli jsme ráno do práce a neměli jsme data za předchozí den. Management tlačil, kde jsou data za včerejšek, kde jsou naše prodeje.

Byli jsme v dlouhém zápasu, ale pak přišel Petr Šimeček z Kebuly s nabídkou testovat nový nástroj, novou databázi jménem Snowflake. Měli jsme podepsat NDA, udělat Proof of Concept a uvidíme. Byla to beta, takže ne všechno fungovalo hladce, některé základní SQL funkce nebyly úplně ideální. Přesto jsme to s Jirkou Grilem otestovali a během tří dnů až týdne nám to vyřešilo všechny problémy s Redshiftem a mohli jsme se opět věnovat byznysu a správnému počítání marže například na lososech. Váha lososů tedy fungovala.

Jsem rád, že Snowflake se ukázal jako správná cesta. Pamatuju si listopad 2014, kdy Vojtaváček přišel s fanfárami, že přecházíme na Redshift a že škálování je vyřešené. Když se tak dívám zpětně, bylo to správné rozhodnutí. Ten moment, kdy jsem tam seděl, byl takový aha moment, co znamená mít XXL warehous nebo S – co je mezi tím rozdíl. Prostě zkusíme, spočítáme náklady a půjdeme dál. Celý princip fungování Kebuly je dnes běžné – všechno na klik a přes kreditní kartu.

Z dnešního pohledu byla ta doba startu těch moderních nástrojů a technologií skvělá. Dnes je normální si během chvilky založit Snowflake účet, zadat kreditní kartu a je hotovo.

Velice rychle jsme se dostali díky akvizici do Mallu, což pro mě nebyl šok, ale spíš kulturní šok. My jsme přišli jako startup s moderními technologiemi – Kebelami, Snowflaky, Gooddaty – do velké desetileté firmy, která fungovala na Hadoopu a různých SAP technologiích. Všechny tyto technologie vyjmenoval Ilja ve vašem podcastu a pro mě to byl takový šok.

Do té doby jsme byli velmi efektivní, i když ne perfektní, ale pomáhali jsme byznysu. Ale druhý den jsem přišel do kanceláří Mallu v Holešovicích a řešili jsme, jak škálovat Hadoop, že musíme objednat další servery, které máme fyzicky nainstalované, a úplně jsem nechápal, proč se to tak řeší. To byl ten šok, že jsem poprvé byl na straně „startup“ a pak jsem si uvědomil, co znamenají enterprise systémy, enterprise nástroje, principy a jak je náročné to manažovat.

Když o tom teď mluvíš, ještě než se dostaneme k dalším případům typu startup, scale-up, Productboard, Shipmank, DeepNote, pověz mi, jak to máš se zkušenostmi při výběru nástrojů? Kde bereš čas na testování beta verzí jako Snowflake, když Redshift nevyšel? Jak to řešíš? Nové nástroje, které mohou za dva roky vyřešit spoustu problémů, versus udržování stávajících systémů a lidí, kteří je znají. Je to vlastně ten inovators dilemma.

Měl bych na tuto otázku jednoduchou odpověď – čas je limitovaný, nikdo nemá ho mnoho věnovat věcem, které ho baví, a zároveň nejsou vždy pracovní. V rychle rostoucích startupech to platí dvojnásob. Pro mě je to vždy docela jednoduché. Podívám se na aktuální problém, který řešíme, nebo se snažím vidět 3–4 kroky dopředu, protože vím, že už se blíží nějaký threshold, kdy nám současný systém přestane stačit, nebo nám přestane vycházet rozpočet na Snowflake, BigQuery či Redshift, to je už jedno. Snažím se řešit akutní problémy nebo ty, které už přijdou brzy.

Samozřejmě, před šesti lety jsem se na to díval jinak než dnes. Dnes už umím spíše predikovat, co přijde, a lépe na to reagovat. Takže vždy řeším to, co aktuálně pálí.

Když se podíváš na současný data landscape, tam je 200, 300, 400 firem, které se pohybují v oblasti datových nástrojů, od moderního stacku výše. Můžeme dlouho diskutovat, proč je zde tolik nástrojů. Čas na testování všech nemám, nevyskúším skoro nic, co mě zaujme, nebo o čem slyším od kamarádů, kteří to používají, například DuckDB, které vyřešilo škálování u Aurory – to si zkusím, ale většinou něco řeším až v práci.

A jak bylo pro tebe fungovat v Rockaway nebo v ECH, v Mall Group z pohledu organizace a kultury? Po tom všem Tralogicém období bylo sedět v kavárně, dělat výsledky pro CEO, ale pak přijít do velké organizace jako Mall Group. Jak sis tam zvykl?

Byla to velmi zajímavá zkušenost. Byl jsem tehdy ještě student na magisterském studiu, takže jsem běhal mezi školou, přednáškami, zkouškami a meetingy. Na jednom meetingu jsem byl se C-level managementem a měl jsem jim říct, co data ukazují a jaké řešení navrhuju. Problém nebyl v tom vymyslet případové studie nebo business case, ale spíš v tom, kdy se to stihne udělat.

V Mall Group jsme narazili na limity Hadoopu a dalších technologií, které tam byly. Neříkám, že byly vyloženě špatné, ale nebyly tak efektivní, jak jsme potřebovali. Ilja o tom určitě mluvil podrobně. Pro mě to byla skvělá zkušenost – naučil jsem se komunikovat s byznysem, s ředitelem prodeje, který má na starosti 20 e-shopů v poměrně rozsáhlé e-commerce skupině. Naučil jsem se vést tyto debaty efektivně.

Asi jsem tam strávil kolem 2,5 roku, a bylo to velmi zajímavé vidět velkou firmu, která řeší základní problémy – blokace příjmů.

Co si vezmu jako osoby, která nezná ty firmy zblízka, kdo si neumí představit datové problémy, je to těžké pochopit, že nemáte prostě Excel se základními čísly po měsících. To byl velký challenge, jak to vytvořit. Nakonec náš tým, nebo cloudové řešení, pomohlo urychlit onboarding a urychlilo ten „aha moment“ u všech – analytiků i byznysových stakeholderů – že existuje dashboard, kde můžete drag and dropovat metriky a dimenze a data jsou validovaná a fungují.

A jak přitom opakuješ, že byznys je vždy na prvním místě, co tě to naučilo ohledně toho, jak mu dávat prioritu a jak mu vysvětlit, že Hadoop technologie brzdy, že je potřeba platformu vyměnit, což je technologická otázka, která krátkodobě znamená náklady?

To je dobrá otázka a existuje několik odpovědí. S byznysem obvykle nemluvíme o technických detailech. Nerozumí jim, nemají na ně čas a nejsou to pro ně důležité věci. Já to dělám tak, že zhruba odhadnu složitost problému z byznysového pohledu, podle toho umím říct, jak dlouho bude trvat řešení. Samozřejmě, vždy jsou nějaké překážky, technický dluh atd., ale s tím musím umět pracovat a nastavit reálný deadline.

Vždy jde o komunikaci a transparentnost – když víme, že deadline nebude dodržen, prvotně to managementu komunikujeme a hledáme alternativy. Je to o partnerství, kde každý má své problémy a otevřeně to komunikujeme.

Je pravda, že to není úplně ideální situace, a pokud něco nestíháme, měli bychom říct, zda existuje riziko, že nestihneme dodat nějaká data na board meeting. V takovém případě je v pořádku všechno zastavit a jít řešit problém. Tento přístup je mnohem lepší, než když na něčem makáte dva až tři týdny a den před deadlinem zjistíte, že potřebujete další měsíc, a pak přijdete za CEO a řeknete, že to nevyšlo. Naopak, když to zjistíte po týdnu, vrátíte se na meeting a řeknete, že máme problémy, můžeme klidně vynechat celou roadmapu, kterou řešíme, pokud je potřeba se teď v tomto momentu věnovat něčemu důležitějšímu. Vždy je to o načasování.

Teď jsi zmínil, že jsi byl v RakyWay či vlastně v Mall Group už dva roky, takže jsme v roce 2018, 2019, jaká byla tvoje nová mise? Vlastně jsi nezmínil úplně, že jsi byl v RakyWay na Kavčích horách, kde si se prý i jednou potkal s Jirkou, že?

Jirko: K tomu nemohu říci mnoho, ale když už si tady připíjíme, tak já jsem autorem názvu Trologik. To byla velmi kreativní brainstormingová seance s Vojtou a je to jeden z mých brandů, na který jsem nejvíc pyšný, protože je tak trefný.

Takže logo jsi nedělal?

Ne, logo dělal Adam Hrubý.

Ano, ano, All Stars tým – Piečard, Speckman, Story. A na tvém tričku pěkné logo, tak mi to připomnělo Trologik. A co se dalo říct, je to, že když jsme seděli v RakyWay v kancelářích, tak kromě e-commerce skupiny byla RakyWay jako taková investiční skupina, která investovala do několika startupů a často bylo hodně společných akcí, kde jsme se potkávali. V jednom momentu jsem se setkal s různými startupy, například Bileto, Brand Embassy, Product Board.

Většinou tam byli tři až čtyři lidé, kteří tam něco programovali od rána do večera. Kdykoli jsem přišel, byli stále v kanceláři a kávu pili Velkým množstvím. SQL Dev byl takovým jazdcem RakyWay a tam jsem vlastně potkal Huberta Polána, Dana Hejla, kteří chtěli mluvit o datech a o tom, jak to děláme v Mall Group, protože měli GoodData a chtěli, abychom jim pomohli řešit škálovací problémy. Což by bylo hodně zvláštní, protože Hubert Polán pracoval v GoodData několik let, takže by asi měl vědět, co GoodData znamená a jak to správně implementovat. Pracoval jako VP of Product, tak ho asi dobře znal.

Ukázalo se, že je to dobrá taktika, když za tebou přijde zakladatel se super nápadem a chce tě nakopnout nebo ti prodat svou vizi, já jsem nikdy neváhal. To, co jsem zažil v Mall Group, byla super zkušenost a asi by to bylo dál dobré, a asi bych dostal na Dynamic Pricing, což byl skvělý projekt. Ale neváhal jsem, startupy jsou stock options, nevěděl jsem, co to znamená, kolik si mám říct, tak jsem do toho šel.

Kolik lidí tehdy bylo v Product Boardu? Chtěl bych znát škálu.

To už bylo v roce 2019, takže to už nebyla malá firma. Myslím, že můj počet byl 28 zaměstnanců na plný úvazek. Takže jsme už nebyli úplně malí, nebo na pohovoru, kterého jsem se účastnil, nás bylo 28. Když jsem nastupoval, už byl větší hub office, nás bylo asi 30. Už jsme měli za sebou Series A, což byl hlavní důvod, proč Product Board hledal datového člověka, protože Hubert se svými zkušenostmi z GoodData věděl, že data je potřeba řešit, a čím dřív se to vyřeší, tím méně problémů bude při škálování firmy.

Series A kolo a pak ještě jeho rozšíření bylo podle mě 10 a 8 milionů dolarů, nebo obráceně – což byl poměrně velký kapitálový vstup na poměry této lokality – a tak jsem do toho vstoupil já. Hubert mi řekl, že jdeme budovat velkou firmu, máme na to investice a data musí být základ.

To mě asi finálně přesvědčilo, že proč ne.

Co vlastně znamená být datovým člověkem a pomáhat tomu, aby data byla základem budoucí velké firmy s kanceláří kolem 28–30 lidí? Možná se na to podíváme úplně od začátku, mě by to zajímalo.

Takže přijdeš do nové firmy, Product Boardu, a co děláš nejdřív? Jak děláš první průzkum? Jak si pak určujes plán na půl roku, na rok? Co to vlastně znamená?

Asi první věc je podívat se do systému a na kvalitu dat, nebo první zjistit, jak reálný je byznys model, abys měl tu matici důležitosti.

Já po svých zkušenostech v Mall Group už tušil, co znamená dělat data a co to obnáší, aby byli všichni spokojení, že mají ráno dashboardy, že tam ty dashboardy jsou, že je mají v mailech, screenshoty, exporty do Excelu a čísla v dashboardech sedí s jejich vlastními čísly. Takže jsem měl nějakou představu. Samozřejmě práce je vždy jiná, pracuješ s různými datovými zdroji.

Product Board byl B2B SaaS firma a já jsem nějak rozuměl metrikám – přecejen to není raketová věda. Ale první krok: Když jsem přišel do firmy, byli jsme v jedné nebo dvou větších místnostech, takže jsem si povídal s lidmi o tom, jak pracují s daty, jak je používají.

Všichni mi říkali, že se data točí někde v kruhu, ale nevidí ta data. Řekl jsem super, pojďme to zmigrovat někam – že to bude raz dva.

No jasně, všechny migrace vypadají jednoduše, až na to, že někdy je lepší to celé překopat. Prostě jen přesunout model z databáze A do B není vždy dobré, většinou lepší vypálit to, než se stěhovat, a to pro data platí podobně.

A bylo to tak i u vás?

Rozhodně, řekli jsme si, že raději napíšeme úplně od základu, vyhodíme vše, co není potřeba. Nebo nějaké věci se vyplatilo zachovat?

Udělali jsme rychlý prototyp úplně jednoduchého modelu nové datové platformy, která tak nějak fungovala do určité míry. Jasně, měli jsme dva datové zdroje, což je velký problém mít dvě „zdroje pravdy“.

Velmi rychle jsem si uvědomil, že jsem sám na všechny datové a analytické problémy, které firma řeší, nebo chce řešit. Můj čas je omezený, můžu tu pracovat celou noc, ale nebudu fungovat, protože se nevyspím. Abych předešel burnoutu, řekli jsme si, že zastavíme tyto věci.

S Danem Hejlem jsme měli debatu o tom, jestli má smysl strávit další dva až tři týdny migrací do nové datové platformy, ale nakonec by to firmě moc nepomohlo.

Mít starou datovou platformu, která se od reality liší o pět procent, je často otázka, jestli by to ovlivnilo rozhodnutí, kdyby byla přesná na cent. Tuto otázku jsem pokládal asi dvě stěkrát.

Lidé často honí datové týmy, aby měly všechno na desetiny procenta přesné, ale někdy je to zbytečné, protože chceme být data-driven organizace a raději mít nějaká data, než žádná.

Data nikdy nebudou stoprocentně přesná, vždy bude nějaký slepý kout, kam se ztratíte. Každý má své Excely a vlastní vzorce. Často se ale bavíme o trendech, které jsou důležité, ne vždy jde o absolutní přesnost. Jasně, příjem je důležitý pro finanční reporting, na to jsou finanční týmy, ale pro ostatní reporty stačí být blízko cíli, i když ten cíl přesně neznáš.

A lidi tě přesvědčí, že jejich čísla jsou „správná“. Zapomněl jsem otázku?

Asi zpět k migraci.

Chápeme, že největší problém byl, že máme nějaký existující reportingový stack, ale nefunguje úplně dobře. Tak co s tím?

První věcí bylo udělat POC na GoodData. Rychle jsem se dostal do stavu, že mě byznys baví, protože mám ekonomické vzdělání a trochu rozumím, jak firma funguje, finance, účetnictví a tak.

Snažil jsem se pochopit, co znamenají metriky jako monthly active users, MRR, ARR, annual recurring revenue a jak se počítají, jaká je teorie za tím.

Brzy jsem pochopil, že nejsou složité, spíše jsem potřeboval základ toho, co postavit a jak.

Formulky v knížkách o účetnictví pro cloudové B2B softwarové firmy jsou poměrně jednoduché.

Začali jsme stavět datový model úplně od nuly s jednoduchou představou, že je lepší mít jednu verzi dat než tři různé.

Řešili jsme oblasti, které nám dělaly problémy, často to byly produktové metriky, snapshoty dat – kolik uživatelů máme, kolik zákazníků, maintenance, aby data byla historizovaná a věděli jsme, co se kdy změnilo.

Pokud jde o metriky týkající se příjmů, měli jsme mnoho zdrojů na faktury a Stripe data pro self-service fakturaci.

Finálně se jednalo o unifikaci více zdrojů, ale vždy se jednalo o model, který obsahoval oblast příjmů nebo účetnictví, produktovou oblast, marketing a prodej.

Co bylo velmi zajímavé, myslím, že to přišel s Tomáš Čuper, že jsme spravovali data pro sales a marketing tak, aby se mohli pohádat, proč jim to nejde – jestli sales nebo marketing.

Bylo to logické – kolik dolarů investujeme do roadmapy, kolik nám to přinese leadů, jak kvalitní jsou a jestli je sales dokáže uzavřít.

To byl první projekt, který zajistil vysokou viditelnost do toho, jak firma utrácí peníze v těchto oblastech.

Pokud investujeme například 100 000 dolarů ročně do marketingu, co nám to přinese na příjmech?

Jak vypadal technologický stack? Říkáš, že tam byla GoodData, ale spoustu věcí jste potřebovali postavit znova a od začátku, kvalitně, nezbrkle. Jak vypadala struktura a priorizace v technologii?

Když jsem přišel do Product Boardu první den, byl tam stack Keboola, Snowflake, GoodData a spousta frustrovaných lidí, kterým to nefungovalo.

Keboola tam byla asi z historických důvodů, protože Product Board začínal v kancelářích Kebooly v Karlíně, když Keboola byla Keboola.

Mně to vyhovovalo, protože jsem stack znal a díky tomu jsem do toho šel, protože nebyl čas se učit novým technologiím.

Nechali jsme Keboolu, ale všechno jsme přepsali do datového modelu. Bavili jsme se o tom, jestli použít Kimball, Inmon nebo Data Vault. Nakonec to není úplně jedno, ale rozhodli jsme se to vyzkoušet, pokud to nebude vyhovovat, není problém později migrovat.

S dalšími lidmi v týmu, které se postupně přidávali (už jsem nebyl sám), jsme usoudili, že GoodData nám nestačí a neviděli jsme v ní budoucnost, kterou potřebujeme.

Udělali jsme tender, podívali se na všechny BI nástroje, porovnali je, nacvičili POC a rychle jsme dospěli k rozhodnutí, že potřebujeme něco jako Looker.

Pro Looker jsme se rozhodli kvůli jeho Analytics as a Code, což bylo velmi zajímavé pro nás inženýry i pro zbytek firmy.

Když jsem někomu řekl, že reporty budou verzované pomocí Gitu, bylo to přijato pozitivně, protože všichni vědí, že je snadné omylem něco rozbít a to může mít velké dopady.

Takže jsme šli do Looker a postupně jsme se rozhodli s Adrianem Tomanem, který se také podílel, pro Data Vault cestu.

Bylo to super postavit to na Snowflake – do té doby to nikdo takhle nedělal.

Mám pocit, že Data Vault je stále vnímán jako nějaká robustní knižka, která vznikla na Oracle databázích.

My jsme si řekli, že to zkusíme, má to historizaci by default, což se nám hodí.

Kdyby tam byl snapshot date a primary key jako jednoduchý primární klíč a každý den jako snapshot, možná by to mělo stejný úspěch.

Často mám pocit, že se to zbytečně řeší a točí se týdny v debatách a v několika schůzkách.

Někdy stačí říct, že to není ideální řešení, ale ideální řešení neexistuje.

Měl jsem základní výhrady k Data Vaultu, protože tam vznikají tři až čtyři tabulky na jednu entitu.

Dnes mám datový model s 300 až 400 tabulkami, se kterými pracuji.

Důvod, proč jsme Data Vault zvolili, byl Looker, který měl semantic layer, i když to ještě nebyl plný semantic layer, ale Looker měl model, který s tím pracoval.

Takže mi to v zásadě bylo jedno, ačkoliv mi to nebylo úplně jedno, ale uživatelé z byznysu či analytici budou klikáním v Lookeru, kde SQL se jim automaticky generuje, neřešit, co je hub, satellite a link, pokud mluvíme o Data Vaultu konkrétně.

Co Product Board jako takový? Říkal jsi, že jsi tam nastoupil, když bylo 28 lidí, byl jsi tam jediný datový člověk, a firma rychle rostla. Jak to probíhalo?

Zhruba podobně jako s Snowflakem – seděl jsem ve firmě, která měla 200 000 problémů a dvě řešení na dva z nich. Připadal mi to jako obrovský chaos a velká výzva toho rychle rostoucího startupu.

Měl jsem několik momentů, kdy každý měsíc nastupovali noví lidé, občas jich najednou přišlo deset a já už je ani neznal, ani jsem neměl čas je potkat na kávě.

To se stalo během jednoho roku, kdy přišlo hodně nových lidí do nových týmů.

Po roce jsem si říkal, že nemám šanci, už jsem neznal ani tváře, nevěděl jsem, kdo jsou, jestli jsou zaměstnanci nebo návštěvy.

Strávil jsem tam tři roky, a z 28 lidí jsme vyrostli na 300. Rok po mém nástupu jsme řešili Series B kolo financování a mám na to pěkný příběh.

Měli jsme Looker model, data, kterým věříme, data ověřená, verzovaná a označená jako verified.

Díky tomu jsme byli schopni rychle ukázat byznysu, že s těmi daty může pracovat a pomáhat všem týmovým procesům.

To znamená, že při financování k nám chodili investoři na Market Street v San Franciscu a ptali se Huberta, CEO, jestli má čas na kávu a chtějí se bavit.

Informace se rychle rozšířily, že Product Board rychle roste, a to byl velmi zajímavý růst pro investory.

A bavili jsme se ještě o tom, že někdy jsi byl večer pět hodin na večeři s kamarády a najednou ti volal Hubert, že…

Co děláš tento víkend? Já zatím nemám úplně žádné plány. Nechceš zítra jet do San Francisca? Takže zítra? No tak pojďme projet kolo a asi je dobrý čas nabrat peníze, protože bude efektivnější, když nebudeš večer celý rok sedět doma u Zoomu, ale přijdeš sem do místnosti, kde budeme mít takový war room a vyřešíme data na ten fundraising.

Takže jsem v tom týmu úplně neváhal, byla to nabídka, kterou se těžko odmítá. A vlastně to byla zajímavá zkušenost v tom smyslu, že přesně takové ty všechny startupové podcasty, které vyprávějí, jak funguje fundraising startupů, že prostě přijdeš do kanceláře, sedí tam tři lidi, kteří bez pozvání přišli, jsou to nějaké výšky, čekají, zda Hubert má čas přijít, zamávají, že jsme tu z toho fondu, a ukažte nám vaše data a váš růst.

Takže se stal moment, kdy jsem se ocitl v kanceláři, kde přišel Index Ventures a ještě další zajímavé VC fondy celosvětově, a já jsem byl v jedné místnosti, kde jsme data řešili pro Huberta a další z vedení. A vlastně ten meeting probíhal…

V místnosti, kde jsme byli dva, jsem dostával otázky typu: “Rychle mi najděte nějaký počet aktivních uživatelů téhle funkce.” Tak jsem rychle klikal v úkrytu, abych mohl dát Hubertovi i ostatním nějaká čísla, a na tom meetingu dokázali reálně říct: “Tak toto je ono číslo.” Protože oni neměli čas se v tom hrabat a podobně.

A nakonec, myslím, že po týdnu odcházeli jsme jako dva, nebyli jsme vyspalí, ale odcházeli jsme jako z dobré večeře, protože to dopadlo. A to byl takový moment, že OK, bylo to náročné, ale díky práci s daty, všem těm strangleům a všem momentům, kdy ti někdo řekne: „Tomu nevěřím, protože mi to nesedí,“ a ty jdeš demotivovaný, že ta práce nemá smysl, tak jsi viděl ten aha moment, že OK, když tomu dáš čas, peníze, energii a správně roadmapu, dokážeš něco takového udělat.

Podle mě je to takový moment pravdy, ne? Ten týden ve War Roomu. Jakýkoliv legacy kód, cokoliv, co jsi někde před dvěma lety nastavil, na tebe vyplave právě v okamžiku, kdy to nejmíň přeješ, což předpokládám, že na otázku kolik je aktivních uživatelů tří dvou funkcí, je přesně to.

Co znamená aktivní uživatel? No, že to na tebe v ten moment totálně vyplave. Přesně tam nechceš točící se kolečko budoucích problémů. Přesně.

Co tě to naučilo o chybách, které jste udělali? Nebo je tohle standardní situace? Je tohle ideální zátěžový test té infrastruktury? Nebo je to tak výjimečné, že po měsících a letech stavění solidního systému jste to najednou museli přiškrtit, protože prostě potřebuješ rychle za dvě minuty informaci ve vedlejší místnosti a ne feature, na které bude něco stát za dva roky?

Jaký je vlastně přístup z této situace? Co tě to naučilo? Pro mě to byl hodně zajímavý životní moment, který si většina z nás asi neprožije takhle. Asi si vzpomínám, jak jsem kývl na to, že přiletím přes víkend nebo v sobotu, že to nebude dovolená, že to nebude sightseeing. Možná všechny naše transformace, všechna data, všechny procesy a dokumentace nemám dokonalé, protože na to nikdy není čas.

Takže jsem nebyl stresován, ale poprvé jsem věděl, že se nejlepší dá zužitkovat 12hodinový let do San Francisca, tak jsem si stáhl všechny kódy do počítače, protože samozřejmě nemáš internet. Tak jsem to nějak zkoumal velmi punkově. Ale jasně, byla tam velká obava z mé strany, že budeme sedět na meetingu, je jedno s kým, každý se mě bude ptát: „Ukaž mi to a to,“ a očekávat ode mě, že hned něco udělám v úkrytu.

A když se budu trápit, bude to trochu nepříjemná situace, jak to nazvat. Těchto situací tam bylo několik, vždy je to o tom, že přijde někdo za tebou a nemusí to bý vždy v „emergentních“ situacích, ale přijde člověk a řekne ti: „Chci tabulku s počtem aktivních uživatelů za měsíce.“ A ty řekneš: „Super! Ale co vlastně řešíš za problém?“ Jaká je otázka za otázkou? A vždycky dojdeme k tomu, že řeší to, že potřebujeme vidět, zda se ta funkce používá nebo ne.

A my jsme skvělí, a jaká je ta funkce konkrétně? Tímto způsobem dojdeme k velmi konkrétnímu problému, který osoba řeší. Často se mi stává, že ti lidé sami nevědí, co řeší, jen ví, že potřebují nějaká data, protože jim to někdo řekl nebo viděli nějaký screenshot.

Ale vrátím se k otázce, stalo se mi, že jsem poslal nějaký export, který jsem později zkontroloval a zjistil, že čísla nebyla úplně přesná nebo metriky nebyly definované tak, jak jsem si myslel, protože byly během času změněny.

Takže možná je někdy lepší trochu zpomalit, což já velmi těžce snáším a obtížně v tomto stylu pracuji, ale možná je lepší se zastavit, nadechnout a vrátit se, což člověku může pomoct znovu nasměrovat mysl a být schopen vrátit se k počítači s jasnou myšlenkou: „Aha, to je problém, který řeším, a má jednoduché řešení,“ nebo: „Kupíš tu kačku a ladíš to s ní.“

Takže něco na ten způsob. Myslím, že všechny ty chyby, mohli bychom je klidně nazvat fuck-upy, jsou pro mě vždy nějaká lekce, kterou si odnáším. Mám pocit, že všechny ty fuck-upy mě posunuly dál, že si uvědomíš: „OK, příště, až budu dělat export pro SILVL, možná ho pošlu kolegovi, který nemá čas, ale nechám to zkontrolovat, protože je to důležitá věc,“ oproti situaci, kdy si myslíš, že to je super, ale možná těch pět minut druhýma očima nebylo špatný nápad.

Tvoje první zastávka v Pravdivou hledu trvala tři roky. Jak vypadal Pravdivou hled a tvoje práce, než jsi odešel? Jaký tam byl motor?

Těsně předtím, než jsem se rozhodl odejít – protože tato story je taková, že jsem už byl dost unavený. To se nemusí zdát, ale lidé, kteří to zažívají ve svých firmách nebo v rychle rostoucích startupech a scale-upech, vědí, jak je to náročné.

Dal jsem si takové dva týdny odpočinku, ale ještě před tím, než přišlo vážné oznámení, které jsem nevěděl dopředu, co bude, a pro mě to byl velký aha moment: všichni jsme se bavili o Solsterix analytice, jak vytvoříme super Looker Explory, Good Data, Tableau, Dashboardy, lidi to budou používat a bude to skvělé, a datový tým nebude vázaný na analytiku.

Sirius byl ale úplně bez datového týmu, takže jsme to nemohli zvládnout. A tehdy přišel moment, že aha, to, co děláme, funguje a má to smysl, že by business dokázal najít věci i sám.

Ano, prošli jsme si ABC nebo AB testy, a řada dashboardů byla hotová a stále se recyklovala, ale ten moment byl: OK, to, co jsme vytvořili, funguje a je čas se posunout dál.

Byl jsem unavený, blížil jsem se k vyhoření, ale potřeboval jsem si odpočinout. Myslím, že to nás bylo zhruba 300 lidí, když jsem odcházel. Firma byla poměrně slušná, ale věděl jsem, že další půlrok v Productboardu by znamenal vyhoření a nechtěl jsem do toho jít.

Tak jsem si dal dva týdny dovolenou a už jsem se nevrátil, protože jsem zjistil, že existují i jiné firmy než Productboard, které mě zaujaly.

Setkal jsem se s Davidem Pavlíkem ze Shipmonku, jeho příběh mě velmi zaujal, Netflix a SpaceX. Vyprávěl jsem mu o Productboardu, o datech, která tam řešíme, a rychle jsme došli k tomu, že oni potřebují lídra na data.

Nikdy jsme moc nepřemýšleli o logistice jako o novém byznysu.

Jasně, logistiku jsem mohl s SAPem skupovat ve firmě, ale Shipmonk byl úplně jiný byznys.

Takže ta oblast byla pro mě úplně nová. A když ji dnes hodnotím, možná to byl zbytečný krok vystoupit z byznysu, který jsem do té doby znal.

Protože e-commerce, B2B SaaS, to jsou virtuální byznysy, všechno je někde jinde.

A tak jsem si řekl, že zkusím Shipmonk – zajímavá česká-americká firma, pro mě naprosto neznámá.

Nevím, do jaké míry je dnes známá, ale velmi.

Těsně předtím, než jsem prožil vyhoření v Productboard, Rockfree, Mall Group a Productboard v době největšího růstu – stačila by mi jedna taková štace, a potřeboval bych spíš dva měsíce dovolené než dva týdny.

Shipmonku určitě narostl a dnes nemusíme vysvětlovat, co dělá, Honza se dostal mezi nejbohatší Čechy.

V jaké chvíli jsi tam nastupoval? Jaká byla mise?

Nastupoval jsem do velmi zajímavé firmy; Shipmonk funguje tak, že vývoj sedí v Praze v Karlíně a sklady jsou v Americe, dnes už myslím i v Evropě, možná i v Chebu.

V době, kdy jsem nastupoval, bylo to tak, že centrála byla na Floridě, s velkým skladem, a vývoj byl tady v Čechách.

Na prvním obědě s inženýrem jsem se ptal, jak vyvíjejí nové funkce ve skladu.

Musíš pochopit, že sklad je o tom, jak jde krabice z bodu A do bodu B, a celou logiku pak přesměruješ.

Funguje to, máme tady lidi, kteří tomu rozumí.

Co ještě pro mě bylo důležité, a asi důvod, proč je Shipmonk tak úspěšný, je kombinace českého talentu a amerického byznysu.

Když jde o data, tam byli dva lidé, kteří nějak fungovali, ale bylo tam stovky až tisíce reportů v Metabase, protože sklad je velmi rychlý, real-time, není čas dělat datový model nebo přesouvat data nějakým ETL procesem.

Byl to relativní chaos.

Aplikace se měnila rychle, data se měnila a metriky zůstávaly logistické, jako například musíš vyzvednout jednu objednávku tvořenou pěti kusy zboží a expedovat ji do půlnoci, protože to je SLA, které musíme dodržet.

To vše bylo vždy stejné, a počítat to bylo velkou výzvou.

Myslím, že mi netrvalo dlouho pochopit, co Shipmonk vlastně dělá a jak to funguje, ale pochopit, jak je to napsané v databázi nebo aplikaci, to je dodnes pro mě velká rocket science.

Musel bych možná strávit roky, abych pochopil, proč je to tak a jak data upravit.

Takže jsem brzy pochopil, že pokud chci mít dopad, tak to asi nebude v Shipmonku, protože bych se musel přestěhovat na Floridu a pracovat ve skladu, což jsem nechtěl v tom teple, abych ten byznys opravdu pochopil.

Protože sklad je fyzická záležitost a Productboard je webová aplikace.

Takže jsem velmi rychle pochopil, že byznysová stránka nebude to, v čem mohu pomoci.

Logistiku rozumím, ale je to strašně složité.

Spíš šlo o to dát dohromady ten technologický stack.

Řešili jsme například streaming, CDC, jak dostat data z produkční databáze do Snowflakeu, aby reporty neběžely přímo na Auroru, která pohání celou aplikaci a sklady.

Když spadne nějaký nevhodný SQL dotaz, sklady se zastaví, což je velký problém.

Řešili jsme tedy, jak najít nejefektivnější nástroje pro přenos dat z AWS Aurory do Snowflakeu.

Překvapivě není mnoho nástrojů úplně úspěšných, protože streaming je složitý.

Můžeme se bavit o binárních logech, které nasloucháš, sleduješ změny, nemáš čas dělat plné reloady, protože dat je obrovské množství.

Každý pohyb ve skladu je jeden záznam a není možné načíst vše celé.

Díky binárním logům vidíš, která hodnota se změnila v jakém sloupci.

Spolu s Kebulou jsme vymysleli řešení, které oni implementovali, což bylo super, protože neměli jsme tady velký tým na data, jen tři nebo čtyři lidi.

Tím jsme odstranili potřebu dělat to in-house.

Byl to pro nás i pro Kebulu velký problém pochopit, co streaming vlastně znamená, není to jen kliknutí na „stream now“ a funguje to.

Důvod, proč jsme streaming řešili, je ten, že nechceme reportovat nad produkční databází, což není úplně dobrý nápad.

A není to vždy dobré ani kvůli indexům, které by se musely měnit kvůli analytice.

Řešili jsme tedy real-time reporting, což by dávalo smysl.

Z mé zkušenosti každý chce real-time reporting, protože proč ne?

Ale nikdo za to nechce zaplatit, protože to je drahá záležitost.

Zkoušeli jsme Snowflake, BigQuery, DuckDB jako databáze, které běží nonstop.

Protože streamuješ data, nemůžeš warehouse „nechat odpočinout.“

Náklady jsou už relativně vysoké jen tím, že běží.

A když to nefunguje správně, je to další problém.

Často jsme tedy řešili, zda chceme real-time, nebo near real-time reporting.

Co znamená near real-time?

Když jsou data o 5 minut starší než realita, změní se něco ve skladu?

Často jsme dělali aplikace a datové produkty pro skladníky, aby věděli, co mají dělat dnes.

Pokud by data byla o 5 minut starší, objednávka už mohla být vyexpedovaná někým jiným.

Takže jsme museli jasně stanovit hranici, co jsou dlouhodobé KPI a co je potřeba v reálném čase, například efektivita směny pracovníků za poslední hodinu versus aktuální potřeba v skladu.

Protože jít sbírat objednávku, která už není, není efektivní.

Rychle jsme se dohodli, že streaming je drahý a není efektivní.

Půjdeme cestou batchových reportů každých 15 minut.

To, co je kritické, zůstane nad produkční databází.

Občas jsme museli upravit indexy a další věci, aby to fungovalo.

Pragmatický přístup: ne všechny designové nápady musejí být v praxi levné a efektivní.

Jaký byl poměr mezi batchovým a real-time počítáním?

Bylo tam několik oblastí, které jsme mapovali, ale vše bylo primárně kolem core businessu.

Co se dělo ve skladu, kde jsi měl televize, viděl, jaký pracovník co odpracoval za hodinu, jaký je trend, jestli se fláká nebo ne.

To bylo v refreshi za 15 minut, protože tam to bylo důležité.

Poměr mohl být klidně 50:50.

Postupně jsme odebírali real-time části z tisíců reportů, které tam vznikly.

Pokud je nikdo nepoužíval, nechávali jsme je na pozdější dobu.

Uvidíme v metadatech.

Attachment Metabase, že to někdo začal používat, tak se k tomu vrátíme, ale primárně řešíme problémy, které máme teď a data, která nevidíme. Super, než se dostaneme na tvou další štaci po Shipmanku, tak opakuješ tady vlastně pořád ten samý stack, respektive Kebula Snowflake Combo, které sis v Mall Groupu vyzkoušel poprvé, a to je v konsolidaci několika středně velkých e-commerce subjektů a jednoho obřího do jedné reportingové platformy.

Potom Product Board, rychle rostoucí scale-up, kde se všechno mění, nyní Shipmank, zase fyzický business. Je to tak, že toto jsou state of the art technologie a vlastně je používáš vždycky, nebo jsou to tvé tools of choice a většinou je to jedno a to, co umíš nejrychleji využít, tak to použiješ, nebo kdy sis sedl na tak dobrou kartu, která se postupem času ukázala jako ten stack, co tě vlastně vyhodil nahoru? Kdyby sis tehdy udělal jiné řešení a zabetonoval se v GoodData, tak bys nebyl tam, kde jsi. Jak tohle vnímáš?

To je velmi dobrá otázka, na to mám možná několik odpovědí. Ta hlavní, která je pro vás zajímavá vzhledem k mému pracovnímu životu, je, že velmi často narážím na to, že máš někdy „distraction“, že si řekneš: „Ten Snowflake je trochu dražší, půjdu se podívat na BigQuery, možná to zmigrujeme a bude to levnější,“ ale to se mi nikdy nevyplatilo. Vždy si říkám: „OK, let's stay focused on the business,“ na ten business a vyříkající se problémy. Jasně, chtěl bych si hrát s novou DugDB verzí, ale nemá to úplně smysl. Takže raději jít pragmaticky a netočit se v kolečku.

Mám pocit, že slovo velocity nemá úplný překlad ze slovenštiny ani češtiny. Speed je vlastně rychlost, jak se hýbeš, ale často můžeš hýbat dokola a nikam se neposunout, jdeš rychle a točíš se v kolečku. Velocity znamená, že jdeš nějakou rychlostí z bodu A do bodu B. A to je přesně to, co si vždy říkám, že ten stack by měl podporovat všechny naše asi firemní OKR, pokud nějaké jsou, a jak vlastně budu pomáhat. Takže je to vždy individuální.

Zatím ten pattern stacku je poměrně zřejmý. Další faktor, který mi tam hraje do karet, je talent lokální v Praze, nebo v celém Československu, nebo v naší časové zóně. Ten network je poměrně zřejmý, že se točí kolem několika firem, a jednou z nich je Kebula, GoodData, DeepNote a další. Takže asi nemám důvod pustit se do nové technologie, kterou neznám, i kdyby byla super zajímavá, ale vím, že pokud najdu někoho, kdo do toho půjde, bude mu trvat půl roku pochopit, jak to funguje, a ten půl rok většinou nemám.

Pokud to správně chápu, DAGDB znáš, víš, že existuje, nějak sis s tím hrál, ale zatím to nebudeš nikam implementovat, prostě čekáš na správnou příležitost, až problém si řekne o řešení v podobě DAGDB, a potom to konečně oprášíš a budeš si s tím hrát, ale do té doby to je na nějakém longlistu věcí, co by tě zajímaly, ale jsou na jistém „heavy master“ režimu. Asi bych to tak shrnul.

Asi pro mě ten moment byl, že jsem zjistil, co znamená DAGDB, když jsem na Twitteru tři dny po sobě četl takové hypeovací příspěvky, že tu je nový Snowflake, a pojďme investovat a nastartovali velké kolo financování, tak jsem si řekl: „OK, zkusím to doma na nějakém CSV.“ Ale velmi dobře si pamatuji všechny problémy, které mě provázely s implementací skoro beta verze Snowflake, že to nebyla úplná procházka růžovým sadem, což asi všichni datoví lidé, kteří pracují s daty a takovými stacky, znají, že to není jen o tom, že to funguje krásně.

Je to o tom, že ráno máš telefonát, že data nejsou, a musíš se probudit a opravit to. Takže bych do velkého produkčního nasazení nesel, pokud to není velká firma. Možná jako lepší příklad je DBT. Myslím, že dnes už DBT nemusíme vůbec představovat. Myslím, že Michal ze Slajda a Jožo z STR odvedli skvělou práci okolo DBT a BlockWallSvitu.

DBT vzniklo jako open source nápad na přesnou verziovanou transformaci. Z toho vznikla velká firma. My jsme ještě v určitých momentech v Product Boardu i Shipmanku řešili, že máme Kebulu, možná to zmigrujeme na DBT, že to bude levnější, protože Kebula nás stojí určitý počet dolarů, DBT stojí tři násobek, a vždycky je debata, kolik to ušetří, řeší se stovky dolarů měsíčně, ale při objemu těch příjmů je to málo, i když zajímavá částka.

Naštěstí jsou to taky peníze, takže to spočítat ve třech buňkách a udělat celkový odhad, co to přinese. A když se na dva týdny zastavíš migrací, takže dva týdny plán, dva měsíce realizace, tak tě to strašně zbrzdí.

Kdybych měl čas, dva měsíce bych věnoval hraní s technologiemi, ale realita je taková, že mám někdy čas jen v pátek večer nebo o víkendu, protože už všichni mi říkají o DBT, že bych tam měl něco umět, abych se do debaty zapojil a měl názor.

Takže když jde o tvrdé peníze, jasné, někdy máš jen odhad. Pěkný příklad je DBT, které změnilo cenový model z flat fee na consumption-based. Takže když jsme migrovali v Product Boardu téměř vše do DBT a platili asi 400 dolarů měsíčně, teď jsme možná na nule nebo ještě horší.

Na druhou stranu nemám čas migraci vracet zpět, protože bych rozbil stack a pak bych večery debuggoval, proč to nefunguje, a to se mi teď nechce.

Kdy to přestane být Hadoopem? Kdy pomocí těchto nástrojů začne přetékat a kdy to bude kritická infrastrukturní priorita? Asi ve chvíli, kdy lidé budou nespokojení, mám na mysli byznys, uživatele nebo analytiky, protože práce pro ně je pomalá, neefektivní.

Když například analytik říká: „To jsem si naklikal velmi těžký explore v Lookeru, SQL je šílené, ale neběží mi,“ tak je super, že jsme investovali čas a peníze do stacku, ale nakonec ten člověk sedí v kolečku a neumí dělat práci lépe z těch čísel, co mu vypadnou.

Je to takový nikdy nekončící feedback loop, kdy mluvíš s lidmi, co si myslí, že někdy to bylo lepší, rychlejší, a teď je to pomalější, tak hledáš příčinu, která je často jen změna nějaké věci: někdo pustil šílenou transformaci bez odsouhlasení, nebo data narostla chybnou funkcí v databázi.

Je to rychlý prototypování, jak se s tím točit, zjišťovat příčiny.

Často používám příklad, že datový stack nebo tooling je buď vitamín nebo pilulka. Buď řeší symptomy, nebo příčinu.

Často vznikne nový tool na určitou část procesu – dokumentace, rychlejší ingestion layer, lepší ETL a podobně – ale je to něco skutečně zásadního, co ti uvolní ruce, nebo další podobný nástroj jako Fivetran, Stitch, Kebula, a další, kterých bych mohl jmenovat hodinu, protože jich je tolik.

Vždy to posuzuji optikou: jak to zlepší můj den? Budu šťastnější, když zmigruju SQL na DBT? Asi ano, protože mám kód verzovaný v GITu a dokážu sám nezpůsobit chybu, protože si uvědomím, že dělám blbost. Ale musím si udělat workflow a projít celým cyklem, jsem na to sám.

Nakonec to může vyústit v situaci, že jsme den před board meetingem přepsali velkou část kódu, kterou jsme ještě ani pořádně netestovali, a omylem jsme ji přepsali v Kebule, či omylem vydali.

Vracíme se k paralelám, kdy je někdy lepší to trochu zastavit a vše přepočítat než mít rychlý prototyp.

Takže je potřeba balancovat mezi tím, aby byznys nezůstal stát a neb čekal, ale zároveň mu nemůžeš dát narychlo uvařené řešení, kterému sám nevěříš.

Já jsem velký minimalista a perfekcionista, takže balancuji tím, že musím za tím stát, musím tomu rozumět, protože já, nebo analytik, co to bude používat, budeme mít další otázky a já nemohu říct: nevím, asi.

Matúš, ty jsi zmínil rámce té lokální sady technologií DeepNote, zvolávám to náhodou, protože tam pracuješ. Můžeš nám o tom říct?

DeepNote sleduji úplně od začátku. Mě velmi zajímají i slovenské projekty, i když žiji v Praze už deset let, sleduji slovenskou scénu. Českou a slovenskou start-upovou scénu asi úplně porovnat nejde, ale na Slovensku jsou zajímavé firmy a jedna z nich je DeepNote.

DeepNote je slovenský start-up, který funguje v Praze, což je super, protože často…

Potřebuješ někde vyjít z jiné mapy, jak to funguje. Myslím, že na Slovensku je ještě hodně práce, jak by se startupy mohly od sebe učit. Ekosystém v Praze je úplně jiný.

My jsme dokonce DeepNote použili v Product Boardu, nějakou úplně beta verzi třeba verze 2.20, nevím, kdy vyšla, úplně náhodně, jen kvůli tomu, že „aha, to je nový Jupyter notebook, možná pomůže našim datascientistům, kteří dokupují RAM v Kebule, stojí nás to peníze a je to nekomfortní“.

Znám ten produkt, sledoval jsem příběh a dostal se do debaty s Jakobem Jurovičem, že DeepNote má funding a velké plány. Řekl jsem si: „To jsem už někdy slyšel,“ což neznamená, že to nemusí být úspěšné, ale cesta je těžká, není to jen o tom, mít funding, samozřejmě.

Navíc slovenský startup Foundry a Superteam – několik lidí z Product Boardu tam pracovalo. Jakob řekl funding a hned se vybavil „frasírovat“ všemi board meetingy a koncem pracovních dnů, úplně vidím ten flashback.

Pro mě to bylo tak, že když jsem odcházel ze Shipmonku, už jsem věděl, že mě ta práce nebaví, že nechci vytvářet kostrové reporty na logistiku, kterou neovlivním.

Abych zamezil vyhoření, i když vyhoření se špatně definuje a každý to má jinak, věděl jsem, že když se ráno probudím a nemám chuť jít do práce, něco není v pořádku.

Tak jsem si dal měsíc, dva pauzu, reálně to byly dva týdny, protože jsem se potkal na nějaké party, možná DataMesh nebo s Martinem Falcomanem, kterého znám z Product Boardu. A on tam měl produkt v DeepNote.

Dostal jsem se tak k tomu, že můj skillset a zkušenosti z Product Boardu by tam byly zajímavé, řeší revenue reporting problémy. Nevím, kolik revenue čekají, ale „Poď nám s tím pomoci.“

Na to jsem vůbec nemyslel, nedělal průzkum trhu, ale řekl jsem si: „OK, zkusím to.“ A byla to dobrá zkušenost.

Když se podíváme na Product Board v letech 2018–2021, byla to extrémně rychle rostoucí firma, trh i klima byly slunečné, žádný mrak, občas oblačnost nad Golden Gate v San Franciscu, kde se vyráběly peníze. Silicon Valley házelo peníze z Letova.

Byla to dobrá zkušenost. Myslím, že rozpočet nebyl nekonečný, ale když si něco obhájíš, není problém koupit Looker, není problém koupit kolebce Snowflake, bude to raketa, ale ušetří to lidi.

Když jsem nastupoval do DeepNote, bylo to minulý rok, mladší z vás možná ví, v posledním roce a půl party skončila, takže mluvíme o období, kdy ta party byla na vrcholu.

V Product Boardu jsi zažil ten hype, Product Market Fit, o kterém mluví Vicey. Růst dvoucifernými čísly každý měsíc byl normální.

Protože mnoho firem nepracuje tolik zblízka, musíš je poznat, pro mě byla DeepNote zkušenost o tom, že potřebují pomoc s daty a analýzou, a to se dá opravit během několika dní nebo týdnů, pokud to děláš sám, protože víš, co dělat a jdeš na to. Business není tak složitý, abych ho nepochopil rychle.

Nebyla to vlastně „overcompensation,“ že ses z Product Boardu přesunul do Shipmonku, kde byla úplně jiná learning curve – fyzické sklady, jiná časová zóna a tak dále? Najednou jsi zjistil, že ses možná zakousl do většího kusu, že tam nemáš tu přidanou hodnotu, páku, jak bys chtěl.

DeepNote byla vlastně jako Product Board a slovenský super tým. Předpokládám, že když jsi tam přišel, mluvili jsme o podobné velikosti, tedy asi 40–50 lidí.

Takže to umíš? Kéž by to tak bylo, ale faktorů je milion. Na to asi není jednoznačná odpověď, nebo se mě jinak zeptej.

Když nás poslouchají lidé na začátku kariéry nebo před velkými kariérními změnami, tak teď, když o tom mluvíš, to zní, jako že na večírku potkáš někoho, kdo je zakladatelem nového startupu, který bude za dva roky v top 3 startupů, přesvědčí tě jít dělat data, i když o nich nic nevíš, a pak to vybuchne. Je v tom rada? Nebo jaký byl tvůj vnitřní proces? Nebo to byla čistá náhoda? Co ti otevřelo tuto příležitost?

Pro DeepNote byla skutečná příležitost, že jsem si uvědomoval fungování datového stacku a ti, co se ztrácejí v bulacích (bulkových dávkách), API a všem možném, co nějak místně funguje s GoodData a dalšími, tak je vidět i z akvizic a fundingů DBT před dvěma roky, jakou valuaci dosáhli.

Jasně, valuace je pouze číslo, které někdo chce zaplatit, a tomu se často nemá cenu zabývat, ale logickou příležitostí, resp. důvodem, proč jsem do toho nakonec šel, bylo: co když jsem součástí něčeho, co může vyrůst, protože máme super český a slovenský talent a americký či slovenský trh.

A protože DeepNote bylo blízké mému srdci, používal jsem ho, viděl jsem, jak se rychle vyvíjí, talent je stále velmi zajímavý, pár lidí jsem tam poznal, byl jsem s nimi na kávě, ptal jsem se, jaká je realita.

Takže to byl můj osobní referenční rámec a veľmi jsem to nepremýšlel. Řekl jsem si: „Zkusím to, dám tomu čas.“

Vždycky říkám, že zkušební doba není jen pro firmu, ale i pro mě, kdy si dám 30, 60, 90 denní cíle – to chce ode mě manažer, i když ne vždy to tak je.

Pak si dám pauzu po měsících a řeknu si: "Je to to, co chci dělat, baví mě to, nebo už vstávám ráno s tím, že dnes otevřu…

[poznámka: text v původním materiálu bohužel končí nedokončený]

U ubytování během chvíle blikalo 20 zpráv a věděl jsem, že čtyři z nich budou nepříjemné, protože něco prostě někde vypadlo. Takže asi jako souhra těchto faktorů mě stále vede k tomu, že DeepNode je velká firma a datový trh je rozsáhlý. Data, všechny datové problémy řeší každý; záleží na tom, jakou máš motivaci je řešit, ale myslím si, že to může být pořád zajímavý segment. Pro mě osobně však bylo těžké vybrat si další firmu, například Product Board nebo Shipbank. Neříkám, že ty firmy nejsou zajímavé, ale DeepNode mi prostě byl blízký. Proto jsem tam šel, poznal zakladatele a hned druhý den jsem přišel do kanceláře a řešili jsme fungování reportingu.

Zpětně je to pro mě velká lekce – mohl jsem se ještě zastavit před podpisem u Kusainu a Ofru a možná se podívat na pár dalších firem a zjistit, kdo kde ještě funguje. Protože to sami poznáte – Data Talk, newslettery jsou skvělé pro všechny datové specialisty a další skupiny, jako Data Flow nebo Facebookové skupiny, ale mám pocit, že není nikde napsáno, že ty firmy nemají čas pohovory s lidmi, které neznají, takže berou jen ty, které znají. Takže to zpětně uděláme raději jinak: řekneme, že mám zajímavou nabídku, ale raději bych se ještě podíval někam jinam.

Pojď nyní trochu převést na téma, co jsi vlastně v DeepNode udělal. Myslím, že jsme se k tomu ještě nedostali, a pro mě je to zajímavé, protože je to potenciálně velká firma, ale také čistě datový, analytický produkt. Jak vlastně vypadá práce s daty u nich? Proč jsi si vybral DeepNode?

Přišel jsem tam s reálnou, nebo spíše s velkou zkušeností jako data practitioner, což bylo něco, co jim chybělo ve snaze vybudovat firmu na úroveň Unicorna, nebo jak to nazvat, tedy prorazit na celosvětovém trhu. Lákalo mě, že mohu postavit celý analytický a inženýrský stack, dělat všechny role od A do Z, tedy být analytikem i inženýrem zároveň a mixovat tyto pozice. Ale hlavní věc byla, že mohu i trochu ovlivnit produkt.

Například jsme měli plán vytvořit novou funkci notebooku, která umožní lepší plánování spouštění notebooků. Produktový manažer se domluvil s designérem a inženýrem a společně to vymysleli. A ten moment byl skvělý, když přišli za mnou s nějakým mock-upem ve Figmě a říkali: „Klikni si to a ukaž, jak to budeš používat ty jako data practitioner.“ Moje práce byla tedy rozdělena na několik částí, vždy dynamicky. Nejprve jsem velmi rychle odstranil základní problémy s daty, potom jsem se přesunul k produktovým rolím, nebo spíše nějaké formě beta tester role, což bylo zajímavé, protože jsem produkťák, který testuje produkt.

Člověk tak nemá čas dělat jen analytickou práci, protože má čtyři schůzky, čtyři kola a čtyři Figmové prototypy, které musí proklikat a dát nějaký názor. Matúši, zapracuj mi. Interní „placený klient“ ;-) Ano, dá se snadno potěšit dobrým jídlem a pivem, ale to asi není hlavní motivace. Pro mě byla super změna, že nejsem jen za všemi nástroji, které už dlouho znám, ale že můj názor skutečně má váhu při plánování vývoje na další čtvrtletí. To byl hnací motor.

Ve finále jsem často nosil různá klobouky – někdy jako sales engineer jsem ukazoval lídrům a zákazníkům, jak lépe používají DeepNote, než to dělám já reálně. Byl jsem na kolech, kde jsem ukazoval, kde klikám a co píšu. Nakonec mi přišla zpráva na Slack, že to zvýšilo revenue. Je to jednoduchá věc, ale opravdu to pomáhalo našemu sales týmu ukázat užitek cloudového notebooku oproti Google Colab, který není úplně kolaborativní. To je skvělé.

Z mých zkušeností takováto role, neboli tento typ obsahu, chybí u většiny B2B firem v datové oblasti. Velké platformy umožňují dělat cokoliv, ale chci vidět, jak se na nich dělá něco opravdu užitečného ihned. To tak vnímám.

A ještě mě na tom baví jedna věc: říkáš o největších, nejvýraznějších značkách na naší technologické scéně. Všechny jsou triple A ranking, vyhrávají soutěže, jsou na obálkách časopisů. Na druhou stranu věci, které řešíš, jsou filosoficky triviální – například přerozdělování rozpočtu. Ačkoliv to může znít jako učitelství, což nechci říkat degradujícím způsobem. V přípravě se psal text „Let’s Talk BI again“. Mám pocit, že v dnešní bublině se vše točí kolem AI, automatizace a velkých projektů, je to sexy téma, ale BI může znít trochu zastarale.

Data warehousing 2.0 a BI jsou stále klíčové věci. Na tvém příběhu se mi líbí, že i vyspělé technologické firmy s velkým financováním řeší základní provozní, finanční a produktové úkoly. Není to jednoduché a potřebují specialisty. Vnímáš to také tak? Že 20 % základních věcí tvoří 80 % hodnoty. Během tří týdnů se to může vyřešit a pak se zaměřit na okrajové případy.

Myslím, že jsem měl štěstí na výběr firem, ale vycházel jsem hlavně ze zakladatelů, CEO a manažerů, kteří chodili každý den do práce. Viděl jsem například Rokewe, Jakuba Haverlanta, což mohlo být skvělé, dále Huberta Palána, Honzu Bednáře v Product Boardu a Jakuba Jurových v DeepNote. Vždycky jsem si udělal due diligence – kdo jsou za lidé, jak přistupují k týmu, jestli mají blogy, přednášky. Šel jsem s nimi na kávu a pokud měli zájem, bavil jsem se s nimi o tom ještě před přijetím.

Toto mě hodně posunulo, protože firma může skončit jakkoli a i velká firma může mít komplikace. Mám spoustu příkladů z historie, kdy to nevyšlo, nebo představa firmy byla horší, než skutečnost. Vždycky mě naučilo, že když jsem měl velký problém, nemohl si s ním poradit, mohl jsem napsat řediteli, že mám názor, co je problém. Oni se o to postarali, je to jejich firma, ne moje. I když chci být vlastníkem celého stacku, produktu, tak vždy mám svůj názor.

Zpětně se mi často vracelo, že mě buď přesměrovali na někoho z vedení, kdo to řeší, nebo daný člověk to už někde zažil, nebo jsem jednoduše cítil, že do těchto česko-slovensko-amerických firem vždy přichází nový člověk, často top manažer na celosvětové úrovni. Nejde o snižování lokálního talentu, ale i v DeepNode jsme měli experty na sales a community building přímo z Bay Area. Takže jsem dostal…

Asi mi vyplatilo sázet na firmy, které nějakým způsobem přežívají na trhu, který může jít nahoru a dolů. Ty křivky jsou totiž jasně viditelné, zejména jako nyní. Vždycky to bylo o zakladateli: jak k tomu přistupuje, jak pracuje. A hlavně jsem hodně pracoval přímo s C-level. Jasně, někdy se bavíš s datovým inženýrem na pět úrovní vzdálenosti od C-levelu, ale ve firmách, jako jsou tyto, firma je viděna z perspektivy vedení. Jasně, někdy ti odpoví za tři dny, týden nebo nemá čas, protože řeší něco jiného, ale mít tu možnost je super věc.

Pokud zůstanu u DeepNode, jak se tam firma posunula během mého působení? Co jsem zažil, co jsem nastavil, vyzkoušel? Asi jako jste slyšeli, že jsem měl několik rolí, někdy i několik najednou. Dělal jsem vše, co firma potřebovala.

To je podle mě skvělé u práce v datech. Reporting, dashboarding je základ, který každý potřebuje, všechny ty Oury a Fitbity. Ale co je zajímavé: rychle s vhodným stackem můžeš vytvářet i další produkty, které nejsou jen datové, ale podporují sales nebo workflow. V DeepNode jsem řešil například správné nastavení Salesforce, protože jsem jej znal z Product Boardu a věděl, jak řešit směrování leadů a round-robin metodu.

Byl jsem tedy i sales ops engineer na nějaký týden, protože jsem věděl, že je to problém a externí pomoc by zabralá dva týdny, než to pochopí. Bavilo mě to, každý den byl jiný, ale brzy jsem pochopil, že můj dopad tam není úplně zásadní, že problém budování datového týmu není to, co DeepNode momentálně řeší.

DeepNode se proto rozhodl vrátit k produktu a možná pivotovat někam jinam. Držím jim palce, je to těžká práce a není to jen o skvělém týmu a financování. Nestačí mít dobrý product market fit, ale také „founder market fit“, jak říká Vojta Roček.

Já jsem se proto rozhodl, že si dám pauzu, sabbatical. Přesunul jsem se z full-time pozice na externí spolupráci, pomáhal jsem s věcmi, které jsem nastavil, zdokumentoval, ale dal jsem si volno. Tak jsem si udělal druhý pokus o dvojměsíční sabbatical, protože ten první skončil po dvou týdnech; dnes to hodnotím jako nejlepší rozhodnutí roku, protože jsem si konečně odpočinul.

I když to nevypadá, všechny ty burn-outy a podcasty či knihy o tom, jak nevyhořet, na tom něco bude. Vždycky jsem si říkal „to nějak zvládnu“, ale pak vyhoříš, půjdeš den do práce a budeš spokojený, protože si dáš týden u moře. Týdenní či dvoutýdenní dovolené jsou fakt málo. Sabbatical na dva měsíce, pak už jsem se nudil a začal chodit na meet-upy a startupové eventy.

Během kariéry mě málokdo potkal na startupových akcích, protože jsem neměl čas je navštěvovat a nechtěl jsem chodit tam jen proto, abych byl unavený další den. Raději jsem byl odpočatý a makal od rána.

Na meet-upech jsem začal sdílet své příběhy, které jsem si dříve nedokázal uvědomit, že by mohly někoho zajímat. Proto dneska sedíme, protože někoho zajaly moje zkušenosti a lessons learned.

Po dvou měsících sabbaticalu, když je hezky, chodím na BigScale, končí to většinou kolem 12. večer a nemám co dělat, tak si dělám rozhovory. Prošel jsem všechny zdroje, joby, LinkedIn, Data Talk, newslettery a další tipy od přátel.

Řekl jsem si, že mám čas, tak ho využiji k rozhovorům. Když dělám výběrová řízení, chci se v tom zlepšit, protože tým pořád buduju. Dělám si poznámky. Všechno bylo přes Zoom.

Za asi měsíc jsem absolvoval asi 15 firem, přes 100 hodin na různých kolech. Obvykle jsem měl ráno tři pohovory za sebou a zároveň musel být rychlý, protože další kola na mě čekala. Bylo to super, lepší pozice v hledání práce.

Zjistil jsem, že zde je spousta zajímavých firem, o kterých se příliš nemluví, které mají zajímavé výsledky, o kterých také není mnoho slyšet. Při pivě někdy zjistíte, že máte kontakt na člověka, který by mohl pomoci.

Nakonec jsem dostal pět nabídek a rozhodl se přestat dělat další case studies pro další firmy. Čtyři nabídky byly z kroužků, ke kterým jsem se dostal skrze různé vzkazy či party – například na data mesh after party jsem komentoval LinkedIn statusy nebo jsem napsal, že mám chuť pomoct startupům.

Už jsem si i vybral firmu, kam jít pracovat, ale pár hodin před podpisem DocuSignu od nich mi zavolal Jirka Brunslík z Product Boardu, že mě zve na oběd, a jestli nechci přijít se podívat.

To byl osudový telefonát, který zastavil mé předchozí plány. Požádal jsem o týden na rozmyšlenou, protože to bylo důležité i pro ně. Nabídl jsem, že můžu nastoupit hned další den, protože mám čas.

Velmi rychle, aniž bych absolvoval klasická kola v Product Boardu, jsem dostal druhý DocuSign. Začal jsem tedy řešit, co chci dál se životem.

Situace v Product Boardu by vydala na samostatný podcast, který můžeme někdy udělat. Problém, který tam řeší, je, že dříve měli poměrně velký a úspěšný datový tým lokálně, ale kvůli byznysovým rozhodnutím se přesouvají role do San Francisca. Nejefektivnější tedy není „nahoru-dolů“ přesouvat role, protože talent na americkém trhu je drahý, oproti našemu relativně levnému, ale efektivnímu lokálnímu trhu.

Product Board dnes nemá nikoho, kdo by je v datech výrazně vedl. Výzva byla tedy jasná – mají složitý stack, který znám, ale dva roky jsem tam nebyl, nemám tam moc lidí, od kterých se mohu dozvědět, co kde běží. Pro mě to byl proto zajímavý challenge, který po pauze potřebuji nebo chci. Už vstávám v šest ráno a někdy už nemám co dělat, podcasty mě přestaly bavit.

Samozřejmě tam bylo několik faktorů, i před DeepNode jsem šel do toho s jednoduchým Excelem, ale…

(Je zde zřejmě text nedokončený; v tomto bodě končí původní text.)

Nebo spreadsheet, kde jsem si porovnával všechny ty firmy. Jasně, kompenzace je jeden faktor z toho, ale pro mě to až tak důležité není. Samozřejmě, pracovat zadarmo není úplně dobré a každý člověk má nějaké minimum a optimum. Ale asi tak, jak se dnes ty kompenzace pohybují, je to plus minus na nějakém platovém pásmu. Jasně, jsou firmy, které připlácejí a které ne, ale všechny ty nabídky nebo ty bulkies jsem měl dost podobné.

Ale ta výzva v Product Boardu byla právě v tom, že tam po roce nefungoval datový tým. Stack funguje, což je dobrá zpráva pro všechny, kteří v Product Boardu budovali ten datový stack, a nebyli jich málo. Ale po roce tam bylo self-service a do dneška to funguje na té self-service bázi. To, že jsme jim investovali čas do všech těch review, tagů, dashboardů, že toto je verified, se opravdu vyplatilo. Ale samozřejmě lidé mají otázky, co s novými projekty, proč se data někdy nereferencují, něco spadne, něco se přepočítá, něco se migruje. Asi klasické problémy.

Takže ta výzva spočívala přesně v tom, že potřebují někoho, kdo bude efektivní v dnešní startupové, tržní, B2B, SaaSové klima, kdo dokáže pomoci firmě dále růst. Když jsem se konečně rozhodoval a dal si s všemi lidmi, které znám v Product Boardu, několik káv, ptal jsem se jich právě na tu firmu. Bylo to hodně káv. Říkám, asi sto hodin. A to jsou nové desítky hodin. Jednou jsem si dal 6–7 espress a nebyl to dobrý nápad, takže to nedoporučuji.

Ale abych se vrátil k tématu, věnoval jsem tomu opravdu čas, jak jsem si asi před Shipmankem a DeepNote uvědomil, že potřebuji sám prozkoumat všechny možnosti. Udělal jsem si rozsáhlý due diligence až do fáze, kdy jsem si volal s Hubertem a ptal jsem se na to, jaký mají příjem, jaký mají burn rate, jaký mají runway, kolik stojí stock option dnes versus v roce 2018, jaký tam je potenciál. A vlastně jsem došel k velmi jednoduchému závěru, když jsem si prohlédl všechny firmy, které mi nabízely práci, řekl jsem si: chci do nich investovat svoje peníze, investoval bych například milion korun. A pokud ano, investuji také svůj čas. Když byla odpověď ne, pak často byla i ta druhá ne, protože čas je velmi omezený zdroj.

A ta výzva v Product Boardu spočívá přesně v tom, že mají přibližně pět let stack, model, 300 tabulek, 200 dashboardů a 1000 reportů. Pro mě je to víceméně jedno v dobrém slova smyslu, protože dnes vyrobit report je otázka tří kliknutí a pěti sekund. Ale příležitost, kterou momentálně v Product Boardu máme, je postavit něco nad tímto stackem a modelem, nějaké nové aplikace.

V dnešním světě ChatGPT, všech těch AI hypeovacích nástrojů a metodologií si myslím, že je to skvělá příležitost to zkusit. Ale velmi rychle, protože nemáme čas strávit týden zavření v místnosti a zkoušet to.

A vlastně to mě na tom lákalo – já jsem si velmi dobře uvědomoval, že to sám celé nezvládnu nebo nezlepším a že budu muset najít lidi, kteří půjdou do toho se mnou. Toto bude hlavní, nebo alespoň doufám, že to tak bude fungovat, když vezmete Product Board dnes a datový stack versus jakoukoli jinou firmu, která chce začínat s daty, je tam rozdíl pěti let. To se nedá moc urychlit. Jasně, dá se, ale podle zkušenosti to není dobrý nápad.

Takže bylo to poměrně jasné rozhodnutí, že zkusím Product Board, dám tomu zkušební dobu a uvidíme.

Takže máš jakoby tu práci hotovou a když děláš nějakou vyšší část toho hodnotného řešení, nějaké data produkty, které jsou součástí produktu, to je ta výzva, chápu to správně?

Výzev je asi několik, mám jich asi dvacet někde v Product Boardu zapsaných s prioritami a všemi dalšími faktory a dimenzemi. Ale tou největší výzvou je vrátit firmě důvěru v data, protože tam půl roku nebyl žádný owner, který by se reálně postavil k tomu oddělení a řekl, že prostě data teď nefungují, ale pracujeme na tom. Lidé nevěděli, co se děje.

To byl jeden z důvodů, proč vlastně potřebují někoho na data – protože data musí fungovat a měla by fungovat. Co se týká toho, co budeme dělat, tak já jsem momentálně sám v týmu a máme externí pomoc, protože jsem sám na plný úvazek. Vždy se velmi orientuji podle peněz, tedy kolik dolarů nám dané řešení přinese, kolik nových zákazníků, leadů to přivede.

Takže podle mě je to super příležitost nejen budovat datový stack, data, reporty, dashboardy, ale i budovat firmu.

Mohli bychom mluvit o dalších projektech, které jsem dělal, ale příkladem je DeepNote, kde jsem budoval sales a ops tooling, což s daty přímo nesouvisí, ale musíš udělat reverse ETL za pět minut a jedeš.

Ano, asi to není úplně nejlepší řešení, nejsnazší, ale funguje to do určité míry a ve startupovém prostředí nemáš čas dělat věci pořádně, kdybys chtěl, tak nemáš čas.

To byla příležitost. Pak jsem si zhodnotil data, která jsem řídil, kolik je financování, revenue, burn rate. Řekl jsem si, že je to asi nejlepší příležitost na trhu, kterou chci zkusit. Když se podíváme na dnešní trh nástrojů a na DeepNote v celkovém ekosystému těchto nástrojů, a potom se podíváme na projektový management a jaký je dnes svět nástrojů, kde máš stovky nástrojů, product management už jich má několik, ale je to stále velký prostor, jak si vzít z toho velkého koláče trhu.

Takže to byl nejlepší investiční ticket z nějakého úhlu pohledu?

Doufám. Na československém trhu?

Doufám. Máme super firmy, ale díky tomu, že mám ten kontext a znám stack, byl jsem od prvního dne efektivní, protože jsem doručoval. Jasně, některé věci jsem musel pochopit déle, ale došel jsem do Jiry, kde bylo 20 ticketů a 100–500 jsem vyřešil do hodiny.

A tři byly tvoje vlastně?

Ano, tři byly méně důležité. Všichni dávali úkoly svým týmům.

Takže abych k tomu říkal, jestli je to ten ticket, věřím, že ano. Věřím, že dojdeme do většího momentu typu IPO, vstup na burzu, nějaké akvizice, nebo možná další kapitálové kolo. Ale zase na druhou stranu díky tomu, jaká je naše kultura transparentnosti, vím, že to není primární problém, který teď řešíme.

Problém, jako každá firma řeší, je jak prodávat produkt a jak najít lepší lidi na trhu, kteří pomohou s produktem a s jeho budováním, samozřejmě.

To beru samozřejmě z hloubi, bez toho to moc nejde.

Takže nakonec jsem si spočítal, že až přijde moment burzy, IPO nebo něco podobného, budu mnohem lépe spát s tím, že jsem se vrátil a pomohl firmě, protože jsem věděl, že má potřebu mé pomoci. A pevně věřím, že se potkáme možná za pár let a bude zase nějaká velká zpráva, třeba první IPO, nebo druhé? První? Uvidíme, uvidíme.

Možná předběhne nějaký rohlík, který si myslím, že k tomu má velmi nakročeno.

Matúši, hodně jsi zmiňoval, řekl bych, monetární analytické důvody, proč je teď správný čas naskočit zpátky do Product Boardu. Ale myslím, že všem je jasné, jak moc ti je firma lidsky blízká, že tam máš to srdce pro firmu. Co z tohoto pohledu tě tam teď čeká? Co tam pro tebe je?

Když jsem 1. září nastoupil do Product Boardu po přibližně týdnu rozhodování, věděl jsem, že to sám celé nezvládnu, že potřebuju najít lidi, kteří půjdou se mnou a pomohou to nastartovat.

Firma má dnes 350 lidí, není to startup. Asi by definicí byla spíš scale-up, který má všechny další problémy.

Takže moje první logická volba nebo plán na první dva týdny bylo najít ty lidi. Protože vím, že musím najít někoho, koho přesvědčím dát výpověď do konce měsíce, aby mohl nastoupit 1. prosince, i když je to extrémně rychlé.

A potřeboval jsem to zvládnout.

Co se mi podařilo a za co jsem opravdu vděčný, je, že jsem přesvědčil dva lidi, kteří se vrací do Product Boardu. Konkrétně Petra Formana a Honzu Řasu, kteří odešli minulý rok a rozhodli se vrátit na mojí cestu nebo na naši původní cestu.

Myslím, že to ukazuje velmi dobře i leadership Product Boardu, že se zkouší hodně věcí, protože máte možnost, máte funding a čas.

Ale pokud něco nefunguje, vrátíte se k tomu, co fungovalo.

A tím, co fungovalo, byl lokální přístup, blízkost produktu a inženýringu.

Nakonec mi hodně pomohlo je přesvědčit, že jejich čas, respektive práce v Product Boardu na konci nebyla úplně zajímavá, byly tam různá politická témata, která úplně nechcete řešit.

Ale podařilo se mi je přesvědčit, aby se vrátili a vracejí se zpět do týmu.

Takže vznikne takový OGs datový tým Product Boardu – návrat ztracených synů.

Ale co jsem chtěl říct je, že už nemám další bumerangy v rukávu, takže je dost možné, že brzy budeme otvírat nové pozice.

Kdo má zájem mluvit o datech a o tom, jak pracujeme v Lookeru, rád zve na kávu a třeba z toho něco vznikne.

Přesně tak, koho z vás zaujaly akcie Product Boardu a Matúšův šarm, ten hledá.

Předchozí zaměstnání v Product Boardu není podmínkou.

Nemusíte se vracet, můžete přijít vůbec poprvé.

A my ti moc děkujeme, že jsi přijal naše pozvání a přišel nám popovídat o své cestě Product Boardem tam a zase zpátky.

Zároveň můžeme naznačit, že pravděpodobně tohle není naposledy, kdy posluchači Data Tolku mají šanci tě slyšet – chystáme vánoční speciál.

Zatím vše tajné, významní hosté, hlavně Matúš.

Děkujeme moc, ať se daří, držíme palce.

Díky moc.

Já děkuji za pozvání a budu se těšit na vánoční speciál.

To je všechno.

Děkujeme, že jste doposlouchali další díl Data Tolku.

Také děkujeme našim partnerům Big Hub, Vypnuto, Manta, Notino, Atakama, Jean Bimu, Seznam.cz a Mews.

Pokud vás zajímají další informace ze světa datových technologií a z československého prostředí,

nechť vás provází data.