Sådan skriver du et produktkravsdokument med AI (gratis skabelon)

Et produktkravsdokument (PRD) er en kort beskrivelse i klart sprog af, hvad du bygger, hvem det er til, hvad det skal kunne, og hvordan du ved, at det virker. AI gør det markant hurtigere at skrive: Du giver den grove noter, og den omsætter dem til strukturerede afsnit, brugerhistorier og edge cases. Din opgave er at levere de beslutninger, AI'en ikke kan tage — målet, omfanget og hvad der udelades — og at kontrollere det, den tilføjer.

Denne guide gennemgår, hvad en PRD skal indeholde, en trin-for-trin-metode til at lave et udkast med en hvilken som helst AI-assistent, prompts til hvert afsnit og en udfyldningsskabelon, du kan kopiere.

Hvad en PRD er til (og hvad den ikke er)

En PRD besvarer fire spørgsmål:

1. Hvorfor bygger vi det her? Hvilket problem, for hvem?
2. Hvad skal det kunne i den første version?
3. Hvad skal det ikke kunne endnu?
4. Hvordan ved vi, at det virkede?

Den er ikke et teknisk design. Den siger ikke, hvilken database eller hvilket framework der skal bruges — det hører hjemme i en separat teknisk specifikation, hvis du overhovedet har brug for en. Den er heller ikke et marketingoplæg eller en forretningsplan. Ved at holde PRD'en til produktets adfærd bliver den nyttig for alle, der læser den: en designer, en udvikler, en interessent der godkender den, eller et AI-app-builder-værktøj der omsætter den til kode.

Hvem har brug for en?

• Solo-founders, der vil stoppe scope creep, før det starter.
• Små teams, der har brug for ét sted, hvor „det vi er enige om“ står.
• Alle, der hyrer en freelancer eller et bureau, fordi en klar PRD giver klarere tilbud. Se hyr en udvikler eller byg med AI.
• Alle, der bygger med AI, fordi en PRDs brugerhistorier og datalister giver bedre prompts end en ustruktureret ønskeliste.

Hvad AI er god til — og hvad den ikke er god til

Den hyppigste fejl er den næstsidste række vendt på hovedet: AI'en udfylder selvsikkert huller med plausible gæt om dine brugere. Behandl alt, den skriver om brugere, markedsstørrelse eller adfærd, som et spørgsmål, du skal verificere, ikke som et faktum.

Trin 1: Skriv det, du ved

Før du prompter noget, så skriv grove noter. Punktopstillinger er fint. Dæk:

• Problemet, i en eller to sætninger, set fra brugerens synspunkt.
• Hvem der har det. Vær konkret: „freelance-bogholdere med 10–40 kunder“, ikke „små virksomheder“.
• Hvad de gør i dag i stedet (et regneark, en mail, et værktøj de ikke kan lide).
• Det ene udfald, der ville gøre version ét til en succes.
• Alt, du allerede ved, at du ikke vil lave.
• Hårde begrænsninger: deadline, budget, skal virke på telefoner, skal integreres med et værktøj, du allerede bruger.

Hvis du ikke har talt med nogen, der har problemet, så gør det først. Sådan validerer du en app-idé har en praktisk måde at gøre det på. En PRD bygget på gæt er et velformateret gæt.

Trin 2: Bed AI'en om et første udkast

Sæt dine noter ind, og bed om et udkast i en fast struktur. En prompt, der virker godt:

Her er mine noter om et produkt. Omsæt dem til et produktkravsdokument med præcis disse afsnit: Resumé, Problem, Brugere, Mål og succeskriterier, Omfang (med / uden), Brugerhistorier med acceptkriterier, Data, Rettigheder, Edge cases, Åbne spørgsmål. Hold det under to sider. Opfind ikke fakta om brugere eller markedet — hvor mine noter ikke siger noget, skal spørgsmålet stå under Åbne spørgsmål i stedet.

Den sidste instruktion er vigtig. At bede AI'en sende ukendte ting til „Åbne spørgsmål“ i stedet for at udfylde dem giver et langt mere ærligt udkast.

Trin 3: Stram hvert afsnit op

Gennemgå udkastet afsnit for afsnit. Disse opfølgende prompts hjælper:

Problem og brugere

Omskriv problemformuleringen i en eller to sætninger set fra brugerens synspunkt. Ingen løsningsord.

Hvis problemformuleringen nævner dit produkt, beskriver den en løsning, ikke et problem.

Mål og succeskriterier

Foreslå tre succeskriterier for version ét, som jeg kan måle i den første måned med et lille antal brugere. For hvert kriterium: sig hvordan jeg ville måle det.

Vælg ét eller to. „Tyve bogholdere bruger det ugentligt i en måned“ kan måles. „Forbedre produktiviteten“ kan ikke.

Omfang

Liste alt i denne PRD, der kunne flyttes til en senere version uden at ødelægge kerneflowet.

AI-værktøjer har tendens til at tilføje funktioner. Denne prompt får dem til at gøre det modsatte. Vær hård: de fleste PRD'er for version ét er for store. Hvad er en MVP forklarer, hvorfor små første versioner lærer dig mere.

Brugerhistorier og acceptkriterier

Skriv hvert krav som en brugerhistorie („Som [bruger] vil jeg [handling], så [resultat]“) med to til fire acceptkriterier i Given / When / Then-form.

