Mall för produktkrav­dokument (PRD)

Fil PRD-mall/Produktkravdokument.md

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

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.

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.

[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: vem funktionen är till för, och researchen bakom problemet
• Krav: vad den måste göra, med prioritet och acceptanskriterier
• Design och flöden: flödet, skärmarna, tillstånden och kantfallen
• Lansering och mått: mått, utrullning och lanseringschecklista
• Beslut och öppna frågor: 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, där filerna importeras som en karta av länkade dokument.

Fil PRD-mall/Produktkravdokument/01 Användare och bevis.md

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

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

Öppna frågor

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

Se även: Produktkravdokument · Krav · Design och flöden

Fil PRD-mall/Produktkravdokument/02 Krav.md

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

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.

Icke-funktionella krav

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 · Design och flöden · Lansering och mått

Fil PRD-mall/Produktkravdokument/03 Design och flöden.md

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.

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

Skärmar

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

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 · Lansering och mått

Fil PRD-mall/Produktkravdokument/04 Lansering och mått.md

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

Utrullning

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 · Krav · Beslut och öppna frågor

Fil PRD-mall/Produktkravdokument/05 Beslut och öppna frågor.md

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

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

Se även: Produktkravdokument · Krav · Lansering och mått