Skrive et produktkravdokument: komplett veiledning i 10 trinn + skriveinstruksjoner for KI

Hvorfor er dokumenter med produktkrav (eller PRD-er) så viktige verktøy for produktteam? Fordi selv om du kan se for deg produktets fremtidige tilstand så tydelig, vil ingen interessenter oppfatte den på helt samme måte.

Jeg er sikker på at det finnes en million skrekkhistorier der ute om produktledere som ikke innså hvor ineffektivt de hadde kommunisert de kritiske elementene i et nytt produkt eller en ny funksjon, før det var for sent. 

Det er derfor et dokument med produktkrav (PRD) er så viktig. Det bruker en detaljert og systematisk tilnærming for å få alle til å være enige om hvordan suksess bør se ut.

I denne veiledningen hjelper vi deg med å lage et fantastisk PRD med tydelige mål, krav og en gjennomtenkt handlingsplan. For å hjelpe deg med å spare verdifull tid har vi dessuten et sett med LLM-instruksjoner som vil generere det meste av PRD-et for deg (eller i det minste gi deg et solid førsteutkast!).

Hva er et dokument med produktkrav (PRD)?

Enkelt sagt beskriver et dokument med produktkrav funksjonene og egenskapene som må inkluderes i en bestemt produktlansering. Det er et sentralt referansepunkt for alle team som er involvert i utformingen og utviklingen av et bestemt produkt. Det er også avgjørende for utarbeidelsen av produktveikartet.

Det brukes tradisjonelt i et prosjektmiljø med fossefallsmetodikk – der produktutviklingsprosessen er sekvensiell – men kan også brukes i smidig produktledelse.

Flere andre dokumenter kan opprettes basert på informasjonen som er samlet inn i PRD-et. Ingeniøravdelingen kan lage et dokument med tekniske krav som beskriver produktspesifikasjonene og systemkravene.

Forretningsanalytikere kan lage et dokument med funksjonelle krav som beskriver hva som skjer når en bruker samhandler med systemet, inkludert trådskisser som viser produktdesignet. 

Brukeropplevelses designere (UX-designere) kan lage et dokument med krav til brukergrensesnittet som forklarer hvordan produktet skal se ut og oppleves.

Hva er fordelene ved å skrive et PRD, og hva inneholder det?

Det er flere fordeler ved å investere tid i å skrive et fullstendig PRD. La oss se på noen av dem:

1. Det får alle interessenter til å være enige.
2. Det tydeliggjør hva som er utenfor omfanget
3. Det fremmer samarbeid mellom team
4. Det setter kundens perspektiv i sentrum for produktet

Når det gjelder strukturen, bør en typisk PRD inneholde følgende:

• Dokumentmetadata, for eksempel redigeringsdato, versjonshistorikk osv.
• Produktmålene du ønsker å oppnå.
• Data fra kundeundersøkelser, for eksempel målpersonas.
• En prioritert liste over funksjoner du ønsker å utvikle.
• Det negative omfanget for funksjonene du ikke skal utvikle.
• Kjernemåltall for å teste disse hypotesene.
• Kjernehypotesene som funksjonene dine tester.
• Lanseringsstrategi som viser når og hvordan funksjonen skal lanseres.

Selv om de fleste PRD-er vil inneholde disse elementene, er det helt greit å legge til eller fjerne elementer basert på behovene dine og produktets virkelighet.

Hva er et eksempel på et produktkravdokument?

Noen ganger er det enklere å forstå hva som må inkluderes i et dokument ved hjelp av en visuell fremstilling, så her er et eksempel på en ferdig PRD.

Slik skriver du et produktkravdokument (med litt hjelp fra LLM-er)

Selv med all informasjonen vi allerede har delt, kan det føles overveldende å sette sammen din første PRD. Ikke bekymre deg – vi hjelper deg! Her er sjekklisten vår i 10 trinn for bruk av AI i kravinnsamling og for å lage en bunnsolid PRD. I tillegg har vi tatt med en mal som hjelper deg med å samle inn all riktig informasjon.

Trinn 1: Få klarhet i problemet

