Základy produktového managementu pro AI tvůrce

Jak během posledních let spolupracujeme s mnoha produktovými manažery a pomáháme firmám vytvářet skvělé produkty a formovat produktové týmy, vidíme mnoho vzorů, které jsou ignorovány nebo špatně chápány. Totéž lze pozorovat u nastupujícího trendu AI / vibe-coding tvůrců. Nepochopení zůstává stejné, pouze kontext se trochu mění. AI / no-code tvůrci vytváří (zatím) menší aplikace s menším dopadem, ale těchto lidí je naopak po celém světě velmi mnoho a zřejmě jich bude přibývat.

Anti-vzory, které se začínají objevovat a mají velký dopad:

• Milujeme svoje řešení a vlastně úplně nevíme, jakou potřebu řeší a komu. Tento vzor je asi nejběžnější. Chtěl jsem si hrát s AI, vibe kódovat, tak jsem si něco vytvořil a hned to hodil do světa. Nějaký výzkum a validace? To je pro slabochy z produktového managementu! Já sypu sračky na první dobrou, hlavně že zkouším a sdílím a je to vidět na LinkedIn! (berte to s lehkou nadsázkou, která ale není daleko od pravdy) 🙂 Málokdo se ptá: Co vlastně řeším za potřebu a komu? Je na trhu více lidí s touto (mou) potřebou? Jsou jich desítky, tisíce nebo miliony? Mají tu potřebu stejnou nebo trochu jinou? Jak a v čem?

• Vytváříme produkty pro náhodné potřeby, který jsou na trhu lépe vyřešeny již existujícími produkty. Tento vzor by se dal nazvat „Nejdřív střílím, až pak koukám, resp. vůbec nekoukám“. Podívali jste se na existující řešení na trhu? Proč ne? Pokud ano, proč vám nevyhovují? Nezapomněli jste na nějaká vestavěná klíčová byznys pravidla, která nejsou na první dobrou vidět (byznys logika, bezpečnost, regulace)? Máte ujasněný segment, pro který to řešíte a šíři potřeb pro vaše řešení? Neřešíte příliš úzkou potřebu?

• Svoji potřebu jednotlivce neumíme generalizovat do potřeb celého segmentu, a tak vytváříme „zbytečnou“ apku pro 1 uživatele (zbytečnou z pohledu trhu, pro vás zbytečná samozřejmě není). Takto bude vznikat obrovské množství balastu aplikací pro pár lidí, ve kterém bude těžké najít kvalitní aplikaci řešící naši potřebu.

• Sub-optimalizace postupů, protože se zaměřujeme na automatizaci rutinních úkolů jednotlivce, ne na optimalizaci procesu jako celku (třeba jeho kompletním odstraněním nebo kompletní změnou). Psal jsem o tom už několikrát a stejná chyba se opakuje s každou vlnou automatizace (viz například digitalizace a také nyní s AI).

• S velkou radostí vibe-code řešení sdílíme, aniž bychom tušili, že jsou plné bezpečnostních a technických děr, a tedy mohou uniknout osobní či finanční data našich uživatelů, způsobit jejich ztrátu, otevřít databázi útočníkům apod.

Tyto vzory jsou důsledkem jak produktové, tak technické neznalosti AI / vibe-coding tvůrců. Nepřispívá tomu ani FOMO efekt kolem AI, který vytváří mnoho hlasitých trendy expertů na sociálních sítích. Často mají (překvapivě?) společné, že nemají technické vzdělání. Důsledkem je pak nadšená snaha (tu nehaním, ta je super!) mnoha tvůrců sdílet se všemi své pokusy a nabádat k jejich použití. Málokdo z nich si ale uvědomuje, že vytváří nejen velké množství produktového balastu duplikováním již existujícího a lepšího, ověřeného trhem a tisíci uživateli, ale také skrytou bezpečnostní hrozbu.

Co by měl vědět AI tvůrce o tvorbě produktů (a technologiích)?

