UX Monday: Opportunity Solution Tree - Jak se nezbláznit z Backlogu

Dámy a pánové, já vás opět znovu vítám tady na UX Monday. Mám obrovskou rado, že jsme se tady mohli setkat v takhle hodnej hojném počtu. Vás je tady dneska jako much, to je skvělý. A tady v úžasných prostorách MSDčka, našeho dlouhodobého partnera, děkujeme za to. A na akci, která se koná každé první ponědělí měsíci a která se jmenuje UX Monday. Dneska po půlroce opět s naším skvělým spíkerem Michalem Vojákem z Design Dev. Děkuju, že opět přijmul tuhle hozenou rukavici a dneska nám tady odpřednáší. Tak, na začátek úplně jedna věc, vlastně pravděpodobně tohle budete znát, Scrum a jeho jakoby backlog. A to je to, jak vlastně my máme zkušenost s tím, že když vlastně vstoupíme jako návrháři do nějakého týmu, tak dost často vlastně si zadává v nějakých epikách, v nějakých usotorkách nejčastějiž zadání. A to samozřejmě není špatně. Ale problém je, že tenhle backlog je primárně pro vývojáře, protože už je to nějaké řešení, které oni potřebují udělat. Je popsané v nějakých user-storkách, samozřejmě z pohledu uživatele, což je v pořádku rozdělí z toho nějakých úkolů. Ale slouží to právě pro product delivery. Oni potřebují nějaké řešení, aby ho dokázali dodat. Protože vlastně klasický backlog, nejdejme tomu bez kramu, funguje tak, že každý týden, každý 14 dní, nejčastěji 14 dní, potřebujete dodávat nějaký potenciální increment produktu, který vy můž A tohle ideálně každý čtrnázdní. Něco, co dokážete dát do aplikace a tím pomoct tý aplikaci. Problém ale nastává samozřejmě v tom, jak to řešení potom vzniká. Protože dost často je tak, že máte nějakou user-storku a pak se dá u Vixákovi, ať ji teda zpracuje. Ale to už je jako reální zadání. A co se na tom dá udělat? Většinou to lehce možná přivohnout, možná na to dát jako uživatelský testování, ale to je všechno. My do toho potřebujeme dostat ale mnohem víc. My potřebujeme začít z nějakého takzvaného outkamu, z nějakého výsledku, kterého chceme dosáhnout. A přes poznání uživatelů dojít vlastně k nějakým příležitostem a pak teprve až k tomu řešení, až k tomu zadání v nějaké části. A ten rozdílný backlog je vlastně v tom, že delivery backlog, to jsem ukazoval, ale discovery backlog vypadá trošku jinak. On vypadá tak, že vy máte třeba nějaký nápad. Bavíte se s uživateli, ty vám říkají nějaké příležitosti, těch příležitostí je celá řada. A teprve na ty příležitosti vy budete mít nějaké řešení. Těch je taky celá řada a v těch potřebujete prioritizovat. A pokud tohle se snažíme naroubovat na ten klasický Scrum, tak nám to dost často drhne. Protože dostaneme nějaké zadání a máme 14 dní na to, nebo třeba dva sprinty, takže měsíc, rychle něco vyrobit. Ale když chceme udělat hloubkový rozhovor, když chceme udělat uživatelský testování, tak se A to, o čem já budu povídat, je, jak tenhle discovery backlog, to znamená ty vaše nápady, příležitosti, ale i ty výsledky, ty cíle, kam se to dojít, organizovat tak, aby se v tom trochu líp dalo vyznat. Zeptám se možná, kdo tady zná Opportunity Solution 3, jako tu metodu jako takovou. Super, pár lidí jo. A kdo ji používá? Jo, tak to už je mnohem méně lidí. Každopádně. To je vlastně metoda, kdy vy nějakým způsobem strukturujete ty informace, který v tom produktu máte, to znamená výsledků, který chcete dosáhnout, podně hledáte příležitosti a podně řešení. Pokud začneme u těch cílů jako takových, schválně, dokázal by tady někdo nazdílet, jaký máte třeba cíle v produktovým týmu, teď se bavíme, můžete mít klidně e-shop, můžete mít klidně nějaký web, ale není problém, pokud vyrábět nějakou sasko nebo nějakou mobilní aplikaci, jaký máte cíle na kvartál nebo na Na rok. Může někdo říct nějaký cíl? Tak někdo? Mě chtěl bych volávat. Zvýšení konverze. Zvýšení konverze. Super. Takže tady máme asi nějaký e-shop do možná nějakou prodenní aplikaci. Zvýšení průměrné ceny objednávky. Super, jasně. Jo, snížení opuštění košíku. Paráda, super. To jsou dobrý síle. To, jaký máme zkušenosti my, co se občas stává a možná bych ještě se vracholku vrátil. Já jsem teďka byl na konferenci a tam vlastně jeden produktový manažer říkal jednu věc a on říkal, že úspěšný produkt se dodává tehdy, pokud splníte klasický trojoperativ. To znamená, dodáte to včas, ve stanovený kvalitě, zastavený peníze. Jenže to má jeden problém. Kde jsou nějaké firmní cíle, to znamená, k čemu to tý firmě pomohlo a kde jsou ty uživatelé, jestli to budou chtít používat. Protože pak se vám velmi snadno může st Projektově vlastně velmi úspěšně, zadovaný čas, zadovanou kvalitu, zadované peníze, jenže té firmě to nepřinese vůbec nic a vyhodíte miliony. Ta druhá věc, co se nám stává, je, že vlastně ty týmy mají ty cíle právě ty dané featury nebo ty řešení. To znamená, že oni třeba vědí, že chtějí přidat nástěnku, oni vědí, že chtějí přidat ikonu do menu, oni vědí, že chtějí přidat nějakou novou funkčnost, ale to je v reálu jenom čistě to řešení. To už jste jako na konci celého toho proces A co to má za problémy? Pokud si třeba vezmeme e-shop, to je příklad z naší praxe, dohodli jsme se s nima, že teraz zvýšíme obrat o 50%. To je nějaký cíl, kterýho chceme dosáhnout za celý třeba rok. A pak přijde z toho týmu, nebo od toho nějakého manažera, tak fajn, tak pojďme skopírovat detail produktu od konkurence. To se nám hrozně líbí a to bude fajn. No a ten problém najednou nastává v tom, že my máme nějaké řešení. Skopírovat detail produktu od konkurence. Tak to uděláme. Chceme do toho přidat nějaký UX, tak to uživatelsky otestujeme. Ale v tu chvíli, kdy se zeptáme, jak to naplňuje ten cíl, jak pomáháme tomu cílu, aby se to stalo. Těžko říct, jak zvyšujeme obrata 50%, čím tomu pomůžeme. A druhá věc, rozhodně důležitá, jak pomáháme tomu uživateli jako takovýmu. Proč předěláváme ten detail toho produktu? Protože chceme zlepšit možná povědomí o tom, jestli produkt je sklade nebo ne. Čemu on vlastně jako nerozumí? To my nevíme. No, do tohohle jsme se A realita je taková, že stále má tam něco UX, něco grafika, je potřeba ten produkt vyrobit, je potřeba ho otestovat. Uživatelsky ho otestujeme, abychom teda si byli jistí, že to ty uživatelé chtějí. Bohužel to je samozřejmě uživatelský testování, testování použitelnosti. Takže oni tím prošli, to bylo bez problémů. No, sečteno, podtrženo 122 tisíc. A výsledek? Jupsík, dupsík. Propad konverze o 10%. A co je nejhorší? Proč? Tak to vůbec netušíme. Protože těch změn bylo celá řada a my vůbec nevíme, co se vzkazilo. Protože my jsme mohli přidat 5 věcí, které pomohly a pomohli jsme přidat 6 věcí, které nepomohly. A těžko říct, kdo byl ten problém. A to je přesně ono. Pokud vlastně ten tým je fokusovaný čistě na řešení, už rovnou chce něco vyrábět, tak on ho vytvoří, změří, v lepším případě změří, některý týmy ani neměřejí, takže vlastně ani nevědí, co se děje, oni ho změřejí, změnějí to, no a ne tak to zkusíme znova, tak zase něco vytvoříme, zase to změříme a zase zjistíme, že to nefunguje. A to je obrovský problém, protože to vás může stát velký peníze. Pokud se zaorientujeme na ten cíl, někteří tady zazněli, tak je to o tom, že vy víte, co chcete vyrábět. Potřebujete pochopit uživatele, to znamená, jakým způsobem můžete naplnit ten váš cíl, pak to vytvoříte a pak to změříte. Není jistota, že by to stejně pomohlo? ale snížíte velmi pravděpodobnost toho, že vytvoříte něco, co nemá přínos pro váš biznis ani pro uživatele. Můžel to nikdy není 100%, ale vždycky pracujete s tím, že snižujete pravděpodobnost toho, že vytváříte něco, co nemá pro ten váš biznis dopad. No a když se právě podíváme na biznisové cíle, pokud to budete hrát angličtině, tak se o tom mluví často jako business outcomes, to znamená, to jsou nějaké výsledky, které chcete ale v firmách si dosáhnout. Ale to jsou věci, které by neměly mít ten produktový tým. Ale může to To může být spoustu věcí, snížit nějaké fixní náklady, cokoliv. To chce ta firma. Proč to nemůže mít produktový tým? Protože pokud my si vybereme, že chceme teda zvýšit obrat o 10%, tak to můžeme dosáhnout spoustu jinýma rozhodnutíma, biznesovejma, jako je třeba zdražit ten produkt. Nebo taky můžeme vytvořit nějaký nový produkt, který nám to vyrobí. Můžeme přijít na nový trh, ale o tomto nemůže rozhodovat ten produktový tým, pokud jste v nějaký větší korporaci, kde je víc produktových týmů, tak oni si nemůžou ř Tohle stvě musí být víc jako biznisový rozhodnutí. Proto ten tým, aby byl efektivní, musí pracovat s tzv. product outcomes. Já to nazývám produktový cílem, mně se to tam do té češtiny úplně nehodí ten výsledek, ale každopádně produktový výsledky, produktový cíle, to je to, co by ten tým měl mít a to, co dokáže ovlivnit. Protože například u e-shopu ale dokážete pravděpodobně ovlivnit odpadovost v košíku. Je to věc, na který můžete pracovat. Ale pokud třeba vyrábíte nějakou aplikaci, tak můžete mít jiné cíle. To znamená zvýšit PFM score o 25%. Nevím, kdo zná tady PFM score, product market fit score. Zná někdo? Tohle je třeba jako skvělá metrika, pokud pracujete v nějakém buď SAS, nebo na nějaký mobilní aplikaci, webový aplikaci atd. Je to velice jednoduchý. Zeptáte se uživatelů na čtyři otázky, respektive na jednu otázku, která má čtyři odpovědi. Co by se stalo, kdyby od zítra nemohli používat tuhle stu aplikaci? Jak by se cítili? byli by velmi znepokojení, byli by trošku znepokojení, nebyli by vůbec znepokojení, anebo prostě tu aplikaci nechtějí používat. A to, co vás zajímá, je ty, kteří by byly, nebo znepokojení, ty, co by byly velmi jako zklamaní. A to je to, co vás zajímá. Protože pokud vy událáte aplikaci novou a pustíte na to tohle a zjistíte, že jen 3% uživatelů, který dneska máte, by byli velmi nespokojení, kdyby to zítra nepoužívali, tak máte obrovskou rezervu v tom bejt lepší. Udává se číslo, že alespoň 40 % byste měli mít tohle score, abyste mohli v tom pokračovat. A je to velmi dobrá metrika, protože to je čistě jenom v rukou týmu, jak toho dosáhne. Protože vy tam můžete mít různý cílový skupiny. Vy se můžete bavit s novými uživatelemi, se stávajícími, jak to zlepšovat, tohle score, abyste byli lepší. A vy cílíte na to, že vás zajímá ty lidi, který by byli velmi naštvaný, pokud vy byste skončili. Protože to jsou ty vaše core lidi, na kterých nakonec ten biznis můž Každopádně to jsem odbočil, to je vlastně jako by to PFM score. Ale můžete řešit třeba zvýšení používání aplikace, pokud vám to dává smysl. Samozřejmě, že ty produktový cíle by měly být zarovnaný s těma vaše biznisovýma cílema. To znamená, že pokud chceme třeba zvýšit obrat, tak je naprosto v pořádku, že bude ten produktový cíl zvýšit o 5% jakoby free účty na placený účty. A jak toho dosáhnout, jaký tam máme problémy a tak dále. To znamená, že ten produktový cíl je vlastně základ pro ten produk a být i tak trochu zároveň ale nezávislý od toho vedení. Ale vy vidíte, že když toho z toho budete dodávat, tak to opravdu pomůže celý té firmě. Ale zároveň jsou to věci, které vy dokážete ovlivnit. Každopádně, pokud si začnete definovat ať už jakýkoliv cíle, ale ty produktové cíle, tak je dobré je mít na nějaký časový interval, například třeba na tři měsíce. Je potřeba, aby byly měřitelný. Pokud máte třeba OKR, tak vlastně tenhle váš produktový cíl jsou ty key resulty. jsou ty věci, které vy dokážete měřit a které dokážete klidně každý týden, každý 14 dní vykazovat, že se opravdu posouváte k tomu vašemu key resultu nebo k tomu vašemu měřitelnému cíli. To znamená, pokud si rekneme, že to je odchodovost v košíku, tak to se dá velmi snadno měřit a vy každou změnou, kterou budete dávat do toho produktu, můžete velmi rychle měřit, zda opravdu k tomu cíli jdete a nebo ne. Proto je potřeba mít dobře stanovený produktový cíl a hledat příležitosti, kterýma to m K tomu se dostanou za chvilinku. Tak, hnedka teďka. Příležitosti. Tak, řekl mi někdo, co si představíte, já tady budu problému o příležitostech. Co jsou pro vás příležitosti? Jo, možná to je nejasný. Každopádně. Jo, tak. Zákaznický problém, anebo já nevím, jak to říct český, pain point? Jo, přesně tak. Jsou to vlastně jakoby zákaznické potřeby, přání, obavy. Je to něco, co reprezentuje vlastně ten názor toho uživatele. A často se tomu taky říká problémy. Pokud budete tohle z toho hledat, často se říká buď příležitosti nebo problémy. Jedna taková, asi hodně starý citát, ale velmi pravdivej. A on naráží právě na to, co jsem říkal, že když se zaseknete v tom řešení, tak je to špatně. Protože Albert Einstein asi snad řekl, nikdy jsem navěřoval, jestli to je pravda. Ale každopádně, kdybych měl hodinu na to vyřešit nějaký problém, tak budu 55 minut přeměšlet o tom problému a jenom 5 minut věnuju tomu řešení. Dost často ty týmy to mají přesně v obráceně. Rychle pochopají ten problém a pak 55 minut šperkujou to řešení. Ale to nemusí být vždycky ta správná cesta. Jak jsem říkal, jak tady vlastně zaznělo, ty příležitosti, to jsou vlastně potřeby, obavy, přání, důvěra, jakou zbuzujete. To je cokoliv, co ten uživatel vlastně potřebuje. A vy byste to ideálně měli vlastně transformovat do nějakých příležitostí, který ten produkt může dělat. Jakým způsobem vlastně příležitosti reálně vznikají? nebo jak třeba my k těm přistupujeme, že pokud máte třeba hloubkový rozhovory, například focus groupy, někde, kde dokážete získávat zpětnou vazbu od vašich uživatelů, tak vlastně si vytáhnete většinou citaci. Nevím, jestli to takhle jakoby děláte, můžete mít třeba plnej zápis, máte 5 A4 z hloubkovýho rozhovoru, abyste se k tomu někdy mohli vracet a z toho si vytahuje ty zajímavý citace. Ty citace se potom v týmu berou a vyrábějí si z toho takzvým insighty, to znamená ti vhledy dochován A potom vy můžete vlastně jakoby zlookovat citace do nějakých insightů a ty insighty pak můžete právě zlookovat do příležitostí, nebo insight celé tedy jakoby rovná příležitost. To, co je dobrý je pro ten tým, aby se v tom líp orientoval, dávat ty příležitosti z pohledu toho uživatele, abyste potom i líp pochopili, když budete procházet neustále vlastně jakoby ten váš Discovery backlog, jak je to vlastně myšlený. Já chci vědět svůj kredit po přihlášení. To může být nějaká příležitost, který ty uživatelé maj. Pokud to budete dělat z toho titulu, jakoby já, můžete se vyhnout v někdy nepochopení toho zadání. Protože pokud vy napíšete jenom, že uživatel má problém s kreditem po přihlášení. Jaký? Pokud to napíšete podobně, jak on to říká, tak vám tohle zdi může pomoct více orientovat potom v těch jeho potřebách a právě v těch příležitostech, který máte. Tak, ukázka příležitostí vlastně. Potřebuju rychle zaplatit službu. To může být nějaká příležitost, kterou vy máte, kterou vám uživatelé říkali, protože... jim dneska trvá třeba dlouho, nebo nevěřím plativní bráně, vypadá porezřele. Samozřejmě, můžou to být nejasnější příležitosti, který potom vy budete dál rozpadat, za chvilku se tomu budu věnovat. A problém právě samozřejmě je, že vy když uděláte hloubkový rozhovory, uděláte jich z 6 uživatele, z 20, nebo klidně s každým uživatelem jednou týdně, tak vám vznikne pravděpodobně v MIRu, samozřejmě každý to vyhodnocuje jinak, my často používáme třeba MIRu, tak nám svoustu různých lístečků, možná svoustu různých potřeb a je potřeba se v tom organizovat. A zde se právě dostáváme hloub už do Opportunity Solution Tree. Opportunity Solution Tree totiž pomáhá právě strukturovat celý váš Discovery Backlog, nebo samozřejmě pokud řešíte nějaký nápad, že máme cíle, známe cíle, děláme výzkum, z toho nám vypadávají ty příležitosti, kdy my si je právě dáváme pod ty cíle, kdy nám to dává smysl. A až teprv, kdy ta příležitost je pro nás jako uchopitelná, je dostatečně detailní a už na ní můžeme generovat nějaké řešení, tak teprv dochází k tomu, že vy si ji vybíráte, generujete řešení, ty řešení potom prioritizujete a až ty, který vyberete v té prioritizaci, tak tyhle by správně se měly začít teprv kreslit do iframeu a měly vyjít na nějakou validaci, ať už třeba na A-B testování, pokud to může trádat do produktu, nebo na usability testing. Ale až v této chvíli, do této doby, vlastně reálně nemusíte vědět, co by se mělo ještě dělat. Tak a ty příležitosti, já jsem mluvil o tom, že jsou nějaký obecnější a mí obecní. Oni jdou vlastně jako by ze zhora od těch obecných k detailnějším. A můžete si to představit tak, že pokud bychom měli třeba produktový cíl, změnit 5% free účtů na placený tarif, uděláte nějaký hloubkový rozhovor a výjde vám z toho, že nic mě neomezuje v používání. Proč bych měl přecházet? dobrý, to je ještě furt nejasný, tak řeknete, událáte si třeba rozhovor, nebo vám to z toho vypadne a zjistíte, že nevím, že aplikace nabízí zajímavý funkce, který já bych chtěl používat, abych to vůbec platil. A tímhle způsobem vlastně vy neustále zkoumáte ty příležitosti a v době, kdy jsou pro vás ještě nejasný, tak vlastně je potřebujete víc hloubě zkoumat a až jsou jasný, tak teprve potom dál generujete řešení. To bylo nejasný, nebo říkal jsem něco špatně, ve smyslu, že byste to nechápali, tak klidně se přihlašte, abychom se u toho trochu víc zastavili. Všechno je jasný. Přihlásí ruku ten, komu je to jasný. Super, dobře. Tak, každopádně, to, co se nám stává a je velmi běžný, že máte jeden cíl, začnete dělat vlastně jakoby výzkum a začnete dávat hodně věcí do jedné úrovně. A to je potom problém. Vy byste si měli snažit dávat do jedné úrovně jako maximálně třeba 7 příležitostí. V tu chvíli, kdy jich tam dáváte víc, tak se to pro vás začne být jako nepřehledný. A je lepší si klidně začít zhlukovat do nějakých právě jakoby globálnějších příležitostí a tyhle si dávat do nižší úrovně. K tomu len s tomu často právě jakoby docházíme s klientama, že oni všechno chtějí vlastně dávat na tu první úroveň, jenže potom se vám stane to stejné, jako jsem ukazoval to Miro. Sice to budete mít v trošku lepším stromě, ale budete mít cíl a 20 příležitostí. Takže je dobr a dělat si v tom trošku pořádek. Je totiž velmi běžný a potřebujete s tím stromem většinou pracovat třeba jednou týdně. Pokud máte produktový tým, který je opravdu fokusovaný na ten váš produkt, tak tohle by měl být rituál, který se dělá každý týden. Prochází si ten strom, hledáte správní příležitosti a hledáte správní řešení a neustále s tím stromem pracujete. A i to tak, že něco vyskoumáte, zjistíte, že máte špatně přehozený příležitosti. tak je prohodíte, nebo je můžete dát na jinou úroveň. Je to jako živej organizmus, je to váš backlog, v kterém se hlavně potřebujete orientovat. Takže nejde o to, že vy robíte něco, kde událáte buď hrozně širokou strukturu, nebo událáte výzkum, vyrobíte strom a pak ho necháte bejt. Je to věc, s kterou byste opravdu měli pracovat každý týden, jako ten produktový tým. Tak, jedna věc, která do toho lehce háže a lehce neháže vidle, je nějaká segmentace, respektive třeba vaše cílový skupiny. Protože samozřejmě my se tady bavíme o příležitostech, ale pokud máte dvě, tři, čtyři cílový skupiny nebo nějaký segmenty, tak se to začne být trošku jako nepořádek. Je dobrý na tohle si to myslet a můžete to už od začátku pod těm cíl si rozhazovat ty vaše segmenty. Například v tomhle případě máme stále změnit 5% výúčtů na placený tarif. Tak ale můžete rozležit chování, že je jediný u nových zákazníků a ustávajících zákazníků a pod ty dávat různý příležitosti. Některý ty příležitosti se vám dokonce začnou jakoby duplikovat, že patří pod obě dvě cílový skupiny. To pro vás může být dobrý indikátor toho, že třeba takováhle příležitost je věc, na kterou se můžete rychle vrhnout, protože zasahuje pro obě dvě vaše cílový skupiny, pro oba dva vaše segmenty. Ale samozřejmě se taky může stát, že máte produkt, který na toh Pokud se vám stane to, že vy robíte segment a začnete podlinkovávat všechny příležitosti se všema, tak je lepší ty segmenty z toho Opportunity Solution Tree vyhodit, protože v tuhle chvíli už nedávají smysl a nemá žádnou přednou hodnotu. No a já jsem tady zmiňoval, ale právě to, že máte ty cíle, ty produktový cíle, za kterými jdete a to, že máte ty příležitosti, vám pomáhá už v té první prioritizaci těch příležitostí, protože vy uděláte hloubkový rozhovor a zjistíte spoustu příležitostí. A vy byste teďka chtěli dělat na všech, který vám se zdají, že jsou dobrý. Můžeme se samozřejmě bavit o tom, proč to je špatný, že vám se zdají, že je dobrý, jestli to je správný z pohledu produktu. Ale každopádně je dobrý právě myslet na to, že pokud tu příležitost nedokážete dát pod ty vaše cíle, které aktuálně máte, no tak si ji aktuálně nemůžete věnovat. To neznamená, že se ji nemáte nikdy věnovat. Ono ze ten kvartál se může stát, že prostě se změní cíle a ta příležitost se vám bude hodit. ale teďka vy víte, že ta prioriteta tam není a že se tomu prostě nemusíte věnovat. A pokud vás někdo zeptá, proč toho neřešíme, tak je to velmi jednoduchý, no protože to teďka nemáme jako cíl a teď se tomu nebudeme věnovat, protože kdybychom to udělali, tak vypálíme čas toho týmu, vypálíme čas vývojářů, ale neposuneme se k tomu cílu, který jsme stanovili, že za ten kvartál tam třeba budeme. Druhá prioritizace těch příležitostí je vlastně v tom, že vy byste se měli koukat vždycky na ty příležitosti, když j Ideálně ze čtyř různých pohledů. První pohled je uživatelský, druhý taky teda, ale první pohled je uživatelský a říká, kolika uživatelů se týká a jak často ten problém pravděpodobně mají. To je dobré, když dokážete nějakým způsobem ověřit, nebo alespoň jako ten produktovej tým odhadnout. Zároveň ale ten druhá věc, co je velmi důležitá, jaký to má ale efekt. Pokud máme nějaký problém, který trápí 90% uživatelů, ale my ho vyřešíme pro ně to nebude mít žádný velký efekt, tak to taky nedává smysl. To znamená, že vás by měl zajímat vlastně ten dopad na ty uživatele. Můžete radši nebo příležitost, která je sice pro 20% lidí, ale ten dopad na ně bude obrovský z pohledu vašeho nebo třeba z biznisu. A to se dostáváme k dalšímu pohledu. Jak to naplňuje firmní cíle? Jak vám to pomůže, když tu příležitost uděláte? Doháníte konkurenci nebo ji předháníte? Jak to vlastně v reálu je? To znamená, je potřeba se na to podívat i z toho biz z konkurenčního hlediska a pak samozřejmě jak to naplňuje firmní cíle. Problém příležitostí, jak v nich vlastně vybírat, je ten, že dost často jakoby vy nevíte, co to je za řešení a je to dost často špatně představitelný. Proto je velmi těžký hledat jako správnou metodu, jak tohle prioritizovat, protože samozřejmě nejjednodušší je, že vy si řeknete, tak se podíváme na peníze, jenže to vy tady nevíte, tohle staje vám příležitost. Za chvilku dojdeme k tomu, jak vymýšlet řešení. kde už můžete odhadovat, jak to bude náročný vyvinout, ale to u příležitostích nejde. To znamená dost často tohle, co to má na starosti tzv. product trio, to znamená product owner, UX a nějakých tech lead, kde o ní se bavějí a snaží se zhodnotit z těchto čtyř pohledů, do jaké příležitosti by se třeba ten daný týden měli věnovat. Ale bohužel tohle se to prioritizovat je relativně složitý nějakýma hard metrikama. Ještě jeden pohled ale, jak se na to můžete koukat. nevím, jestli znáte one way door, island, two way door rozhodnutí. Ono to je vlastně velmi jednoduchý. Je to o tom, když jdete dveřma, jestli se můžete snadno vrátit. Pokud vy uděláte nějaký rozhodnutí, který pro vás bude velmi složitý potom zvrátit, pokud vy si vyberete příležitost, který vy víte, že například, když tady máme, chceme změnit 5 % free účtu na placený tarif, máme příležitost a zjistíme, že uživatelé Co dělají? Ta příležitost je, že si smažu data, abych nestratil limit. To je super. A nebo nevím, zda aplikace v placené verzi potřebuju. Pokud my se rozhodneme dělat cokoliv s tím limitem, tak to může být velmi náročný, pravděpodobně. Se potom třeba vrátit, když tohle si vybereme. Pokud si ale vybereme třeba lepší propagaci placených věcí, tak to můžeme zvrátit velmi rychle. To znamená, je docela dobrý se na to koukat, že pokud si vyberete nějakou příležitost, jak bude složitý to potom vzrušit, aniž byste to To je právě jakoby one way door and two way door rozhodnutí nebo nějaký jakoby řešení. Tak. A dostáváme se k řešením jako takovejm. Jo, není to tady úplně vidět. Každopádně, vy když si potom vyberete to konkrétní řešení, které vás zajímá, to znamená, že si chceme tomu s tomu věnovat, už je to představitelný, tak byste měli začít v tom týmu a klidně i ve větším počtu, klidně zapojit vývoáře, začít ideovat. A vy potřebujete co nejvíc řešení. Protože... To, že vy vymyslíte spoustu řešení, vám dá v dalším kroku možnost prioritizovat a vybrat to, který vám bude dávat největší smysl. Ideací existuje celá řada. Já osobně používám nejčastější brainstorming nebo design studio. Kolegové u nás používají třeba worst possible idea, provokaci a pak třeba design studio nebo crazy aids. Jenom v rychlosti možná. Brainstorming asi pravděpodobně. Všem jasný, brainwriting je hodně podobná věc, jenom si to píšete, aby se nedocházelo k tomu hejtování, který občas u brainstormingu dochází a nemělo by tam být. Design studio, máme tady spoustu designérů, takže pravděpodobně všichni znají, to znamená kreslíme si, kreslíme si, mezi sebou radíme si. Crazy age, zase design sprintu, děláme něco podobného, ale s osmi řešeníma. Storyboard, kreslíme si storyboard a bavíme se o něm. Worst possible idea. To jsou možná trošku neznámější metody. Znáte tady všechny worst possible idea? Jo. Třeba právě kolegové to používají vlastně před už potom reálným třeba design studiem nebo tak. A to je to, kdy ten tým si říká nejhorší nápady, které napadnou na to daných řešení. A zaprvé dochází k diskuzi, ale tohle ještě není tak špatný, tak možná tohle bychom mohli rozvíjet. A zároveň to ukazuje vlastně, kde jsou nějaké jako limity. Vy si řeknete, co všechno je jako špatný. A pak při dalších izracích vy víte t Ta provokace je velmi podobná věc, kdyby vlastně provokačně říkáte nějaké nápady a snaží se to vyvolat nějakou diskuzi. Ale pokud si dáte UX ideace do Google, najdete spoustu dalších řešení, jde o to, abyste našli v týmu, co vám pomáhá a jde o to, abyste dokázali vymyslet co nejvíc řešení, protože v nich potom potřebujete prioritizovat to, co pro vás bude nejpřínosnější. Protože pokud vy a teďka vlastně Navazujeme na to, vždy si smažu data, abych nenarazil na limit pro místo, tak začneme ideovat. A někdo řekne, nepůjde smazat data. Taky řešení, prostě to nepůjde a je to fajn. Někdo řekne, limit se bude vztahovat pouze na měsíc, to znamená, že to v tom měsíci smažeme, tak ale furt to nejde navýšit. Věnule se to až s každým měsícem. A takhle vlastně generujete nápady, které vás napadnou. abyste potom v nich dál mohli prioritizovat. Zase, priorititačních modelů je spousta. My používáme pohled z productria, to znamená koukáme se na to z pohledu biznisu, z pohledu UX, to znamená uživatele a z pohledu technické provedetelnosti. Znamená se s různýma tímama, některý mají třeba jenom jako impact, to znamená řešit, jaký bude dopad a jaká bude cenová náročnost. Některý lidi používají, myslím si, že rájí spy. Je to o tom, co vám vyhovuje. Je to vlastně jedno. Každopádně my na to koukáme právě z pohledu toho product tria. To znamená, že product owner řekne jeho pohled, jak to pomůže tomu biznisu. UXák řekne, jak to pomůže uživatelům. A techleast řekne, jak je to pravděpodobně proveditelný. A je to z toho hlediska, že každý člověk mluví za svoji odbornost. Protože setkali jsme se s jinou věcí a to je tečková metoda. Tečková metoda je úplně skvělá, pokud děláte retrospektivy a ty lidi říkají, co je nejvíc tr Pokud to ale použijete v řešení, kdy vymyslíme jako tým různý fečury, různý řešení, pak se je otečkujeme, protože chceme do toho zapojit tým, tak to pak nasadíme a zjistíme, že spoustu těch věcí bylo na... no, bylo. A ten problém je v tom, že vlastně do toho rozhodování se nedávají... ty expertízy těch lidí a dávají si jejich pocity. Vstupuje do toho kognitivní zkreslení, vstupuje do toho indukce redukce, vstupuje do toho sociální a informační bublina. Ty lidi se rozhodují vůči tomu, že jim se to takhle líbí a tak to tečkujou. Jenže to nemusí být vůbec správně. Takže to, co bych doporučil, je vyhnout se tečkový metodě při prioritaci řešení. Zvolte metody, je jich spousta, a zvolte metody, který tohle z toho Vyrušej. Vyrušej právě kognitivní zkreslení a vyrušej indukci, dedukci. Možná jenom indukci, dedukci znáte? Jo? Všichni? Jo, indukce. Tak tady vidím. Protože dedukce je pravděpodobně všem známá, i když občas se právě zaměňuje za indukci. A to je, kdy z globálních nějakých pravd tvrzení skládáme lokální. Například, když řeknu, že Facebook je sociální síť a sociální síť spouuje lidi, tak můžu říct, že Facebook spouuje lidi. Nevyrobil jsem nic novýho, jenom z nějakých dvou globálních tvrzeních jsem vyrobil jednu lokální. Indukce jde na hledání pravdy ze spoda. To znamená, že z lokálních tvrzeních se snaží složit globální pravdu. To znamená, Lukáš je na Facebooku, Petr je na Facebooku, Vlasta je na Facebooku. Tak jsou všichni na Facebooku přece. No jo, jenže to nemusí být pravda. To může být pravda z 5% nebo z 90%. A pokud na základě tohohle z toho vyberete nějaký řešení, protože vám se to takhle zdá, vstoupí do toho sociální informační bublina, takže máte fakt pocit, že se rozhodujete správně, tak to může být velmi nereální, protože jenom jste byli ovlivněný indukcí sociální informační bublinou a různýma kognitivníma zkresleníma. Takže pozor na tečkovou metodu v prioritizaci řešení. Tak a docházíme k validaci. Protože teďka, teprve jsme vyrobili a vymysleli, respektive vybrali to správné řešení a teď je potřeba ho zvalidovat. Protože stále nevíme, jak to je. K tomu můžou sloužit právě uživatelské testování, kdy vy se ptáte, jestli to řešení řeší ten jejich problém. Může k tomu sloužit AB test, to je úplně skvělý, na e-shopech se to dá velmi snadno dělat. Kdy vlastně máte nějaké řešení, dáte ho do produkce a rovnou otestujete, jestli to opravdu funguje nebo nefunguje. Nebudu dodovaný testování. Těch validačních metod je zase celá řada. Ale nezapomeňujeme na to, že potom, co si vyberete něco, nakreslíte to do Wi-Frameu, i klidně to už vadelského testujete, tak je prostě potřeba neustále i to měřit, validovat a ověřovat si, že jdete po správný cestě. Tak, pokud bychom se podívali na nějaký kompletnější Opportunity Solution Tree, tak on opravdu, ten tým, a je to velmi nápomocný, by ho měl znát, měl by ho vidět a měl být z toho, že vy znáte biznisový cíle. To znamená, že Z toho vy znáte vaše produktový cíle. Potom víte, že ty cíly můžete naplňovat přes nějaký různý persony, různý segment, to, co vám dává smysl. Pod to si potom řadit vlastně ty příležitosti a pod to tebe v řešení. Takhle to možná vypadá, že to je brutálně složitý a hrozně náročný, ale tohleto ten tým dělá každý týden. Ten cíl toho, jak pracovat se stromem, je totiž ten, že vy si řekněte, že máte nějaký cíl, uděláte první rychlý uživatelský rozhovory, zjistíte první příležitosti a rychle edujete první řešení a už třeba během 14 dní, 3 týdnů dokážete dodávat nějaké řešení, které dokážete měřit. A v tomhle vlastně jako by sprintu, v tom discovery sprintu, jedete opravdu třeba každý týden, každý 14 dní, kdy vlastně ten strom neustále prozkoumáváte. A jak jsem říkal, cílem není ho vytvořit rychle celý velkej. Vy klidně můžete mít po prvním uživateli, protože o tom tady úplně nemluvím, ale je třeba dobré testovat každý týden Pokud dneska třeba testujete na začátku nějakého procesu nebo na konci, tak se vám může stát, že během téhle doby, kdy vy něco vyskoumáte s uživatelem a událáte si hloubkový rozhovory, pak to dva měsíce vymýšlíte, pak to oživatelsky otestujete, tak uběhly dva měsíce, kdy jste se nebavili s uživatelem. A teďka by mě zajímalo, kolik lidí za ty dva měsíce řekne, jo, tak to zahodíme všechno, nebo to špatně, to je v pohodě. To většinou si tím neudělají. Ty týmy začnou říkat, no tak to rychle upravíme, ať to teda trochu funguje. Tak to ještě upravíme, tak to ještě upravíme. Pokud budete testovat s uživatelema každý týden, s jedním uživatelem, tak za měsíc nazbíráte podobný počet, jako kdybyste testovali jednou za měsíc. Máte pět rozhovorů, pět uživatelských testů. Ale jste schopní validovat ty vaše nápady velmi rychle. Pokud já mám nějaký problém a za dva dny se budu bavit s uživatelem a on mi ho nepotvrdí, tak ho můžu posunout někam jinam. Protože pravděpodobně to možná nebyl problém. A nebo když to vnímám, že to je důležité, tak to můžu klidně celý ten měsíc zkoušet, zkoušet, zkoušet. Ale mám mnohem jednodušší variantu z toho vždycky ustoupit, protože mám každý týden slyším od uživatelů, to je nesmysl, to je nesmysl, to je nesmysl. My jsme třeba, protože vyrábíme vlastní nástroje pro product Discovery, tak jsme vytvářeli, nebo respektivě, on má součástí toho nástroje, jsou uživatelský výzkumy. A my jsme si řekli, že by bylo skvělé, kdyby v těch uživatelských výzkumech byl takový jako feed. Uživatele se přihlásí do aplikace a vyskočí mu, na čem ostatní týmy dělají, jaký dělají výzkumy. A už já říkali jsme si, tak to je takový Facebook vlastně, uděláme tady Facebook wall. Celý tým se do toho natchnul. Udělali jsme si design studio, udělali jsme si všechno možné. No ale šli jsme vlastně za pár dní za uživatelema a bavili jsme se o tom s nima. A oni nám řekli, jo, to je hezký, ale za prvé, na to dneska máme Teams a Slack, a za druhé, to tam nikdo nepoužívá. To nám řekli tři lidi a tak jsme řekli, fajn, možná to je dobrý nápad, ale možná ne, dáváme ho prostě pryč. Nebudeme ho vyvíjet, protože v tu chvíli nám to vůbec nedávalo smysl. Ale o to věřili jsme se to vlastně velmi rychle, během prostě pár týdnů a nevěnovali jsme do toho větší úsilí, než vlastně jakoby jeden... Brainstorming, jedno design studio, jeden meeting a pak jsme se potom párkát zmínili na pravidelných výzkumech s uživatelema. Víc jsme do toho neinvestovali. Pokud bychom se do toho nadchli, vyrobili řešení, nechali ho naprogramovat, pak ho ukázali uživatelům a oni by řekli, hm, pro nás přínus není, tak bychom řekli, no tak jak to udělat jinak, tak tam asi chybí onboarding, tak tam asi chybí něco a jak jim to zatraktivnit. Ale ono to možná vůbec nenává smysl. A o tom vlastně je to, když vy v tom týmu neustále se bavíte s uživatelema a neustá A opravdu, my na projektech potom to děláme třeba tak, že si dáme jeden cíl, zjistíme třeba první kdese příležitostí a první řešení a už jdeme v řešení. A další týden obohacujeme ten strom a řešíme vlastně, který příležitosti se můžeme věnovat dál. Tímhle způsobem je dobrý na to nahlížet. Je to prostě pravidelná věc. Není to to, že to dáte do myra a řeknete si, hui, udělali jsme strom. To vám nebude úplně k ničemu. Ale je to potřeba opravdu nad tím pracovat. Je potř tak vlastně ten Discovery tým by měl sedět nad tímhle backlogem a neustále ho procházet a znát ho. Tak, jaké těžkosti s tím vlastně jsou? My narážíme často na to, že ty týmy právě nemají nastavené cíle. A v tu chvíli je velmi těžké vůbec řídit jakýkoliv příležitosti a jakýkoliv řešení, protože oni nevědí, za čem jdou. Oni znají si řešení. Takže je velmi vhodné si vůbec říct, že vám tohle půjde nebo nepůjde. Je totiž složitý právě se odprostit od toho, solution focus, řešení, na ten problém focus v tomhle případě, kdy vy prostě potřebujete jít za tím cílem a jít za těma příležitostma. To, co je ta těžkost a to, s když jsme se třeba setkali, je, že třeba týmy, lesy, to dělají obráceně. Oni udělají výzkum a pak třeba hledají cíly, kterých můžu dosáhnout. To nemusí být úplně špatně, ale je potřeba, aby to zase bylo spojené s těma biznisovýma cílema. Každopádně, to, co bych doporučil, pokud byste se rozhodli tuto metodu vyzkoušet, je potřeba jít postupně. Pokud se budete snažit to celé změnit a budete třeba i v nějaké korporaci, která takhle nebude nastavená, tak za stížku všemnosti vám můžu říct, že pravděpodobně narazíte. Je to hodně složitý tohle, co to jako změnit. Pokud tam přijdete a řeknete, už nechceme řešit řešení, chceme řešit cíle a chceme teďka řešit příležitosti a chceme tady udělat dual track agile, což je právě chceme tady dělat Opportunity Solution 3, tak pravděpodobně jako narazíte a bude to velmi náročný. Je dobrý spíš si vybrat to, co vám jako půjde a zkusit si to. To znamená, dobrý, dneska jsme hodně zacílení na nějaké řešení, tak pojďme, když myslíme nějaké řešení, zkusit jít o to úroveň vejš, říct si, proč to řešíme pro toho uživatele a vrátit se zpátky ideací, jestli nejzistou jiné řešení. Tak, potvrzeno? Takže jít vlastně postupně na to a zkoušet to zavádět, to, co v Z mých zkušeností zavést produktové cíle je skoro jako ta nejsložitější věc, pokud je dneska jako nemáte. Záleží ale. Ale pokud tohle chcete vyzkoušet, tak bych klidně začal ze spoda, ale vlastně jako přidával ty části od spoda a snažil se nejdřív jako by zorientovat v těch řešeních, v té ideaci, v té prioritizaci těch řešení a prozkoumávání toho stromu, i když nebudete znát ty cíle, nebo si aspoň nějaký virtuální vyrobit. A až vám to podaří, tak potom by začít třeba dělat celý ten strom. Tak. Jedna věc, s čem se to dá dělat, dá se to dělat v Miru, určitě doporučuji, to je fajn nástroj, můžete zkusit UserApp, náš nástroj, malý branding. Tak a ještě jedna věc, co je potom dobrá jenom vědět, Opportunity Solution 3 je vlastně jakoby vyprávět příběhů, protože vy tohle z toho potom můžete použít, když budete se chtít bavit třeba klidně s nějakýma stakeholderama, tak vy budete říkat, my chceme zvýšit jí firmě obrat a to tak, že chceme změnit 5% uživatelů z free verze, na placenou verzi. Použijeme teďka stávající zákazníky, který fungují tak, že si smažou data, aby nemuseli platit. Ono to vypráví příběh těch uživatelů a té vaší firmy, jak vlastně změnit ten váš produkt k lepšímu. Je dobrý na to koukat právě, že Opportunity Solution 3 je nějakej storyteller, který vám vlastně jako pomůže vyprávět ten příběh celému tomu týmu. Je velmi vhodný do tohle zapojit i vývojáře. do těch testů uživatelských, do těch interviů. Zapojte ty vývojáře, aby i věděli, proč to chcete dělat. Hodně vám to pomůže a ono vám to pomůže kdykoliv. Kdy krokoli bude chtít vědět, proč tohle děláte, tak mu řeknete, protože tady máme tu listu větev, v tomhle se teďka věnujeme. Je to velmi jednoduchý, je to velmi pochopitelný a můžete vám pomoct i přesvědčit to vedení, proč děláte to, co děláte. Tak, jenom jedna věc, já tady mluvím hodně o backlogu, dá se to práv Pokud máte nějakou designovou výzvu, chcete si něco ověřit, používáte třeba Double Diamond, můžete použít Opportunity Solution 3 úplně stejně. Máte nějakou výzvu, to je vlastně ten síl, pak máte hledání těch insightů, vy generujete příležitosti a pak řešení. Můžete použít to, pokud dneska používáte třeba Double Diamond právě pro nějaký proces, tak můžete vizualizovat ty výstupy z toho Double Diamondu právě přes Opportunity Solution 3 klidně k jednorázovej věcem. A kde to používáme? My to používáme opravdu jako takřka všude. Je to spíš o tom, jak nám to jde s tím klientem, ale může to být Cisco, webová aplikace, Airshop. Vyráběli jsme takhle nedávno s WebGlobem celý nový web, vlastně touhle metodou. Je to jakoby jedno. Je to o tom, aby ten tým byl na to nastavený a rád to použíjí kdykoliv, abyste prostě věděli, proč to chcete vytvářet. Pokud vás zajímá víc, určitě doporučuju Terezu Torres, Continuous Discovery Habits. Spoustu věcí je tam popsaných. a Teresa je vlastně Continuous Discovery coachka, která tohle dělá okolo celého světa. Právě a myslím si, že ona vymyslela Opportunity Solution 3 jakože vyloženě ona. Takže ona tohle řeší, řeší to s týma a právě to učí. Takže Teresa Torres určitě doporučuji buď knížku, ale dělá taky školení, má nějakou slehku komunitu. Pokud vás to zajímá, určitě je tam spoustu dobrých informací. A co se z toho odnést? Už jenom v rychlosti. Zkuste se zaměřit od biznesových cílů přes produktové cíle, přes příležitosti, až právě na hledání toho správního řešení. Děkuju. My taky děkujeme. Díky moc. Prostor pro otázky a případnou diskuzi. Já věřím, že dotazů bude spoustu, protože pokud se nebudete ptát vy, tak se budu ptát já. Výborně, máme tady dotaz. Tak děkuji, bylo to super. Já mám dvě otázky, tak já rovnou řeknu v obě. První jsem se chtěla zvedlat na ten nástroj, protože my v tuhle chvíli je malujeme v miru a já furt věřím, že existuje něco lepšího. Jakože, odhledá, když se ten strom rozkočatí, tak mi přijde, že už se tam ta přehlednost ztrácí, tak jestli na to máš nějaký tip. A druhá věc je životnost toho stromu. Jako bez tvojí zkušenosti, že třeba mně přijde, že... Dává smysl to mít nad kvartál, když je přes nějaké OKR, ale často pak to nový OKR třeba není úplně daleko od toho původního. Je to jenom, buď to to pokračuje, nebo se jenom trošku upraví, tak co s tím potom a jak dlouho myslíš, že může nebo má ten jeden strom existovat? Tak to první kreslíte jako Opportunity Solution 3. Tohle byl vlastně jako první nějaká naše myšlenka, kdyžsi dávno, proč jsme tohle vůbec začali dělat. Jakoby ten nástroj jako takovej, protože vlastně na tohle smethod není. A myslím, že tady je pár lidí z podakboardu teda. Každopádně vlastně to, s čím máme zkušenost je, že ty lidi vlastně dělají třeba v DAS style výzkum. Z výzkumu si to vyrobej do myra. A zmyra to potom vlastně jakoby sprioritizujou, řešili si nějaký věci, pak trávají do product boardu, aby si to jakoby sprioritizovali. Protože my vlastně sami si děláme continuous product discovery pro náš nástroj. A to je jakoby věc, kterou někteří lidi dělají. A my se tam narážíme na obrovský problém v tom, že vlastně se ztrácí spoustu informací během tohle z toho. A to byla vlastně ta prvotní myšlenka, proč jsme se vůbec do toho jakoby pustili. Tak to jenom jakoby k tomuhle z tomu. Existuje, teď jsem právě v komunitě od Terezy Torres viděl ještě jeden nástroj přímo na Opportunity Solution 3, ten je ale v Closed betě a zatím je někdo k tomu ně dal přístup, takže nevím, ale taky existuje už jakoby čistě na Opportunity Solution 3. Když tak se pak můžeme podívat a nazdílim jakoby, nazdílim, co to je. A s tím jakoby zkušenost nemám, protože zatím jakoby není venku. Continuous Product Discovery ještě jak jisto jeden nástroj, který jako já znám, ono je když je spousta. A to je Glidr, mám pocit. A nevím, jestli někdo zná nebo nemá zkušenost s ním. Každopádně já se do něj vždycky hlásím jako jednou za dva měsíce, abych se podíval jako jak postupuje. A já ho prostě furt nechápu, takže to je jako zase jako můj problém. Ale právě že jako těch moc nástrojů jako takových není. A v Miru to dělá jako co vím spoustu jako firm, který tohle z to jako řešejí. Ale mám zkušenost, že oni zahazují ten strom velmi rychle, protože právě v tom se hrozně rychle ztrácejí. Takže tohle jsou ty problémy, které k tomu docházejí. Jo, ta životnost. To je taky problém, který my se snažíme vyřešit, protože to, co je podle mě dobré dělat, je snažit se ten strom využít v tom kvartálu na maximum a pak to prostě zahodit ty věci. Ale... Podle mě je dobrý věc evidenci nápadů a pak s těma novýma věcmi to znova začít propojovat. Zahazovat je to podle mě velmi vhodný, protože to začne být za chvilku hrozně nepřehledný. Protože z těch příležitostí vzniká celá řada. My jsme teďka dělali ten projekt právě konkrétně s WebGlobem a za těch 24 měst týdnů, co jsme tam měli, to bylo hrozně košatý. A pak je podle mě dobrý si říct, jestli furt ještě jsou ty produktové cíle stejný nebo ne. A pokud ne, tak bych doporučil si prostě zrevidovat ty zajímavé věci, udál si ty nový produktový cíle a jenom si prostě přeházit ty zajímavé věci a ty ostatní zahodit. Ale zároveň třeba jakoby to, co my řešíme je právě archivovat si ty výzkumy, tak aby tam furt byly jakoby vidět ty příležitosti, které z toho byly. Protože zase jiná zkušenost z jedné velké banky. Každopádně je taková, že se často dělají výzkumy, které se opakují a spálí se v tom jako velké peníze, protože už někdo udělal nějaký výzkum a nezná ty výstupy nebo neví, kde to je a tak dále. Takže za mě je docela vhodný mít dobře udělaný ty výstupy, těch výzkumů. A vlastně, když víte, že děláte nějaký podobný výzkum, tak se podívat do toho, jestli vám to nehodí a vytáhnout si buď ty příležitosti nebo ty insighty a znova si to napojovat na ten strom, co dává smysl na bodem. To je moje z Rád se při kstřemi od osetních lidí. Díky. Ahoj. Ty jsi zmiňoval, to byla jaká praktičnější, drobnější otázka, ty jsi zmiňoval, že to používáte jako komunikační nástroj se stakeholdersma, ale jako příklad si tady vlastně ukázal jenom jednu tu větev vlastně. Nechybějí jim tam ty ostatní možnosti větve a tak jako a potom, teda druhá strana mince. Jak je v tom orientujete, když máte třeba právě nějaký takovýhle kvartální košatější strom, protože chápu, že vy se v tom vyznáte, je to produktový trl se v tom vyzná a tak, ale jako jak to pak používáte s ostatním a okolím, který do toho není tak ponořený. Jo, my na to propravdě docela narážíme na celé problém, protože dost často... Z naší zkušenosti, i když tohle máme, tak ty stakeholders stejně chtějí vidět jejich řešení. A proto jsem tady ukazoval tu jednu větev, protože ta vede na toho řešení, které se vyberlo místo jiného řešení, který ten stakeholder chce. A proto jsem tady ukazoval jednu větev, kdy se mu řekne, jdeme takhle, takhle, takhle a takhle, a proto jsme vybrali to konkrétní řešení. Z mé zkušenosti není dobré pouštět tolik lidí, protože se v tom ztratějí. Podle mě to je spíš pro ten produktovej tým, aspoň taková je moje zkušenost, který v tom dělá, je v tom ponořenej. Když tohle jsme dávali nějakým lidem, kteří se toho neorientujou, tak spíš do to klikli, klikli a řekli, hele, to prostě pro mě není. Tohle je podle mě spíš dobrý pro tu argumentaci, a taky to stejně nepomůže vždycky, ale pro tu argumentaci, proč jsme se rozhodli pro tohle složení a ne pro jiný, protože máme nějaký alignment, víme, proč jsme to udělali a vede tomu tohle 100. Bohužel pokud v té organizaci je ten efekt hypo, to znamená, že nejvyšší placená osoba rozhoduje, stejně na konci, tak je to těžký, ale tohle slouží pro pomoc v komunikaci. Já bych to ještě spíš obohatil o ty další řešení, ale už ne moc o ty další věci, protože bychom se potom dostávali do diskuze, a proč tohle řešení, a proč na tohle řešení, a proč tohle řešení. Ale z mý zkušenosti ty stejich holdery zajímá, proč to není to moje řešení, a proč je to to vaše řešení. Takže tam je potom dobré vidět, my máme nějakou prioritizaci, máme tady nějakou cestu, proč jsme vůbec k tomhle došli a za mě je spíš důležitá ta prioritizace toho řešení, to znamená, ale fajn, tohle bychom mohli udělat, ale vnímáme takový dopad na uživatele a ten je třeba menší, anebo nechceme ten vývojový tým zabít na půl roku, protože tohle řešení je na půl roku a my radši věnujeme 20 menším přírostkům než jedno řešení, které sice může mít biznesový přínos, možná i uživatelský A tohle trochu jako na mindsetu toho produktového týmu. Ten Opportunity Solution 3 je jenom nástroj, který tomu pomáhá, ale stejně to je na těch bedrech toho produktového týmu, aby to dokázal obhájet. S tímhle narážíme často. Máme nástroje, jenže je to spíš o tom mindsetu té firmy, než o tom, že jsou tady jako nástroje a ty nám pomůžou. Ty nástroje pomáhají, ale nevyřešejí za vás ty problémy třeba v komunikaci se stakeholders. Chcel jsem zaptať, můžu vy o tom už jste řekli, ale jak organizovaná tá spolupráce mezi Discovery a Discovery produktovým tímem a tímem, který pracuje na delivery? Jak často máte tu synchronizace, jak spolupracujete, užíváte nejaký dual track agile nebo něco podobného? A jak jdou to? ze sprintama. Máte nějakou centralizaci po sprintam nebo ne? Jo, jo. Já přemýšlím, že si tam nahodím jenom možná ten dual track agile. Každopádně my právě máme zkušenost s tím, že většinou pracujeme s tím, že ten delivery team, znamená ty vývojáři, kteří jedou ve Scrumu, tak ty dá ve Scrumu jakoby jet můžou. Jedou ve 14-denních sprintech a mají nějaký vlastní backlog, který je založený na userstorkách atd. A my jako návrháři jedeme v týdenních sprintech. A vlastně, a teďka, tak trochu jako rozdíl mezi Product Discovery a Continuous Product Discovery je primárně v zapojení toho vývojového týmu. Nejlepší varianta, která se nám daří spíš tak napůl, je pokud vy zapojíte vývojáři co nejvíc. To znamená, my máme jednou týdenně synchro mezi delivery a discovery, kdy vlastně řešíme, co chceme dělat, proč to plánujeme. Tohle je ale furt za mě jednoduchá věc, kdy v tom týmu, v tom discovery, je čistě ten tech lead, který pak funguje jako komunikátor mezi tím delivery a discovery týmem. To není úplně ideální, ale je to lepší než nic, protože on tam je jako takovej... Vyslanec, který říká, tohle je takhle složitý, já vám to zjistím, jak to vývojaře dlouho budou udělat, tak dále, tak dále. Mnohem lepší je ty vývojaře zapojit víc a třeba to víc zapojení je právě začít je brát na ty hloubkový rozhovory, začít je brát na uživatelský testování. Opět, pokud bychom řešili, že vy je vezmete jednou za měsíc na jednodenní vytestování, tak oni pravděpodobně, co mám zkušenost, budou prskat a budou říkat, jo, to je celý den zabitej, to je prostě naprd Pokud vy jim řeknete, tady ve středu potřebujeme jednu hodinu, připojte se vzdáleně na lookback a poslouchejte jenom, co mají ze ty problémy, tak si to spíš jako najdou. A pomůže vám to hrozně v tom, že vy pak nebudete řešit, proč řešíme tuhle příležitost. A nebo proč teda popátí předělávají tohle řešení. Velmi častá věc. Vždyť jako my jsme teda nasadili Continuous Product Discovery, tak proč to furt předěláváme? Oni to jako nechápou. Jenom, že prostě my taky nevíme, co přesně jako pomůže. Proto jenom snižujeme tu nejistotu toho, že vyrobíme něco, co pro ty uživatelé bude mít nejmenší přínos. Ale když oni to vidějí, že my jsme se shodli na něco, že dává smysl, a pak vidějí, že to vyhořilo na tom testu, tak oni mají mnohem většinu důvěru v to, to znova předělat. To je podle mě plná integrace, když se vám podaří hodně ty vývojáři zapojit. To, co děláme na některých projektech, že máme týdenní statusy právě s tím technlídem. kdy on vlastně ví, co chceme dělat, účastnit si některých těch věcí a předává to do toho týmu. To je podle mě takový základ, kdy tohle nějak může fungovat. Ale mnohem lepší je zatáhnout celý ten tým do toho. Ale pozor, je potřeba to také trochu moderovat, trochu řídit, protože zase nechci tady byli všichni u všeho. Některý týmy mají také to nutkání, že Agile znamená plnou zastupovatelnost a všichni můžou dělat všechno a všichni by u všeho mohli bejt. A proto to věc, která trvá tý To je také problém. Je potřeba najít nějakou aviváž, nějaké vyrovnání. Každopádně to, co právě třeba funguje dobře, a my nejsme v tom zatím ještě tak daleko, ale snažíme se, je zapojovat je právě třeba do těch pravidelných rozhovorů, když to udáte třeba přes lookback. Možná tedy používáte lookback, dáte je prostě někam, oni nedokážou nadávat tomu uživateli, protože taková vyučnost na některých možná byla. A tohle může fungovat. Ale je zatím podle mě složitá cesta. Ale zase, máme zkušenost, že ty vývovaři, kteří jsme zapojili, tak mnohem víc chápali ty změny a mnohem méně prskali, když jsme chtěli předělávat potřetí nějakou věc. Jestli to byla odpověď na tu otázku? Já vlastně předpokládám, že v rámci těch příležitostí jdete nějakým způsobem z toho stromu ze spora nahoru, kdy je řešíte. A chtěl jsem se vlastně zeptat, jak řešíte to, kdy... kdy však vyhodnotíte, kdy je ta příležitost dostatečně pokrytá a přesunute se na tu další. A druhá otázka je vlastně, jak nastavujete metriky pro konkrétní experimenty. Jo, tak. Teďka nevím, jestli jsem pochopil ze spora nahoru. Jo, vlastně předpokladám, že nějakým způsobem jako ta příležitost se dá, nějak jako parent-child, to znamená ta příležitost máští nějaké podpříležitosti. Jasně. Ono to je právě jakoby... Tak. Ono to je vlastně tak, že když my tohle procházíme, tak vlastně jdeme jakoby ze shora. A proto jsem říkal, že když udáte tu flat strukturu, tak bude velmi těžký v tom prioritizovat. To znamená, že jdeme ze shora a říkáme si, která ta příležitost nám dává smysl si ji aktuálně věnovat. Právě z úzni pohledů. Čím ten tým víc je namočený v těchto věcech, to znamená, čím víc tomu rozumí, tím líp dokáže dávat odhady pro to, který byste se měli vydat vlastně reálně. A když si prioritizujeme tu příležitost, tak pak se rozhodujeme, jestli vlastně ta příležitost už je uchopitelná k tomu, abychom ji mohli ideovat, nebo je jako neuchopitelná. Když bych řekl třeba příklad z mobilní aplikace pro nějakou banku, tak třeba může být příležitost, a to se nám, protože já jsem tam pracoval pět let, tak třeba se nám stalo, aplikace je pomalá. A my říkáme, co je to, že aplikace je pomalá? No tak ji musíme zrychlit. Tak musíme asi zrychlit backendy. Jenže to jsme jako nevěděli. To bylo zase jako náš špatný předpoklad v tomhle případě. A když jsme šli hloubš a bavili jsme se uživatelů, proč je aplikace pomalá, tak jsme zjistili, že není problém v tom, že když překlikávají mezi obrazovkama, tak to dlouho trvá, ale říkali nám, že aplikace je pomalá, protože když posílají peníze z jednoho účtu na druhej, tak to trvá 20 minut, teda 20 vteřin, ale když jsou třeba v AirBence, tak to mají během usknutí prstu. A tohle znamenalo, že je pomalá. A to je ten rozdíl v tom, že ta příležitost byla nesprávně probádaná. My už jsme ideovali, co je to řešení, ale my jsme nechápali, co se podstatní uživatelé myslejí. A to je právě to, kdy vy potřebujete pochopit nejdřív ty příležitosti. Protože jiná věc může být třeba mobilní aplikace a řekneme si, já se v aplikaci neorientuju. OK, tak asi nám našpatně jmenu. Ale pokud půjdeme hloubš... tak oni pod tím mysleli to, že nedokážou dohledat, kde si sjednají souzku s vývankovním poradcem. Nebo že nedokážou dohledat transakci, která byla před 14 dnama. Protože ta příležitost byla ještě nejasná a ještě by se neměla ideovat, protože je jako nedostličně proskoumaná. Takže potom, když dochází k tomu výběru na těch různých úrovních, tak ten tým si musí říct, jestli už je to příležitost, s kterou se dá něco dělat, anebo ne. A v tomhle se jakoby prioritizuje. Což doufám, že byla částečně první Možná můžu ještě doplnění. Ano. Furt to se měl. Spíš jsem, částečně jste mi odpověděl, spíš jsem narážil vlastně na to, kdy nějakým způsobem tu příležitost předpokládám nepokryjete jedním konkrétním řešením. Moje otázka právě směřovala spíš k tomu vlastně, kdy si řeknete, že to dané řešení naplnilo tu danou příležitost a posunete se vlastně k té další příležitosti. Jo, a tohle to aspoň z mý zkušenosti, pokud si mnohem mám zkušenosti, tak taky bych se na tohle rád přichytřil. Ale každopádně to, jak my s tím pracujeme, je právě to, že my jdeme do té hloubky a potřebujeme najít nějaké první řešení co nejrychlejiš. A pak jdeme v úroveň vejš a říkáme, jestli dává nám to smysl. chceme se věnovat nějaký jiný příležitosti a tu třeba potom ideujeme. Nebo řekneme, hele dobrý, teď jsme udělali nějaký přínos s uživatelům, pokud to dokážeme rovnou měřit přes ten cíl, tak to pojďme změřit. A protože ono to dost často zaprvé, ten produktivý tým nemusí mít jenom jeden cíl. On může mít tři cíle. nebo dva cíle. Pokud máte třeba ty rezulty, tak těch cílů může být víc, kterým vy k partálu potřebujete pokrejt. Takže zakopat se v jedné konkrétní příležitosti nebo třeba v nějaké víc detailní příležitosti na dlouhou dobu, ten tým taky jako neposune. A třeba ta moje zkušenost je dobrá v tom, hledat co nejrychlejší přínosy a skákat vlastně z příležitosti na příležitost a říkat si, které příležitosti vám dávají smysl z té prioritizace. Protože vy když berete ten první level, a řeknete si fajn, tak tady máme dopad pro uživatele, 5% pravděpodobně, 90%, 90%, 8%, tak už rovnou vím, že se chci třeba věnovat těmhle dvou příležitostem. A udělám v nějaký jedný změnu, můžu si klidně změřit, co to udělalo, ale můžu jít na druhou příležitost a tu si jako vychle probládat. To je jako moje zkušenost. Pokud má někdo jinou, určitě se jako rád nachyčím, ale problém je v tom, že vlastně tenhle ten jakoby... ten prostor těch příležitostí je jako nekonečnej, to můžete zkoumat do nekonečna a furt budete nacházet nový a nový věci a ten produktový tým si musí říct, zda mu to ještě jako stojí za to v tom jako bádat, a nebo ne. Protože ono úplně stejně to může být tak, a to se tam taky stává, že vy třeba zpriorizujete tři řešení na to příležitost, protože to dává smysl a všechny tři jsou jako by malinký, ale je to prostě podle mě o tom produktovým týmu, aby si s tím jako by řekal, protože... tu příležitost, když budete neustále a neustále zkoumat s novými a novými lidmi, tak furt budete nacházet nový a nový věci. Samozřejmě čím víc to budete zkoumat, tak tím ten přířůstek s novými uživatelemi, kterými se budete bavit, bude menší a menší. Ale budete to nacházet neustále. Podle mě je dobré v tom nezabřednout a spíš se snažit pomoct kde se dá, s těmi největšími přískokami za nejmenší čas. A když zbude čas, tak ji detailnějiš do ostatních věcí, aby člověk nezabředl v jedné části. Moje z Ale jestli máš nějakou zkušenost, tak rád si poslechnu, mě to zajímá. Jo, my s tím vlastně pracujeme trochu jinak. My vlastně to řešíme úplně od sporu, to znamená, my máme právě na příležitosti dané ještě nějaké podpříležitosti, na ty podpříležitosti klidně nějaké další podpříležitosti, na ty dané podpříležitosti tvoříme konkrétní řešení a pro ty řešení tvoříme experimenty, které vyhodnocujeme. Tam byly ty experimenty. Co my nejčastějiž používáme na experimenty, tak je právě buď AB testování, kde to jde. Mám zkušenost, že v Airshopech je to velmi lehký, velmi jednoduchý. V některých produktech jako třeba Ingenium. Třeba když máme my user app, tak my dokážeme dávat nový změny třeba každý týden. Problém je, že třeba my nemůžeme nábejde testovat, protože to vůbec naši zákaznickou bází nevává smysl třeba. Takže vlastně potřebujeme řešit a my řešíme vlastně víc takový problém interviu. To znamená, že my se vlastně jim ukazujeme třeba to řešení a bavíme se, jestli to řeší ty jejich problémy. A pak teprve potom se spíš snažíme dohledat, jestli se posouváme v tom našem cíli, který jsme se dali. Protože je pro nás velmi těžký to dole změřit. Z mý zkušenosti nejlepší je to měřit třeba A-B testama, pokud to jde. Ale to podle mě jako nejde všude. A některý týmy, zase moje zkušenost, mají touhu A-B testovat všechno, ale tam musí být jako nějaká statistická průkaznost. A prostě pokud oni začnou testovat, jakože, co jsem taky viděl, máme uživatelský testování, A-B test. Co se vám líbí? A-B testujeme. A to prostě taky jako nefunguje. Takže ono je potřeba používat ty metriky dobře. Co se třeba dá a co jsme taky používali? Má to... takový diskutabilní přínos. Je třeba ptát se na NPS na konci toho uživatelského testování. To znamená, že proběhne nějakej test a dá se otázka, jestli by takovou funkčnost měl, jestli by to doporučil svým známým rodiněm, nějakým kolegům. A podle toho, jak odpoví, tak vzniká nějaká diskuze nad tím, kudy my se chceme ubírat a jestli to opravdu dává smysl, nebo jestli jenom nám hál, protože jsme mu dali pětistovku, tisícovku za test. Takže nějakými takovými otázkami se snažíme zvalidovat. Jestli to dává smysl, protože pokud ten produkt nemá kvantitu, tak se velmi těžko v tu chvíli ověřuje, že ten experiment je jako, nebo aspoň nám teda, jestli to dává smysl. Pro nás je usmysluplnější spíš se měřit nějaký ten produktový cíl jako globálně a právě přinášet se nejrychlejiště změny dole a pak spíš se jen koukat, zda nám to pomáhá nebo nepomáhá. Super, díky. Já možná zareaguju ještě na tu otázku předtím, nebo jak jste se vlastně ptali, jak to používáme my, tak nevíme, jestli vás dostatečně nachytřím, protože vlastně my s tím vlastně neděláme kontinuální výzkum, takže ty nový příležitosti nedokážeme nějak obohacovat neustále, ale fungujeme na té úrovni, že vlastně pro ten experiment konkrétní vytvoříme experiment kart a kdy vlastně vytvoříme úplně nejmenší MBPčko, co dá, abychom to právě dokázali otestovat prostě naživo v ozovkách. nějakou dobu toto vlastně trvá, než se to vyhodnotí a kdy budeme moci říct, jestli to má nebo nemá smysl. Proto jsem se vlastně ptal, kdy i vyhodnotíte, že ta daná příležitost je pokrytá, protože vlastně pracujeme v dual tracku, dual edge, a nějakou dobu trvá, než se to vlastně vyhodnotí, tak kdy si říct, jestli to mělo smysl, jestli s tím můžeme okračovat nebo ne. Já osobně a třeba třeba jak s tím pracujeme my, tak právě jako spíš jako skáčeme, to znamená, uděláme tohle z toho, skočíme někam jinam, udáme tohle z toho a globálně pak sledujeme ten dopad, protože to je dost často malý. Jenom třeba k těm experimentům. My to třeba děláme tak, že máme třeba i klidně tři úrovně uživatelských testů, kdy vlastně první děláme low fidelity, kdy se nad tím spíš jenom bavíme, pak děláme high fidelity, kdy testujeme vyloženě použitelnost toho řešení, ale pak, když to nasadíme, tak děláme uživatelské testování na reální produkci, abychom zjistili, dosáhnadávno, kdy jsme přidali právě jako uživatelský výzkum a ten jsme začali vyrábět modálem. To znamená, že chci vyložit hloubkový rozhovor, tak vyskočí modál a tam má proč se dělat nějaké cíle, kdy bych to chtěl dokončit, nějakého výzkumníka, kterýho přidatím a tak dále. Spoustu věcí v tom nástroji zakládáme modálami. Nikdy to nebyl problém. Tohle byl najednou větší modál, který měl víc informací. A ten člověk, ten výzkumník, který ho zakládal, vlastně jako nebouplně jistý, a tak často kliklal jako bokem. A my jsme to měli udaný tak, že se to jako zavřelo a samozřejmě, protože to je jako close beta nebo open beta, tak samozřejmě smazali data. Takže on vlastně ten výzkum během toho rozhovoru vyplnil asi čtyřikrát a říkal, tak tohle mě fakt teda totálně štve. A v tu chvíli my jsme to vylančovali, za tři dny jsme měli tenhle výzkum, zjistili jsme, že tenhle modál by mohl být fakt jako problém, takže jsme za dva dny vystavili verzi, která prostě ano, nejjednodušší řešení, které nás tu chvíli napadlo, nejde zavřít modál na kliknutí vedle. Ale vlastně během pěti dnů jsme dokázali udělat něco, co pravděpodobně spoustu uživatelů by mohlo štvát. Rychlý řešení a už se teďka tomu týhle příležitosti nechceme věnovat, protože samozřejmě mohli bychom ukládat data do tohohle z toho, mohli bychom to schovávat, mohli bychom tam dávat koncepty, který si ty lidi zakládali. Spoustu práce, který já teďka nevím, jaký má přínos. Ale rozhodně vím, že tohle z toho jsme vyřešili problém a proto je podle mě dobrý i testovat vlastně tu produkci, pokud testujete třeba viframey, protože některý věci v tom viframeu prostě třeba neotestujete. Takže my jedeme jako takhle a validuj To ale samozřejmě neřeší jako dopad, to řeší spíš nějakou použitelnost, která by se třeba spíš hodila k cíli právě toho product market fitu, který potom vyříká spokojenost s tím produktem, protože tenhle člověk byl evidentně fakt naštvaný a možná by ho to nezajímalo už jako dál, protože prostě byl naštvaný. Ale tohle to nám v tu chvíli pomohlo, protože jsme udělali rychlé řešení, udělali jsme to během pěti dnů, protože právě máme ty pravidelné testy. Pravděpodobně jsme pomohli, a já samozřejmě jako nevím kolika, ale já věřím, že dost uživatelům, kterým by prostě mám zlej data. Možná ne úplně šťastně, ale to zjistíme v příštích testech, kdy už to nejde odkliknout a uvidíme, co na tobou říkat. A takhle vlastně jedeme iterativně, abychom vylopšovali produkt na základě zpětné vazby, než vymýšleli složití řešení, které nás napadají. To je v pohodě a je to velmi těžký, co tady s Dominikem jsem teďka nedávno řešil. Potřebujeme A já říkám, no to je prostě jako jedně video, protože to lidi to nepochopěj. No a Adam mi říkal, no a proč tam prostě je nám jenom obrázek a prostě popis těch vysí, pojď mi to vyzkoušet. Já říkám, to mě fakt nenapadlo. Prostě sice jsem designer, ale prostě takhle jednoduchý řešení mě v tu chvíli vůbec nenapadlo. A dokázali jsme ho vydat za pět dní ven. Otestovali jsme, zjistili jsme, že nefungují úplně ideálně, ale už jsme vlastně věděli, že to má nějaký přínos a už minimálně je tam něco navíc. než kdybychom vyráběli teďka dva měsíce videa, protože to je trochu složitější. A to je přesně o tom, udělali jsme si rychlou ideaci, teda po telefonu, a vymysleli jsme něco rychlýho, co vyřešilo problém, který ty nužovatele měli. A už za tý den jsme dokázali testovat, jestli to funguje. A takhle se snažíme k tomu přistupovat. Díky. Máme prostor na buď jednu větší otázku, nebo dvě menší otázky. Můžete si vybrat. Žádná otázka. Tak tahle možnost nebyla ve volbách, ale dobře. Ne, vlastně ne. Ty jsi mluvil o tom, že jste tam navrzen nějaký feed s těma výzkumama, aby ty lidi hezky viděli, co kdo řeší a pak si jevkali, jste to donesli na nějaký pravidelný uživatelský testy, kde tři lidi to zabili. A jak je možný, že jste to zabili po třech lidech, který mohli mít jen blbou náladu? Jak jste to ještě validovali nebo jak jste věděli, že tohle je ten správný mzorek? Jsem rád, že to říkáš, protože to byl tvůj rápad, mám boci. Ne, každopádně, to si dám srandu. No, protože ta odpověď nám přišla jako v tu chvíli natolik validní, že jsme nechtěli vyrábět něco, co je jako velmi složitý a dál to jako validovat. Dál jsme to jako nevalidovali, ale pokud bychom chtěli, jakože my jsme teda nechtěli, protože nám to návalo smysl, tak je dobrý, aby, protože... Možná to navádí na tu jednu věc, protože když se potom bavíme s některými lidmi a říkáme pravidelný testování, který probíhá s jedním uživatelem každý týden, ale my chceme v tom mít nějakou kvantitu v vozovkách. Chceme tam těch šest lidí, chceme tam těch osm lidí, kteří se třeba doporučují na hloubkový rozhovory, nebo chceme tam pět lidí na uživatelský testování, protože ty nám prokážou nějakou chybovost toho problému. To je pravda, ale problém je v tom, že všechno tohle stejně je jako kvalita. Takže kdybychom chtěli víc ověřit to, co říká Vlasta, tak za mě by jedině dávalo smysl už potom mít vejš, v úroveň a to znamená dále do toho kvantitu. To znamená udělat dotazník, pokud by nám to stálo za to. Ideálně pokud by byla aplikace, tak použít nějaký nástroj, který udělá třeba dotazník přímo v aplikaci, jestli mají vůbec takovou potřebu. Respektive spíše, jak tu potřebu dneska asi řešejí. To je asi otázka, jak to zvolit, tak aby to dávalo vůbec jako smysl. Pokud bychom to chtěli, dá se to To je jedna věc. Druhá věc, proč jsme to zabili po tak málo uživatelích, pokud bychom to nechtěli zabít, dát se to opravdu dělat celý měsíc. Můžete si jich ptát neustále, neustále. Pokud chcete dosáhnout toho, že se chcete zeptat třeba 8 lidí, tak ono se to reálně dá dělat třeba měsíc a půl. A tu s pětlou vás dost často nazbíráte za podobný čas. Protože pokud bych měl jednou za měsíc, jednou za dva měsíce rozhovor s uživatelema, uživatelský testování, tak stejně čekáte jeden měs Když to děláte pravidelně, tak tu otázku, která vás konkrétně zajímá, tak můžete pokládat neustále a neustále a opravdu si sbírat ty argumenty pro ten celek. To je jedna věc. Co se týče uživatelského testování, na co se jste neptal, ale řekl bych klidně, tak jako designéři určitě znáte, kdy jdete s nějakým Wi-Frame-em, prototypem nebo čímkoliv na ten test, dáte to pevnímu uživateli a řeknete si, ty krása, tak tahle textace je fakt špatná, pojďme ji rychle předělat. Nebo ježišmarad, tohle je fakt špatně, tohle se to lidi nevidějí. Tak to pojďme předělat. Tohle se vám nestane, když děláte pravidelní testy, protože dobrý, tak to neprošlo. A nemáte 10 minut, 15 minut mezi respondentama, aby se to předělali, protože fakt už nedává smyslet to dál testovat, protože to fakt byla chyba. Ale máte týden na to, to vylepšit a dát znovu do toho testu. To je třeba další přínos, proč dělat pravidelní testy, protože se zbavíte týhle z toho problému, že vy víte, už s prvním uživatelém víte, že tam máte v té aplikaci nějakých třeba 40-50 problémů použitelnosti, který trápějí každého třetího uživatele. A tohle můžete dělat pravidelně každý týden, ale musíte čekat buď měsíc, ale hlavně nemusíte po prvním uživateli to rychle předělávat, protože jste zapomněli na textaci, nebo to dali mimo viewport, a když je to úplně jasný, že to mělo být trošku vejš, tak tohle na to máte si celý týden rozmyslet a trochu poupravit. A tohle je další výhoda pravidelného testu, na což se vás to úplně nept o těchto pravidelných testování, ty se určitě častokrát dostaneš ke stejné příležitosti v průběhu toho času. Mě by zajímalo, jakým způsobem zaznamenáváš zjištění, tyto citace z různých výzkumů, aby byly nalinkované k tomuto konkrétnímu příležitosti. V našem nástroji to právě jde. Proč jsme tohle začali řešit? Protože my většinou potřebujeme jít i zpětně, a i s těma stakeholderama. Vlastně oni se ptají, proč to děláme. Protože oni řeknou, my máme nějakou příležitost, proč se jí věnujeme. A my řekneme, no protože to nějaký lidi říkali. Aha, a co teda říkali? No oni říkali třeba tohle. Lookback, myslím si, že už to umí a vás dokáže nalinkovat i do toho přímo jako videa. To znamená, že vy řeknete prostě, tady ten člověk řekl tohle. To je velmi přínosný pro stakeholders. Dokonce jsem se bavil s jednou výzkumnící z monety, že zvažovala dělat podcasty pro stakeholders. Ve smyslu toho, že udělá výzkum a ty nejzajímavější věci nahraje, aby ty stakeholders se mohly poslouchat v autě. Tohle to, aby oni věděli, proč se to děje. A to je to, co my vlastně potřebujeme. A to je ten problém, který jsem říkal. My tady máme nějaký výzkum, který je v lookbacku. Ten se přepíše do Mira na nějaký insighty a ty se potom vyhodnocují někde v Miru nějakýma linkama, ani většinou ani linkama, ale prostě do nějaké Opportunity Solution 3 opět v Miru. A to se potom zadává jakoby někam dál, aby se to vyhodnocovalo. Buď do Product Boardu, nebo to někteří se transformují rovnou do nějaké user-storky a pak to dávají do IRI. Spoustu věcí se v tu chvíli ztrácí a pak, když ty lidi chtějí vědět, ty stakeholders, jakože to dost často chtějí vědět, proč se to dělá, tak ta cesta je vlastně hrozně těžká prokázat. Takže tohle nám právě dává obrovský smysl, jít vlastně od těch příležitostí, co ty lidi řekli, takže to znamená, co jsme pochopili našim insightům. Insighty, proč vznikly, z nějakých verbatimů. A verbatim se řekly v nějakém plném přepisu, to znamená tady ten člověk to řekl. Ideálně samozřejm Já si myslím, že produktový tým by to nepotřeboval, ale prostě dost často pracujeme v korporacích, kde prostě ty seglelci potřebují přesvědčovat a tohle je docela fajn mít. Takže ta evidence právě pro nás je velmi těžká a proto jsme vyráběli, nebo proto vyráběme i úzrad. Abychom se dokázali právě orientovat v podstatě Discovery. Super, děkuji. Michal Voják, Design Dev. Díky.