Før du gjør noe annet, er det avgjørende at du har klart for deg hvilket problem du prøver å løse, og hvilke brukerpersonas du prøver å løse det for. Dette vil påvirke nøyaktig hvilken funksjonalitet du inkluderer i produktet, og hvilke funksjoner du prioriterer for lanseringen. 

Dokumentet for forretningskrav (BRD) bør inneholde en behovsbeskrivelse som beskriver problemet man står overfor, og hvordan produktet bør handle for å løse dette problemet. Det er viktig å gå gjennom BRD-en og få klarhet i nøyaktig hva virksomheten trenger fra produktet før du utarbeider PRD-en.

Trinn 2: Gå gjennom markeds- og brukerundersøkelser

Innen du skriver en PRD, bør du allerede ha markedsundersøkelsene og personaene dine klare. Men noen ganger kan personaen for en bestemt funksjon avvike fra den generelle personaen du har. Hvis det gjelder deg, kan vi derfor generere en personabeskrivelse ved hjelp av denne LLM-ledeteksten:

Her er utskrifter fra flere intervjuer om produktoppdagelse som jeg har gjennomført med brukerne mine.

{last opp utskriftene dine som txt-filer i denne meldingen}

Gå gjennom disse utskriftene, analyser fellestrekkene blant dem og generer en personabeskrivelse i henhold til denne strukturen (avgrenset med XML-tagger):


<USER_PERSONA_STRUCTURE>

1. Navn:

(Fiktivt, men realistisk, for eksempel Anna, den travle regnskapsføreren)

2. Demografi:

	•	Alder
	•	Kjønn (valgfritt)
	•	Bosted
	•	Yrke

3. Mål:
	•	Primære mål de ønsker å oppnå
	•	Sekundære eller relaterte mål

4. Utfordringer/smertepunkter:
	•	Viktige hindringer de møter
	•	Frustrasjoner eller behov

5. Atferd:
	•	Relevante vaner, preferanser og bruksmønstre

6. Foretrukne verktøy/plattformer:
	•	Apper, nettsteder og enheter de ofte bruker

7. Et kort sitat (valgfritt, men virkningsfullt):

Én setning som fanger opp hvordan de føler det rundt behovene sine.

(Eksempel: «Jeg vil bare ha et system som sparer meg for tid uten at jeg trenger en bruksanvisning.»)

</USER_PERSONA_STRUCTURE>


Eksempel:

Navn: Anna, den travle regnskapsføreren

Demografi: 34 år, bor i Chicago, statsautorisert regnskapsfører i et lite firma

Mål: Fullføre kundeoppgaver raskere, minimere manuelle administrative oppgaver

Utfordringer: For mye papirarbeid, tungvint programvare, tidspress

Atferd: Jobber lange dager i skattesesongen, foretrekker enkle apper som er tilgjengelige på mobil

Foretrukne verktøy: QuickBooks, Slack, Google Drive

Sitat: «Hvis det ikke er enkelt, har jeg ikke tid til det.»


Krav til generering av persona:

- Bruk bare informasjonen som er oppgitt i utskriftene, og ikke finn på informasjon som ikke finnes der.

- Bruk bare egenskaper som finnes i minst 80 % av utskriftene jeg har delt med deg.

- Hvis du ikke finner nok informasjon om et bestemt element i personaen, skal du la det stå tomt.

Som et resultat får du en personabeskrivelse som du kan inkludere i produktkravdokumentet ditt. Men dobbeltsjekk det KI-genererte innholdet, siden det kan inneholde feil.

Steg 3: Involver funksjonelle interessenter

Som vi har nevnt, utvikles de beste PRD-ene i samarbeid. Kall inn til et tverrfunksjonelt møte for å innhente innspill fra ulike deler av virksomheten, slik at du kan bruke dem i kravdokumentet ditt. 

Dette er en god anledning for interessentene til å påpeke eventuelle antakelser, ta opp bekymringer rundt risikoer eller begrensninger og notere eventuelle avhengigheter som kan påvirke produktutviklingsprosessen. 

Steg 4: Definer hovedhypotesen og produktmålingene

