V 2FRESH se věnujeme produktovému designu a navrhujeme weby, aplikace, zákaznické portály nebo třeba nemocniční informační systémy. A v našem podcastu si povídáme s produktovými a designovými lídry o tom, jak funguje design u nich ve firmách. Povídáme si hodně o tom, jak design může pomáhat byznysu. Snažíme se najít nějakou inspiraci v tom, co funguje a nefunguje.

2Fresh Design Podcast: Rozhovor s Tomášem Netrvalem - Head of Product v Keboola, který popisuje, jak přepisují svůj produktový proces pomocí AI nástrojů, jako je Cursor, a proč dnes dávají přednost funkčnímu prototypu před vymazleným mockupem ve Figmě.

Ahoj, vítejte u dalšího dílu 2Fresh Design Podcastu. V 2Fresh pomáháme firmám s UX, produktovým designem nebo jejich designovou vyspělostí. Navrhujeme weby, aplikace, zákaznické portály nebo třeba nemocniční informační systémy.

Ahoj.

My si spolu dneska budeme povídat o tom, jak v Keboole měníte způsob, jakým stavíte produkty, kdy do celého procesu intenzivně zapojujete AI, včetně toho, že místo Figmy navrhujete nové věci přímo v kódu. Já Keboolu znám už dlouho a vždycky to byla respektovaná česká technologická firma, ale pro naše posluchače, co vlastně dělá Keboola?

V jedné větě, Keboola je self-service datová platforma, která pomáhá našim zákazníkům efektivně integrovat, procesovat a analyzovat data, která potřebují. Dále to pokračuje v naši celkovou vizi — automatizaci business procesů s pomocí AI, kterou se nyní snažíme intenzivně zabudovat dovnitř.

Zaznamenal jsem, nevím, jestli tomu rozumím správně, že se snažíte ta data zpřístupnit i méně technickým uživatelům. Obvykle s těmito systémy pracují spíše techničtí uživatelé, ale mám pocit, že Keboola se snaží přinést tyto možnosti i manažerům, kteří tu technickou znalost nemají. Je to tak?

Spíš jde o méně technické lidi v datovém týmu. Když máme třeba větší organizaci a v ní různé týmy, tak pomáháme fungování těchto týmů tím, že si mohou zpracovat a sdílet datové výstupy. Vidíme také, že méně techničtí uživatelé v business jednotkách dodávají technické dovednosti businessu, a proto potřebují platformu na správu dat. Nemají za sebou třeba pět let zkušeností a nejsou to senior datoví analytici — i na ně cílíme. Souvisí to s AI, která by měla významně pomáhat s přípravou dat a se vším, co je s tím spojené.

Tohle podle mě ještě hodně změní, jak firmy fungují, a my si o tom budeme dneska také povídat. Ty jsi Head of Product, jaká je přesně tvoje role ve firmě a jak vypadá váš produktový tým?

Moje role, stručně řečeno, spočívá v exekuci naší strategie. Zahrnuje přípravu roadmapy, řízení týmu produktových manažerů a designérů, realizaci naplánovaných iniciativ a samozřejmě hledání nejefektivnější cesty, jak toho dosáhnout společně s naším engineeringem, abychom rychle dodali hodnotu.

Do té roadmapy věci navazují na strategii, o které jsi mluvil. Ta strategie vzniká na úrovni boardu, nebo kdo ji u vás vytváří?

Je to tak. Strategie vzniká na úrovni našeho leadership týmu, kde máme definovanou misi a cíle, kterých chceme dosáhnout. Není to fixní a rigidní věc.

Máme možnost to měnit, když vidíme, že jsme se netrefili, tak to změníme a stanovíme si nový cíl v rámci strategie. Aktuálně máme tři hlavní cíle, které podporují strategii, a snažíme se na ně napojovat iniciativy, které mají podpořit růst a to, čeho chceme dosáhnout.

Máte nějaký pravidelný rytmus k té strategii, ve kterém ji aktualizujete nebo revidujete? My třeba v 2Fresh se snažíme udělat na rok nějaké cíle, nějakou vizi, a potom to na kvartální bázi revidujeme, respektive to revidujeme průběžně. Máme kvartální all hands meetingy, říkáme jim demoday, a to bývá takový milník, který nás nutí se zamyslet a případně změnit směr. Máte něco podobného?

Pro tento rok máme nastavené cíle. Jestli se změní v průběhu roku, uvidíme, ale pracujeme v režimu týdenních iterací, kdy procházíme, kam jsme se posunuli.

Jak velká je dnes Keboola? Kolik máte lidí? Vím, že jste loni nebo předloni dostali velkou investici, myslím, že to byla na českém trhu jedna z největších nebo alespoň významných investic.

Přiznám se, že neznám přesné číslo, ale je to kolem 150 lidí.

A jak velký je produktový tým?

Produktový tým se skládá z produktových manažerů, designérů, datových analytiků, kteří nám pomáhají s produktovou analytikou, a product operations. Máme tři designéry, pět produktových manažerů, tři lidi na produktovou analytiku a jednoho člověka na product operations.

Takže dohromady asi 15–20 lidí.

Myslím, že to vychází na 15 lidí.

A vývojáři mají svůj tým, těch je kolik?

Máme 20+ vývojářů, teď také přesně nevím.

Orientačně stačí. Pojďme rovnou na tu změnu, kterou jste prošli. Zaznamenal jsem to na začátku února, kdy Petr Šimeček, jeden z vašich zakladatelů, psal na LinkedInu, ale předpokládám, že možná i na Twitteru a jinde zmiňoval, že procházíte změnou v tom, jak děláte produktový management a vývoj. Padaly tam termíny, které jsou dnes velmi populární — nástroje jako Kurzor, využití Clauda pro vytváření kódu. Některé firmy mluví o tom, že občas přeskakují Figmu a jdou rovnou do prototypování v kódu. Vy jste se do toho očividně vrhli dost po hlavě. Zajímalo by mě, jak jste to dělali předtím a co teď změnou procházíte.

Vidíme tu změnu, která je zde. AI je tady, bude tady a výrazně ovlivní práci lidí. Předtím, nebo ještě minulý rok, jsme měli klasický přístup.

Jako produktový tým jsme udělali research, který se dělal manuálně. Už minulý rok tady bylo GPT, takže některé věci bylo možné s ním konzultovat. Po přípravě jsme se domluvili s engineeringem, kde jsme prošli zadání iniciativy, která měla vliv na naše cíle.

Pak jsme společně vymýšleli, jak to uděláme. Toto kolečko bylo poměrně dlouhé. Následně engineering pracoval klasickou cestou.

Všechno se psalo ručně, kód. Později se k tomu začal přidávat Copilot v Gitu.

Dostali jsme se do bodu, kdy vidíme, jak všechno kolem nás zrychluje, a nám trvá dlouho dodat věci, které považujeme za malé a rychlé, ale ve skutečnosti takové nejsou. Tak jsme si sedli a řekli si, co s tím můžeme udělat. Vypsali jsme si sedm věcí, co můžeme zlepšit a co naopak vyhodit.

Rozhodli jsme se výrazně adaptovat AI do naší každodenní práce — jak v engineeringu, tak v produktovém týmu. Důležitým prvkem bylo také, že nechceme týmy oddělovat, ale chceme pracovat více společně od samého začátku.