Všechny užitečné odkazy z prezentace najdete na konci popisu 👇

Nápadů jak vylepšit produkt je vždy mnoho. Nezáleží, zda vytváříte prodejní web, e-shop, SaaSko či jakýkoliv jiný digitální produkt. Vždy je něco, co byste do produktu vy nebo někdo z týmu dali. Občas, nebo možná i často, to není ani z nikdo týmu, ale nějaký nadřízený manažer. V jiných případech přichází s myšlenkou či potřebou váš uživatel. Tedy často se stává, že toho co by se dalo dělat je nepřeberné množství...

Michal Voják představí jak pracovat s metodou Opportunity Solution Tree. Ta pracuje s požadovanými produktovými výsledky (Product outcome), uživatelskými potřebami a know-how týmu, který se díky ní dokáže lépe orientovat ve svém Discovery Backlogu. Na paktických ukázkách Michal vysvětlí, jak s metodou pracovat, jak hledat správné příležitosti a jak prioritizovat správná řešení.

Titulky zajišťuje Středisko Teiresiás Masarykovy univerzity, již pravidelný partner UX Monday.

***

Michal Voják v Designdev řídí jako Product Design Lead návrhové oddělení čítající 10 návrhářů. Za více jak 8 let v oboru UX spolupracoval s e-shopy, korporacemi a různými firmami na různorodých produktech. Propaguje zavádění Product Discovery do firem a vede startup s názvem userUP, který má za cíl pomoc firmám s Product discovery.

***

Zaujalo vás setkání? Zvažte dobrovolný příspěvek - platba je možná na transparentní účet Asociace UX 2202638327 / 2010. Prostředky budou použity na podporu budoucích akcí.

Chcete vědět více? Zapojte se na https://www.meetup.com/asociace-ux

Slidy z prezentace najdete zde: https://www.slideshare.net/AW-dev/jak-se-nezblaznit-z-discovery-backlogu-opportunity-solution-treepdf