Jak napsat PRD (specifikaci produktu) s AI (zdarma šablona)

Specifikace produktu (PRD) je krátký popis v běžném jazyce: co stavíte, pro koho to je, co to musí umět a jak poznáte, že to funguje. AI psaní výrazně urychlí: dáte jí hrubé poznámky a ona z nich udělá strukturované sekce, uživatelské příběhy a okrajové případy. Vy doplníte rozhodnutí, která AI udělat nemůže, tedy cíl, rozsah a to, co se vynechá, a zkontrolujete, co přidala.

Tento průvodce popisuje, co má PRD obsahovat, krok za krokem postup, jak ho sepsat s libovolným AI asistentem, prompty pro jednotlivé sekce a šablonu k vyplnění, kterou si můžete zkopírovat.

K čemu PRD slouží (a k čemu ne)

PRD odpovídá na čtyři otázky:

1. Proč to stavíme? Jaký problém a pro koho?
2. Co to musí umět v první verzi?
3. Co to zatím umět nebude?
4. Jak poznáme, že to funguje?

Není to technický návrh. Neříká, jakou databázi nebo framework použít, to patří do samostatné technické specifikace, pokud ji vůbec potřebujete. Není to ani marketingový brief nebo byznys plán. Právě to, že se PRD drží chování produktu, ho dělá užitečným pro každého, kdo ho čte: designéra, vývojáře, člena vedení, který ho schvaluje, nebo AI nástroj, který z něj generuje kód.

Kdo ho potřebuje

• Solo zakladatelé, kteří chtějí zabránit rozšiřování rozsahu, než začne.
• Malé týmy, které potřebují jedno místo, kde žije to, na čem se dohodli.
• Každý, kdo najímá freelancera nebo agenturu, protože jasná specifikace dostane jasnější nabídky. Viz najmout vývojáře, nebo stavět s AI.
• Každý, kdo staví s AI, protože uživatelské příběhy a seznam dat v PRD jsou lepší prompty než nestrukturovaný seznam přání.

Co AI zvládne dobře a co ne

Nejčastější chyba je opačná verze předposledního řádku: AI sebejistě doplní mezery věrohodnými odhady o vašich uživatelích. Cokoli, co napíše o uživatelích, velikosti trhu nebo chování, berte jako otázku k ověření, ne jako fakt.

Krok 1: Vypište, co víte

Než cokoli zadáte do promptu, sepište hrubé poznámky. Stačí odrážky. Pokryjte:

• Problém v jedné nebo dvou větách z pohledu uživatele.
• Kdo ho má. Buďte konkrétní: „externí účetní s 10 až 40 klienty“, ne „malé firmy“.
• Co dělají dnes místo toho (tabulka, e-mail, nástroj, který nemají rádi).
• Jediný výsledek, který by z první verze udělal úspěch.
• Věci, které už víte, že dělat nebudete.
• Pevná omezení: termín, rozpočet, musí fungovat na telefonech, musí se propojit s nástrojem, který už používáte.

Pokud jste s nikým, kdo má tento problém, nemluvili, udělejte to nejdřív. Jak ověřit nápad na aplikaci popisuje praktický postup. PRD postavené na dohadech je jen dobře naformátovaný dohad.

Krok 2: Požádejte AI o první návrh

Vložte své poznámky a požádejte o návrh v pevné struktuře. Prompt, který funguje dobře:

Tady jsou moje poznámky k produktu. Převeďte je na specifikaci produktu (PRD) přesně s těmito sekcemi: Shrnutí, Problém, Uživatelé, Cíle a metriky úspěchu, Rozsah (v / mimo), Uživatelské příběhy s kritérii přijetí, Data, Oprávnění, Okrajové případy, Otevřené otázky. Držte se pod dvěma stranami. Nevymýšlejte si fakta o uživatelích ani o trhu. Tam, kde moje poznámky nic neříkají, napište otázku do sekce Otevřené otázky.

Poslední pokyn má význam. Když AI řeknete, aby neznámé věci dávala do sekce „Otevřené otázky“ místo toho, aby je doplňovala, dostanete mnohem poctivější návrh.

Krok 3: Zpřesněte každou sekci

Projděte návrh sekci po sekci. Tyto navazující prompty pomohou:

Problém a uživatelé

Přepiš problém do jedné nebo dvou vět z pohledu uživatele. Žádná slova o řešení.

Pokud problém popisuje i váš produkt, pak popisuje řešení, ne problém.

Cíle a metriky úspěchu

Navrhni tři metriky úspěchu pro první verzi, které mohu změřit během prvního měsíce s malým počtem uživatelů. U každé napiš, jak bych ji měřil.

Vyberte jednu nebo dvě. „Dvacet účetních to používá každý týden po dobu měsíce“ je měřitelné. „Zvýšit produktivitu“ měřitelné není.

Rozsah

Vypiš vše, co je v tomto PRD a dalo by se přesunout do pozdější verze, aniž by se rozbil hlavní postup.

Nástroje AI mají sklon přidávat funkce. Tento prompt je nutí dělat opak. Buďte nemilosrdní: většina PRD pro první verzi je příliš velká. Co je MVP vysvětluje, proč malé první verze naučí víc.

Uživatelské příběhy a kritéria přijetí

Napiš každý požadavek jako uživatelský příběh („Jako [uživatel] chci [akce], abych [výsledek]“) s dvěma až čtyřmi kritérii přijetí ve formátu Given / When / Then (za předpokladu / když / pak).

