Sådan skriver du et PRD: Komplet guide i 10 trin + AI-skriveprompter

Hvorfor er dokumenter med produktkrav (eller PRD'er) så vigtige værktøjer for produktteams? Fordi uanset hvor tydeligt du kan forestille dig dit produkts fremtidige tilstand, vil ikke to interessenter opfatte det på samme måde.

Jeg er sikker på, at der findes en million skrækhistorier fra produktchefer, som ikke indså, hvor ineffektivt de havde kommunikeret de kritiske elementer i et nyt produkt eller en ny funktion, før det var for sent. 

Det er derfor, at et dokument med produktkrav (PRD) er så vigtigt. Det anvender en detaljeret, systematisk tilgang til at sikre, at alle er enige om, hvordan succes bør se ud.

I denne guide hjælper vi dig med at skabe et fantastisk PRD med klare målsætninger, krav og en gennemtænkt handlingsplan. For at hjælpe dig med at spare værdifuld tid har vi desuden et sæt LLM-prompter, som kan generere det meste af dit PRD for dig (eller i det mindste give dig et solidt første udkast!).

Hvad er et dokument med produktkrav (PRD)?

Kort sagt beskriver et dokument med produktkrav de funktioner og den funktionalitet, der skal inkluderes i en specifik produktudgivelse. Det er et centralt referencepunkt for alle team, der er involveret i design og udvikling af et bestemt produkt. Det er også afgørende for udarbejdelsen af produktkøreplanen.

Det anvendes traditionelt i et projektmiljø med en vandfaldsmetode—hvor produktudviklingsprocessen er sekventiel—men kan også anvendes i agil produktledelse.

Der kan oprettes flere andre dokumenter ud fra de oplysninger, der er indsamlet i PRD'et. Teknisk afdeling kan oprette et teknisk kravdokument, der beskriver produktspecifikationerne og systemkravene.

Forretningsanalytikere kan oprette et funktionelt kravdokument, der beskriver, hvad der sker, når en bruger interagerer med systemet, herunder trådrammer, der viser produktdesignet. 

Brugeroplevelsesdesignere (UX) kan oprette et kravdokument for brugergrænsefladen, der forklarer, hvordan produktet bør se ud og føles.

Hvad er fordelene ved at skrive et PRD, og hvad indeholder det?

Der er flere fordele ved at investere tid i at skrive et komplet PRD. Lad os se på nogle af dem:

1. Det bringer alle interessenter på samme side.
2. Det gør det tydeligt, hvad der er uden for omfanget
3. Det fremmer samarbejdet mellem teams
4. Det sætter kundens perspektiv i centrum for produktet

Hvad angår strukturen, bør en typisk PRD indeholde følgende:

• Dokumentmetadata såsom redigeringsdato, versionshistorik osv.
• Produktmål, som du ønsker at opnå.
• Data fra kundeundersøgelser, såsom målpersoner.
• Prioriteret liste over funktioner, som du ønsker at udvikle.
• Negativt omfang for de funktioner, du ikke vil udvikle.
• Centrale målepunkter til test af disse hypoteser.
• Centrale hypoteser, som dine funktioner tester.
• Udgivelsesstrategi, der viser, hvornår og hvordan funktionen lanceres.

Selvom de fleste PRD'er vil indeholde disse elementer, er det helt i orden at tilføje eller fjerne elementer baseret på dine behov og dit produkts virkelighed.

Hvad er et eksempel på et dokument med produktkrav?

Nogle gange er det lettere at forstå, hvad der skal med i et dokument, ved hjælp af en visuel fremstilling, så her er et eksempel på en færdig PRD.

Sådan skriver du et dokument med produktkrav (med lidt hjælp fra LLM'er)

Selv med alle de oplysninger, vi allerede har delt, kan det føles overvældende at sammensætte din første PRD. Bare rolig; vi hjælper dig! Her er vores tjekliste i 10 trin til AI i kravindsamling og udarbejdelse af en solid PRD. Desuden har vi inkluderet en skabelon, der hjælper dig med at indfange alle de rigtige oplysninger.

Trin 1: Få klarhed over problemet

Før du gør noget andet, er det afgørende, at du har klarhed over det problem, du forsøger at løse, og de brugerpersonas, du forsøger at løse det for. Det vil påvirke præcis, hvilken funktionalitet du inkluderer i produktet, og hvilke funktioner du prioriterer til udgivelsen. 

Dokumentet med forretningskrav bør indeholde en behovsbeskrivelse, der beskriver det problem, der opleves, og hvordan produktet bør fungere for at løse dette problem. Det er vigtigt at gennemgå BRD'en og få klarhed over præcis, hvad virksomheden har brug for fra produktet, før du udarbejder PRD'en.

Trin 2: Gennemgå markeds- og brugerundersøgelser

På det tidspunkt, hvor du skriver en PRD, bør du allerede have din markedsundersøgelse og dine personaer klar. Men nogle gange kan personaen for en bestemt funktion adskille sig fra den generelle, du har. Så hvis det er tilfældet for dig, kan vi generere en personabeskrivelse ved hjælp af denne LLM-prompt:

Her er udskrifter fra flere produktindsigtsinterviews, jeg har gennemført med mine brugere.

{uploadér dine udskrifter som txt-filer i denne meddelelse}

Gennemgå venligst disse udskrifter, analysér de fælles træk blandt dem, og generér en persona-beskrivelse efter denne struktur (afgrænset af XML-tags):


<USER_PERSONA_STRUCTURE>

1. Navn:

(Fiktivt, men realistisk, f.eks. Anna, den travle revisor)

2. Demografi:

	•	Alder
	•	Køn (valgfrit)
	•	Lokation
	•	Beskæftigelse

3. Mål:
	•	Primære mål, som de ønsker at opnå
	•	Sekundære eller relaterede mål

4. Udfordringer/smertepunkter:
	•	Væsentlige hindringer, de står over for
	•	Frustrationer eller behov

5. Adfærd:
	•	Relevante vaner, præferencer og brugsmønstre

6. Foretrukne værktøjer/platforme:
	•	Apps, websteder og enheder, de ofte bruger

7. Et kort citat (valgfrit, men effektivt):

En sætning, der indfanger, hvordan de har det med deres behov.

(Eksempel: “Jeg vil bare have et system, der sparer mig tid uden at kræve en manual.”)

</USER_PERSONA_STRUCTURE>


Eksempel:

Navn: Anna, den travle revisor

Demografi: 34 år, bor i Chicago, statsautoriseret revisor i et mindre firma

Mål: Færdiggøre kundeopgaver hurtigere, minimere manuelle administrative opgaver

Udfordringer: For meget papirarbejde, klodset software, tidspres

Adfærd: Arbejder sent i skattesæsonen, foretrækker enkle apps, der er tilgængelige på mobilen

Foretrukne værktøjer: QuickBooks, Slack, Google Drive

Citat: “Hvis det ikke er enkelt, har jeg ikke tid til det.”


Krav til generering af personaen:

- Brug kun oplysningerne i udskrifterne, og opfind ikke oplysninger, der ikke findes der.

- Brug kun karakteristika, der findes i mindst 80 % af de udskrifter, jeg har delt med dig.

- Hvis du ikke finder tilstrækkelige oplysninger til et specifikt dataelement for personaen, skal du lade det stå tomt.

Som resultat får du en persona-beskrivelse, som du kan inkludere i dit dokument med produktkrav. Men dobbelttjek venligst det LLM-genererede indhold, da det kan indeholde fejl.

Trin 3: Inddrag funktionelle interessenter

Som vi har nævnt, udvikles de bedste PRD'er i samarbejde. Indkald til et tværfunktionelt møde for at indhente input fra forskellige områder af virksomheden, så det kan indgå i dit kravdokument. 

Dette er en god mulighed for interessenterne til at påpege eventuelle antagelser, rejse bekymringer om risici eller begrænsninger og notere eventuelle afhængigheder, der kan påvirke produktudviklingsprocessen. 

Trin 4: Definér din centrale hypotese og produktmålinger

Uanset hvilken type funktion du bygger, forventer du, at den vil have en eller anden form for indvirkning på dine brugere eller din virksomhed. For at kunne måle denne indvirkning og se, om din funktion var en succes eller ej, skal du først definere en hypotese, der kan testes.

Mit foretrukne format for en hypotese kaldes Hvis-så-fordi. Det ser sådan ud:

Vi tror, at hvis vi [udvikler funktion A], så vil [den centrale måling B] [stige/falde] med [C-mængde], fordi [forklar hvorfor].

Hvis jeg for eksempel arbejder på Spotify, kan det se sådan ud.

Vi tror, at hvis vi udvikler playlister til morgenrutiner, vil den daglige fastholdelse stige med 5 %, fordi flere mennesker vil bruge Spotify hver dag om morgenen.

Hvis du vil automatisere denne proces med AI, skal du blot forklare med dine egne ord, hvad du forventer, at funktionen skal opnå, og bede den om at formulere det i et Hvis-så-fordi-format. Her er prompten:

{indsæt din funktionsbeskrivelse her}

Formulér venligst en hypotese ved hjælp af Hvis-så-fordi-formatet.

Krav:

- Hypotesen må højst være på 100 ord.

- Brug kun den kontekst, jeg har angivet.

Når hypotesen er klar, skal du også definere de produktmålinger, du vil måle for denne funktion.

Du vil naturligvis måle den måling, som din hypotese er rettet mod (fastholdelse i Spotify-eksemplet). Men der er også 3 vigtige målinger, du har brug for til enhver funktion:

• Ibrugtagning
• Fastholdelse
• Engagement

Du kan bede AI'en om at hjælpe dig med at vælge den rigtige måling samt de hændelser, som dit analyseværktøj skal udløse for at måle disse målinger. Her er en prompt, du kan bruge til det.

{indsæt din funktionsbeskrivelse her}

Her er hypotesen:

{indsæt din hypotese fra den forrige prompt her}

Foreslå venligst målinger, der skal spores, sammen med deres hændelsesudløsere. Foreslå målinger i disse kategorier:

- Ibrugtagning

- Fastholdelse

- Engagement

Tag venligst i betragtning, at jeg vil tilføje disse målinger i produktkravsdokumentet for den funktion, jeg har beskrevet.

I vores Spotify-eksempel vil målingerne være følgende:

Ibrugtagning: % af brugerne, der startede en morgenplayliste. Hændelsesudløseren er det tidspunkt, hvor brugeren starter playlisten.

Fastholdelse: % af brugerne, der har brugt morgenplaylist'en i 7, 14 og 30 dage. Hændelsesudløseren er det tidspunkt, hvor brugeren starter playlisten.

Engagement: Det gennemsnitlige antal minutter, brugerne har lyttet til playlisten. Hændelsesudløserne er, når playlisten startes og stoppes.

Trin 5: Gør dine designs klar

Ingen PRD er komplet uden design – hvis funktionen kræver det. Nogle teams vedhæfter de endelige designs; andre foretrækker kun at inkludere overordnede koncepter eller en prototype og finpudser detaljerne senere sammen med teamet.

Begge tilgange har fordele og ulemper. Endelige designs giver klarhed, men gør leveringen af PRD'en langsommere. Tidlige koncepter fremskynder overdragelsen, men medfører risiko for fejlfortolkning og omarbejde.

Det optimale punkt? Del designs, der dækker den centrale brugerrejse og de vigtigste tilstande, og spring mindre elementer som tomme eller fejlagtige tilstande over. Heldigvis giver moderne UX-designværktøjer dig mulighed for at få både en prototype og et design på samme tid.

På den måde leverer du dit design og din PRD til teamet tidligere, samtidig med at risikoen for tvetydighed minimeres.

Trin 6: Nedbryd din idé i uafhængige funktioner

Jeg tror ikke, jeg behøver at fortælle erfarne PM'er om fordelene ved at nedbryde en stor funktion i mindre, overskuelige brugerhistorier. Hvis du er ny inden for produktledelse, er her nogle af fordelene:

• Små historier er nemmere for dit team at estimere.
• De er nemmere at levere, eftersom teamet kan fokusere på én historie ad gangen og færdiggøre dem uden besvær.
• De er hurtigere at teste, eftersom dine QA'er kan teste én historie, mens teamet arbejder på den næste – dermed paralleliseres testernes og udviklernes arbejde.
• De giver dig fleksibilitet til at fjerne de mindre vigtige fra omfanget for at fremskynde leveringen.

Det er godt at nedbryde funktionen, men det er kun halvdelen af arbejdet. Den anden halvdel er at prioritere dem. Ikke alle historier er lige vigtige. Nogle dele af din funktion udgør den centrale brugerrejse, mens andre er gode ekstra tilføjelser. I vores Spotify-eksempel vil listen over vigtige og ikke-vigtige historier se sådan ud, når MoSCoW-prioriteringsmetoden anvendes.

Når man ser på listen her, er det tydeligt, at muligheden for, at brugerne kan se morgenafspilningslisten og få adgang til den med ét tryk, er langt vigtigere end muligheden for at redigere afspilningslisten.

Så hvis du er under tidspres og har brug for at levere hurtigt, kan du fjerne brugerhistorien om redigering fra din udgivelse og flytte den til fremtidige udgivelser.

Nogle laver denne liste i et regneark. Men jeg anbefaler at bruge et specialiseret værktøj til produktroadmaps, da det også har indbyggede funktioner til prioritering og integration.

Trin 7: Definer udgivelsesstrategien

Udgivelser i det virkelige liv er sjældent så ligetil som at færdiggøre hele funktionen og sende den i produktion. Det meste af tiden er en udgivelse af en stor funktion (som er værdig til sin egen PRD) en proces i flere faser, der potentielt kan omfatte følgende:

• Udvikling af MVP-versionen, der kun indeholder de uundværlige historier, og gennemførelse af en betaudgivelse.
• Indsamling af feedback, udbedring af problemer, tilføjelse af historier, der bør med, og forberedelse til produktionsudgivelsen.
• En gradvis udgivelse i produktion i flere faser.
• Tilføjelse af funktioner, der kunne være med, hvis du kan se, at der er behov for dem.

For at fremskynde processen med at udarbejde en udgivelsesstrategi kan du bede din LLM om hjælp ved hjælp af denne prompt.

Jeg vil bygge {indsæt din funktionsforklaring her}.

Her er en liste over brugerhistorier for denne funktion, prioriteret ved hjælp af MoSCoW:

{indsæt funktionslisten fra det foregående trin her}

Opret venligst en lanceringsstrategi for den. Strategien skal:

- Gruppere funktionerne i listen ovenfor i flere udgivelser, herunder MVP-versionen.

- Hvis du finder det nødvendigt, inkludere en betafase

- Hvis du finder det nødvendigt, have en gradvis udrulning med 2 eller flere faser, herunder deres tidsplaner, procentdelen af brugere, der skal inkluderes i faserne, samt en beskrivelse af de typer brugere, der skal inkluderes i hver udrulningsfase.

Kriterier for at afgøre, om en betaversion er nødvendig (i CSV-format, afgrænset af XML-tags):

<BETA_RELEASE_CRITERIA>

Kriterium,Betaversion,Direkte produktionsudgivelse

Brugerrisiko,Mellem til høj – usikker bruger påvirkning eller potentielle regressioner,Lav – funktionen er grundigt testet og indebærer lav risiko for brugerne

Funktionens modenhed,MVP eller eksperimentel; kan mangle finpudsning eller en komplet brugeroplevelse,Fuldt udviklet og stabil

Behov for feedback,Højt – tidlig brugerfeedback er afgørende for at validere retningen eller valg af brugeroplevelse,Lavt – der er tillid til funktionens værdi og brugervenlighed

QA-tillid,Moderat – kræver test i den virkelige verden som supplement til intern QA,Høj – grundigt testet internt

Usikkerhed om forretningspåvirkning,Det er uklart, om den vil påvirke vigtige KPI'er (fastholdelse, konvertering osv.),Forventet positiv eller neutral påvirkning understøttet af tidligere validering

</BETA_RELEASE_CRITERIA>

Kriterier for at afgøre, om en gradvis udgivelse er nødvendig (i CSV-format, afgrænset af XML-tags):

<GRADUAL_RELEASE_CRITERIA>

Kriterium,Gradvis udgivelse,Fuld øjeblikkelig udgivelse

Brugerrisiko,Høj – funktionen kan forårsage regressioner, fejl eller forvirring, hvis den rulles bredt ud,Lav – minimal forstyrrelse for brugerne, selv hvis der opstår uventede problemer

Risiko for systembelastning,Høj – funktionen kan øge belastningen på servere eller backend; ukendt skaleringsadfærd,Lav – ydeevnen er valideret under forventede spidsbelastningsforhold

Ændringens omfang,Stort – berører kritiske stier, centrale brugeroplevelsesforløb eller backend-logik,Lille – selvstændig, valgfri eller begrænset i omfang

Overvågningsberedskab,Metrikker, alarmer og logfiler er klar til at registrere problemer i små brugergrupper,Ikke væsentligt – lav risiko for ubemærkede fejl eller regressioner, der er svære at opdage

Kompleksitet ved tilbageførsel,Høj – svært at tilbageføre, når den først er fuldt udgivet (f.eks. skema-migreringer eller dataændringer),Lav – let at deaktivere eller rette, hvis noget går galt

</GRADUAL_RELEASE_CRITERIA>

Det er højst sandsynligt, at de tidsplaner, som LLM'en gav dig, vil være urealistiske. Du er derfor velkommen til at ændre dem baseret på dit teams kapacitet og dine produktmål.

Trin 8: Udarbejd PRD'en

Ved hjælp af de oplysninger, der blev indsamlet i det foregående trin, kan du nu udarbejde PRD'en.

Igen vil vi for at spare tid bede vores valgte LLM om at gøre det for os ved hjælp af denne prompt.

Opret venligst et produktkravsdokument ved hjælp af denne struktur (afgrænset af XML-tags):


<PRD_STRUCTURE>

1. Målsætning

    - Vision
    - Mål
    - Persona(er)

2. Funktioner (tabel med følgende kolonner)

    - Kort navn på brugerhistorie
    - Kort beskrivelse af brugerhistorie
    - Prioritet for brugerhistorie

3. Brugerflow og design

    - Indsæt pladsholderteksten "indsæt dine links til brugerrejse og design her"

4. Lanceringsstrategi

    - Udgivelsesfaser med omfang. Inkluder en betaversion, hvis jeg har angivet en i lanceringskonteksten nedenfor
    - strategi for gradvis udrulning, hvis jeg har angivet en i lanceringskonteksten nedenfor. Hvis gradvis udrulning er relevant, skal du inkludere procentdelen af brugere, der skal inkluderes i faserne, samt en beskrivelse af de typer brugere, der skal inkluderes i hver udrulningsfase.

5. Analyse

    - Centrale hypoteser
(tabel med disse kolonner)
    - Metrik
    - Målændring
    - Hændelsesudløser

</PRD_STRUCTURE>


Brug venligst disse kontekstelementer til at generere PRD'en (afgrænset af XML-tags):

<USER_PERSONAS>

{indsæt beskrivelse af persona her}

</USER_PERSONAS>


<CORE_HYPOTHESIS>

{kopiér og indsæt den centrale hypotese fra de foregående trin her}

</CORE_HYPOTHESIS>


<KEY_METRICS>

{kopiér og indsæt listen over nøglemetrikker fra de foregående trin her}

</KEY_METRICS>


<USER_STORIES>

{kopiér og indsæt listen over brugerhistorier fra de foregående trin her}

</USER_STORIES>


<RELEASE_STRATEGY>

{kopiér og indsæt lanceringsstrategien fra de foregående trin her}

</RELEASE_STRATEGY>

Det eneste, du mangler, er hurtigt at gennemgå PRD-indholdet. Vær især opmærksom på visionen og målene, da LLM'en vil forsøge at generere dem ud fra dine funktionsbeskrivelser. Hvis du ikke bryder dig om dem, kan du frit redigere dem.

Trin 9: Indhent godkendelse

Når PRD'en er færdig, skal du sørge for, at den bliver godkendt af kunden. For et internt projekt kan det være projektsponsoren eller den øverste ledelse. Det er med til at sikre forretningsmæssig overensstemmelse og opbakning til produktudviklingsprocessen. 

Det er afgørende at få lanceringskriterierne accepteret, så der ikke opstår misforståelser om præcis, hvad produktet vil kunne gøre med hensyn til funktionalitet, brugervenlighed og ydeevne ved afslutningen af udviklingsprocessen.

Trin 10: Del og kommunikér

Efter at PRD'en er blevet godkendt, skal du oplyse, hvor PRD'en vil blive opbevaret, og kommunikere processen for at få adgang til, se og ændre PRD'en under produktudviklingsprocessen. 

Den færdige PRD bør bruges som referencepunkt gennem hele projektet og kan opdateres i realtid, hvis kravene ændrer sig. Der bør dog altid være en måde at identificere, hvad der oprindeligt blev aftalt, og alle ændringer bør dokumenteres grundigt og ledsages af en begrundelse for ændringen.

Bedste praksis for dokumenter med produktkrav

Forhåbentlig har vi nu gjort det helt klart, hvad et PRD bør indeholde, så lad os se nærmere på nogle bedste praksisser for at udarbejde det.

• Få input fra interessenter. De bedste PRD'er udarbejdes med input fra alle centrale interessenter. Det giver ingen mening at oprette en lang liste over kritisk funktionalitet, hvis ingeniørerne blot forklarer, at den ikke kan understøttes. Ved at inddrage andre teams tidligt skabes der klarhed, og antagelser, begrænsninger og afhængigheder kan identificeres.
• Udnyt moderne værktøjer. Heldigvis findes der mange softwareorienterede dokumentationsværktøjer, som hjælper os med at oprette og administrere PRD'er. Notion indeholder for eksempel færdige PRD-skabeloner, som du kan bruge sammen med tabeller med avanceret formatering, hvor du kan angive dine antagelser eller funktioner. Confluence leveres derimod med indbygget integration til Jira og BitBucket, så du kan indlejre opgaver og udgivelser i dokumentet.

• Iterér efter behov. PRD'et er beregnet til at være et levende dokument. Ændrede kunde- eller markedskrav kan betyde, at produktets funktioner skal udvides, omprioriteres eller helt droppes. Tidsplanen skal muligvis komprimeres for at sikre en position som først på markedet eller forlænges, hvis en antagelse ikke holder.

• Brug versionsstyring. Selvom det er vigtigt, at PRD'et gennemgås og ændres efter behov, er det afgørende, at produktchefen altid kan se, hvad der oprindeligt blev aftalt. Ved at bruge versionsstyring og sikre passende adgangsniveauer er der altid en oversigt over, hvad der historisk blev aftalt, hvad der er blevet ændret, og hvorfor.

• Hold det synligt. Et PRD er ikke et engangsdokument, der smides i en skrivebordsskuffe efter projektplanlægningsmødet – det er et kritisk aktiv i projektledelsen. Som vi har diskuteret, fungerer dit PRD som et referencepunkt for alle teammedlemmer, der arbejder på produktet, så det er afgørende, at det holdes synligt. 

Skabelon til dokument med produktkrav

For at afslutte dette får du her en PRD-skabelon, som du kan bruge til at komme i gang med at udarbejde dit første dokument med produktkrav i dag. 

Sørg for at tilpasse den, så den passer til dit projekts behov, og tilføj eller fjern afsnit efter behov for at skabe klarhed.

Skabelon til dokument med produktkrav

Få klarhed over dine produktkrav i dag

Hvis du trofast har arbejdet dig gennem oplysningerne ovenfor, er du godt på vej til at skabe et fremragende dokument med produktkrav.

Selvom det kan tage lidt tid i starten, er fordelene indsatsen værd, og vores eksempelskabelon kan hjælpe dig med at planlægge og udvikle dit næste fantastiske produkt.

Vi er et fællesskab af produktfolk (ligesom dig!), så hvis du fandt disse oplysninger nyttige, kan du tilmelde dig vores nyhedsbrev. Vi holder dig opdateret med nyttige artikler, vejledninger, anmeldelser af værktøjer og meget mere.