Uansett hvilken type funksjon du utvikler, forventer du at den skal ha en eller annen innvirkning på brukerne eller virksomheten din. For å kunne måle denne innvirkningen og se om funksjonen var vellykket eller ikke, må du først definere en testbar hypotese.

Mitt favorittformat for en hypotese kalles Hvis–så–fordi. Det ser slik ut:

Vi tror at hvis vi [utvikler funksjon A], vil [kjernemåling B] [øke/reduseres] med [C mengde], fordi [forklar hvorfor].

Hvis jeg for eksempel jobber med Spotify, kan det se slik ut.

Vi tror at hvis vi utvikler spillelister for morgenrutiner, vil den daglige brukerbevaringen øke med 5 %, fordi flere vil bruke Spotify hver dag om morgenen.

For å automatisere denne prosessen med KI forklarer du ganske enkelt med dine egne ord hva du forventer at funksjonen skal oppnå, og ber KI-en formulere det i et Hvis–så–fordi-format. Her er ledeteksten:

{sett inn beskrivelsen av funksjonen din her}

Formuler en hypotese ved hjelp av Hvis–så–fordi-formatet.

Krav:

- Hypotesen skal ikke være lengre enn 100 ord.

- Bruk bare konteksten jeg har oppgitt.

Når hypotesen er klar, må du også definere produktmålingene du ønsker å måle for funksjonen.

Selvsagt ønsker du å måle den målingen hypotesen din retter seg mot (brukerbevaring i Spotify-eksempelet). Men det finnes også tre nøkkelmålinger du trenger for enhver funksjon:

• Adopsjon
• Brukerbevaring
• Engasjement

Du kan be KI-en hjelpe deg med å velge riktig måling, samt hendelsene som analyseverktøyet ditt bør utløse for å måle disse målingene. Her er en ledetekst du kan bruke:

{sett inn beskrivelsen av funksjonen din her}

Her er hypotesen:

{sett inn hypotesen fra den forrige ledeteksten her}

Foreslå målinger som bør følges opp, sammen med hendelsesutløserne deres. Foreslå målinger innenfor disse kategoriene:

- Adopsjon

- Brukerbevaring

- Engasjement

Ta hensyn til at jeg skal legge disse målingene inn i produktkravdokumentet for funksjonen jeg har beskrevet.

I Spotify-eksempelet vårt ville målingene vært følgende:

Adopsjon: % av brukerne som startet en morgen-spilleliste. Hendelsesutløseren er tidspunktet da brukeren starter spillelisten.

Brukerbevaring: % av brukerne som har brukt morgen-spillelisten i 7, 14 og 30 dager. Hendelsesutløseren er tidspunktet da brukeren starter spillelisten.

Engasjement: Gjennomsnittlig antall minutter brukerne har lyttet til spillelisten. Hendelsesutløserne er når spillelisten startes og stoppes.

Steg 5: Gjør designene dine klare

Ingen PRD-er er komplette uten design – hvis funksjonen trenger det. Noen team legger ved ferdige design, mens andre foretrekker å bare inkludere konsepter på høyt nivå eller en prototype og finpusse detaljene senere sammen med teamet.

Begge tilnærmingene har fordeler og ulemper. Ferdige design gir klarhet, men gjør leveringen av PRD-en tregere. Tidlige konsepter gjør overleveringen raskere, men innebærer risiko for feiltolkning og omarbeiding.

Det ideelle kompromisset? Del design som dekker den sentrale brukerreisen og de viktigste tilstandene, og hopp over mindre elementer som tomtilstander eller feiltilstander. Heldigvis lar moderne UX-designverktøy deg lage både en prototype og et design samtidig.

På denne måten leverer du designet og PRD-en til teamet tidligere, samtidig som du minimerer risikoen for uklarheter.

Steg 6: Bryt ned ideen din i uavhengige funksjoner

Jeg tror ikke jeg trenger å fortelle erfarne PM-er om fordelene ved å bryte ned en stor funksjon i mindre, mer håndterbare brukerhistorier. Hvis du er ny innen produktledelse, er her noen av fordelene:

• Små historier er enklere for teamet å estimere.
• De er enklere å levere, siden teamet kan fokusere på én historie om gangen og fullføre dem uten problemer.
• Raskere å teste, siden QA-teamet kan teste én historie mens teamet utvikler den neste – noe som gjør at testere og utviklere kan arbeide parallelt.
• Gir deg fleksibilitet til å fjerne de minst viktige fra omfanget for å fremskynde leveringen.

Det er bra å bryte ned funksjonen, men det er bare halve jobben. Den andre halvdelen er å prioritere dem. Ikke alle historier er like viktige. Noen deler av funksjonen representerer den sentrale brukerreisen, mens andre er nyttige tillegg. I Spotify-eksempelet vårt vil listen over viktige og uviktige historier se slik ut når vi bruker MoSCoW-prioriteringsmetoden.

Når vi ser på listen her, er det tydelig at muligheten for brukerne til å se morgen-spillelisten og åpne den med ett trykk er langt viktigere enn muligheten til å redigere spillelisten.

Hvis du derfor har begrenset tid og må lansere raskt, kan du fjerne brukerhistorien for redigering fra lanseringen og flytte den til fremtidige lanseringer.

Noen lager denne listen i et regneark. Men jeg anbefaler å bruke et spesialisert verktøy for produktveikart, siden det også har innebygde funksjoner for prioritering og integrasjoner.

Steg 7: Definer lanseringsstrategien

Lanseringer i virkeligheten er sjelden så enkle som å fullføre hele funksjonen og levere den til produksjon. Som oftest er en lansering av en stor funksjon (som er omfattende nok til å ha sin egen PRD) en prosess i flere faser, som potensielt kan omfatte følgende:

• Utvikle MVP-versjonen, som bare inneholder de nødvendige historiene, og gjennomføre en betalansering.
• Samle inn tilbakemeldinger, løse problemene, legge til historiene som bør være med og forberede produksjonslanseringen.
• Gjennomføre en gradvis produksjonslansering i flere faser.
• Legge til funksjonene som kan være med, hvis du ser at det er behov for dem.

For å fremskynde prosessen med å lage en lanseringsstrategi kan du be LLM-en din om hjelp ved å bruke denne ledeteksten.

Jeg vil bygge {sett inn funksjonsforklaringen din her}.

Her er en liste over brukerhistorier for denne funksjonen, prioritert ved hjelp av MoSCoW:

{sett inn funksjonslisten fra forrige trinn her}

Opprett en lanseringsstrategi for den. Strategien skal:

- Gruppere funksjonene i listen ovenfor i flere lanseringer, inkludert MVP-versjonen.

- Hvis du finner det nødvendig, ha en betalanseringsfase

- Hvis du finner det nødvendig, ha en gradvis utrulling med 2 eller flere faser, inkludert tidslinjene deres, prosentandelen brukere som skal få utrullingen i fasene, samt en beskrivelse av hvilke typer brukere som skal inkluderes i hver utrullingsfase.

Kriterier for å avgjøre om beta-lansering er nødvendig (i CSV-format, avgrenset med XML-tagger):

<BETA_RELEASE_CRITERIA>

Kriterium,Betalansering,Direkte produksjonslansering

Brukerrisiko,Middels til høy – usikker brukerpåvirkning eller mulige regresjoner, lav – funksjonen er godt testet og medfører lav risiko for brukerne

Funksjonsmodenhet,MVP eller eksperimentell; kan mangle finpussing eller komplett UX,Ferdig utviklet og stabil

Behov for tilbakemeldinger,Høyt – tidlige tilbakemeldinger fra brukere er avgjørende for å validere retning eller UX-valg,lavt – det er høy tillit til funksjonens verdi og brukervennlighet

QA-tillit,Middels – trenger testing i virkelige situasjoner for å supplere intern QA,Høy – grundig testet internt

Usikkerhet rundt forretningspåvirkning,Det er uklart om den vil påvirke viktige KPI-er (bevaring, konvertering osv.),Forventet positiv eller nøytral påvirkning, støttet av tidligere validering

</BETA_RELEASE_CRITERIA>

Kriterier for å avgjøre om gradvis lansering er nødvendig (i CSV-format, avgrenset med XML-tagger):