Začali jsme s tím něco dělat. První věc byla, že jsme si vytvořili čisté prostředí, kam můžeme rychle nasazovat věci, takzvaný Stack Canaries. A neovlivňuje to produkci.

Zároveň jsme v produktovém týmu začali pracovat s Kurzorem, a to už od rané fáze. To znamená, že Kurzor mi dnes může pomoci při definici iniciativy, v analýze i při marketingovém výzkumu.

Když zadám přesně to, co chci, jsou výsledky dnes velmi dobré. Když jsem specifický, řeším jednu věc a ptám se, jak tuto věc dělají jiné firmy na trhu, třeba kolik stojí, porovnej mi to, tak si to pak mohu sumarizovat a vytvořit z toho výstup.

To je část definice, která také výrazně zrychluje produktovou práci. I rozhovory se zákazníky dokážeme zpracovat pomocí Kurzoru. Jsou to audio nebo videonahrávky.

Většinou jde o Google Meet hovory. To se dá také zpracovat a rovnou použít. Nyní jdeme cestou, že chceme mít všechny naše produktové iniciativy v Kurzoru. K němu je i Git repozitář a všechno chceme mít uložené v Gitu jako markdown soubor. Díky tomu to můžeme rychle a snadno předat engineeringu, který na to může navázat. Když začnou pracovat na nějaké věci, načtou si do Kurzoru naši předchozí práci a mohou hned začít třeba s architekturou nebo návrhem řešení.

Vytvoří design dokument, jak ta věc bude fungovat i z technického pohledu. Co nám nefungovalo, bylo být oddělení. Mít mezi sebou prostoj, kdy my něco připravujeme, pak to s nimi probereme a zase se to vrací zpět.

Proto nyní prosazujeme menší, více fokusované týmy, které pracují společně od prvního momentu. A začínají tvořit a rychle iterovat.

To znamená, že jste předtím něco vytvořili v produktovém týmu, pak jste to na nějaké schůzce probrali s developmentem, oni si to převzali a šli na tom pracovat. A teď měníte i organizační strukturu v tom, že do produktového týmu bude začleněný už nějaký vývojář?

Dosud jsme měli týdenní plánování, kdy jsme procházeli iniciativy, které chceme dělat, pak se vyvíjelo tři týdny, a pak jsme zase měli plánování. Tři týdny se čeká, než se něco dodá a než jdeme validovat. To je v dnešním světě příliš pomalé.

Je to starý způsob, který se ukazuje být dlouhodobě nefunkční.

Máte přesně definované, jak ten nový tým bude vypadat organizačně? Jestli tam budete mít vždycky za vývoj nějakého full-stack vývojáře, nebo jestli tam je tech lead nebo CTO, jak to máte organizačně u vás?

Nové týmy vzniknou podle domén, které máme a co řešíme v produktu. Tým bude zastoupený backend a frontend vývojáři plus produktový manažer jako owner týmu. Pod tím máme sdílené zdroje. Sdílené zdroje vnímáme jako design — to jsou sdílené zdroje pro týmy, které budou vznikat.

Ty vertikální týmy a pak samozřejmě infrastructure tým, který je také sdílený zdroj. Když tým potřebuje něco nasadit na infrastrukturu, tak si požádá o kapacitu.

Jasně, protože nedává smysl mít v každém týmu na plný úvazek třeba designera, když pro něj není tolik práce.

Přesně tak. Tým by měl být dostatečně soběstačný, aby dokázal věc začít sám připravovat, sám vyvinout, nasadit, otestovat a spravovat release.

Mě hodně zaujalo to, co jsi říkal, že u vás v Kurzoru probíhá už ta příprava a fáze ideace nebo návrhu těch feature, a možná i částečně tvorba roadmapy, včetně toho, že to je pak zanesené v Gitu a dostává se to takhle k vývojářům. To mi přijde zajímavé, protože většina diskuze, kterou dnes vidím, je spíš o tom, že máme definované, co chceme dělat, a teď se bavíme o delivery, a ta delivery se přesouvá do Kurzoru a podobných nástrojů. Mohl bys víc popsat, jak s Kurzorem fungujete nebo chcete fungovat v rámci produktové discovery? To znamená, jak tam dostat rozhovory s uživateli nebo zpětnou vazbu? Na co je Kurzor napojený? Zatím jsem hodně viděl, že lidé si přípravu udělají v Groku nebo Claudu nebo GPT někde bokem, a pak do Kurzoru už zadají product requirement document. Mohl bys to rozvést?

Je to možné. Prostředí Kurzoru je pořád více vývojářské, takže ne každému se do toho asi chce. Klidně se dá jít cestou, že si to připravím bokem a pak jdu do Kurzoru, ale není to vůbec potřeba, protože já tam odbavím všechno. Ta síla je v tom, že si s ním můžu začít povídat a challengeovat ho, na co jsem ještě zapomněl. “Dej mi otázky, na které ti musím odpovědět” a pojďme společně dodefinovat to, co chci udělat.

A postupuje to dál — když už to mám připravené, tak můžu začít dělat i prototyp. Kurzor je schopný udělat výstup, který bude hmatatelný, třeba preview, který v ideálním případě, když je to nová věc, by mohl být rovnou převzat engineeringem. Ti by to doladili, přidali k tomu security věci a další, které Kurzor ještě nedokáže zvládnout, a mohli bychom mít první produkt venku. K tomu je podle mě ještě cesta. Vidíme, že to dnes jde dělat na nových věcech, ale na naší stávající codebase je to složitější.

Je potřeba mít dobře popsané repozitáře a mít aktualizovaný rules soubor k jednotlivým věcem, když chci měnit stávající věci. Takže prototyping je tady určitě na místě a měl by také zrychlit celý vývoj. Už i naši UX designéři některé věci dělají rovnou a přeskakují Figmu tam, kde to dává smysl.

Ne vždy je to efektivní, ale už na to také najíždíme.

Nedávno jsem si o tom povídal s Honzou Tomanem ze Supernovy, který říkal, že Figmu používáme dnes, protože je to levné. Když chceš něco navrhnout, je to levné ve srovnání s vývojem. S tím, jak se zvyšuje schopnost AI nástrojů, se začne stávat levnější i přímá práce s kódem. Dnes, jak říkáš, je některé věci pořád rychlejší udělat ve Figmě — záleží na tom, co přesně děláš.

Je výhoda, že jsem původem full-stack vývojář, i když to už dlouho nedělám. Rozhraní Kurzoru je pro mě sympatické, protože mi to připomíná tu dobu, a dokážu se v tom orientovat. Líbí se mi, že zjednodušuješ všechno do jednoho prostředí. Předpokládám, že do toho musíš správně nahrát data. Řešíte už tohle? Teď se řeší integrace na různé agenty. Máte to už vyřešené, nebo je to výzva, jak dostat data dovnitř? Předpokládám, že musíte dostat svoji codebase, aby Kurzor rozuměl architektuře, jak to funguje, a dokázal dělat návrhy.

Pak tam asi musíte dodat produktovou roadmapu, featury nebo zákaznický feedback. Tohle už nějak řešíte?

