Aplikace může splnit zadání, projít akceptačními testy a být připravená ke spuštění. A přesto nemusí splnit důvod, proč vznikla.
Lidé jí nerozumějí. Nedokončí to, kvůli čemu přišli. Nebo ji jednou vyzkoušejí a už nemají důvod se vrátit.
Za větou „potřebujeme vytvořit aplikaci“ se totiž mohou skrývat dvě různá očekávání. Jedna firma potřebuje někoho, kdo zrealizuje připravené zadání. Druhá hledá partnera, který jí pomůže zjistit, co má vlastně vzniknout, aby investice dávala smysl.
V DesignDevu tento druhý přístup nazýváme Success as a Service — úspěch jako služba. Začíná společným pojmenováním výsledku, který má produkt přinést uživatelům a podnikání klienta. Podle něj pak řídíme návrh, vývoj i další rozvoj.
Rozdíl poznáte už podle otázek, které vám dodavatel položí.
Kdy dává smysl objednat si vývoj
Pokud máte vlastní produktový tým, znáte potřeby uživatelů a umíte řídit technická rozhodnutí, můžete potřebovat především posílit vývoj.
Vy určujete směr a dodavatel pomáhá s realizací. Taková spolupráce může dobře fungovat jako development as a service.
Potíž nastává, když vlastní produktové zázemí nemáte, očekáváte pomoc s celým produktem, ale spolupráce se od začátku soustředí pouze na seznam funkcí.
Co má aplikace umět? Kolik bude mít obrazovek? Kdy ji potřebujete spustit?
To jsou potřebné otázky. Ještě před nimi by ale měly zaznít jiné: Komu má aplikace pomoci? Jaký problém řeší? Proč by ji lidé měli chtít používat? A podle čeho poznáme, že investice dává smysl?
Bez společných odpovědí může každý pracovat k jinému cíli. Dodavatel k předání aplikace. Klient k výsledku, který od ní očekává.
Co nám říká předání aplikace
Součástí předání bývá uživatelské akceptační testování, často označované jako UAT. Ověřuje, zda je řešení přijatelné pro zamýšlené použití a splňuje dohodnutá kritéria. ISTQB: Acceptance Testing
Jeho vypovídací hodnota ale závisí na tom, co jsme do těchto kritérií zahrnuli a jaké situace jsme skutečně otestovali.
Představte si rezervační aplikaci. Uživatel si vybere termín, vyplní údaje a dostane potvrzení. Celý postup funguje.
Jenže firma ji pořizovala hlavně proto, aby snížila počet nevyužitých termínů. To, že lze rezervaci vytvořit, nám ještě neříká, zda lidé na termíny častěji přicházejí.
Musíme sledovat i tento výsledek. A zjistit, co mu brání.
Možná lidé potřebují připomenutí. Možná jednodušší změnu termínu. Možná problém vzniká úplně jinde, než jsme při psaní zadání předpokládali.
Právě tak uvažujeme o Success as a Service: důvod, proč produkt vzniká, musí zůstat součástí rozhodování i po schválení zadání.
Začít potřebujeme u předpokladů
Každý nový produkt stojí na několika předpokladech.
Že lidé daný problém mají. Že je pro ně dost důležitý. Že jim naše řešení pomůže lépe než způsob, který používají dnes. Že mu porozumějí a budou ho chtít používat. Že ho dokážeme dodat v potřebné kvalitě. A že bude ekonomicky dávat smysl.
Právě jejich ověřováním se zabývá product discovery.
Nemusí mít podobu dlouhé studie. Má nám pomoci získat dostatek podkladů pro další rozhodnutí, s přiměřenými náklady.
Něco zjistíme rozhovorem. Něco až ve chvíli, kdy člověka necháme pracovat s prototypem. Technické riziko může vyžadovat malý funkční experiment. Ochotu platit nebo dlouhodobě používat službu pak potřebujeme ověřovat skutečným chováním.
Důležité je poznat také současné alternativy. Lidé mohou problém řešit jinou aplikací, tabulkou, telefonátem nebo zavedeným pracovním postupem. Naše řešení jim musí nabídnout dostatečný přínos, aby stálo za změnu.
A potřebujeme rozumět ekonomice produktu. Kdo za něj zaplatí a jak se k zákazníkům dostaneme? Ospravedlní příjmy nebo dosažené úspory náklady na získání zákazníků, vývoj, provoz a další rozvoj?
Pozitivní reakce na prezentaci je dobrý začátek. Pro velkou investici ale potřebujeme víc.
Někdy je dobrým výsledkem nepokračovat
Před začátkem ověřování bychom měli vědět, co chceme zjistit, kolik do toho vložíme a jaký výsledek povede k pokračování, změně nebo zastavení.
I zastavení může být dobré rozhodnutí.
Pokud zjistíme, že lidé problém nepovažují za důležitý nebo že ho neumíme řešit za přijatelných nákladů, můžeme zbytek rozpočtu a času využít jinde.
Tomuto uvažování odpovídá i zahraniční výzkum. Camuffo a jeho kolegové ve čtyřech randomizovaných kontrolovaných studiích zahrnujících 759 firem zjistili, že výuka systematického přístupu k formulování a ověřování předpokladů zvyšovala pravděpodobnost ukončení nápadů. Ověřování tedy nemusí sloužit jen k hledání důvodů, proč pokračovat. Může nám pomoci poznat, kdy pokračovat nemáme. Studie, 2024
I to patří k našemu pojetí Success as a Service. Pomoci klientovi rozhodnout, kam vložit peníze a čas, může mít větší hodnotu než realizovat původně naplánovaný vývoj.
Rychlejší vývoj potřebuje jasný směr
AI asistované programování a vibe coding zpřístupňují tvorbu aplikací dalším lidem. Dávají šanci i nápadům, které by dříve mohly skončit na nedostatku času, peněz nebo programátorských znalostí.
Rozsah této tvorby ukazují například údaje Lovable: v srpnu 2026 platforma oznámila přes 60 milionů vytvořených projektů. Ve svém červnovém reportu uvedla, že 80 % tvůrců se označuje za lidi v netechnických rolích. Jde o vlastní údaje platformy, nikoli statistiku hotových a úspěšných produktů. Lovable, srpen 2026, The Build Economy, červen 2026
To, že může vzniknout více aplikací a mohou vzniknout rychleji, ještě nedokazuje jejich přínos ani obchodní úspěch. Počet vytvořených projektů nám neříká, jestli řeší důležitý problém, jestli je lidé chtějí používat nebo zda se jejich provoz vyplatí.
V našem přístupu proto AI využíváme také ke zkrácení cesty od předpokladu k jeho ověření. Malý seniorní tým propojuje produktové uvažování, design a vývoj a připravuje to, co pro další rozhodnutí skutečně potřebujeme.
Někdy je to prototyp, jindy technický experiment, jednoduchá služba s ruční obsluhou nebo první použitelná verze produktu. Volba záleží na tom, kde je největší nejistota.
Předem si společně určíme rozpočet a důkazy, které budeme hledat. Podle typu produktu může jít o první platící zákazníky, opakované používání nebo prokazatelnou úsporu práce. Z výsledků pak rozhodneme, zda pokračovat, upravit směr, nebo nápad zastavit.
Spuštěním ověřování nekončí
S prvními skutečnými uživateli získáme další informace. Uvidíme, kde se ztrácejí, co používají a jestli dosahují výsledku, kvůli kterému přišli.
Proto propojujeme discovery s delivery: průběžné poznávání potřeb a ověřování předpokladů s návrhem, vývojem a provozem produktu.
Podle zjištění vybíráme další krok. Někdy je to nová funkce. Jindy zjednodušení té stávající nebo úprava původního plánu.
Ani zkušený tým nemůže předem vědět, že každý nápad pomůže. Výzkumná práce o experimentování v Microsoftu uvádí, že jen přibližně třetina testovaných nápadů zlepšila metriky, na které cílila. Jde o výsledky produktových experimentů, nikoli o míru úspěšnosti celých aplikací. Ukazují ale, proč má smysl očekávaný přínos změn ověřovat. The Benefits of Controlled Experimentation at Scale, 2017
Pro Success as a Service je tento průběžný způsob práce zásadní. Spolupráce pokračuje sledováním skutečných výsledků a rozhodováním, do čeho má smysl investovat dál.
Co od produktového partnera chtít
Při výběru dodavatele se vedle ceny a termínu ptejte také:
Jak společně určíme, co má aplikace přinést uživatelům a našemu podnikání?
Jak ověříme, že řeší důležitý problém lépe než způsob, který lidé používají dnes?
Jak zjistíme, že ji lidé skutečně chtějí používat a mají důvod k ní přejít?
Může produkt obchodně fungovat? Kdo za něj zaplatí a pokryje jeho přínos náklady na získání zákazníků, vývoj a provoz?
Které předpoklady potřebujeme ověřit před větší investicí?
Jak ověříme, že lidé řešení chápou a dokážou s ním dosáhnout toho, kvůli čemu přišli?
Co budeme měřit po spuštění a podle čeho upravíme další postup?
Odpovědi vám pomohou poznat, jakou spolupráci si skutečně objednáváte.
V DesignDevu propojujeme produktové uvažování, design a vývoj od prvních otázek až po dlouhodobý rozvoj. S klientem určujeme očekávaný přínos, pojmenováváme rizika a podle získaných důkazů rozhodujeme, do čeho investovat dál.
Tomu říkáme Product Success as a Service. Úspěch společně definujeme a průběžně ověřujeme, jestli se k němu produkt přibližuje. Může znamenat vyšší příjmy, méně nevyužitých termínů, úsporu práce nebo jinou konkrétní změnu, kvůli které se vyplatí produkt vytvářet.
Úspěch na trhu vám nikdo nemůže poctivě zaručit. Můžete ale požadovat partnera, který umí vysvětlit svá doporučení, ověřuje zásadní předpoklady a řekne vám i to, že některou funkci zatím nepotřebujete.
Pokud si nejste jistí, jestli vaše zadání odpovídá skutečné potřebě, probereme to spolu. Řekneme vám i to, co bychom ověřovali jako první.
Přelom na rok 2026 znamenal zásadní zlom. Agentic AI systémy a moderní nástroje redefinovaly naše pracovní postupy a posunuly efektivitu na novou úroveň. Od produktového discovery v našem nástroji userUP přes návrh UX, UI a design systémů až po nasazení kódu. Výstupy z uživatelského výzkumu, naše ideace a prioritizace se obratem mění v produktovou analýzu či strategii. Produktová analýza se přetaví v zadání, to v prototyp nebo UX/UI artefakty, a prototyp rovnou v kód – často rovnou produkčního.
AI proměnila vývoj softwaru. Umíme rychleji psát kód. Rychleji generovat návrhy. Rychleji stavět prototypy. Rychleji analyzovat data. Rychleji vytvářet obsah. Rychleji spouštět nové nápady. To všechno je pravda. Jenže v produktové realitě je tu jeden problém: rychlejší výroba automaticky neznamená lepší produkt. Pokud nevíme, co přesně řešíme, pro koho to řešíme, jak silný je daný problém a proč by kvůli tomu lidé měli změnit své chování, AI nám může pomoct hlavně s jednou věcí: rychleji postavit něco, co nikdo vlastně nepotřebuje.
Máte vizi? Pojďme ji proměnit v úspěšný digitální produkt