Rád bych pro AI / no-code tvůrce shrnul základní přístupy k produktovému managementu, které si musí osvojit, aby mohli vytvářet hodnotné aplikace, které budou jejich uživatelé využívat. Pokud si tvoříte jen tak pro sebe, můžete zde přestat číst. Pokud však chcete, aby vaše produkty využívali i ostatní a byly pro ně hodnotné a přínosné, doporučuji číst dál.

Začneme postupně. Když tvoříte produkt, měli byste myslet na následující tři perspektivy:

• Smysluplnost a životaschopnost produktu – řeší produkt reálnou potřebu nebo bolest na trhu dost velkému počtu lidí (možná i AI agentů)? Našli jste vhodný byznys model, který vám umožní na produktu vydělat?

• Použitelnost – pochopí zákazníci, jak se produkt používá? Dokáží vaši aplikaci používat a dokončit svůj úkol? Je v tom apka intuitivní?

• Technickou proveditelnost – je aplikace vůbec technicky proveditelná se současnými technologiemi? Je napsaná technicky dobře, je stabilní, rozšiřitelná a hlavně bezpečná?

Pokud některou z těchto perspektiv zanedbáte, nebude produkt fungovat. Pojďme se podívat, s čím z toho vám pomáhají vibe-coding nástroje a co si musíte pohlídat vy sami:

1/ Smysluplnost a životaschopnost produktu

Zde vám vibe-coding ani LLM moc nepomůže, tuto část si musíte odmakat vy sami výzkumy s klienty (už můžete ve firmě nějaké mít, ptejte se po nich), analýzou různých existujících reportů či výzkumů agentur. Jazykové modely s chatboty mohou pomoci s agregací dat a hledáním vhledů a pochopení v rozhovorech a reportech, ale nenahradí vám rozhovor samotný, jak bohužel často neproduktoví lidé tvrdí. Jazykové modely stojí na pravděpodobnosti, budou tedy předkládat obecnější odpovědi, ne specifické postoje a zvyky jednoho člověka, které nás zajímají primárně.

Této části se budu věnovat nejvíc z jednoho důvodu. Čím víc lidí bez technického a produktového vzdělání bude usilovat o vytváření řešení přesahujících hranice svých jednoduchých pokusů o časovou úsporu rutinních úkolů, tím více se budou muset naučit to, co se IT svět učil ohledně tvorby produktů posledních zhruba 20-30 let. Skutečně to není jen o tom, sednout k vibe-coding nástroji a něco vytvořit. I tento nový postup vyžaduje bolestivou část, které se říká hluboké přemýšlení.

V produktových inovacích jsem za dvě desítky let slyšel mnohokrát, jak je nápad tajný, důležitý a nemůže mi ho ten člověk říct (nápadů mají všichni spousty), ale také jsem viděl, jak v praxi o nápad zase tolik nejde, klíčem je naopak správná a důsledná realizace. Důležité je nápad přetavit do něčeho, co se dá dobře používat, potřebuje to hodně lidí (nejen vy sami) a taky jak nastavit byznys model, aby to i udržitelně vydělávalo. Takže nápad je jen malinká část úspěchu, klíč leží v reálných potřebách, dobré realizaci, fungujícím byznys modelu a ve správném načasování. Tady už je vidět, že některé věci ani nedokážete ovlivnit. Příkladem je třeba správné načasování, kdy trh váš produkt pochopí a přijme, zvláště u nových typů produktů.

2/ Použitelnost (CX)

Zde mohou vibe-coding nástroje trochu pomoci (něco dobře a logicky navrhnou) nebo naopak dodají pocit, že to není třeba řešit, protože to za vás udělal AI nástroj. Trochu se bojím, že sexy vzhled výsledku zamaskuje nefunkční podstatu, již je špatný koncept a logika produktu. Problémem je totiž pochopení pojmů CX a designu. Design a CX není o barvičkách a hezkém vzhledu, je to o konceptu produktu, jeho flow, návaznostech, poskytnutých informacích, intuitivním ovládání. Jinak řečeno design a CX je o dobře vyřešené obsluze potřeb, které má produkt řešit. Bavíme se zde o návrhu konceptu celého produktu, ne o vzhledu již (blbě) navrženého konceptu, které vám AI nástroj může předložit.