Ten feedback a celá agentní vrstva, to je podle mě na samostatný podcast. My to teď intenzivně řešíme — jak to zabudovat a jak správně poskytovat data, jak s nimi pracovat, aby model dostatečně pomohl uživateli dosáhnout toho, co chce. To je na pořadu dne. Ale některé věci jsou jednodušší — každý může vzít Kurzor a začít věci dělat rovnou. Může tam rovnou nahrávat z vlastních znalostních systémů informace, které potřebuje pro svoji práci nebo pro další vývoj.

My používáme Confluence, takže můžeme jakýkoliv výstup vzít a použít Confluence jako zdroj. U Google Meet nahrávek si můžu pustit transkript videa a už z toho mám text, nebo to můžu vzít jako MP3 z videa a nechat ho analyzovat. Takže cest je více a cílem je zjednodušit si život.

Nebudu přepisovat rozhovor s někým — nechám ho přepsat a jen zkontroluju, jestli je to správně. Když je to správně, jdu dál.

Když člověk musí zpracovat 5–7 rozhovorů, trvá to časově dlouho.

Ten plán je takový, že ty rozhovory vám žijí v nějakém repozitáři, kam je budete dávat? Nebo to zatím ručně nahráváš jako MP3 do složky a pak to necháš Kurzor s nějakým rozšířením nebo integrací na agenta přepsat? Máte to už nějak vymyšlené, nebo spíš experimentujete?

Experimentujeme. Používáme Google na všechno a nahrávky máme v Google Drive. Tam ukládáme všechny naše dokumenty.

A s Confluence je to asi podobné? Asi můžeš mít integraci z Kurzoru na Confluence, takže pak můžeš říct: “Podívej se do Confluence na tohle”, třeba na nějaký ticket nebo product requirement, a můžeš s tím pracovat?

Ne všichni u nás ve firmě jsou v Gitu. Proces si představujeme tak, že budu pracovat s Kurzorem, připravím podklady, ty se dostanou do Gitu v markdown souborech, všechno pěkně popsané, a v pozadí poběží akce, která pushne data do Confluence. Když udělám další změnu v repozitáři produktové iniciativy a systém tam uvidí změnu, automaticky se spustí další push a Confluence bude stále aktuální. Když někdo chce něco vyhledat o firemních projektech, může se na to podívat.

To zní, že se vytváří úplně fundamentálně nový proces produktového managementu. Bude stavět na tom, co dnes existuje, ale tooling bude nový, flow bude nová. To bude zajímavé.

Na jaká omezení dnes narážíte?

Jak jsi řekl, tooling je přesně to, v čem se musíme zlepšit. Práce dnešních produktových manažerů je dost odlišná od budoucích produktových manažerů a nástrojů, které používají. A produktový manažer, který neadaptuje AI, podle mě přijde o práci ve prospěch toho, kdo ji adaptuje a bude s ní pracovat.

To se určitě stane brzy. Problémy už jsme trochu nakousli. Hodně bojujeme s fokusem týmu. Ve starém setupu to nešlo. Jednak, jak jsme se bavili, ty prostoje mezi tím, než se něco udělá a připraví, jsou dlouhé.

A jednak jsme pořád řešili bookování vývojářských kapacit. “Už se něco dodělalo, tak se může jít na tohle.” “Ne, ještě nemůže, protože tam chybí dodělat tohle.”

Iniciativy se nám různě posouvaly v čase a je to hrozně těžké celé zmanažovat. Zvlášť když na tom musí lidé spolupracovat. Stávalo se nám, že někdo pracoval na třech věcech najednou.

Jedna skončí, dvě tam jsou pořád, ale zrovna on zná tuhle nejlépe. Je to nejlepší cesta, jak to udělat co nejrychleji, tak se vrhnul na další. Občas se nám stávaly i hard stopky, naše interní “red buttony”.

Když jsme u důležitého zákazníka viděli, že něco nefunguje, zastavili jsme se a šli to opravit. Až pak jsme se vrátili k normálnímu režimu. Tohle všechno chceme vyřešit těmi vertikálními týmy, které budou cross-funkčně nezávislé a dokážou fungovat samy ve své doméně, kterou potřebují upravovat.

Na to si musíte udělat čas, změnit organizaci. Co si dovedu představit, na co my narážíme — máme team Design Operations, protože máme 35 lidí, takže jsme násobně menší než vy.

Jsme všichni designéři, děláme čisté user experience, produktový design, UI, service design, UX research a věci kolem toho. Jedna věc je, že děláme operations — už dnes děláme design a projekty pro klienty tak, jak to umíme, ale pak chceme dělat i research and development, což znamená zlepšování našich procesů. Co je pro nás nejtěžší, je udělat si čas na research and development, na zlepšování.

Předpokládám, že to u vás může být také výzva, protože máte produktovou roadmapu, chcete doručovat featury zákazníkům a vylepšovat produkt, ale zároveň se na tohle potřebujete trochu zastavit a zapojit důležité lidi, kteří pomohou s tou změnou. Kdo je do toho zapojený? Kdo to definuje?

Ano, samozřejmě to bere energii, ale když je pak vidět výstup, je to věc, kterou chceme společně udělat. Tuto konkrétní změnu hodně tlačím já s naším šéf inženýrem.

To znamená, ty za produkt…

A on za engineering.

Definujete nebo tlačíte tu iniciativu, ty změny. A kdo je širší nebo užší tým, který se na tom podílí?

Všichni, celý produkt i engineering.

To znamená, že všichni lidé jsou do toho zapojení? Takže když třeba uděláte nějakou změnu, kterou vymyslíte, tak to představíte celému produktovému a vývojovému týmu?

Je strašně důležité mít buy-in od všech, aby ta věc fungovala. Musíme se na tom shodnout. Jsme hodně otevření, takže si ty věci vždycky řekneme, jak jsou.

A snažíme se řešit spoustu otázek kolem toho, kde změna přináší posun i ve fungování a přemýšlení. To vyvolává další a další otázky, které bude třeba řešit. Ale tomu se nevyhneme.

Něco staršího končí a něco nového, lepšího, začíná.

Já kolem sebe i teď vidím názory, že lidé jsou z té neustálé změny unavení a že AI věci opravdu hodně mění, že to je náročné. S tím asi nic neuděláme, ale máte nějaký recept na tohle? Přijde mi, že jsou lidé, kteří jsou z toho nadšení a tlačí to dopředu.

Mě to teď trochu pohltilo, zkouším dělat věci, baví mě to a mám spíš pozitivní očekávání. Ale vím, že pro každého to jednoduché není.

Jo, je to tak. Já sám mám respekt před AI, ale vidím, kde ji můžeme využít a kde nám může pomoci. Kam to nakonec dospěje, nevím.

Doufám, že to bude pozitivní a že se nenaplní žádné černé scénáře, které někdo může mít. Ale je to podle mě na nás, abychom to dokázali správně ukočírovat a uvědomili si, jak to využít co nejlépe.

Podle mě tuhle změnu už nezastavíme. To je první věc. A ten, kdo se neadaptuje, podle mě skončí.

Myslím, že to bude i velká byznysová výhoda. Mluvil jsi o tom, že jde hodně o rychlost — že dokážete být rychlejší v doručování produktů.

Já jsem teď viděl na Twitteru post od Guillermo Raucha, který dělá Vercel a v0, což je jeden z nástrojů na AI budování produktů. Psal, že nejdůležitější metrika budoucnosti pro produktové týmy bude čas od uživatelského feedbacku k doručení funkce na produkci. To se mi strašně líbilo — dnes slyšíš od uživatelů, že chtějí něco změnit, a to dnes trvá měsíc.