<GRADUAL_RELEASE_CRITERIA>

Kriterium,Gradvis lansering,Full umiddelbar lansering

Brukerrisiko,Høy – funksjonen kan forårsake regresjoner, feil eller forvirring hvis den rulles ut bredt,Lav – minimal brukerforstyrrelse selv om uventede problemer oppstår

Risiko for systembelastning,Høy – funksjonen kan øke belastningen på servere eller baksystemer; ukjent skaleringsatferd,Lav – ytelsen er validert under forventede toppbelastninger

Endringens omfang,Stort – berører kritiske stier, sentrale UX-flyter eller logikk i baksystemet,Lite – selvstendig, valgfritt eller begrenset i omfang

Beredskap for overvåking,Målinger, varsler og logger er klare til å oppdage problemer i små brukergrupper,Ikke avgjørende – lav risiko for skjulte feil eller regresjoner som er vanskelige å oppdage

Kompleksitet ved tilbakerulling,Høy – vanskelig å reversere etter full lansering (f.eks. skjemamigreringer og dataendringer),Lav – enkelt å deaktivere eller rette hvis noe går galt

</GRADUAL_RELEASE_CRITERIA>

Mest sannsynlig vil tidslinjene som LLM-en ga deg, være urealistiske. Du må derfor gjerne endre dem basert på teamets kapasitet og produktmålene dine.

Trinn 8: Utarbeid PRD-en

Ved hjelp av informasjonen som ble samlet inn i forrige trinn, kan du nå utarbeide PRD-en.

Igjen, for å spare tid ber vi den valgte LLM-en om å gjøre det for oss ved hjelp av denne ledeteksten.

Opprett et produktkravdokument ved hjelp av denne strukturen (avgrenset med XML-tagger):


<PRD_STRUCTURE>

1. Mål

    - Visjon
    - Målsettinger
    - Persona(er)

2. Funksjoner (tabell med følgende kolonner)

    - Kort navn på brukerhistorie
    - Kort beskrivelse av brukerhistorie
    - Prioritet for brukerhistorie

3. Brukerflyt og design

    - La det stå en plassholdertekst her "sett inn lenker til brukerreisen og designet her"

4. Lanseringsstrategi

    - Lanseringsfaser med omfang. Inkluder betalansering hvis jeg har oppgitt en i lanseringskonteksten nedenfor
    - strategi for gradvis utrulling hvis jeg har oppgitt en i lanseringskonteksten nedenfor. Hvis gradvis utrulling er relevant, inkluder prosentandelen brukere som skal få utrullingen i fasene, samt en beskrivelse av hvilke typer brukere som skal inkluderes i hver utrullingsfase.

5. Analyse

    - Kjernehypoteser
(tabell som inneholder disse kolonnene)
    - Måling
    - Målendring
    - Utløsende hendelse

</PRD_STRUCTURE>


Bruk disse kontextelementene når du genererer PRD-en (avgrenset med XML-tagger):

<USER_PERSONAS>

{sett inn beskrivelsen av personaen her}

</USER_PERSONAS>


<CORE_HYPOTHESIS>

{kopier og lim inn kjernehypotesen fra de forrige trinnene her}

</CORE_HYPOTHESIS>


<KEY_METRICS>

{kopier og lim inn listen over nøkkelmålinger fra de forrige trinnene her}

</KEY_METRICS>


<USER_STORIES>

{kopier og lim inn listen over brukerhistorier fra de forrige trinnene her}

</USER_STORIES>


<RELEASE_STRATEGY>

{kopier og lim inn lanseringsstrategien fra de forrige trinnene her}

</RELEASE_STRATEGY>

Det eneste du har igjen å gjøre, er å gjennomgå PRD-innholdet raskt. Vær spesielt oppmerksom på visjon og målsettinger, siden LLM-en vil forsøke å generere dette basert på funksjonsbeskrivelsene dine. Hvis du ikke liker dem, kan du gjerne redigere dem.

Trinn 9: Sikre godkjenning

Når PRD-en er ferdig, må du sørge for at den blir godkjent av kunden. For et internt prosjekt kan dette være prosjekteieren eller den øverste ledelsen. Dette bidrar til å sikre forretningsmessig samsvar og støtte til produktutviklingsprosessen. 

