Gå til innholdet
Nodary
Start gratis

Mal for produktkrav­dokument (PRD)

Seks lenkede dokumenter som tar en funksjon fra problemet til lanseringen: hvem den er for, hva den må gjøre, hvordan flyten ser ut, hvordan du vet at den virket, og hver beslutning underveis. Last dem ned som Markdown-filer: de åpnes i hvilken som helst editor, viser diagrammet sitt på GitHub og i Obsidian, og importeres til Nodary som et kart.

Last ned malenÅpne live-demoen

6 Markdown-filer i en .zip, 6 kB

Gratis, uten konto og uten e-post. Bruk den, endre den, del den.

ProduktkravdokumentBrukere og bevisKravDesign og flytLansering og måltallBeslutninger og åpne spørsmål

Les hver side før du laster ned

Oversikten får plass på én skjerm og lenker til fem deler, så utvikling, design og support finner hver sin side og en endring forblir liten. Kursive linjer sier hva du skal skrive; eksemplene følger én og samme eksempelfunksjon, delingslenker som utløper.

Dokumenter

Fil PRD-mal/Produktkravdokument.md

Produktkravdokument

Slik bruker du malen: kursive linjer er veiledning. Erstatt dem med dine egne ord, og slett dem deretter. Verdier i hakeparentes fyller du ut. Hold denne siden på én skjerm: det er den en travel leser, en ny kollega eller en AI-agent leser først.

Kort fortalt

FeltDenne funksjonen
Funksjon[Navn]
I én setning[Hva brukeren kan gjøre når den er sluppet]
Produkteier[navn]
Teknisk ansvarlig[navn]
Designansvarlig[navn]
Status[utkast, under gjennomgang, godkjent, sluppet]
Planlagt versjon[dato eller versjon]

Problem

Hvem som har problemet, hva det koster dem i dag, og hvordan du vet det. Et problem uten bevis er en gjetning: lenk til researchen i Brukere og bevis.

Eksempel (en eksempelfunksjon): Folk deler et dokument med en kunde til gjennomgang og glemmer så at lenken finnes. Måneder senere åpner den seg fortsatt. Tre kunder spurte forrige kvartal hvordan man får en lenke til å slutte å virke på en bestemt dato.

[Problemet, i to eller tre setninger]

Mål og ikke-mål

Målene sier hva som endres for brukeren, ikke hva teamet bygger. Ikke-målene er beslutningene som hindrer omfanget i å vokse i det stille.

  • Mål: [hva brukeren kan gjøre, eller ikke lenger må gjøre]
  • Mål: [...]
  • Ikke-mål: [hva denne versjonen bevisst lar være]
  • Ikke-mål: [...]

Suksess på én linje

Det ene målet som en måned etter lansering sier om det virket. Hele listen står i Lansering og måltall.

[Mål] går fra [utgangsverdi] til [ønsket verdi] innen [dato].

Resten av PRD-en

Hver del er et eget dokument. Lenk til den i stedet for å kopiere, så hvert faktum finnes og endres på ett sted.

Malen er fri til å bruke, endre og dele. Den kommer fra Nodary, der filene importeres som et kart av lenkede dokumenter.

Last ned malen6 Markdown-filer i en .zip, 6 kB

Slik bruker du den

  1. Skriv problemet før løsningen

    Fyll først ut oversiktens problem, mål og ikke-mål, sammen med utvikleren og designeren som skal bygge funksjonen. Er dere tre ikke enige om problemet, stopp der.

  2. Gjør hvert skal-krav testbart

    Gi hvert skal-krav akseptkriterier som noen andre kan sjekke. Et krav ingen kan teste, er et ønske.

  3. Få den gjennomgått, og hold den sann

    Be om gjennomgang når kravene er klare, og oppdater PRD-en når en beslutning endrer dem. En PRD som stopper ved oppstart, er feil ved lansering.

  4. Skriv ned hva som endret seg og hvorfor

    Hver beslutning går i beslutningsloggen med hvem som tok den. Når noen spør hvorfor funksjonen virker slik, er svaret én lenke unna.

Importer den til Nodary som et kart

