V rychle se měnících produktech největší brzda často není technologie, ale tok práce. Zákazník pošle nápad, tým ho vloží do backlogu, ten se prioritizuje, plánuje a až pak se začne realizovat. Mezitím uplyne čas. Nápad může zestárnout. A hlavně: zákazník už necítí, že na jeho návrhu se pracuje přímo teď.
Zakladatel a CEO BrainTrust Ankur Goyal popisuje, jak v jejich týmu Codex změnil právě tuhle část vývojového procesu. Nejde jen o to „zkusit další nápad“. Jde o to dostat zákaznické feature requesty do fáze, kde je lze ověřovat téměř okamžitě a společně s uživatelem iterovat v reálném čase.
Obsah
- ⚡ Proč je backlog často pomalý pro zákaznické nápady
- 🧠 Co je Codex a proč ho tým v BrainTrust používá
- ⏱️ Iterace v reálném čase: od feature requestu k ukázce za zhruba 10 minut
- 🔁 Iterovat a ideovat společně: proč je „společné doladění“ klíčové
- 🥣 „Molten phase“: proč má smysl ukazovat věci, které ještě nejsou hotové
- 🎯 Kvalitnější zpětná vazba: co vzniká, když uživatelé „hrají“ s návrhem
- 🧩 Jak vypadá workflow v praxi (a proč je to pro týmy použitelné)
- 🌍 Proč zrovna u zákaznických feature requestů dává AI největší smysl
- 📈 Jak to může změnit způsob, jak plánujete produkt
- 🛠️ Nejlepší „vedlejší efekt“: zákazník se stává účastníkem designu
- ✅ Co si z toho odnést, i když Codex nepoužíváte (nebo ho teprve zvažujete)
- 🔎 Praktická otázka pro týmy: jak rychle dokážete ukázat, že rozumíte návrhu?
- 📣 Codex jako „otvírák dveří“ k reálnému dialogu
- 🚀 Závěr: od backlogu k živé spolupráci
⚡ Proč je backlog často pomalý pro zákaznické nápady
BrainTrust má zákazníky, kteří jsou velmi aktivní se svou zpětnou vazbou. Nejde o tiché období mezi verzemi. Lidé posílají konkrétní návrhy na vylepšení. Tyto návrhy se dřív dostávaly do backlogu, kde se následně prioritizovaly a plánovaly.
Tohle je běžný model. Má své výhody: přehled, priorita, konzistence. Jenže má i nevýhody pro „rychlou“ spolupráci:
- Časový odstup: uživatel čeká, než se jeho požadavek vůbec dostane k realizaci.
- Nejasnost během čekání: zákazník může mít pocit, že návrh „zmizí“ v systému.
- Slabší iterace: bez rychlého prototypu se často diskutuje v rovině představ, ne v rovině reálného chování produktu.
Goyal zmiňuje, že dřívější proces znamenal, že návrhy se „enter into a backlog“ a až poté se řešily. Cíl Codexu je přesně proti tomu. Zkrátit vzdálenost mezi nápadem a ověřením.
🧠 Co je Codex a proč ho tým v BrainTrust používá
Codex je nástroj, který umí pomáhat s programováním a generováním řešení na základě zadání. V kontextu BrainTrust ho Goyal popisuje jako mechanismus, který umožní zkoušet více variant a rychle je převádět do něčeho, co lze ukázat zákazníkovi.
Klíčová myšlenka je, že Codex nefunguje jen jako „jednorázový pokus“. Tým ho používá pro rychlé generování a testování velkého množství nápadů. Goyal to shrnuje tak, že se snaží „not just try one idea, but try like a hundred ideas“.
To zní možná jako přehnané číslo, ale záměr je jasný: místo hledání jediné správné cesty najednou se rozbíhá proces tvorby více možností, dokud se nedostanete k něčemu, co má největší šanci fungovat pro konkrétní potřebu zákazníka.
⏱️ Iterace v reálném čase: od feature requestu k ukázce za zhruba 10 minut
Goyal popisuje workflow, který je ve výsledku jednodušší, než by mohlo znít:
- Na Slacku přichází zákaznický feature request.
- Goyal zprávu zkopíruje a vloží do Codexu.
- Vytvoří preview branch, tedy náhledovou větev s ukázkou toho, jak by daná změna mohla fungovat.
- Následně feature request ukážou zákazníkovi do zhruba 10 minut.
Důležité je, že to není „vysvětlení, že by se to mohlo udělat“. Je to mechanika, která přepíná vývoj do režimu okamžitého ověřování.
Tento přístup má několik dopadů, které si jako produktový tým můžete snadno představit:
- Zákazník dostane okamžitou odpověď, ne až po plánování a implementaci.
- Vzniká společná práce na tom, jak bude funkcionalita vypadat.
- Vynecháte část hádání, protože zákazník vidí konkrétní návrh a může na něj reagovat.
🔁 Iterovat a ideovat společně: proč je „společné doladění“ klíčové
V tradičním procesu se často stává, že komunikace o feature requestu probíhá ve dvou separovaných světech: zákazník popíše problém, tým poté navrhne řešení a teprve později se to dostane zpět k zákazníkovi. Tím se iterace zpomaluje a komplikují se očekávání.
Goyal ale popisuje, že pomocí Codexu „we get to iterate and ideate on the feature request with the customer in real time“.
To znamená, že do práce se dostává stejný rytmus jako u zákazníkovy zpětné vazby. Jakmile je možné prototypovat a předvést variantu, lze:
- rychle testovat předpoklady (co si zákazník představuje, co je možné reálně udělat),
- měnit detaily na základě reakce uživatele,
- odhalit, že problém byl pochopen správně nebo naopak vyžaduje upřesnění.
🥣 „Molten phase“: proč má smysl ukazovat věci, které ještě nejsou hotové
Jedna z nejzajímavějších částí Goyalova popisu je metafora „molten phase“. Tým nechce jen jednorázově předat hotové řešení. Naopak ukáže zákazníkovi feature request v době, kdy ještě probíhá tvarování.
Goyal říká, že zákazník „get them playing with the feature request while it's in this kind of molten phase“.
Co to prakticky znamená? Že prototyp není jen pro tým. Je to nástroj, jak zákazníkovi umožnit pracovat s návrhem v čase, kdy je možné provádět úpravy rychle a relativně levně.
U hotového produktu se podobná flexibilita často ztrácí. V molten fázi ale můžete:
- zjistit, co uživatelé opravdu používají a jak,
- nechat je zkoušet tok interakcí,
- sbírat kvalitnější komentáře, protože odezva není abstraktní.
🎯 Kvalitnější zpětná vazba: co vzniká, když uživatelé „hrají“ s návrhem
Goyal uzavírá, že s tímto workflow získávají „really, really high quality, interesting feedback“.
To je přesně to, co si mnoho týmů přeje, ale často nemá prostředky to takhle realizovat. Vysoká kvalita zpětné vazby zpravidla vzniká z kombinace tří věcí:
- Konkrétnost: zákazník komentuje fungující koncept, ne obecnou myšlenku.
- Rychlost: dokud je návrh čerstvý a snadno se mění, změny se dají promítnout do další iterace.
- Zapojení: uživatel se necítí jako pasivní pozorovatel backlogu, ale jako aktivní spolutvůrce.
Když zákazník dostane okamžitou ukázku, je pravděpodobnější, že odešle komentáře typu „Tady to funguje dobře, ale tady bych chtěl…“ než obecné „To by šlo, ale nejsem si jistý.“
🧩 Jak vypadá workflow v praxi (a proč je to pro týmy použitelné)
Nejde jen o „použití AI“. Jde o proces. Podle popisu z BrainTrust vypadá workflow takto:
- Zachytím feature request od zákazníka (například ze Slacku).
- Přenesu zadání do Codexu (zkopíruju zprávu a vložím).
- Vytvořím preview branch, tedy technický náhled změny.
- Ukažu to zákazníkovi velmi rychle, typicky v řádu minut.
- Společně iterujeme podle reakcí zákazníka.
Tohle je především zkrácení cyklu. Místo dnů a týdnů mezi nápadem a ověřením získáte rytmus, ve kterém se dá pracovat metodou „zkus, ukaž, zlepši“.
Pro týmy to může znamenat také něco psychologicky důležitého: zákazníci mají pocit, že jejich návrhy nejsou pouze evidované, ale aktivně tvarované.
🌍 Proč zrovna u zákaznických feature requestů dává AI největší smysl
Codex může být užitečný v mnoha oblastech. Ale tenhle scénář je specifický: feature request je často popsaný textem. A přesně ten text je vstup, se kterým se dá rychle pracovat.
V kontextu BrainTrust je to o tomhle:
- Zákazník posílá návrh konkrétní funkce.
- Zadání je „něco, co má změnit chování“.
- To umožní rychle generovat náhled a prokázat nápad v praxi.
Pokud by byl proces pomalý, výhoda by se ztratila. Když ale dokážete návrh přeměnit na něco, co zákazník může vyzkoušet, vzniká efekt, který Goyal popisuje jako iteraci v reálném čase.
📈 Jak to může změnit způsob, jak plánujete produkt
Jakmile dostanete feature requesty do režimu rychlých previewů, začnete přemýšlet jinak o plánování.
Nemusíte rušit backlog. Ale můžete backlog používat jinak: ne jako místo, kde návrhy čekají na začátek práce, ale jako místo, kde se shromažďují podklady. A samotná validace může probíhat dřív, než se dostanete k velkým implementacím.
V praxi to může vést k:
- rychlejší validaci, jestli zákazníci opravdu chtějí to, co popisují,
- jemnějšímu upřesnění požadavků,
- menšímu počtu překvapení při implementaci, protože jste už produktovou myšlenku ověřili v náhledové podobě.
🛠️ Nejlepší „vedlejší efekt“: zákazník se stává účastníkem designu
Největší přínos popsaný v tomto přístupu není jen rychlost. Je to proměna role zákazníka.
Goyal výslovně zdůrazňuje, že zákazník nejen dostane feedback, ale „you actually get them playing“ s návrhem. To je velký rozdíl. Feedback získaný z hraní s prototypem bývá:
- konkrétnější,
- založený na reálné interakci,
- často rychleji přetavitelný do konkrétních změn.
Když uživatel zkouší, zjistí věci, které se v popisu problému nemusí objevit. A tým tím pádem získává nové úhly pohledu ještě před tím, než vloží velké úsilí do finální realizace.
✅ Co si z toho odnést, i když Codex nepoužíváte (nebo ho teprve zvažujete)
Možná Codex ve vašem týmu zatím neřešíte. I tak ale jde z popisu BrainTrust vyčíst principy, které jsou přenositelné.
Zásadní principy jsou tři:
-
Zkraťte cyklus mezi požadavkem a ověřením. Když to trvá týdny, iterace se vypaří.
-
Udělejte z prototypu předmět komunikace. Není to interní práce „pro vývojáře“, ale materiál pro společnou práci.
-
Nechte zákazníka zkoušet v „měkké“ fázi. U hotových věcí se hůře mění směr. V molten fázi jde směr snadno upravit.
Pokud máte jiný workflow než preview branch generovaný přes Codex, můžete si analogii postavit i jinak: rychlá mini implementace, rychlý prototyp, krátká demonahrace a společné testování. Záměr je stejný: získat kvalitní feedback, který má oporu v reálném chování návrhu.
🔎 Praktická otázka pro týmy: jak rychle dokážete ukázat, že rozumíte návrhu?
Jedna věta z popisu BrainTrust je ve své podstatě testem: co když zákazník dostane ukázku do zhruba 10 minut? Nejde o přesný čas. Jde o to, jak rychle dokážete převést textový request do něco, co se dá vidět a zkusit.
Můžete si položit otázky:
- Když přijde feature request, dokážeme do několika hodin udělat něco viditelného?
- Je to něco, co zákazník může použít, nebo jen slyšet vysvětlení?
- Je v procesu místo pro společné ideace a iterace, nebo je to jednosměrný tok?
Pokud je odpověď spíš „ne“, může být právě tohle oblast, kde vám přidání AI nebo přehodnocení procesu pomůže nejvíc.
📣 Codex jako „otvírák dveří“ k reálnému dialogu
Celé sdělení lze shrnout jednoduše: Codex v BrainTrust slouží jako prostředek, který umožní vyzkoušet zákaznické feature requesty v reálném čase.
Goyal popisuje dva hlavní efekty:
- rychlou iteraci a ideaci přímo s obdrženým requestem,
- zapojení zákazníka tak, že si návrh skutečně „ohraje“, ne jen okomentuje.
Výsledek je kvalitnější zpětná vazba, protože komunikace není pouze o představách. Je o vyzkoušeném chování a společném doladění.
🚀 Závěr: od backlogu k živé spolupráci
Dřív feature requesty končily v backlogu. Následně se prioritizovaly. Teď se dají převést do preview branchu a ukázat zákazníkovi během zhruba 10 minut. Mezi těmito dvěma přístupy je obrovský rozdíl: ten první je sekvenční a čekací, ten druhý je interaktivní a průběžný.
BrainTrust tak získává možnost ideace a iterace s kýmkoli, kdo posílá návrhy. A hlavně získává feedback, který je „really, really“ kvalitní a zajímavý právě proto, že zákazník není pouze posluchač. Je součástí práce, dokud je prostor pro změny.
Pokud tvoříte produkt a zákaznická zpětná vazba je důležitá, stojí za to zamyslet se nad jednou věcí: jak můžete zkrátit cestu od nápadu k ověření. A jak můžete udělat prototyp natolik rychlý a přístupný, aby zákazník nemusel čekat na backlog, ale mohl pomáhat směrovat řešení hned.