Jak často jste se zasekli v e-shopu, protože vás nutil vytvořit si účet a nemohli jste bez něj nakoupit a zaplatit? Kolikrát jste odešli bez dokončeného nákupu? Toto je špatný design. Když v infotainmentu v autě na několik kliknutí hledáte běžné ovládání typu klima nebo telefonu. Toto je špatný design.

Už i jednoduchá apka typu reportování času na projektu může na špatném konceptu krachnout. Čím složitější je daná doména a čím více byznys pravidel musí řešení pojmout, tím důležitější roli hraje design (koncept) celého řešení. Tuto abstraktní vrstvu potřebuje AI typicky spíš jako vstup, než že by ji tvořilo samo a navrhlo podle ní komplexnější produkt.

Klientská zkušenost je tedy často klíč k pochopení produktu a schopnosti dokončit úkol, který od produktu očekávám. Pomáhá vám s ním vibe-coding nástroj nebo ho naopak maskuje a uvádí vás do stavu, že jej není třeba řešit a vyřešil ho za vás?

3/ Technická proveditelnost

S touto produktovou perspektivou nyní tvůrcům vibe-coding pomáhá nejvíc. Nemusíte umět programovat a dokážete udělat skvělou apku, že? Tak to tvrdí spousta AI „expertů“ a firem na trhu… a nebo vůbec? Určitě vám AI nástroje pomohou s tvorbou prototypů v řádu minut oproti hodinám až dnům bez AI nástrojů. To je pecka bez diskuzí. Po ověření potřeb můžete s klienty validovat více myšlenek a konceptů řešení (pamatujete na design?), upravovat je hned na místě a dále pokračovat ve validaci s klientem. Tato oblast je přínosná bez diskuzí.

To, co jsem popsal, ale není hotový digitální produkt! Bavíme se zde o ověření a pochopení konceptu řešení v rámci procesu vývoje produktu. Nemluvíme o výsledné dobře fungující aplikaci. Tu poté píšou vývojáři na základě výše popsaných vstupů a diskuzí.

Pokud berete výstup vibe-codingu jako hotový produkt, je třeba upozornit na část, která je často přecházena (možná proto, že někteří hlasití AI propagátoři nemají technické vzdělání). Jde o technickou kvalitu a pozadí produktu. Produktový vývoj je dost také o tom, jak je software napsaný, zda je kód přehledný, rozšiřitelný, stabilní, výkonný, a hlavně bezpečný, zvlášť pokud jde třeba o soukromá data či platby. Někdy mi přijde, že lidé bojující na jedné straně s každou cookie a proti velkým firmám či institucím, že jim žádná data nedají, na druhé straně nadšeně otevřou svojí novou vibe-coding apkou firemní či finanční data všem na internetu 🙂 Často tedy aniž by to vůbec tušili. Jsou hrdí na svůj výtvor řešící (pouze) jejich potřebu, sdílí to bez znalosti cílovky všem, ať to taky používají a tím ohrožují i jejich data.

Rychlost odezvy je další zásadní věc. Vibe-kódovaná aplikace se může dobře chovat pro jednotky uživatelů, jakmile jich ale máte stovky nebo tisíce, může se apka zahltit a přestat odpovídat nebo se chovat nepředvídaně. To vše má silný vliv na uživatelskou zkušenost.

Další problematikou je ošetření chybových stavů, co když se dostanete někam, kam jste neměli? Jak zareaguje aplikace? Co vám oznámí? Umí se z tohoto stavu „probrat“ nebo ji musíte shodit a znovu spustit? Co se stane s daty a rozpracovanými akcemi v daný moment? Budou částečně uloženy nebo zahozeny?

Vidíte, že otázek a technických oblastí je mnoho. Cílem textu ale není vás odradit, cílem je ukázat, že jsou 3 zásadní oblasti, které je vhodné při tvorbě produktů pomocí vibe-codingu promyslet a z technického pohledu pak třeba poprosit někoho o kontrolu nebo dotažení. Navíc musím dodat, že jsem byl vždy jen průměrný programátor a nikdy jsem nebyl expert na bezpečnost aplikací a sítí 😉 Na to si najděte zdroje od expertů v této oblasti. Chci jen upozornit, že současné vibe-coding nástroje nejsou moc dobré v zabezpečení a někdo toho může cíleně využívat.