A možná za chvíli to bude trvat den nebo hodinu. Psal o tom v souvislosti s tím, že firmy, které tohle dokážou, budou uživatelé milovat a uspějí na trhu spíš. Měříte něco takového?

Je to tak. Dnes se měří tzv. cycle time — přesně to, co dodáš. Máme dobrou zkušenost s tím, že když máme menší věci, nějaké feedbacky, které jsme schopni rychle zapracovat, jsou to jednotky dnů, a vidíme obrovskou pozitivní zpětnou vazbu od zákazníka, který říká, že je super, že jsme to zapracovali. Ale pak jsou věci, které nám trvají hrozně dlouho, a tam je kámen úrazu.

Tam potřebujeme začít rozsekat věci na menší kousky, začít rychleji dodávat a rychleji validovat se zákazníkem na neprodukčním prostředí, kam ho můžeme pozvat a ukázat mu první verzi, která by měla být hotová co nejdřív, protože může doznat změn.

Asi už není cesta, že bych to do detailu ladil ve Figmě, jak to má vypadat. Protože nevím, jak to ve finále dopadne, celý ten produkt. Otočí se to ještě třikrát, udělá se tam dalších x změn a nebudu pořád dokola aktualizovat Figmu.

Tady už si to můžu dělat s prototypem. Ideální stav podle mě je, když budeme mít popsaný náš design systém ze všech prvků, z čeho se to skládá, a já si z toho budu schopný rychle vystavit novou věc nebo změnu, která bude kopírovat náš design styl a bude rovnou připravená k testování.

Na vašem Canary prostředí, předpokládám, že i designéři nebo produktoví manažeři si mohou ty změny testovat přímo v kódu? Že to není tak, že něco připraví a pak potřebují vývojáře, aby to nasadil na to prostředí, ale že to mohou dělat sami?

Ano. Dnes má celý produkt přístup k celému repozitáři našeho produktu, takže když něco potřebuji, můžu se napojit na repozitář, který zrovna řeší nějakou věc, a začít si s Kurzorem povídat o tom repozitáři. “Co je ta funkce, kterou tohle repo zajišťuje? Popiš mi to.”

Já se k tomu dostanu, pak mu řeknu: “Dobře, chápeš to?” Řeknu: “Jo, chápu to.” A teď: “Chci upravit tohle, pomoz mi upravit tuhle věc.” On to pomůže upravit a je možné si to na lokále vyzkoušet. Když je to dostatečně dobré, měla by být možnost nasadit to na náš vývojový stack, kde si to vyzkouším.

K tomu dnes směřujeme, ale tam ještě úplně nejsme. Jedeme tam inženýrská kolečka, ladí se to, ale tam je ta budoucnost.

Směřuje to k tomu, že se všechno sbližuje. Není to o tom, že by někdo izolovaně něco dělal, ale sbližujeme se.

A role produktového manažera se dost výrazně mění. Jednak s těmi nástroji, jednak s tím, co musí umět. Budoucí produktový manažer bude podle mě více technický, protože tomu musí rozumět, když najednou vede oblast, kterou tlačí dopředu a snaží se ji zlepšovat.

Takže bude více technický, více designový, bude si pomáhat nástroji, které má kolem sebe, bude se snažit hodně automatizovat a dodat hodnotu uživateli co nejdříve. Je to takový mini CEO ve své doméně.

Takže i více byznysový.

Ano.

Byznysový by měl být. To by měla být podstata dobrého produktového manažera, že rozumí dobře byznysu a tlačí ho dopředu, tak na tom se asi nic nezměnilo. Ale ten technický aspekt je něco, co vidím i v designu — designéři budou muset rozšířit svůj skillset do technologie. Samozřejmě, jak se budou AI agenti zlepšovat, tak ta potřeba bude nižší.

Já to dnes vidím v tom, že když jsem si před půl rokem napsal první rozšíření do Chrome, které propojuje LinkedIn s HubSpotem, nahradil jsem tím nějaký SaaS. Jak se říká, že SaaS je mrtvý, tak přesně takhle jsem nahradil Surfe a už tím šetříme spoustu peněz. I když to byl spíš experiment, funguje to docela dobře.

Co jsem u toho viděl je, že populární termín “vibe coding” — že to říkám přes prompty Kurzoru, Wizardu, Replitu nebo jiným nástrojům a jen tak surfuji na tom, co dělají — mi přijde, že dnes ještě úplně nefunguje prakticky. Do nějaké míry jde nerozumět tomu a jen říct “něco vybuduj” a pak do toho házet zpátky chybové hlášky, a ono to dokáže opravovat chyby do určité míry.

Ale pak mi přijde, že když člověk nemá technickou znalost, často se někde zacyklí nebo zasekne. Já jsem teď chtěl udělat rozšíření Chrome extension a řekl jsem si, že vůbec nebudu koukat na to, co dělá Kurzor, budu mu jen říkat, co má dělat, a uvidím, jestli si s tím poradí. On to rozbil — z extension o tisíci řádcích najednou vznikly tři tisíce řádků kódu a nebyl schopný to sám opravit.

Já jsem nechtěl koukat na to, co řeší, ale když jsem po páté viděl, že to pořád nefunguje, podíval jsem se a zjistil, že si vybral dvě řešení, ani jedno nefungovalo, a on jen střídal: “teď udělám tohle, teď tohle” a zasekl se. Takže mi přijde, že člověk potřebuje mít nějakou technickou znalost, aby dokázal ten kód přečíst alespoň základně a říct: “Tady vidím, že se děje něco, co by se dít nemělo” a nasměrovat agenta správně. Ale myslím si, že do budoucna se to bude zlepšovat.

Tyto problémy tam samozřejmě jsou, u nás vidíme také to zacyklení. Ale nenutně ten člověk musí mít technický screen, hlavně u nových věcí. U stávajících, kde člověk upravuje existující codebase, je to určitě dobré. Ale zase, s Kurzorem se můžu dostat do stavu, že mi pomáhá se učit. Když něco nevím, rovnou s ním iteruji.

“Hele, co je tohle? Proč tady nasazuješ nějaký server nebo databázi? Co je databáze?” A on mi začne vysvětlovat věci, které dělá. Učím se u toho za běhu, de facto.

Což je vlastně hezké. A jsem hrozně rád, že se to u nás chytlo a naši designéři chtějí začít dělat prototypy tímto způsobem. Vidí v tom přidanou hodnotu, že se mohou soustředit více na designérskou práci než na úpravy.

Je pravda, že designéři se zatím mohou soustředit třeba na vybudování vymazleného design systému, protože mi přijde, že AI zatím nemá ten cit pro detail. Když potřebuješ něco opravdu do detailu mít tak, jak chceš, to podle mě zatím neudělá. Takže designéři se mohou soustředit na tohle.

To je dobré. Zároveň pro designery někdy nemá smysl ladit něco ve Figmě půl dne, když si mohou udělat rychlý prototyp třeba ve v0 nebo podobném nástroji. Já jsem teď zkoušel, když jsme měli poptávku na design finančního auditovacího nástroje, který už měli nějak promyšlený, a chtěli udělat rychlý klikací prototyp.

