Så skriver du ett PRD med AI (gratis mall)

Ett produktkravsdokument (PRD) är en kort beskrivning på vanlig svenska av vad du bygger, vem det är till för, vad det måste göra och hur du vet att det fungerar. AI gör det mycket snabbare att skriva ett: du ger den råa anteckningar och den omvandlar dem till strukturerade avsnitt, användarberättelser och kantfall. Ditt jobb är att leverera de beslut AI:n inte kan fatta — målet, omfattningen och vad som lämnas utanför — och att kontrollera vad den lägger till.

Den här guiden tar upp vad som hör hemma i en PRD, ett steg-för-steg-sätt att skriva ett utkast med vilken AI-assistent som helst, prompter för varje avsnitt och en mall att fylla i som du kan kopiera.

Vad en PRD är till för (och vad den inte är)

En PRD besvarar fyra frågor:

1. Varför bygger vi det här? Vilket problem, för vem?
2. Vad måste det göra i första versionen?
3. Vad gör det inte ännu?
4. Hur vet vi att det fungerade?

Det är inte en teknisk design. Den säger inte vilken databas eller vilket ramverk du ska använda — det hör hemma i en separat teknisk specifikation, om du behöver en alls. Det är inte heller en marknadsföringsbrief eller en affärsplan. Om PRD:n håller sig till produktens beteende blir den användbar för alla som läser den: en designer, en utvecklare, en intressent som godkänner den eller ett AI-verktyg för appar som omvandlar den till kod.

Vem behöver en?

• Solo-grundare som vill stoppa scope creep innan det börjar.
• Småteam som behöver en gemensam plats för ”vad vi kommit överens om”.
• Den som anlitar en frilansare eller byrå, eftersom en tydlig PRD ger tydligare offerter. Se anlita en utvecklare eller bygg med AI.
• Den som bygger med AI, eftersom en PRD:s användarberättelser och datalista ger bättre prompter än en ostrukturerad önskelista.

Vad AI är bra på — och vad den inte är

Det vanligaste felet är den näst sista raden upp och ner: AI:n fyller tyst i luckor med trovärdiga gissningar om dina användare. Behandla allt den skriver om användare, marknadsstorlek eller beteende som en fråga att verifiera, inte ett faktum.

Steg 1: Skriv ned vad du vet

Innan du skriver någon prompt, skriv råa anteckningar. Punktlistor duger. Täck in:

• Problemet, i en eller två meningar, sett från användarens perspektiv.
• Vem som har det. Var specifik: ”frilansbokförare med 10–40 kunder”, inte ”småföretag”.
• Vad de gör idag i stället (ett kalkylblad, e-post, ett verktyg de inte gillar).
• Det enda resultat som skulle göra version ett till en framgång.
• Allt du redan vet att du inte kommer att göra.
• Hårda begränsningar: deadline, budget, måste fungera i mobilen, måste integreras med ett verktyg du redan använder.

Om du inte har pratat med någon som har problemet, gör det först. Så validerar du en appidé har ett praktiskt sätt att göra det. En PRD byggd på gissningar är en välformaterad gissning.

Steg 2: Be AI:n om ett första utkast

Klistra in dina anteckningar och be om ett utkast i en fast struktur. En prompt som fungerar bra:

Här är mina anteckningar om en produkt. Omvandla dem till ett produktkravsdokument med exakt dessa avsnitt: Sammanfattning, Problem, Användare, Mål och framgångsmått, Omfattning (med / utan), Användarberättelser med acceptanskriterier, Data, Behörigheter, Kantfall, Öppna frågor. Håll det under två sidor. Hitta inte på fakta om användare eller marknaden — där mina anteckningar inte säger något, skriv frågan under Öppna frågor i stället.

Den sista instruktionen är viktig. Att be AI:n dirigera okända uppgifter till ”Öppna frågor” i stället för att fylla i dem ger ett betydligt mer ärligt utkast.

Steg 3: Skärp varje avsnitt

Gå igenom utkastet avsnitt för avsnitt. Dessa uppföljningsprompter hjälper:

Problem och användare

Skriv om problemformuleringen i en eller två meningar ur användarens perspektiv. Inga lösningsord.

Om problemformuleringen nämner din produkt beskriver den en lösning, inte ett problem.

Mål och framgångsmått

Föreslå tre framgångsmått för version ett som jag kan mäta under första månaden med ett litet antal användare. För varje, säg hur jag skulle mäta det.

Välj ett eller två. ”Tjugo bokförare använder den varje vecka i en månad” är mätbart. ”Förbättra produktiviteten” är det inte.

Omfattning

Lista allt i den här PRD:n som kan flyttas till en senare version utan att den centrala flödet går sönder.

AI-verktyg tenderar att lägga till funktioner. Den här prompten gör tvärtom. Var obarmhärtig: de flesta PRD:er för version ett är för stora. Vad är en MVP förklarar varför små första versioner lär dig mer.

Användarberättelser och acceptanskriterier

Skriv varje krav som en användarberättelse (”Som [användare] vill jag [handling] så att [resultat]”) med två till fyra acceptanskriterier i formen Givet / När / Så.