Nodary er et AI-nativt arbeidsområde der et teams dokumenter lenkes i stedet for å hope seg opp. Importer .zip-filen, så kommer PRD-en med de fem delene sine under seg, lenkene mellom sidene beholdt og diagrammet tegnet. Sett den under gjennomgang og be en eier eller administrator av arbeidsområdet eller prosjektet godkjenne den, se hva som er endret siden ditt forrige besøk, og la AI-agenter koblet til via MCP lese kravene før de skriver kode mot dem.

  1. Åpne kartet til et prosjekt og velg «Importer».
  2. Velg fanen «Mappe eller ZIP», og deretter «Velg en ZIP-fil».
  3. Velg den nedlastede filen, sjekk trestrukturen og importer.

Free-planen rommer ti dokumenter per arbeidsområde, prosjektets egen side medregnet: malens seks får plass i et nytt arbeidsområde med rom for tre til. Nodary har også en innebygd produktspesifikasjon (PRD) på én side.

Nodary for produkt- og utviklingsteam
En live tavlevisning i Nodary som grupperer dokumenter etter status (utkast, under gjennomgang, ferdig, blokkert), hvert kort med ansvarlig og frist; eksempelprosjektet som vises, er et spill.

Skrive en PRD teamet faktisk bruker

En PRD mislykkes på to måter: den beskriver en løsning ingen har stilt spørsmål ved, eller den slutter å bli oppdatert etter oppstart. Disse vanene hindrer begge.

Start med problemet

Skriv hvem som har problemet og hva det koster dem før noen løsning. Team som er enige om problemet, krangler mindre om skjermbildene.

Si hva dere ikke skal gjøre

Ikke-mål er også beslutninger. Å skrive dem ned er det som hindrer en funksjon i å vokse en uke av gangen.

Gjør kravene testbare

«Rask» og «enkel» kan ikke sjekkes. «Lenken slutter å åpne seg innen ett minutt etter sluttdatoen» kan bygges og testes.

Prioriter med skal, bør og kan

En versjon slippes når hvert skal-krav er oppfylt. Bør og kan er det dere bytter bort når datoen nærmer seg.

Lenk til bevisene

Hver påstand om brukerne lenker til intervjuet, saken eller dataene bak den, så den som gjennomgår kan sjekke i stedet for å tro.

Hold den levende

Oppdater PRD-en når en beslutning endrer den, og skriv hvorfor. Til slutt skal den beskrive det som ble sluppet, ikke det som var planlagt uke én.

Spørsmål om PRD

Hva er en PRD?

Et produktkravdokument (product requirements document, PRD) beskriver en funksjon eller et produkt før det bygges: problemet det løser, hvem det er for, hva det må gjøre, hvordan suksess måles og hva som er utenfor. En produktsjef eier det som regel; utviklere, designere, support og stadig oftere AI-agenter for kode leser det.

Hva bør en PRD inneholde?

Minst problemet og bevisene for det, mål og ikke-mål, brukerne, krav med prioritet og akseptkriterier, de viktigste flytene og kanttilfellene, suksessmål, utrullingsplanen og en logg over beslutninger og åpne spørsmål. Malen har ett dokument for hver gruppe.

Hvor lang bør en PRD være?

Lang nok til at teamet kan bygge og teste funksjonen uten å stille deg det samme spørsmålet to ganger. Oversikten bør få plass på én skjerm; kravene vokser med beslutningene, ikke med ideene.

Hva er forskjellen på en PRD og et teknisk designdokument?

PRD-en sier hva funksjonen må gjøre og hvorfor. Det tekniske designdokumentet sier hvordan systemet skal gjøre det: arkitektur, data, grensesnitt og risikoer. Skriv PRD-en først, og lenk deretter de to sammen.

Kan AI-agenter bruke PRD-en?

Ja. En PRD i lenkede dokumenter gir en agent konteksten den trenger. I Nodary leser agenter koblet til via MCP, som Claude, ChatGPT eller Cursor, kravene og beslutningsloggen med dine tilganger før de skriver.

Kan jeg bruke malen utenfor Nodary?

Ja. Filene er vanlig Markdown: Obsidian åpner den utpakkede mappen som et hvelv med alle lenker i orden, og GitHub viser filene med diagrammet. Verktøy som importerer Markdown én fil om gangen, beholder tekst og tabeller; sjekk hvordan de håndterer lenker mellom filer.

Les videre

Hold kravene der teamet jobber.

Importer malen til Nodary, så blir PRD-en et kart som teamet ditt og AI-agentene dine holder oppdatert. Gratis med to medlemmer, ett prosjekt og ti dokumenter, uten kort.

Start gratisÅpne live-demoenLast ned malen