Buď jsme to mohli udělat ve Figmě, kde by to někdo hezky nakreslil a bylo by to vyladěné, ale pocit z interakce by byl omezený, protože Figma má své limity — jde jen o kliknutí z obrazovky na obrazovku. Když jsem řekl, že to zkusím dát do v0, vytvořil jsem si nejdřív product requirement document v Groku na základě deep searche a přemýšlení, a pak jsem to tam nahrál. v0 používá Shadcn komponenty, které samy o sobě vypadají dobře, a během 20 minut jsem měl prototyp, který jsem mohl poslat klientovi a říct: “Co třeba tento směr?”

Klient sice říkal, že to chce trochu jinak, ale během hodiny po callu, kde nás briefoval, jsme mu byli schopni něco ukázat a začít se bavit o něčem hmatatelném. To diskuzi hrozně posunulo dopředu, naladili jsme si, kterým směrem jít a kterým ne. A to je vlastně to, o čem jsme se bavili — čas od feedbacku k vytvoření prvního artefaktu, získání feedbacku a změny — jsem zkrátil oproti tomu, kdyby to designer dělal od začátku.

Já jsem dnes schopný, pokud má klient už nějakou představu, vzít screenshot z nějaké platformy a dát ho v0 nebo Kurzoru, a on na základě toho postaví řešení podobné tomu nástroji. Takhle rychle to dnes jde, a bude to stále lepší.

Ještě když jsme u produktových manažerů, chtěl bych dodat, že se u nás snažím hodně tlačit na vzdělávání, nejen v AI, ale obecně. Protože nástroje vezmou produktovému manažerovi dost práce, ale teď v tom dobrém smyslu. Nevím, jak to bude dlouhodobě, ale krátkodobě to bude velký pomocník. Produktovým manažerům musí zůstat klíčové produktové dovednosti — to je podle mě produktový instinkt, storytelling a schopnost prodávat to, co děláme. To je to, co AI zatím nedokáže nahradit, i když časem možná ano. Teď to bude to, co produktového manažera může posunout dál, když bude využívat všechny nástroje kolem sebe a zlepší se.

Když se na to podívám z pohledu designérů, je to tam velmi podobné. Někdo tomu říká “taste” nebo vkus — že pro designéry bude důležité být arbitry vkusu, aby dokázali zhodnotit, co umělá inteligence vytvoří. To je jedna oblast, která mi přijde důležitá. Druhá je, že se budou více věnovat discovery fázi, samozřejmě AI asistované, ale tam bude jejich hlavní hodnota — pomáhat definovat produkt.

Takže možná se role produktových manažerů a designérů nějakým způsobem propojí. Produktoví manažeři budou více designovat a kódovat, designéři budou více produktovat a kódovat, a vývojáři budou více designovat a produktovat. Role se různě promíchají, a možná ve vzdálenější budoucnosti se to rozložení změní a budeš hledat do firmy full-stack product buildera nebo někoho do menšího produktového týmu a pojede ti více produktových iniciativ.

Já si nemyslím, že se nutně firmy budou zmenšovat — to je jedna vize budoucnosti, že firmy nebudou mít tisíc, ale sto lidí, a budou s těmi sto lidmi dělat to, co dělali s tisíci. Spíš si myslím, že firmy budou moci zkoušet více věcí a ty lidi si nechají, ale už jich nebude 50 pracovat na jedné věci, ale těch 50 lidí bude dělat třeba deset věcí.

Třeba některé týmy v budoucnosti budou úplně autonomní a bude v nich jeden nebo nula lidí, protože tam bude sada agentů, kteří budou zkoušet nová řešení. Až tak daleko to může dojít. Uvidíme, kam to bude spět.

Tohle je podle mě zajímavé, že když se o tom bavím s vývojáři, produktovými manažery i designéry — to produktové trio — tak mi přijde, že pro všechny tyto lidi nástup AI znamená podobné věci. Všichni to vnímají stejně.

Možná další téma, které se objevuje, je, že seniorní designéři už mají vybudovaný ten “taste”. Řemeslo dlouho dělali, tak poznají, co je dobré a co není. Když jsou to dobří designéři, kteří přemýšlí i o produktu, dokážou to posoudit i z hlediska byznysu. A podobně to předpokládám bude u produktových manažerů.

Co si říkám je, jak pracovat s juniorními lidmi, kteří tohle ještě nemají vybudované a kterým tu práci AI může trochu vzít. Ale ty je vlastně chceš vychovávat, abys potom měl lidi, kteří to dokážou řídit. Tak vůbec to vychovávání nové generace se asi také dost promění.

Je to určitě velké téma. Jak jsme se bavili, je to to sbližování, ke kterému dnes dochází. Jak udělat z juniorů seniory?

Je to obrovské téma. Protože junioři nebudou v novém světě potřeba, ale senioři ještě ano. Ale jak to teď udělat?

Budeme mít speciální kempy, kde se budou trénovat junioři, aby se z nich stali senioři, aby byli ready do toho světa? Je to vůbec možné? Já nevím.

Je to určitě velké téma.

To bude zajímavé. Zároveň jsem teď četl, říkal to někdo z Andreessen Horowitz, že si myslí, že nejvíc na této vlně pojedou lidé, kteří mají v současnosti nejvíc volného času. Ti zachytí vibe coding a naučí se na tom.

Možná nás v uvozovkách “přejedou”. A říkal, že jedna skupina takových lidí jsou studenti. Takže možná se výchova juniorů změní, ale možná se to naučí sami díky tomu, že začnou vibe codovat, stejně jako my jsme kdysi zkoumali existující stránky a učili se tak, že jsme koukali do kódu a rozebírali si ho. Možná se ta nová generace to naučí sama taky takhle, jen jiným způsobem. To mi přišlo jako zajímavá myšlenka.

Když si vzpomeneš na Tomila na té CSS věci, to všechno dělat ručně, to bylo hrozně…

Jo, je to tak. Dnes je ta doba úplně jinde. Od ručního vývoje pak přišly různé frameworky, templaty a bootstrapy, a dnes je to najednou ještě dál. Pro mě osobně je hodně zajímavá ta platforma v0, která postaví na Node.js celý stack a člověk s tím může dál pracovat, to pro mě jako designera je zajímavé.

Na druhou stranu další téma, u kterého bychom se mohli zastavit, je bezpečnost té produkce nebo posílání na produkční prostředí.

Četl jsem nedávno post od jednoho vibe codera, člověka, který vůbec neumí programovat a postavil si vlastní aplikaci. Strávil na tom samozřejmě nějaký čas, neudělal to za den, ale vytvořil aplikaci, která je něco jako Kurzor pro psaní článků. Začal to normálně prodávat a hrozně to vyskočilo, protože lidé, co ho sledují, viděli, že postavil aplikaci, kterou prodává, a to mu zařídilo slušnou trakci. Ale hned druhý den nebo pár dní poté, co to uvedl, psal, že ho někdo hacknul a přišel o nějaké peníze. Tam vidím dost úskalí, a ty jsi to také zmiňoval, že bezpečnost je u vás důležitá.

U nás obzvlášť.

No jasně.

Ale to jsou ti senioři, kteří se postarají o to, aby tvé řešení bylo dostatečně zabezpečené. I předávání dat AI musí hlídat.

Některým lidem nevadí, že jejich data jdou do AI a ta se na nich bude učit dál. Ale někdy jsou ta data citlivá, takže je potřeba zajistit, že to běží někde izolovaně.

