Představme si poradu, na které se z nápadu během půl hodiny stane „priorita“. Nikdo přesně neřekl, jaký problém řeší, pro koho je důležitý ani podle čeho poznáme, že je hotovo. O měsíc později tým pilně vyrábí něco, co možná nikdo nepotřebuje — jen už do toho investoval příliš mnoho času, aby se na to ptal.
Právě na tento druh chaosu míří Yeti, nový MCP server pro návrh produktů s Claudem. Jak jsme psali v rychlé zprávě o Yeti, nástroj vede práci přes pět fází a teprve potom ji předává do Jiry. Není to samostatný produktový stratég ani kouzelný generátor dobrých nápadů. Je to spíš digitální procesní manažer, který vám znepříjemní přeskočení důležitých otázek.
A to je možná jeho nejzajímavější vlastnost. V době, kdy se AI prodává hlavně jako zkratka, Yeti staví hodnotu na opačném principu: některé zkratky nepovolí. Neví, jestli je váš produkt dobrý. Umí ale vynutit, aby bylo vidět, co jste při jeho návrhu vynechali.
Nejdřív problém, potom řešení
Yeti rozděluje návrh do fází discovery, definition, prioritization, flows a verification. V první části se zapisuje problém, uživatelé a cíl. Následují požadavky, uživatelské příběhy a akceptační kritéria, potom prioritizace, návrh toků a závěrečná kontrola rozsahu.
Pořadí není jen organizační dekorace. V přísném režimu strict Yeti neposune projekt do další fáze, pokud nejsou splněné podmínky té současné. Povinný požadavek se například musí propsat do uživatelského příběhu. V režimu free lze pokračovat i s nedodělky, ale nástroj je nahlásí místo toho, aby je schoval pod další vrstvu hezky znějícího textu.
Tady se ukazuje rozdíl mezi chatbotem a procesním nástrojem. Chatbot vám na požádání sepíše specifikaci, i když jste mu dodali jen neurčité přání. Yeti se pokouší udržet návaznost mezi jednotlivými rozhodnutími. Neznamená to, že návaznost bude správná, ale alespoň má podobu, kterou lze projít a zpochybnit.
To je důležitá hranice. Pokud do systému vložíte špatně pochopený problém, dostanete disciplinovaně rozpracovaný špatný problém. Formální úplnost nenahradí rozhovor se zákazníkem, pozorování skutečného používání ani odvahu přiznat, že původní nápad nestojí za další práci.
RICE nevymyslí za vás, co má smysl
Yeti pracuje také s prioritizací RICE — tedy s rámcem, který kombinuje dosah, dopad, jistotu a náklady práce. Původní vysvětlení RICE od Intercomu je užitečné právě proto, že z prioritizace dělá explicitní odhad, ne tajný pocit produktového manažera.
Jenže výpočet není věštírna. Yeti může držet čísla, řadit kandidáty a ukázat, co z nich vychází. Nemůže za vás poctivě vědět, kolik uživatelů funkci zasáhne, jak velký dopad bude mít nebo nakolik svému odhadu věříte. Čísla zadaná bez podkladů vytvoří přesvědčivější tabulku, ne přesnější rozhodnutí.
Tohle je místo, kde se AI produkty často tváří chytřeji, než ve skutečnosti jsou. Když model doplní chybějící odhad, dostaneme hladký text a možná i elegantní skóre. Yeti je zajímavější právě tehdy, když čísla nechá na člověku a jeho úlohu nesplete s generováním dalšího odstavce.
Priorita navíc není slib. Je to pořadí práce pod určitými předpoklady. Jakmile se změní dosah, náklady nebo jistota, změní se i výsledek. Dobrý nástroj proto nemá rozhodnutí uzamknout, ale ukázat, z čeho vzniklo a co by ho mohlo převrátit.
Claude dostane kontext, Yeti drží stav
Technicky je Yeti postavený jako MCP server. Podle dokumentace MCP jde o způsob, jak propojit AI aplikaci s externími nástroji a daty. V tomto případě Claude nepracuje jen s jedním promptem, ale může přes nástroje zakládat projekty, doplňovat požadavky, měnit fáze a připravovat podklady pro další krok.
Stav projektu se ukládá do lokální databáze SQLite. Součástí je také lokální dashboard, který je podle zdrojového kódu pouze pro čtení, běží na adrese 127.0.0.1 a zobrazuje fáze, chybějící položky, pokrytí požadavků příběhy, RICE i diagramy toků. To je praktické rozdělení rolí: konverzace slouží k práci, přehled k orientaci.
Lokální databáze ale neznamená, že všechna data zůstávají doma. Yeti ve svém popisu výslovně uvádí, že obsah projektu posílá Claudovi jako kontext MCP. Kdo do návrhu vloží citlivé informace o zákaznících, cenách nebo interních procesech, musí proto řešit nejen místo uložení SQLite souboru, ale také svého poskytovatele modelu a jeho nastavení.
Je to podobná lekce jako u každé „lokální“ vrstvy kolem cloudového modelu: místní soubor může chránit stav aplikace, ne však automaticky celý tok dat. Rozhodnutí o tom, co do projektu patří, musí pořád dělat člověk a firma. Yeti tento problém neodstraňuje, jen ho dělá viditelnějším.
Jira přichází až po návrhu — a to je dobře
Po dokončení návrhu umí Yeti vytvořit v Jiře jeden úkol pro každý požadavek a jeden příběh pro každý uživatelský příběh. Nástroj si uloží vazbu na vzniklé issue, umí je později aktualizovat a z Jiry dokáže načíst stav a označit odpovídající položky v návrhu jako hotové.
Důležitý detail je výchozí dry run. Při prvním volání se tedy nejprve vypíše, co by se vytvořilo, místo aby se okamžitě zaplnila firemní tabule úkoly. Teprve explicitní přepnutí dovolí skutečný zápis. Synchronizace stavu z Jiry je naopak popsaná jako operace pouze pro čtení z pohledu Jiry; Yeti si podle ní upraví vlastní stav, ale v Jiře nic nepřepisuje.
To není maličkost. Rozdíl mezi „model připravil návrh“ a „systém založil desítky úkolů v produkčním nástroji“ bývá přesně místem, kde se z pohodlí stává provozní problém. Yeti tady alespoň nabízí mezikrok, který lze kontrolovat. Samotný fakt, že dry run existuje, samozřejmě neříká, zda ho každý tým skutečně použije.
Jira je navíc externí služba s vlastním přístupem a vlastním modelem oprávnění. Yeti v dokumentaci počítá s adresou instance, e-mailem účtu a API tokenem v prostředí. Praktickou podobu volání popisuje oficiální dokumentace Jira REST API; odpovědnost za to, kam token vede a jak široká práva má, ale zůstává na provozovateli.
Nejlepší vlastnost Yetiho není automatizace
Na Yetiho navazuje širší trend, který jsme rozebírali u řízení více AI agentů ve Factory. Jakmile AI začne vyrábět více výstupů, problémem už není jen rychlost generování. Týmy potřebují vědět, co je skutečně rozhodnutí, co je rozpracovaná práce a kde je ještě nutný člověk.
Yeti řeší menší, ale podobně důležitý kus tohoto problému. Snaží se oddělit nápad, požadavek, příběh, prioritu a úkol. Když se tyto vrstvy slévají do jednoho chatu, všechno může působit hotově jen proto, že to má správný tón. Struktura není záruka správnosti, ale bez struktury se správnost kontroluje velmi špatně.
Zároveň není nutné přijmout každý podobný nástroj jako nový střed firemního světa. U TaskPocketu jsme psali o oddělení správy úkolů od volby asistenta. Yeti jde jiným směrem: produktový návrh nejen zpřístupňuje modelu, ale také ho svazuje s konkrétním workflow. Pro tým to může být užitečná disciplína, pro jiný tým další vrstva, kterou bude muset udržovat.
Právě údržba rozhodne, jestli podobný systém pomůže. Fáze se mohou stát rituálem, akceptační kritéria formalitou a RICE soutěží v sebejistých odhadech. Nástroj, který vynutí vyplnění polí, ještě nevynutí poctivý výzkum. To už je práce lidí, kteří produkt znají, mluví s uživateli a jsou ochotní zastavit projekt předtím, než se promění v drahou povinnost.
Mladý projekt, rozumná hranice slibů
Yeti je otevřený pod licencí MIT a vyžaduje Node.js 22.13 nebo novější. GitHub u projektu uvádí vydání v1.0.0 z 23. října 2026 a následné rychlé opravy; aktuální vydání v1.0.3 podle poznámek přidalo jméno pro MCP Registry, nikoli novou kódovou funkci. O den dřívější v1.0.2 opravila spuštění přes npx.
To je dobré číst jako popis raného nástroje, ne jako důkaz hotové produktové platformy. Zdrojový kód ukazuje konkrétní workflow, lokální úložiště, dashboard a Jira konektor. Nevidíme z něj ale nezávislé měření, že týmy díky Yetimu dělají lepší produkty, rychleji nacházejí skutečné potřeby nebo méně často zahazují špatné nápady.
Yeti proto není AI, která vám vymyslí produkt. Je to pokus udělat z návrhu produktů proces s kontrolními body a předat výsledek do nástroje, kde už se práce vykonává. Jeho hodnota nebude v tom, kolik textu Claude vyprodukuje, ale zda tým díky němu dřív uvidí vlastní nejasnosti.
To je možná méně působivý slib než „nechte AI řídit produkt“. Je ale mnohem užitečnější. Dobré rozhodnutí nevzniká tím, že model dostane více pravomocí. Vzniká tím, že člověk musí před dalším krokem říct, co vlastně ví, co pouze odhaduje a co ještě vůbec neověřil.