Acceptkriterier er tjeklisten, du tester op imod senere. „Givet en booket tid, når en anden kunde ser kalenderen, så vises tiden ikke“ kan testes. „Booking fungerer godt“ kan ikke.

Edge cases og rettigheder

For hver brugerhistorie: list hvad der sker med tomme data, ugyldigt input, et langsomt eller fejlet netværkskald, og en bruger, der ikke burde have adgang.

Her får AI sit værd. Den er hurtig til at finde de tomme tilstande og rettighedshuller, folk glemmer.

Trin 4: Gennemgå det som en skeptiker

Læs det hele endnu en gang og tjek:

• Hver påstand om brugere kommer fra dig eller fra research, ikke fra AI'en.
• Omfang „uden for“ er mindst lige så langt som omfang „med“.
• Hver brugerhistorie har acceptkriterier, som nogen kan teste uden at spørge dig.
• Datasektionen lister hver type post, appen gemmer, og hvem der kan se den.
• Åbne spørgsmål har en ansvarlig og en dato.
• Intet teknisk har sneget sig ind, medmindre det er en reel begrænsning („skal virke offline“ er et krav; „brug Redis“ er ikke).

Del derefter den med én person, der vil bruge eller bygge produktet, og spørg hvad der er uklart. Deres spørgsmål er hullerne.

Udfyldningsskabelon til PRD

Kopiér dette ind i et dokument og erstat parenteserne. Slet de afsnit, der reelt ikke gælder.

Produktnavn: [navn] Ansvarlig: [person, der træffer beslutningerne] Status: [udkast / under review / godkendt] — Sidst opdateret: [dato]

1. Resumé

[To eller tre sætninger: hvad det er, for hvem, og det vigtigste udfald.]

2. Problem

[Problemet set fra brugerens synspunkt. Hvad de gør i dag, og hvorfor det gør ondt.]

3. Brugere

4. Mål og succeskriterier

• Mål: [det udfald version ét skal opnå]
• Metrik: [hvordan du måler det, og målet]
• Ikke-mål: [noget folk måske antager, at denne version ikke forsøger at gøre]

5. Omfang

I version ét:

• [funktion]
• [funktion]

Ikke i version ét:

• [funktion, og hvorfor den kan vente]
• [funktion, og hvorfor den kan vente]

6. Brugerhistorier

Historie 1: Som [bruger] vil jeg [handling], så [resultat].

• Givet [kontekst], når [handling], så [resultat].
• Givet [kontekst], når [handling], så [resultat].

Historie 2: Som [bruger] vil jeg [handling], så [resultat].

• Givet [kontekst], når [handling], så [resultat].

7. Data

8. Rettigheder

[Hvem der kan logge ind, hvilke roller der findes, og hvad hver rolle kan se og ændre.]

9. Edge cases

• [Tom tilstand: hvad der vises, når der endnu ikke er data]
• [Ugyldigt input: hvad der sker ved en forkert mail eller et manglende felt]
• [Adgang: hvad der sker, når nogen åbner en side, de ikke burde kunne]

10. Integrationer og begrænsninger

[Betalinger, mail, eksisterende værktøjer, deadlines, budget, enheder den skal virke på.]

11. Åbne spørgsmål

Fra PRD til prompts

En god PRD bliver næsten direkte til prompts til en AI-app-builder:

• Resuméet, brugerne og datatabellen bliver din første prompt.
• Hver brugerhistorie bliver én opfølgende prompt.
• Hvert acceptkriterie bliver noget, du tester i preview.
• Listen „ikke i version ét“ er det, du lader være med at bede om endnu.

At bygge én historie ad gangen og tjekke dens acceptkriterier, før du går videre, er langt mere pålideligt end at indsætte hele PRD'en og bede om alt. Sådan skriver du prompts til AI-app-builders dækker promptsiden mere detaljeret.

Almindelige fejl

• At skrive løsningen som problemet. „Brugerne har brug for et dashboard“ er en løsning. „Ejere kan ikke se, hvilke fakturaer der er forfaldne, uden at åbne hver enkelt“ er et problem.
• Intet afsnit om „uden for omfang“. Uden det genåbnes omfanget i hver samtale.
• At lade AI'en opfinde brugere. Personas, AI'en har lavet, føles virkelige, men er det ikke.
• Metrikker, du ikke kan måle. Hvis du ingen måde har at tælle det på, er det ikke en metrik.
• Aldrig at opdatere den. En PRD, der ikke længere passer til det, du bygger, er værre end ingen. Hold en „sidst opdateret“-dato og ændr den, når beslutningerne ændrer sig.

Brug en PRD med Mythex

Hvis du bygger i Mythex, kan du indsætte din PRD direkte i chatten. Det at starte i Plan-tilstand passer godt til en PRD: Agenten læser den, foreslår en tilgang og en trinliste, du kan gennemgå i en plan-fane, og den begynder først at ændre filer, når du trykker på Build. Du kan også gemme de dele, der altid skal gælde — målgruppe, brand og regler — som projektviden, så du ikke gentager dem i hver chat. Mythex-dokumentationen om chat forklarer tilstandene Build, Plan og Ask, og skabelonerne er en hurtig måde at se, hvordan en første version kunne se ud, før du skriver det fulde dokument.

Spørgsmål