Při tvorbě produktů je tedy vhodné zamyslet se nad cílovkou a její potřebou, konceptem řešení (designem) a technickou architekturou a bezpečností. Obrovský rozdíl může být apka pro mě vs. pro stovky lidí, soukromá vs. firemní, apka na generování memes vs. apka s platebními údaji.

Jak tedy na to, abyste vibe-coding vytěžili a začali tvořit dobré produkty řešící skutečnou potřebu více lidí? Zkusil jsem popsat stručný postup a kroky, které je vhodné promyslet a odpovědět si, ideálně pak i validovat s trhem. A ano, přesně k tomu můžete použít i vibe-coding prototypy (tedy až od kroku 3 :)).

Stručný postup ověření nápadu pro vibe-coding tvůrce

1/ Porozumění klientovi a jeho potřebám

Víte pro koho aplikaci tvoříte? Jak velká je cílovka a jaké potřeby řeší? Jak je řeší nyní? Neexistuje již na trhu podobná aplikace, která toto řeší? Proč mi žádná z nich nesedí? Neobsahují nějakou logiku, na kterou jsem zapomněl? Neřeší potřebu o něco více obecně, aby seděla širšímu segmentu? Pokud jste nic nenašli, zkuste si odpovědět, proč dosud nic neexistuje? Není téma třeba příliš technicky či logicky náročné?

2/ Efektivní ověření vašich nápadů, hypotéz, domněnek

Všichni máme spoustu nápadů, ale jen málo z nich stojí za to, aby se z nich stal produkt 😉 vážně věřte mi 🙂 a nebo si to nyní zkuste. Zamyslete se, jak zní vaše hypotézy stojící za myšlenkou na produkt a zkuste si je vyvrátit. Ptejte se potenciálních uživatelů:

• Jak pracují dnes a co jim funguje a co je brzdí?

• Jak řeší hlavní úkoly (potřeby) nyní? Jaké používají nástroje, produkty, řešení?

• Dělají něco stále ručně? Proč, když existují dostupné digitální produkty?

• Platí již nyní za nějaká řešení? Za jaká? Kolik asi?

Hlavně se prosím v této fázi neptejte, co říkají na váš produkt a zda se jim líbí. Zvlášť ne, pokud nemáte ještě ověřenou potřebu a ani nevíte, zda je člověk naproti vám vaše cílovka. Pozor taky na kamarády a rodinu J Buď vás mají rádi a falešně vám potvrdí, jak úžasný produkt máte (oni ale nemusí být cílovka, tudíž to není průkazné) nebo naopak budou říkat irelevantní věci (opět, oni nemusí být cílovka ;)).

Ověřený nápad a hypotéza však JEŠTĚ NENÍ kvalitní produkt. Tto je další a možná i těžší část, která vás nyní čeká.

3/ Hledání správného řešení

Pokud máte ověřené potřeby a jsou skutečně palčivé a žádné řešení pro ně neexistuje nebo ty nalezené nejsou dobré, můžete se vrhnout na hledání řešení. Začněte návrhem konceptu. Pamatujete? Design. Nalézt vhodné řešení a navrhnout jeho koncept a detaily je mix umění a technické dovednosti 😉

Musíte se zamyslet nad konceptem a ten promítnout do nějaké formy řešení. Tady je dobré se naučit, jak rychle a efektivně ověřovat koncepty řešení s uživateli. Ano, a přesně tady opět pomáhá vibe-coding a množství prototypů, které můžete ověřovat.

Pamatujte, že situaci může zesložitit doména vašeho produktu, tedy složitost byznys logiky a mnoho zakódovaných pravidel. Tato pravidla musíte zakomponovat do vašeho konceptu řešení tak, aby se aplikovala, kdy mají a ideálně nebránila dokončení úkolu (pamatujete na eshopy s nutností registrace?).

Pamatujte na výše popsaný pohled technické proveditelnosti. Umí vaše vibe-coding nástroje řešit bezpečnost, performance, použitelnost? Co vše je pro daný typ produktu potřeba? Máte někoho, kdo může být v celém tomto kroku přítomen a pomůže s technickou podporou a doladěním?