Det er svært viktig å få lanseringskriteriene godkjent, slik at det ikke oppstår misforståelser om nøyaktig hva produktet vil kunne gjøre når det gjelder funksjonalitet, brukervennlighet og ytelse ved slutten av utviklingsprosessen.

Trinn 10: Del og kommuniser

Etter at PRD-en er godkjent, må du informere om hvor PRD-en skal lagres, og kommunisere prosessen for tilgang til, visning av og endring av PRD-en under produktutviklingsprosessen. 

Den ferdigstilte PRD-en bør brukes som et referansepunkt gjennom hele prosjektet og kan oppdateres i sanntid hvis kravene endres. Det bør imidlertid alltid finnes en måte å identifisere det som opprinnelig ble avtalt på, og alle endringer bør dokumenteres grundig og ledsages av en begrunnelse for endringen.

Beste fremgangsmåter for dokumenter med produktkrav

Forhåpentligvis har vi avklart nøyaktig hva en PRD bør inneholde, så la oss se nærmere på noen fremgangsmåter for å utarbeide den.

• Innhent innspill fra interessentene. De beste PRD-ene utarbeides med innspill fra alle sentrale interessenter. Det er ingen vits i å lage en lang liste over kritisk funksjonalitet bare for at ingeniørene skal forklare at den ikke kan støttes. Ved å involvere andre team tidlig skaper man klarhet og gjør det mulig å identifisere antakelser, begrensninger og avhengigheter.
• Utnytt moderne verktøy. Heldigvis finnes det mange programvareorienterte dokumentasjonsverktøy som hjelper oss med å opprette og administrere PRD-er. Notion inkluderer for eksempel ferdige PRD-maler som du kan bruke sammen med tabeller med avansert formatering, der du kan føre opp antakelsene eller funksjonene dine. Confluence leveres på sin side med innebygd integrasjon med Jira og BitBucket, slik at du kan bygge inn oppgaver og utgivelser i dokumentet.

• Iterer etter behov. PRD-en skal være et levende dokument. Endrede kunde- eller markedskrav kan bety at produktets funksjonalitet må utvides, omprioriteres eller forkastes helt. Tidsplanen må kanskje komprimeres for å sikre en posisjon som først ute i markedet, eller forlenges dersom en antakelse ikke blir realisert.

• Bruk versjonskontroll. Selv om det er viktig at PRD-en gjennomgås og endres etter behov, er det avgjørende at produktsjefen alltid kan se hva som opprinnelig ble avtalt. Ved å bruke versjonskontroll og sørge for riktige tilgangsnivåer finnes det alltid en oversikt over hva som historisk er avtalt, hva som er endret, og hvorfor.

• Hold den synlig. En PRD er ikke et dokument som skrives én gang og deretter legges i en skrivebordsskuff etter planleggingsmøtet for prosjektet – den er en viktig ressurs for prosjektstyringen. Som vi har diskutert, fungerer PRD-en som et referansepunkt for alle teammedlemmene som arbeider med produktet, så det er avgjørende at den holdes synlig. 

Mal for dokument med produktkrav

For å avslutte dette får du her en PRD-mal som du kan bruke til å begynne å utarbeide ditt første dokument med produktkrav allerede i dag. 

Sørg for å tilpasse den til prosjektets behov, og legg til eller fjern deler etter behov for å skape klarhet.

Mal for dokument med produktkrav

Få klarhet i produktkravene dine i dag

Hvis du har jobbet deg grundig gjennom informasjonen ovenfor, er du allerede godt på vei til å lage et fremragende dokument med produktkrav.

Selv om det kan ta litt tid i begynnelsen, er fordelene verdt innsatsen, og eksempelmalen vår kan hjelpe deg med å planlegge og utvikle ditt neste flotte produkt.

Vi er et fellesskap av produktfolk (akkurat som deg!), så hvis du syntes denne informasjonen var nyttig, abonner på nyhetsbrevet vårt. Vi holder deg oppdatert med nyttige artikler, veiledninger, verktøyanmeldelser og mer.