# Mall för produktkravdokument (PRD)

Sex länkade dokument som tar en funktion från problemet till lanseringen: vem den är till för, vad den måste göra, hur flödet ser ut, hur du vet att den fungerade och varje beslut på vägen. Ladda ned dem som Markdown-filer: de öppnas i valfri editor, visar sitt diagram på GitHub och i Obsidian och importeras till Nodary som en karta.

Gratis, inget konto, ingen e-post. Använd den, ändra den, dela den.

[Ladda ned mallen (.zip)](https://nodary.ai/downloads/prd-mall.zip)

## Läs varje sida innan du laddar ned

Översikten ryms på en skärm och länkar till fem delar, så att utveckling, design och support hittar var sin sida och en ändring förblir liten. Kursiva rader säger vad du ska skriva; exemplen följer en och samma exempelfunktion, delningslänkar som slutar gälla.

- Produktkravdokument: Sidan alla läser först: problemet, målen, vad som ingår och inte, och en länk till varje del.
- Användare och bevis: Vem funktionen är till för, vad de gör i dag utan den och researchen bakom problemet.
- Krav: Vad funktionen måste göra, varje krav med sin prioritet och kontrollen som bevisar det.
- Design och flöden: Hur användaren rör sig genom funktionen: flödet, skärmarna, tillstånden och kantfallen.
- Lansering och mått: Hur du vet att det fungerade, hur den rullas ut och vad som skulle få dig att backa.
- Beslut och öppna frågor: Varje beslut som ändrade PRD:n, med vem som fattade det och varför, och frågorna som fortfarande är öppna.

### Produktkravdokument

_Så använder du mallen: kursiva rader är vägledning. Ersätt dem med dina egna ord och radera dem sedan. Värden inom hakparentes fyller du i. Håll den här sidan på en skärm: det är den som en stressad läsare, en ny kollega eller en AI-agent läser först._

#### I korthet

| Fält | Den här funktionen |
| --- | --- |
| Funktion | [Namn] |
| I en mening | [Vad användaren kan göra när den släppts] |
| Produktägare | [namn] |
| Teknisk ansvarig | [namn] |
| Designansvarig | [namn] |
| Status | [utkast, under granskning, godkänd, släppt] |
| Planerad version | [datum eller version] |

#### Problem

_Vem som har problemet, vad det kostar dem i dag och hur du vet det. Ett problem utan bevis är en gissning: länka researchen i_ [Användare och bevis](https://nodary.ai/sv/templates/prd#doc-users).

_Exempel (en exempelfunktion): Folk delar ett dokument med en kund för granskning och glömmer sedan att länken finns. Månader senare öppnas den fortfarande. Tre kunder frågade förra kvartalet hur man får en länk att sluta fungera ett visst datum._

[Problemet, i två eller tre meningar]

#### Mål och icke-mål

_Målen säger vad som ändras för användaren, inte vad teamet bygger. Icke-målen är besluten som hindrar omfattningen från att växa i tysthet._

- Mål: [vad användaren kan göra, eller inte längre behöver göra]
- Mål: [...]
- Icke-mål: [vad den här versionen medvetet lämnar utanför]
- Icke-mål: [...]

#### Framgång på en rad

_Det enda mått som en månad efter lanseringen säger om det fungerade. Hela listan finns i_ [Lansering och mått](https://nodary.ai/sv/templates/prd#doc-launch).

[Mått] går från [utgångsvärde] till [mål] senast [datum].

#### Resten av PRD:n

_Varje del är ett eget dokument. Länka till den i stället för att kopiera, så att varje fakta finns och ändras på ett ställe._

- [Användare och bevis](https://nodary.ai/sv/templates/prd#doc-users): vem funktionen är till för, och researchen bakom problemet
- [Krav](https://nodary.ai/sv/templates/prd#doc-requirements): vad den måste göra, med prioritet och acceptanskriterier
- [Design och flöden](https://nodary.ai/sv/templates/prd#doc-design): flödet, skärmarna, tillstånden och kantfallen
- [Lansering och mått](https://nodary.ai/sv/templates/prd#doc-launch): mått, utrullning och lanseringschecklista
- [Beslut och öppna frågor](https://nodary.ai/sv/templates/prd#doc-decisions): vad som beslutades, av vem och varför, och vad som är öppet

_Mallen är fri att använda, ändra och dela. Den kommer från_ [Nodary](https://nodary.ai/sv)_, där filerna importeras som en karta av länkade dokument._

### Användare och bevis

**Ägare:** [namn] · **Status:** utkast · **Senast granskad:** [datum]

_Vem funktionen är till för och vad du vet om dem. Varje påstående här ska peka på sin källa._

#### Vem den är till för

| Vem | Vad de försöker göra | Vad som står i vägen |
| --- | --- | --- |
| [Huvudanvändare] | [...] | [...] |
| [Sekundär användare] | [...] | [...] |

_Exempel (en exempelfunktion): En kundansvarig delar ett utkast till offert med en kund under en vecka av kommentarer. I dag sätter hon en påminnelse för att stänga av länken, och glömmer ibland._

#### I dag, utan funktionen

_Vad användarna gör i dag, steg för steg, genvägar inräknade. Genvägen är ofta den bästa specifikation du får._

1. [Steg]
2. [Steg]
3. [Genväg]

#### Bevis

| Källa | Vad den säger | Datum | Länk |
| --- | --- | --- | --- |
| [Kundintervju] | [...] | [datum] | [...] |
| [Supportärenden] | [...] | [...] | [...] |
| [Användningsdata] | [...] | [...] | [...] |

#### Öppna frågor

- [ ] [Fråga], [vem som besvarar den], [senast när]

Se även: [Produktkravdokument](https://nodary.ai/sv/templates/prd#doc-overview) · [Krav](https://nodary.ai/sv/templates/prd#doc-requirements) · [Design och flöden](https://nodary.ai/sv/templates/prd#doc-design)

### Krav

**Ägare:** [namn] · **Status:** utkast · **Senast granskad:** [datum]

_En rad per krav, skrivet som något användaren kan göra. Prioriteten är skall, bör eller kan: en version släpps när varje skallkrav är uppfyllt._

#### Användarberättelser

| ID | Som | vill jag | så att | Prioritet |
| --- | --- | --- | --- | --- |
| K1 | [användare] | [...] | [...] | [skall, bör, kan] |
| K2 | [...] | [...] | [...] | [...] |
| K3 | [...] | [...] | [...] | [...] |

_Exempel (en exempelfunktion): K1. Som den som delar ett dokument vill jag välja dagen då en länk slutar fungera, så att en kund förlorar åtkomsten när projektet är slut. Skall._

#### Acceptanskriterier

_För varje skallkrav, kontrollerna som bevisar att det fungerar. Skriv dem så att en testare, eller en AI-agent, kan köra dem utan att fråga dig._

| Krav | Givet | När | Då |
| --- | --- | --- | --- |
| K1 | [ett utgångsläge] | [en handling] | [resultatet som någon kan kontrollera] |
| K1 | [...] | [...] | [...] |

#### Icke-funktionella krav

| Område | Krav |
| --- | --- |
| Prestanda | [...] |
| Säkerhet och integritet | [...] |
| Tillgänglighet | [...] |
| Språk | [...] |
| Kompatibilitet | [webbläsare, enheter, versioner] |

#### Utanför omfattningen

- [Vad den här versionen inte gör, och varför]
- [...]

#### Öppna frågor

- [ ] [Fråga], [vem som besvarar den], [senast när]

Se även: [Användare och bevis](https://nodary.ai/sv/templates/prd#doc-users) · [Design och flöden](https://nodary.ai/sv/templates/prd#doc-design) · [Lansering och mått](https://nodary.ai/sv/templates/prd#doc-launch)

### Design och flöden

**Ägare:** [namn] · **Status:** utkast · **Senast granskad:** [datum]

_Länka designfilerna i stället för att klistra in dem. Håll flödet och besluten bakom det här, så att text och skärmar aldrig säger emot varandra._

#### Användarflöde

_Huvudvägen, från där användaren börjar till det hen får. Kan teamet inte rita den är den inte beslutad än._

```mermaid
flowchart LR
  n0["Ingång"]
  n1["Första handling"]
  n2["Viktigt val"]
  n3["Bekräftelse"]
  n4["Resultat"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_Huvudflödet, från [där användaren börjar] till [det hen får]_

#### Skärmar

| Skärm | Syfte | Designlänk | Status |
| --- | --- | --- | --- |
| [Skärm] | [...] | [...] | [skiss, mockup, slutlig] |
| [Skärm] | [...] | [...] | [...] |

#### Tillstånd

_Varje skärm har fler tillstånd än den lyckliga vägen. Bocka av varje när den är designad, eller skriv varför den inte kan inträffa._

- [ ] Tom: inget att visa än
- [ ] Laddar
- [ ] Fel, med vad användaren kan göra sedan
- [ ] Saknar behörighet
- [ ] Långsam eller bruten anslutning
- [ ] Mycket lång text och mycket stora tal

#### Kantfall

| Fall | Vad som händer |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_Exempel (en exempelfunktion): Någon öppnar en länk en minut efter dess slutdatum: hen ser att länken har slutat gälla och vem hen kan fråga, aldrig en felsida._

#### Öppna frågor

- [ ] [Fråga], [vem som besvarar den], [senast när]

Se även: [Krav](https://nodary.ai/sv/templates/prd#doc-requirements) · [Lansering och mått](https://nodary.ai/sv/templates/prd#doc-launch)

### Lansering och mått

**Ägare:** [namn] · **Status:** utkast · **Senast granskad:** [datum]

_Ett huvudmått, två eller tre sekundära och ett skyddsmått: något som inte får bli sämre medan huvudmåttet förbättras._

#### Mått

| Mått | Typ | Utgångsvärde | Mål | Mäts med | Uppföljningsdatum |
| --- | --- | --- | --- | --- | --- |
| [...] | [huvud] | [...] | [...] | [...] | [datum] |
| [...] | [sekundärt] | [...] | [...] | [...] | [...] |
| [...] | [skydd] | [...] | [...] | [...] | [...] |

#### Utrullning

| Steg | Vem som får den | Datum | Vidare när |
| --- | --- | --- | --- |
| [Internt] | [teamet] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Alla] | [...] | [...] | [...] |

#### Lanseringschecklista

- [ ] Hjälpartikel skriven
- [ ] Supportteamet informerat
- [ ] Versionsinformation utkastad
- [ ] Analyshändelser kontrollerade
- [ ] Återställning testad

#### Återställning

_Vad som skulle få dig att stänga av funktionen, och hur. Bestäm det före lanseringen, medan ingen är fäst vid resultatet._

- Vi backar om: [...]
- Hur: [en flagga, en version, ett skript]
- Vem som beslutar: [namn]

Se även: [Produktkravdokument](https://nodary.ai/sv/templates/prd#doc-overview) · [Krav](https://nodary.ai/sv/templates/prd#doc-requirements) · [Beslut och öppna frågor](https://nodary.ai/sv/templates/prd#doc-decisions)

### Beslut och öppna frågor

**Ägare:** [namn] · **Status:** utkast · **Senast granskad:** [datum]

_När ett beslut ändrar PRD:n, lägg till en rad här och uppdatera sidan det gäller. Loggen säger varför; sidan säger vad som gäller nu._

#### Beslutslogg

| Datum | Beslut | Beslutat av | Varför | Ändrad sida |
| --- | --- | --- | --- | --- |
| [datum] | [...] | [...] | [...] | [...] |

_Exempel (en exempelfunktion): Länkar fungerar till slutet av sin sista dag i ägarens tidszon, inte till midnatt UTC. Beslutat av produktägaren och den tekniska ansvarige, eftersom kunder i andra tidszoner förlorade åtkomsten en dag för tidigt i betan. Ändrad sida: Krav._

#### Öppna frågor

| Fråga | Vem som besvarar den | Senast | Svar |
| --- | --- | --- | --- |
| [...] | [namn] | [datum] | [...] |

Se även: [Produktkravdokument](https://nodary.ai/sv/templates/prd#doc-overview) · [Krav](https://nodary.ai/sv/templates/prd#doc-requirements) · [Lansering och mått](https://nodary.ai/sv/templates/prd#doc-launch)

## Så använder du den

### Skriv problemet före lösningen

Fyll först i översiktens problem, mål och icke-mål, tillsammans med utvecklaren och designern som ska bygga funktionen. Är ni tre inte överens om problemet, stanna där.

### Gör varje skallkrav testbart

Ge varje skallkrav acceptanskriterier som någon annan kan kontrollera. Ett krav som ingen kan testa är en önskan.

### Låt den granskas och håll den sann

Be om granskning när kraven är klara, och uppdatera PRD:n när ett beslut ändrar dem. En PRD som stannar vid uppstarten är fel vid lanseringen.

### Skriv ned vad som ändrades och varför

Varje beslut hamnar i beslutsloggen med vem som fattade det. När någon frågar varför funktionen fungerar så, är svaret en länk bort.

## Importera den till Nodary som en karta

Nodary är en AI-native arbetsyta där ett teams dokument länkas i stället för att samlas i högar. Importera .zip-filen så kommer PRD:n med sina fem delar under sig, länkarna mellan sidorna kvar och diagrammet ritat. Sätt den som under granskning och be en ägare eller administratör för arbetsytan eller projektet godkänna den, se vad som ändrats sedan ditt senaste besök och låt AI-agenter som är anslutna via MCP läsa kraven innan de skriver kod mot dem.

1. Öppna ett projekts karta och välj Importera.
2. Välj fliken ”Mapp eller ZIP” och sedan ”Välj en ZIP-fil”.
3. Välj den nedladdade filen, kontrollera trädet och importera.

Free-planen rymmer tio dokument per arbetsyta, projektets egen sida inräknad: mallens sex får plats i en ny arbetsyta med utrymme för tre till. Nodary har också en inbyggd produktspecifikation (PRD) på en sida.

## Skriva en PRD som teamet faktiskt använder

En PRD misslyckas på två sätt: den beskriver en lösning som ingen ifrågasatt, eller så slutar den uppdateras efter uppstarten. De här vanorna förhindrar båda.

### Börja med problemet

Skriv vem som har problemet och vad det kostar dem innan någon lösning. Team som är överens om problemet bråkar mindre om skärmarna.

### Säg vad ni inte ska göra

Icke-mål är också beslut. Att skriva ned dem är det som hindrar en funktion från att växa en vecka i taget.

### Gör kraven testbara

”Snabb” och ”enkel” går inte att kontrollera. ”Länken slutar öppnas inom en minut efter slutdatumet” går att bygga och testa.

### Prioritera med skall, bör och kan

En version släpps när varje skallkrav är uppfyllt. Bör och kan är det ni byter bort när datumet närmar sig.

### Länka bevisen

Varje påstående om användarna länkar till intervjun, ärendet eller datan bakom det, så att den som granskar kan kontrollera i stället för att tro.

### Håll den levande

Uppdatera PRD:n när ett beslut ändrar den, och skriv varför. Till slut ska den beskriva det som släpptes, inte det som planerades vecka ett.

## Frågor om PRD

### Vad är en PRD?

Ett produktkravdokument (product requirements document, PRD) beskriver en funktion eller en produkt innan den byggs: problemet den löser, vem den är till för, vad den måste göra, hur framgång mäts och vad som ligger utanför. En produktchef äger den oftast; utvecklare, designers, support och allt oftare AI-agenter för kod läser den.

### Vad ska en PRD innehålla?

Minst problemet och bevisen för det, mål och icke-mål, användarna, krav med prioritet och acceptanskriterier, de viktigaste flödena och kantfallen, framgångsmått, utrullningsplanen och en logg över beslut och öppna frågor. Mallen har ett dokument för varje grupp.

### Hur lång ska en PRD vara?

Så lång att teamet kan bygga och testa funktionen utan att ställa samma fråga till dig två gånger. Översikten ska rymmas på en skärm; kraven växer med besluten, inte med idéerna.

### Vad skiljer en PRD från ett tekniskt designdokument?

PRD:n säger vad funktionen måste göra och varför. Det tekniska designdokumentet säger hur systemet ska göra det: arkitektur, data, gränssnitt och risker. Skriv PRD:n först och länka sedan ihop dem.

### Kan AI-agenter använda PRD:n?

Ja. En PRD i länkade dokument ger en agent det sammanhang den behöver. I Nodary läser agenter som är anslutna via MCP, som Claude, ChatGPT eller Cursor, kraven och beslutsloggen med dina behörigheter innan de skriver.

### Kan jag använda mallen utanför Nodary?

Ja. Filerna är vanlig Markdown: Obsidian öppnar den uppackade mappen som ett valv med alla länkar fungerande, och GitHub visar filerna med sitt diagram. Verktyg som importerar Markdown en fil i taget behåller text och tabeller; kontrollera hur de hanterar länkar mellan filer.

Sidan: https://nodary.ai/sv/templates/prd