Acceptanskriterierna är checklistan du testar mot senare. ”Givet en bokad tid, när en annan kund tittar i kalendern, så visas inte tiden” går att testa. ”Bokningen fungerar bra” gör det inte.

Kantfall och behörigheter

För varje användarberättelse, lista vad som händer vid tomma data, ogiltig inmatning, ett långsamt eller misslyckat nätverksanrop och en användare som inte borde ha åtkomst.

Här tjänar AI verkligen sin plats. Den är snabb på att upptäcka de tomma vyerna och behörighetsluckorna som människor glömmer.

Steg 4: Granska det som en skeptiker

Läs hela dokumentet en gång till och kontrollera:

• Varje påstående om användare kommer från dig eller från research, inte från AI:n.
• Omfattningen ”utanför” är minst lika lång som omfattningen ”inom”.
• Varje användarberättelse har acceptanskriterier som någon kan testa utan att behöva fråga dig.
• Datasektionen listar varje typ av post appen sparar och vem som kan se den.
• Öppna frågor har en ägare och ett datum.
• Inget tekniskt har smugit in om det inte är en verklig begränsning (”måste fungera offline” är ett krav; ”använd Redis” är det inte).

Dela sedan den med en person som kommer att använda eller bygga produkten och be henne säga vad som är otydligt. Hennes frågor är luckorna.

PRD-mall att fylla i

Kopiera detta till ett dokument och ersätt hakparenteserna. Ta bort avsnitt som verkligen inte är relevanta.

Produktnamn: [namn] Ägare: [person som ansvarar för besluten] Status: [utkast / under granskning / godkänd] — Senast uppdaterad: [datum]

1. Sammanfattning

[Två eller tre meningar: vad detta är, för vem och huvudresultatet.]

2. Problem

[Problemet sett från användarens perspektiv. Vad de gör idag och varför det gör ont.]

3. Användare

4. Mål och framgångsmått

• Mål: [resultatet version ett måste uppnå]
• Mått: [hur du mäter det, och målvärdet]
• Icke-mål: [något folk kan anta, som den här versionen inte försöker göra]

5. Omfattning

I version ett:

• [funktion]
• [funktion]

Inte i version ett:

• [funktion, och varför den kan vänta]
• [funktion, och varför den kan vänta]

6. Användarberättelser

Berättelse 1: Som [användare] vill jag [handling] så att [resultat].

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

Berättelse 2: Som [användare] vill jag [handling] så att [resultat].

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

7. Data

8. Behörigheter

[Vem som kan logga in, vilka roller som finns och vad varje roll kan se och ändra.]

9. Kantfall

• [Tomt läge: vad som visas när det inte finns några data ännu]
• [Ogiltig inmatning: vad som händer med en felaktig e-postadress eller ett saknat fält]
• [Åtkomst: vad som händer när någon öppnar en sida den inte borde nå]

10. Integrationer och begränsningar

[Betalningar, e-post, befintliga verktyg, deadlines, budget, enheter det måste fungera på.]

11. Öppna frågor

Från PRD till prompter

En bra PRD omvandlas nästan direkt till prompter för ett AI-verktyg för appbygge:

• Sammanfattningen, användarna och datatabellen blir din första prompt.
• Varje användarberättelse blir en uppföljningsprompt.
• Varje acceptanskriterium blir något du testar i förhandsvisningen.
• Listan ”inte i version ett” är det du låter bli att be om ännu.

Att bygga en berättelse i taget och kontrollera dess acceptanskriterier innan du går vidare är betydligt mer tillförlitligt än att klistra in hela PRD:n och be om allt på en gång. Så skriver du prompter för AI-appbyggare går djupare på promptdelen.

Vanliga misstag

• Att skriva lösningen som problemet. ”Användarna behöver en instrumentpanel” är en lösning. ”Ägare kan inte se vilka fakturor som är förfallna utan att öppna var och en” är ett problem.
• Ingen sektion för ”utanför omfattningen”. Utan den öppnas omfattningen på nytt i varje samtal.
• Att låta AI:n hitta på användare. Personor som AI:n hittat på känns verkliga men är det inte.
• Mått du inte kan mäta. Om du inte har något sätt att räkna det är det inte ett mått.
• Att aldrig uppdatera den. En PRD som inte längre stämmer med det du bygger är sämre än ingen alls. Behåll ett ”senast uppdaterad”-datum och ändra det när besluten ändras.

Använda en PRD med Mythex

Om du bygger i Mythex kan du klistra in din PRD direkt i chatten. Att börja i läget Plan passar bra för en PRD: agenten läser den, föreslår ett tillvägagångssätt och en stegchecklista som du kan granska i en planflik, och börjar bara ändra filer när du trycker på Build. Du kan också spara de delar som alltid ska gälla — målgrupp, varumärke, regler — som projektkunskap så att du inte behöver upprepa dem i varje chatt. Chattdokumentationen förklarar lägena Build, Plan och Ask, och mallarna är ett snabbt sätt att se hur en första version kan se ut innan du skriver det fullständiga dokumentet.

Frågor