Jo, že máš nějaké svoje prostředí, kde ta data nejsou sdílená s modelem někde venku. Jedno z témat, na které také narážím, je, že jsi zmiňoval, že máte vaše testovací prostředí, na kterém můžete pracovat. Předpokládám, že aby s ním všichni mohli pracovat, musí být relativně jednoduché ho rozběhnout.

To vám připravil vývojářský tým?

To nám připravil náš infrastructure tým. A je to prostředí, které nastavíme tak, že když se rozbije, tak se rozbije. A hned ho okamžitě dokážeme zase nahodit a pak běží dál.

To znamená, dá se nějak resetovat do původního stavu?

Máme tam základní věci, aby všechno fungovalo. Nejsou tam úplně všechny věci z platformy, jsou tam ty důležité, které aktuálně potřebujeme.

A když přijde nový designér do týmu nebo produktový manažer a chce si tohle rozběhnout, je to otázka minut nebo hodin, dnů?

Je to hned. Je to přístupné všem ve firmě, jenom je otázka, jak tam ty věci dostaneme, jakou cestou, jak často. Ale může mít přístup do minuty v momentě, kdy k nám nastoupí.

Proběhne nějaký onboarding, kde si řekneme principy, přidáme ho do Kurzoru, přidáme ho do Gitu, dostane přístup do těch stacků a může jet.

Máte jedno prostředí, na které se připojují všichni. Není to tak, že by každý měl rozběhnuté svoje vlastní prostředí, ale je to sdílené. A přesně — když to někdo rozbije, tak to resetnete nebo rollbackujete do funkční podoby. To je dobré.

Předpokládám, že jste měli, myslím, že Petr Šimeček o tom psal, nějaký interní workshop, kde jste to ukazovali lidem a učili je základy Kurzoru. Které věci se dnes člověk musí naučit jako základ, aby s tím mohl u vás pracovat?

To záleží na tom, s jakými dovednostmi ten člověk přichází. Pokud to už zná, nebude to pro něj něco úplně nového. Ale když to nezná, celé to prostředí je pro něj nové.

To znamená, že se musí naučit komunikovat s tím agentem správně. Vpravo agent, uprostřed content, vlevo struktura — je potřeba se s tím sžít, začít to používat a napojit na to Git. To je dovednost, kterou někteří lidé vůbec nemají, takže se musí naučit, co je Git, k čemu slouží, co je commit, co je pull request, takové klasické věci, aby věděli, co se tam děje, a dokázali si to udržet.

Protože cesta k udržení je právě přes Git. Když to neverzuješ, rozpadne se ti to pod rukama. Dějí se tam změny, které ti to mohou v jednu chvíli úplně rozbít. Takže best practice je rozkouskovat to na co nejmenší kousky a verzovat to po malých věcech, abys měl schopnost to rollbacknout, kdykoliv budeš chtít, kdykoliv narazíš na nějaký problém.

Takže co nejčastěji commitovat.

Co nejčastěji commitovat ty změny.

Jedna věc je zorientovat se v Kurzoru a jak funguje, napojení na Git. Ještě nějaká klíčová věc?

V rámci tohoto světa je to asi naučit se s Kurzorem, pochopit Git, naučit se pracovat s Gitem, a pak už jsou to klasické produktové činnosti, které k tomu patří. Když si představíme kruh produktového lifecyclu — začíná Discovery, pak je prototyping, pak development, launch, pak to měříme, vyhodnocujeme, a to se pořád opakuje dokola. Snažím se, abychom tohle co nejvíc automatizovali pomocí nástrojů.

Takže když v Discovery začínáš, použiješ Kurzor, jdeš dál do prototypingu, tam stále zasahuje Kurzor. U developmentu může být Kurzor, nebo si někdo najde jiný nástroj, třeba od JetBrains a další poskytovatelé různých nástrojů, různých Copilotů. Tam už jsme u engineeringu. U launche je to také podobné, můžeme automatizovat nasazování a komu se to ukáže, včetně toho, jak se to změří, jestli je to dostupné.

Teď si děláme interní aplikaci, která nám pomáhá analyzovat zákaznické feedbacky, třeba i tikety, které budou chodit k nově vydané funkci. Model dokáže poznat a vytáhnout určité informace. Když někdo začne mluvit o tom, že zkoušel funkci XY, tak to zachytí a hned nám zobrazí, jestli to bylo pozitivní nebo negativní, kolik těch feedbacků bylo, jak vypadají data, jaké akce udělat na základě těch dat, abychom to zlepšili. Máme s tím pokračovat, nebo to máme rovnou ukončit, protože je to slepá cesta a nikdo to nepoužívá?

To jsou otázky, které dnes produktový manažer zodpovídá ručně, ale do určité míry je lze automatizovat. Tak, aby byl schopný to validovat rychleji.

Zaznamenal jsem u vás snahu budovat rychleji různé funkce nebo produkty a hledat nové hodnoty pro zákazníky. Předpokládám, že tohle je snaha: “Tady jsme něco vytvořili, co nejrychleji posbíráme zpětnou vazbu a rozhodneme se, jestli má smysl v tom pokračovat, nebo jdeme dělat něco jiného.” Říkal jsi, že stavíte nový nástroj, který vám má pomoct.

Je to datová aplikace postavená ve Streamlitu aktuálně, kterých můžeme mít klidně stovky. I naši zákazníci si mohou sami stavět Streamlitové aplikace a nasadit je k nám přímo nad jejich daty a pracovat s nimi. A do budoucna to není jen Streamlit, de facto si můžu postavit jakou aplikaci budu chtít.

Může být Reactová nebo jiná.

Streamlit, promiň, ten pojem neznám. Co to je?

Streamlit je technologie, která ti pomůže velmi rychle postavit vizuální datovou aplikaci, aniž by sis musel startovat třeba BI, když chceš udělat nějakou analýzu nebo si s tím hrát. Je to na bázi Pythonu, takže je to velmi snadné. A AI dokáže generovat i tyto aplikace velmi rychle.

Je to framework, který se teď používá pro vizualizaci dat.

Takže místo abych se hrabal někde v kódu nebo v nějakých složitých rozhraních, které nejsou přizpůsobené na můj use case, tak si ve Streamlitu vytvořím interface, který je přizpůsobený tomu druhu dat, se kterým pracuji.

Jo, to mohou být ad-hoc aplikace, nebo dlouhodobě využívané aplikace, které se používají opakovaně. A všechno dokážu vytvořit z AI — když zadám příkazy, pomůže mi s úpravou dat a pak mu řeknu: “Já teď ta data potřebuji vizualizovat takhle a pracovat s nimi v té aplikaci, pomoz mi ji postavit.” Za chvíli je venku kód, který si vezme a krásně se to nasadí.

Krása v těch aplikacích je, že jsou oboustranné. Nejenom čtou a dokážou ti zobrazit to, co chceš, ale můžeš s nimi interagovat a zapisovat nové vstupy do tvé databáze nebo tabulky, když chceš.

To znamená, že si třeba vytáhneš nějaká data, přečteš si je — teď si vymyslím: když stavíte tu aplikaci na zákaznický feedback, tak si vytáhneš data, kde bude, co říkali zákazníci o nové funkci, pak si to obohatíš o nějaký sloupec, ve kterém bude sentiment — jestli pozitivní nebo negativní — a pak třeba o nějakou prioritu nebo závěr, a těmito daty to zase obohatíš.