Kritéria přijetí jsou kontrolní seznam, podle kterého později budete testovat. „Když je termín rezervovaný a jiný klient si prohlíží kalendář, pak se termín nezobrazí“ je testovatelné. „Rezervace funguje dobře“ testovatelné není.

Okrajové případy a oprávnění

Pro každý uživatelský příběh vypiš, co se stane při prázdných datech, neplatném vstupu, pomalém nebo neúspěšném síťovém požadavku a uživateli, který nemá mít přístup.

Tady se AI skutečně hodí. Rychle najde prázdné stavy a mezery v oprávněních, na které lidé zapomínají.

Krok 4: Projděte to jako skeptik

Přečtěte si celý dokument ještě jednou a zkontrolujte:

• Každé tvrzení o uživatelích pochází od vás nebo z výzkumu, ne od AI.
• Rozsah „mimo“ je alespoň tak dlouhý jako rozsah „v“.
• Každý uživatelský příběh má kritéria přijetí, která někdo může otestovat, aniž by se musel ptát vás.
• Sekce dat uvádí každý typ záznamu, který aplikace ukládá, a kdo ho vidí.
• Otevřené otázky mají odpovědnou osobu a termín.
• Nic technického se tam nevloudilo, pokud to není skutečné omezení („musí fungovat offline“ je požadavek; „použít Redis“ ne).

Pak ho ukažte jednomu člověku, který produkt použije nebo bude stavět, a zeptejte se, co je nejasné. Jeho otázky ukážou mezery.

Šablona PRD k vyplnění

Zkopírujte si tuto šablonu do dokumentu a nahraďte závorky. Smažte sekce, které se opravdu netýkají.

Název produktu: [název] Odpovědná osoba: [kdo rozhoduje] Stav: [koncept / v revizi / odsouhlaseno] — Naposledy upraveno: [datum]

1. Shrnutí

[Dvě nebo tři věty: co to je, pro koho a hlavní výsledek.]

2. Problém

[Problém z pohledu uživatele. Co dělají dnes a proč je to bolí.]

3. Uživatelé

4. Cíle a metriky úspěchu

• Cíl: [výsledek, kterého musí první verze dosáhnout]
• Metrika: [jak to změříte a cílová hodnota]
• Mimo cíl: [něco, co by lidé mohli předpokládat, ale tato verze to dělat nechce]

5. Rozsah

V první verzi:

• [funkce]
• [funkce]

Není v první verzi:

• [funkce a proč může počkat]
• [funkce a proč může počkat]

6. Uživatelské příběhy

Příběh 1: Jako [uživatel] chci [akce], abych [výsledek].

• Za předpokladu [kontext], když [akce], pak [výsledek].
• Za předpokladu [kontext], když [akce], pak [výsledek].

Příběh 2: Jako [uživatel] chci [akce], abych [výsledek].

• Za předpokladu [kontext], když [akce], pak [výsledek].

7. Data

8. Oprávnění

[Kdo se může přihlásit, jaké existují role a co každá role může vidět a měnit.]

9. Okrajové případy

• [Prázdný stav: co se zobrazí, když ještě nejsou žádná data]
• [Neplatný vstup: co se stane se špatným e-mailem nebo chybějícím polem]
• [Přístup: co se stane, když někdo otevře stránku, na kterou nemá nárok]

10. Integrace a omezení

[Platby, e-mail, stávající nástroje, termíny, rozpočet, zařízení, na kterých musí fungovat.]

11. Otevřené otázky

Od PRD k promptům

Dobré PRD se téměř přímo mění v prompty pro AI nástroj na tvorbu aplikací:

• Shrnutí, uživatelé a tabulka dat se stanou vaším prvním promptem.
• Každý uživatelský příběh se stane jedním navazujícím promptem.
• Každé kritérium přijetí je něco, co v náhledu otestujete.
• Seznam „není v první verzi“ je to, co zatím nepožadujete.

Stavět po jednom příběhu a před přechodem na další zkontrolovat jeho kritéria přijetí je mnohem spolehlivější než vložit celé PRD a žádat všechno najednou. Jak psát prompty pro AI nástroje na tvorbu aplikací se věnuje promptování podrobněji.

Časté chyby

• Napsat řešení jako problém. „Uživatelé potřebují dashboard“ je řešení. „Majitelé nevidí, které faktury jsou po splatnosti, aniž by otevřeli každou z nich“ je problém.
• Chybějící sekce „mimo rozsah“. Bez ní se rozsah v každém rozhovoru znovu otevírá.
• Nechat AI vymýšlet uživatele. Personas, které AI vytvořila, působí skutečně, ale skutečné nejsou.
• Metriky, které nejde změřit. Pokud to nemůžete spočítat, není to metrika.
• Nikdy neaktualizovat. PRD, které už neodpovídá tomu, co stavíte, je horší než žádné. Uvádějte datum poslední úpravy a měňte ho, když se mění rozhodnutí.

Použití PRD s Mythexem

Pokud stavíte v Mythexu, můžete PRD vložit přímo do chatu. Režim Plan se pro PRD hodí: agent si ho přečte, navrhne postup a kontrolní seznam kroků, který můžete zkontrolovat v záložce plánu, a začne měnit soubory až po stisknutí Build. Stálé části, které mají platit vždy, jako publikum, značku a pravidla, můžete uložit jako znalosti projektu, takže je nebudete opakovat v každém chatu. Dokumentace k chatu vysvětluje režimy Build, Plan a Ask a šablony jsou rychlý způsob, jak si představit, jak by mohla vypadat první verze, než sepíšete celý dokument.

Otázky