Kde má AI v týdnu produktového manažera skutečně místo
Produktový management jsou čtyři různé role sdílející jeden kalendář. Hodně čtete (feedback, tickety, přepisy, exporty z analytiky), hodně píšete (specifikace, aktualizace, briefy), trochu analyzujete (funnely, kohorty, výsledky průzkumů) a neustále přesvědčujete. Každá z těchto činností vyžaduje jiný model, a proto jedno AI předplatné pokryje zhruba dvě třetiny práce a zbytek působí jako boj.
| Úkol PM | Nejlepší model | Proč |
|---|---|---|
| Narativ PRD, problémová prohlášení, aktualizace produktu | Claude | Udrží dlouhou argumentaci, píše text, který si engineer skutečně přečte |
| Tematizace feedbacku, klastrování ticketů, strukturovaná extrakce | GPT | Spolehlivý u striktních výstupních formátů a konzistentních kategorií |
| Discovery research, průzkum konkurence, tržní kontext | Gemini | Nejlepší na aktuálním webovém obsahu, vrací zdroje, které lze otevřít |
| Dlouhé přepisy, research podklady, reporty na 100 stran | Gemini | Kontextové okno 1M tokenů, takže se celý korpus vejde do jednoho průchodu |
| Kritika specifikace a hledání okrajových případů | Jakýkoli model, který specifikaci nepsal | Nezávislý čtenář odhalí, co autor nevidí |
Nic z toho nenahrazuje úsudek o tom, co stavět. Zkracuje to vzdálenost mezi tím, mít vstupy, a mít něco sepsané, a přesně tam se ve většině týdnů PM ztrácí čas. I přepínání je levné: na Whizi Pro zprávy v Claude Sonnet 5 stojí 10 kreditů z měsíčního limitu 2 000 kreditů, extrakce v GPT-5.6 Luna stojí 1 a Gemini 3.7 Flash čte přepisy za 2 kredity na zprávu.
Napsat PRD, který se engineerovi nevrátí zpět
Většina AI psaných specifikací selhává na stejné věci: popisují funkci, ne rozhodnutí. Engineering nepotřebuje odstavec o tom, proč je zákazník důležitý. Potřebuje stavy, okrajové případy a to, co se stane, když volání selže. Poproste o to explicitně a výstup se zásadně změní.
Prompt: nejprve problémové prohlášení
Napiš sekci problémového prohlášení PRD. Důkazy, které mám: [vlož tickety podpory, analytiku, citace z rozhovorů]. Nenavrhuj řešení. Vrať: kdo má problém, jak často, co dělá místo toho aktuálně, co ho to stojí a co bychom očekávali, že se změní, kdyby byl vyřešen. Označ jakékoli tvrzení nepodložené vloženými důkazy jako ASSUMPTION.
Prompt: tělo specifikace
Přeměň toto na specifikaci pro engineeringový tým. Funkce: [popis]. Stavy uživatele k pokrytí: [seznam]. Vrať: user stories s akceptačními kritérii, každý stav včetně prázdného, načítání, chyby a odmítnutého oprávnění, chování při nedostupné závislosti, analytické eventy s jejich vlastnostmi a otevřené otázky. Nevymýšlej požadavky, které jsem neuvedl. Vše, co jsi musel předpokládat, uveď v samostatné sekci na konci.
Prompt: kritický průchod
Chovej se jako staff engineer, který tuto specifikaci recenzuje před odhadem. Vypiš jen problémy: nedefinované chování, chybějící stavy, protichůdné požadavky, skrytou migrační práci a cokoli, co v refinementu vyvolá dodatečnou otázku. Specifikaci nepřepisuj.
Spusťte tento třetí prompt v modelu, který specifikaci nepsal. Spolehlivě odhalí tři otázky, které by váš tým jinak vznesl při refinementu, a jejich zodpovězení předem je rozdíl mezi dvacetiminutovým groomingem a padesátiminutovým.
Jak z nezpracovaného feedbacku udělat něco, co lze prioritizovat
Nejvýnosnější AI úkol v produktovém managementu není psaní. Je to čtení 400 kusů feedbacku ve formě, se kterou lze jednat. Manuálně je to půl dne práce. S modelem dobře zvládnuté je to 20 minut a kvalita závisí téměř výhradně na tom, zda si vynutíte stabilní kategorie.
Prompt: první průchod tematizace
Zde je nezpracovaný feedback od zákazníků. Rozděl ho do témat. U každého tématu vrať: název, počet kusů, závažnost naznačenou jazykem, reprezentativní citaci zkopírovanou přesně a zda je téma chyba, chybějící funkce, problém s použitelností nebo neshoda očekávání. Neslučuj témata s odlišnou hlavní příčinou, i když je formulace podobná. Citace neparafrázuj. Feedback: [vlož].
Prompt: druhý průchod proti fixní taxonomii
Rozklasifikuj stejný feedback pouze podle těchto kategorií: [vlož svou existující taxonomii]. Vše, co nesedí, jde do UNCLASSIFIED s vysvětlením. Vrať tabulku kategorie, počtu a procenta.
Struktura dvou průchodů je klíčová. První průchod ukáže, co je v datech skutečně obsaženo. Druhý dělá výsledek srovnatelný s minulým čtvrtletím, což z něj dělá použitelný podklad pro prioritizační diskuzi, ne jen zajímavost.
| O co požádat | Co získáte | K čemu je to dobré |
|---|---|---|
| Témata s počty | Seřazený seznam problémových oblastí | Vstup do roadmapy, kvartální plánování |
| Pouze přesné citace | Neupravený jazyk zákazníka | Copy, positioning, přesvědčování vedení |
| Rozdělení závažnosti a frekvence | Matice 2x2 bolesti proti objemu | Rozhodnutí, co opravit první |
| Rozpory | Kde segmenty chtějí protichůdné věci | Odhalení falešného konsenzu včas |
Poslední řádek stojí za stálý prompt: Kde v tomto feedbacku chtějí různí uživatelé neslučitelné věci? Uveď segmenty a tradeoff. Seznam témat rozdíly zplošťuje, a nesoulad je obvykle v datech to nejužitečnější.
Discovery, konkurence a research, na který nikdy není čas
Discovery je práce, která se škrtá první, když se release opozdí, a přesně tehdy je špatné rozhodnutí nejdražší. Skenování s podporou modelu nenahradí rozhovory se zákazníky, ale nahradí výmluvu, proč vstupovat do rozhodnutí naslepo.
Prompt: rozbor konkurence
Vytvoř rozbor toho, jak [konkurent] řeší [job to be done]. Pokryj: jejich deklarovaný positioning jejich vlastními slovy, flow tak, jak je zdokumentované v jejich help centru, ceny tam, kde jsou veřejné, co se změnilo za posledních 12 měsíců s daty a témata stížností viditelná ve veřejných recenzích. Ke každému tvrzení uveď URL. Odděl, co firma tvrdí, od toho, co pozorují třetí strany.
Prompt: syntéza rozhovorů
Přečti tyto přepisy rozhovorů. Vrať: úkoly, které se uživatelé snaží splnit, workaroundy, které si vytvořili, momenty, kdy vyjádřili frustraci s přesnými citacemi, a jakékoli místo, kde se to, co uživatel řekl, liší od toho, co popsal jako dělané. Nezobecňuj nad rámec přepisů. Pokud se vzorec objeví v méně než třech rozhovorech, označ ho jako jednotlivé pozorování, ne jako vzorec.
Toto poslední omezení je to, co PM nejčastěji zapomínají. Modely rády tvoří přehledné vzorce a přehledný vzorec ze dvou rozhovorů je způsob, jak roadmapa skončí sloužit zákazníkovi, který neexistuje. Ke každému tvrzení si žádejte počty.
Exekutivní narativ a launch komunikace
Stejný obsah musí existovat na čtyřech výškách: specifikace pro engineering, aktualizace pro tým, odstavec pro leadership review a launch note pro zákazníky. Přepisování mezi výškami je nejmechanickější práce v této roli a nejsnáze se předává dál.
Prompt: změna výšky
Přepiš toto pro [publikum]. Zajímá je [konkrétní obavy]. Mají [úroveň] kontextu v této oblasti produktu. Zachovej každé faktické tvrzení identické. Délka: [omezení]. Začni rozhodnutím nebo výsledkem, ne pozadím. Draft: [vlož].
Prompt: odstavec pro leadership
Zkomprimuj tuto aktualizaci do 120 slov pro exekutivu, který si to přečte jen jednou. Struktura: co se změnilo, co to znamená pro metriku, ke které jsme se zavázali, co od nich potřebujeme a jediné riziko, které stojí za jejich pozornost. Žádná adjektiva, která nejsou změřená.
Prompt: pre mortem
Předpokládej, že tento launch za šest měsíců selhal. Napiš tři nejpravděpodobnější vysvětlení, seřazená podle pravděpodobnosti, pouze na základě toho, co je v plánu níže. U každého uveď včasný signál, který bychom mohli sledovat. Plán: [vlož].
Udržujte všechny čtyři výšky ve stejném vlákně Whizi. Launch note dědí kontext ze specifikace a analýzy feedbacku, takže při každé změně publika nemusíte funkci znovu vysvětlovat.
Kde AI klame produktové manažery konkrétně
Tři chybové vzorce jsou v této roli důležitější než ve většině ostatních.
Vymyšlené citace. Pokud požádáte o reprezentativní citace bez ukotvení modelu ke zdrojovému textu, občas získáte věrohodnou větu, kterou žádný zákazník neřekl. Vždy instruujte citace kopíruj přesně, neparafrázuj, a před tím, než citace skončí na slidu, tři z nich namátkově zkontrolujte proti raw datům.
Falešná jistota z malých vzorků. Model tematizuje osm ticketů podpory se stejnou jistotou, jako by tematizoval osm set. U každého tématu si žádejte počty a cokoli pod hrstkou výskytů považujte za pozorování, ne za signál.
Divadlo roadmapy. Požádat model o prioritizaci backlogu vyprodukuje sebejisté pořadí odvozené jen ze slov ve vašich ticketech. Nemá přístup k vaší strategii, kapacitě, technickému dluhu ani k obchodu, který se uzavírá příští čtvrtletí. Použijte ho na strukturování tradeoffu, nikdy k rozhodnutí samotnému.
- Uložte prompt šablonu pro PRD v Claude a kritickou prompt šablonu ke spuštění v jiném modelu
- Uložte šablonu tematizace feedbacku v GPT s vloženou vaší existující taxonomií
- Uložte šablonu skenování konkurence v Gemini, která vyžaduje URL ke každému tvrzení
- Vždy si ke každému tématu žádejte počty a malé počty považujte za pozorování
- Instruujte model, aby citace kopíroval přesně, poté namátkově zkontrolujte tři proti zdroji
- Před launch review, ne po něm, spusťte pre mortem na každý launch plán
- Držte specifikaci, feedback a launch komunikaci v jednom vlákně, aby kontext přecházel dál
Časté dotazy
Mohu vložit rozhovory se zákazníky?
Ano. Pro dlouhé přepisy použijte Gemini: jeho kontextové okno 1M tokenů pojme zhruba 2 000 stran textu, takže se celá sada rozhovorů vejde do jednoho průchodu bez rozdělování. Nejprve odstraňte jména, e-maily a identifikátory firem. Role a segmenty jsou vše, co analýza potřebuje, a odstranění zbytku vás udrží mimo většinu interních datových politik.
Integruje se Whizi s Jira nebo Linear?
Zatím nativně ne. V praxi workflow vypadá tak, že vygenerujete strukturovaný výstup ve Whizi (user stories s akceptačními kritérii, tabulka témat s počty) a vložíte ho do svého trackeru, což trvá vteřiny, protože formát už odpovídá tomu, co tracker očekává. Požádejte o výstup jako Markdown tabulku nebo jako jeden issue na blok, pokud je chcete vkládat jednotlivě.
Který model píše nejlepší PRD?
Claude na narativní sekce, tedy problémové prohlášení, zdůvodnění a cokoli, o čem musí být přesvědčen člověk. GPT na strukturované sekce, tedy user stories, akceptační kritéria, tabulky stavů a definice analytických eventů. Rozdělení dokumentu mezi oba stojí jedno navíc přepnutí modelu a viditelně zkracuje editační průchod.
Je bezpečné vkládat interní roadmapu nebo tržby?
Whizi netrénuje na vašich konverzacích a datová politika každého poskytovatele je dostupná ještě před tím, než daný model povolíte. Politika vaší firmy je obvykle přísnějším omezením. Osvědčený zvyk je citlivá čísla indexovat, ne vkládat absolutní hodnoty, protože analýza relativního pohybu funguje stejně a čísla přestanou být citlivá.
Umí AI prioritizovat můj backlog?
Umí strukturovat tradeoff, což je skutečně užitečné: ohodnotit položky proti kritériím, která definujete, odhalit, kde jsou dvě položky na sobě závislé, a ukázat, kterým segmentům daná volba slouží. Rozhodnutí udělat neumí, protože nemá přehled o vaší strategii, kapacitě týmu ani obchodním kontextu. Jakékoli pořadí, které vyprodukuje, berte jako podnět k diskuzi.