Nebo můžu rovnou vytvořit a poslat do Jiry task, který má vyřešit nějakou věc, kterou jsem zjistil z té analýzy, aniž bych vylezl z aplikace, prostě jsem stále v ní. A to platí i v Kurzoru. Takže s Kurzorem si můžu připravit zadání, udělat prototyp a ve finále i roztaskovat to a všechno poslat do Jiry jako tasky, které se pak realizují.

A když tam bude ještě nějaký agent, který pak ty tasky posbírá a za mě to vyrobí… Tak tam to někam směřuje.

Teď jsme v takovém období vzrušujícího experimentování s těmito věcmi. Máte na tohle třeba nějaké pravidelné schůzky, kde to řešíte, vyhodnocujete, nebo jedete prostě: “Teď jsme narazili na tohle, tak se potkáme, jdeme to řešit.”

Teď nemáme nic úplně strukturovaného. Jak jsi řekl, je to nové, vzrušující… Jednou jsem na našem intranetu použil přirovnání, že když vyjely digitální displeje a hodinky, tak se to začalo dávat úplně všude.

Na čepici se najednou objevily digitálky. Všude se to začalo dávat. A postupně se ten hype zklidnil a zůstalo to tam, kde to dává smysl — trouba, myčka a podobně.

Ale přece to nebudu mít na čepici. A s AI to podle mě bude taky tak. Teď je to obrovský hype, každý zkouší, kde to použít, ale ono se to nějakým způsobem zase usadí.

Získá to svoje místo a bude to s námi normálně fungovat. A někde, kde to nedává smysl, se to používat nebude.

Co mi přijde dobré, co u vás vidím, je, že máte lidi, které to baví a kteří to chtějí tlačit dopředu. Ve výsledku mi přijde, že dnes je to hodně o tom, jestli si někdo ve firmě sedne, začne s tím experimentovat a přinese z toho něco užitečného. A vy očividně máte tým, který tohle tlačí, což je skvělé.

A pak podle mě v téhle fázi asi nepotřebuješ strukturovaný proces. Pamatuji si studii, kterou jsem četl před 10–15 lety, kdy Google nebo nějaký tým v Googlu studoval, jak se liší úspěšné a neúspěšné týmy, jaké jsou atributy úspěšných produktových týmů. Jedna z věcí, které zkoumali, bylo, jestli to ovlivňuje, jak jsou týmy strukturované. Měli tam týmy, kde panoval totální chaos, random se potkávali a dělali věci trochu náhodně, a pak měli týmy, které byly extrémně strukturované, měly timer na schůzkách a měly přesně všechno nasazené. A závěr z téhle studie byl, že to nemá žádný vliv na úspěšnost týmu.

Že tohle není faktor, který v tom hraje roli, a že spíš je důležité, aby těm lidem v týmu to vyhovovalo a dělali to tak, jak to tým cítí. Ale jestli pojedou více punk nebo budou více strukturovaní, to nemá vliv.

Proto se ani u nás, když jsme tím procházeli, nesnažíme nadiktovat přesně podmínky. Samozřejmě je nějaký rámec, jak týmy musí fungovat spolu, ale každý tým si to uvnitř bude moci uzpůsobit, jak chce. Chci mít standup třikrát týdně? Pětkrát týdně? Nevím, to je na vás. Domluvte se, co vám nejvíc vyhovuje.

Co chceme je, abychom jeli weekly outcomes, a jak se to v nich uspořádá a jaký rytmus si zvolí, to je na tom týmu. Někdo je více strukturovaný, někdo méně. To strašně záleží.

Jsem zvědavý, kam nás tohle zavede.

Já taky.

Baví mě to teď hodně pozorovat. Bude to i náročné, ta změna, si myslím, ale já na to koukám optimisticky v tom, že si myslím, že nás to posune k tomu, abychom dělali více té práce, co nás baví, a méně té, co nás nebaví. Uvidíme, jak to třeba u vývoje bude, protože u vývojářů vidím, že spoustu lidí fakt baví kódovat.

Vytvářet ten hezký kód. Hodně z těch lidí jsou až takoví umělci v tomhle.

A myslím to v dobrém slova smyslu. A tyto nástroje samozřejmě možná tuhle radostnou část mohou do nějaké míry sebrat. Ale pak si zase říkám, že když jsou ti lidé fakt dobří…

Já jsem to zažil, když jsem ještě byl vývojář — vznikl framework Mootools, jeden z prvních JavaScriptových frameworků jako jQuery, ale na rozdíl od jQuery, která byla více orientovaná na efekty, Mootools se snažil dělat vyšší programování. Byl to jeden z průkopníků AJAX aplikací a programování na frontendu. Mimochodem to také dělal Guillermo Rauch, co dnes dělá Vercel a v0.

A tam jsem si všiml, že opravdu ta krása kódu definovala možná vůbec to, jak se změnilo programování časem. Krása, ale i ve smyslu funkčnosti. A možná pro tyto lidi tady zůstane pořád prostor definovat standardy toho, jak by to AI měla psát.

To bude spíš umění potom.

Taky to může být, že se to bude vystavovat někde v galeriích. “Podívejte na tuhle třídu.”

Na obraze ten kód.

“Tohle je nádherná třída psaná ve Visual Code rok 2024” a bude to někde za 50 let v nějakém centru moderního umění.

Podle mě to bude v nové době jako hobby. Ten, kdo bude chtít ručně psát kód, tak to bude jeho hobby. Ale v práci asi…

Možná jako vinyly nebo něco takového. To je vlastně velký business, ale zároveň je to taková nika. Tak jo, to je zajímavé.

Na to jsem zvědavý. Na závěr by mě ještě zajímalo, Tomáši, jedna věc, protože ty jsi Head of Product a máš v týmu designéry. Jaké je tvoje očekávání od designérů? Možná i jak se to změnilo teď, nebo jak se to mění?

Tak od toho, že po nich třeba nechci Figma prototyp, ale už živý prototyp, tak je to hlavně o tom, že očekávám, že budou klást velký důraz na user experience jako takové. To je ta zkušenost zákazníka s produktem, když s ním přijde do styku, to je to důležité, co designér má. A o to by se měli oni postarat.

To musí být nejlepší. Hodně se teď snažíme orientovat i na UX. A v tomhle směru potřebujeme mít produkt velmi rychle pochopitelný pro lidi a snadno použitelný.

Takže v tomhle směru. Ať už to jde od shora, od nějakých principů UX, až po malé částečky typu “nemám dva save buttony na stránce, protože to nedává smysl.” A tohle musí držet.

Důraz je na použitelnost, na snadnost užití, což většinou přináší nějaké rychlejší zaškolení pracovníků u klienta. Možná menší chybovost, rychlejší práci v systému. Takže tohle je ten fokus, co očekáváš od designérů.

Zároveň je tam ten moderní jednoduchý design, který by měl být dostatečně dobře popsaný, aby se dal znovu použít na nové věci, které ty týmy staví. A nemusel si vytahovat pořád nějaké nové prvky.