4/ Iterujte nad řešením a produkt dolaďujte podle zpětné vazby a měření

Tvořte další verze a iterujte nad nimi. První verze produktu není nikdy ta dobrá, vždy jsme něco mohli pochopit jinak, návrh něco neobsahuje, máme pokryté jen základní scénáře apod. Zde AI převzala téměř celý krok a zrychlila na rychlost světla 🙂

Tvorby se nelekejte, ale pozor na sdílení vašich výtvorů

Na závěr ještě jednou zdůrazním, určitě nikoho nechci brzdit ve zkoušení tvorby svých aplikací pomocí moderních AI nástrojů. Zkoušejte, hrejte si, automatizujte osobní rutiny, ale nesdílejte vaše výstupy s výzvou, ať si je lidí kolem vás vyzkouší a používají. Pokud sdílíte, tak s varováním, že řešení nemáte technicky ověřené z pohledu bezpečnosti, stability, údržby, a tudíž hrozí nebezpečí úniku osobních údajů, resp. dat v aplikaci použitých a zpracovávaných (to mohou být i vaše hesla pro přístup používaná i jinde).

To, na co chci upozornit, je vaše nevědomá činnost a její důsledky. Z technického pohledu může vést k bezpečnostním hrozbám. Z produktového pohledu můžete přispívat k tvorbě balastu mnoha jednouživatelských aplikací k pocitově vnímaným potřebám (vašim osobním), které ztíží nalezení dobrého produktu, který řeší ověřené potřeby specifickým segmentům.

V neposlední řadě pak automatizace osobních rutin aplikovaná v práci, může vést k mnoha sub-optimalizacím z pohledu celku. Automatizujete svůj krok a můžete rozbít celé flow, přetížit kolegu, u kterého zatím automatizace provést jednoduše nelze apod. V pracovních postupech je třeba se dívat na celek: proč daný postup či proces existuje? Na jaké další kroky a pravidla je navázán? Jak můžeme zlepšit tento proces, nejen moji agendu? Bez těchto znalostí můžete dosáhnout optimalizace vaší práce a rozbít celý proces na úrovni firmy. Více o tomto tématu jsem psal jinde.

Jen další krok v dlouhodobé evoluci nebo skutečně skoková změna?

Rychlá úvaha na závěr. Podobné snahy jako je vibe-coding můžeme ve vývoji digitálních produktů vidět už víc jak dvě desítky let (uff, už je to doba co jsem vstoupil na trh práce :)). Byl zde Rapid Application Develeopment (RAD), který sliboval uživatelskou tvorbu produktů bez nutnosti znalosti programování (GUI buildery, knihovny komponent apod.). Pak zde byl koncept Model-Driven Developmentu (MDD) vycházející z analytických a logických modelů, které popisovaly a generovaly řešení. Obojí se uchytilo a obohatilo vývoj, IDE nástroje, postupy vývoje softwaru.

Díky konfiguracím, modelování s generováním kódu, formulářům a GUI builderům se podařilo zpřístupnit úpravu digitálních produktů uživatelům a tím demokratizovat změny a trochu už i tvorbu digitálních produktů. Tyto principy jsou tedy s námi desítky let, vibe-coding není novinka, jen už toho dokáže díky technologii o něco víc. Stále má ale ty stejné problémy:

• musíte vědět, co chcete (potřeby a řešení)

• musíte to umět dobře popsat a navrhnout (design)

• (nepředvídatelné) technické a bezpečnostní díry a nedokonalosti

Jak vytvářet digitální produkty bez nutnosti programování tedy řešíme již desítky let. Zatím se ale spíše víc a víc potvrzuje, že tyto nástroje pomáhají znalým expertům dělat svůj úkol rychleji a kvalitněji. Není to řešení (zatím), které odstraní programátory a udělá tvůrce kvalitních digitálních produktů z kohokoliv. Proč si to myslím? Velká byznysová a logická komplexita produktů, neznalost principů produktového managementu v širší populaci a také lenost hluboce myslet tomu zatím brání. Sám se těším, jak se budou tyto trendy dál vyvíjet.