To znamená, že ta role se možná i v tomhle trochu mění od toho, že designéři kreslí jednotlivé obrazovky. Samozřejmě oni na to budou muset dohlížet, aby tam byla dobrá použitelnost, ale zároveň připravují tu infrastrukturu. Podobně jako jsi mluvil o tom, že máte vývojový infrastrukturní tým, tak oni připravují infrastrukturu, aby ostatní týmy mohly stavět věci.

To je ten design systém vlastně. Když ho máš pohromadě a je dobrý, tak z něj čerpají týmy okolo.

A zároveň ho potřebuješ mít. Tím spíš, že dnes se design systémy do nějaké míry v některých věcech komoditizují, B2B aplikace vypadají hodně podobně, takže možná chceš klást důraz na to, jak přizpůsobit ty generické věci vašemu byznysu, vašemu produktu. A tam z mého pohledu je jedna nová velká výzva pro designéry — jak budou vypadat interfejsy poháněné AI. Dnes to jsou všechno prompty, což má své výhody a nevýhody, a myslím si, že spousta těch věcí nemusí být prompty.

Mohou to být nějaká nová táhla, tlačítka, obrázky, něco jiného.

Možná nějaké nové trendy tady budou přicházet s těmi agenty, které se na nás budou valit, tak je bude potřeba někde šikovně zobrazit, ukočírovat a propojovat.

Všiml jsem si, že děláte nějaké akce. Pořádali jste, nevím, jestli něco chystáte, kam bys třeba chtěl pozvat lidi nebo kde vás mohou sledovat, aby to viděli. Vím, že jste dělali možná už nějaký meetup.

Dělali jsme teď meetup zaměřený na Kurzor, zkušenosti s Kurzorem, abychom trochu tu komunitu rozproudili. Děláme to s Product Tankem, v našem office i v jiných prostorách, takže když budete sledovat Product Tank, tam se budou objevovat nějaké eventy.

A teď mě k tomu napadlo, že když jsme dělali ten event u nás, překvapilo mě, nebudu jmenovat ty firmy, jak někde mají AI úplně zakázané. Když jsme se tam bavili, říkal jsem, co se snažíme dělat a jak se v tom posouváme, a oni vlastně ještě nemají ani povoleno, aby to v práci používali, což je zajímavé.

Ty kontrasty jsem chtěl zmínit — my na to už hodně najíždíme a někdo to vlastně ignoruje.

Nedávno jsem se o tom bavil v kuchyňce s jedním naším designérem a narazili jsme na to, že někdo žije fakt v téhle bublině AI hypu jako my, kde vidíš, jak se to mění, zkoušíš to, experimentuješ s tím a už vidíš první výsledky. Ale zároveň jsou firmy, kde to možná potrvá roky, než se tomu otevřou a tu změnu vůbec umožní.

To může být zajímavé i pro lidi na trhu — pro designéry, produktové manažery, vývojáře — že možná i na trhu nějakou dobu budou práce pro všechny. Nemusím se úplně bát, že když se nepřizpůsobím nějaké rychlé změně, že by mě to diskvalifikovalo. I když já se snažím být vpředu, být připravený na tu změnu a učit se nové věci, myslím si, že i pro lidi, kteří do toho teď nechtějí úplně skočit, ta práce tady bude dlouho a příležitosti budou. Protože některé firmy se nebudou chtít přizpůsobit.

Obecně se to většinou říká jako klišé o korporacích, že se hlavně brání změně, aby se něco nepokazilo. Zároveň některé firmy budou brzdit regulace, primárně z oblasti ochrany dat a osobních údajů, což může být problematické pro implementaci nových technologií, pokud je nedokážeš rozběhnout interně v izolovaných modelech.

Otázka je, jestli ty roky vůbec mají. Ten luxus některé asi mají, jo, regulované prostředí, jasně. I když máme zákazníky, kteří podléhají regulacím a adoptují AI. Ale pak někdo ne, tak je to asi jejich rozhodnutí, ale nevím, jestli žijí v tom luxusu, že mají čas na to to nedělat.

Někdo ano, někdo asi ne.

Říká se, že vzniknou produktové týmy, které budou mít pět lidí a překonají velké korporace. Budou mít do roka třeba 100 milionů dolarů recurring revenue. To jsou různé předpovědi od Sama Altmana a Y Combinatoru.

Jsem na to zvědavý, protože třeba teď Lovable, což je jeden z nástrojů pro tvorbu těchto věcí — nevím, jestli oni říkali, že za sedm týdnů se dostali na něco jako 10 milionů dolarů recurring revenue. Otázka je, čemu člověk může věřit a co všechno je v pozadí, ale byl to nějaký raketový start s těmito věcmi.

A ta konkurence, to si nebudeme nalhávat, ta tady je všude.

A bude větší.

A bude větší, jo. Někde je malá, někde je větší, ale i u vesmírných programů je konkurence už dnes, i když malá, ale je tam.

Tohle podle mě vlastně zvětší tu konkurenci, protože bariéra vstupu do spousty oborů se hrozně sníží s tím, jak ty věci se stanou realizovatelné. Otázka, pak to s sebou ponese i možná negativní věci, typu, že budeme zahlceni low quality věcmi v některých oblastech. Dovedu si představit, že App Store s mobilními aplikacemi a hrami začne být zahlcený tím, že každý si vygeneruje hru a publikuje ji, a teď bude potřeba vybírat ty kvalitní věci, ale to je zase jiné téma.

To je jiné téma. Mě třeba zaujaly poslední dvě zprávy, úplně jsem je nezkoumal do detailu. První byla, že AI navrhlo nějaký nový počítačový čip, který reálně funguje — nechali ho vyrobit na základě toho návrhu, ale sami neví, jak funguje.

To mě překvapilo, ta zpráva, zajímavé, takže i do tohoto odvětví už to proniká. A pak je tady ta biotechnologie, kdy jsem zaznamenal, že AI navrhlo syntézu nějakého proteinu pro nový druh léku, který léčí, teď nevím, která to byla nemoc, nějaká z těch civilizačních. Ať to byl Parkinson nebo něco takového, přesně nevím.

Vědci řekli, že to dává smysl, co z toho vylezlo. Že je to nenapadlo, protože oni museli strašně dlouho iterovat, ale AI to proiterovalo tak rychle, že z těch informací, které mu dali, vylezlo něco, co chtějí teď dát na testování. Podle mě to, kam se to bude rozlézat, je strašně moc odvětví.

Super, tak já doufám, že za pět let si dáme podcast někde z pláže, už za nás všechno budou dělat roboti, my budeme mít pohodu a budeme dělat jenom to, co nás baví. Doufám, že tam to směřuje.

Dobře, nastavuji si timer.

Tomáši, díky moc, že jsi dorazil a že jsi poodkryl to, s čím teď experimentujete. Doufám, že se potkáme na nějakém meetupu, kde si to vyzkoušíme, přímo v Kurzoru něco naklikáme.

Určitě, já díky.

Ahoj.

Ahoj.

Poslouchali jste podcast designového studia 2Fresh. Pokud potřebujete pomoc s designem vašich produktů a služeb, nebo chcete poradit, jak posunout UX vyspělost vaší firmy dopředu, ozvěte se nám. Ahoj zase příště.

2FRESH Design podcast

2FRESH Design podcast tvoříme v designovém studiu 2FRESH. Pokud potřebujete pomoct s designem vašich produktů a služeb, nebo chcete poradit, jak posunout UX vyspělost vaší firmy dopředu, ozvěte se nám.