Slik skriver du en PRD med AI (gratis mal)

En produktkravspesifikasjon (PRD) er en kort beskrivelse på vanlig språk av hva du bygger, hvem det er for, hva det må gjøre, og hvordan du vet at det virker. AI gjør det mye raskere å skrive en: du gir den grove notater, og den gjør dem om til strukturerte seksjoner, brukerhistorier og kantsituasjoner. Din jobb er å ta beslutningene AI-en ikke kan ta, som målet, omfanget og det som utelates, og å kontrollere det den legger til.

Denne guiden dekker hva en PRD bør inneholde, en trinnvis måte å lage et utkast på med en hvilken som helst AI-assistent, ledetekster for hver seksjon, og en utfyllingsmal du kan kopiere.

Hva en PRD er til for (og hva den ikke er)

En PRD svarer på fire spørsmål:

1. Hvorfor bygger vi dette? Hvilket problem, og for hvem?
2. Hva må det gjøre i den første versjonen?
3. Hva skal det ikke gjøre ennå?
4. Hvordan vet vi at det fungerte?

Den er ikke en teknisk design. Den sier ikke hvilken database eller hvilket rammeverk du skal bruke, det hører hjemme i en egen teknisk spesifikasjon, hvis du trenger en i det hele tatt. Den er heller ikke et markedsføringsdokument eller en forretningsplan. Ved å holde PRD-en til produktets oppførsel blir den nyttig for alle som leser den: en designer, en utvikler, en interessent som skal godkjenne, eller et AI-verktøy for apper som gjør den om til kode.

Hvem trenger en?

• Soloetablerere som vil stoppe at omfanget vokser før det begynner.
• Små team som trenger ett sted der «det vi ble enige om» ligger.
• Alle som engasjerer en frilanser eller et byrå, fordi en tydelig PRD gir tydeligere tilbud. Se hvordan du ansetter en utvikler eller bygger med AI.
• Alle som bygger med AI, fordi en PRDs brukerhistorier og datalister gir bedre ledetekster enn en ustrukturert ønskeliste.

Hva AI er god til, og hva den ikke er

Den vanligste feilen er den nest nederste raden snudd på hodet: AI-en fyller hull med troverdige gjetninger om brukerne dine. Behandle alt den skriver om brukere, markedsstørrelse eller atferd som et spørsmål du må verifisere, ikke et faktum.

Steg 1: Skriv ned det du vet

Før du skriver noen ledetekst, skriv grove notater. Punktlister er greit. Dekk:

• Problemet, i én eller to setninger, sett fra brukerens synspunkt.
• Hvem som har det. Vær spesifikk: «frilansbokførere med 10–40 kunder», ikke «små bedrifter».
• Hva de gjør i dag i stedet (et regneark, e-post, et verktøy de misliker).
• Det ene resultatet som ville gjort første versjon til en suksess.
• Alt du allerede vet at du ikke skal gjøre.
• Harde begrensninger: frist, budsjett, må fungere på mobil, må integreres med et verktøy du allerede bruker.

Hvis du ikke har snakket med noen som har problemet, gjør det først. Slik validerer du en app-idé har en praktisk måte å gjøre det på. En PRD bygget på gjetninger er en godt formatert gjetning.

Steg 2: Be AI-en om et første utkast

Lim inn notatene dine og be om et utkast i en fast struktur. En ledetekst som fungerer godt:

Her er notatene mine om et produkt. Gjør dem om til en produktkravspesifikasjon med nøyaktig disse seksjonene: Sammendrag, Problem, Brukere, Mål og suksessmål, Omfang (inn / ut), Brukerhistorier med akseptansekriterier, Data, Tilganger, Kantsituasjoner, Åpne spørsmål. Hold det under to sider. Ikke finn på fakta om brukere eller markedet. Der notatene mine ikke sier noe, skriv spørsmålet under Åpne spørsmål i stedet.

Den siste instruksjonen er viktig. Å be AI-en sende ukjente ting til «Åpne spørsmål» i stedet for å fylle dem inn, gir et langt mer ærlig utkast.

Steg 3: Stram inn hver seksjon

Gå gjennom utkastet seksjon for seksjon. Disse oppfølgingsledetekstene hjelper:

Problem og brukere

Skriv problemformuleringen om med én eller to setninger, sett fra brukerens synspunkt. Ingen løsningsord.

Hvis problemformuleringen nevner produktet ditt, beskriver den en løsning, ikke et problem.

Mål og suksessmål

Foreslå tre suksessmål for versjon én som jeg kan måle den første måneden med et lite antall brukere. For hvert, si hvordan jeg ville målt det.

Velg ett eller to. «Tjue bokførere bruker det ukentlig i en måned» kan måles. «Øke produktiviteten» kan ikke det.

Omfang

List opp alt i denne PRD-en som kan flyttes til en senere versjon uten å ødelegge kjerneflyten.

AI-verktøy har en tendens til å legge til funksjoner. Denne ledeteksten får dem til å gjøre det motsatte. Vær brutal: de fleste PRD-er for første versjon er for store. Hva er en MVP forklarer hvorfor små første versjoner lærer deg mer.

Brukerhistorier og akseptansekriterier

Skriv hvert krav som en brukerhistorie («Som [bruker] vil jeg [handling] slik at [resultat]») med to til fire akseptansekriterier i Gitt / Når / Så-form.

Akseptansekriteriene er sjekklisten du tester mot senere. «Gitt en booket time, når en annen kunde ser kalenderen, så vises ikke timen» kan testes. «Booking fungerer bra» kan ikke det.

Kantsituasjoner og tilganger

For hver brukerhistorie, list opp hva som skjer med tomme data, ugyldig input, en treg eller mislykket nettverksforespørsel, og en bruker som ikke skal ha tilgang.

Her er det AI-en fortjener sin plass. Den er rask til å se de tomme tilstandene og tilgangshullene folk glemmer.

Steg 4: Gå gjennom den som en skeptiker

Les hele dokumentet en gang til og sjekk:

• Hvert påstand om brukere kom fra deg eller fra research, ikke fra AI-en.
• Omfang «ut» er minst like langt som omfang «inn».
• Hver brukerhistorie har akseptansekriterier som noen kan teste uten å spørre deg.
• Datadelen lister hver type post appen lagrer, og hvem som kan se den.
• Åpne spørsmål har en eier og en dato.
• Ingenting teknisk har sneket seg inn, med mindre det er en reell begrensning («må fungere offline» er et krav; «bruk Redis» er ikke det).

Del den deretter med én person som skal bruke eller bygge produktet, og spør vedkommende hva som er uklart. Spørsmålene deres er hullene.

Utfyllingsmal for PRD

Kopier dette inn i et dokument og erstatt parentesene. Slett alle seksjoner som ikke gjelder.

Produktnavn: [navn] Eier: [person som har ansvar for beslutningene] Status: [utkast / under gjennomgang / godkjent] — Sist oppdatert: [dato]

1. Sammendrag

[To eller tre setninger: hva dette er, for hvem, og hovedresultatet.]

2. Problem

[Problemet sett fra brukerens synspunkt. Hva de gjør i dag, og hvorfor det er vanskelig.]

3. Brukere

4. Mål og suksessmål

• Mål: [resultatet versjon én må oppnå]
• Måling: [hvordan du måler det, og målet]
• Ikke-mål: [noe folk kan anta, som denne versjonen ikke prøver å gjøre]

5. Omfang

I versjon én:

• [funksjon]
• [funksjon]

Ikke i versjon én:

• [funksjon, og hvorfor den kan vente]
• [funksjon, og hvorfor den kan vente]

6. Brukerhistorier

Historie 1: Som [bruker] vil jeg [handling] slik at [resultat].

• Gitt [kontekst], når [handling], så [resultat].
• Gitt [kontekst], når [handling], så [resultat].

Historie 2: Som [bruker] vil jeg [handling] slik at [resultat].

• Gitt [kontekst], når [handling], så [resultat].

7. Data

8. Tilganger

[Hvem som kan logge inn, hvilke roller som finnes, og hva hver rolle kan se og endre.]

9. Kantsituasjoner

• [Tom tilstand: hva som vises når det ikke finnes data ennå]
• [Ugyldig input: hva som skjer med feil e-post eller manglende felt]
• [Tilgang: hva som skjer når noen åpner en side de ikke skal ha tilgang til]

10. Integrasjoner og begrensninger

[Betalinger, e-post, eksisterende verktøy, frister, budsjett, enheter den må fungere på.]

11. Åpne spørsmål

Fra PRD til ledetekster

En god PRD blir nesten direkte til ledetekster for en AI-appbygger:

• Sammendraget, brukerne og datatabellen blir din første ledetekst.
• Hver brukerhistorie blir én oppfølgingsledetekst.
• Hvert akseptansekriterium blir noe du tester i forhåndsvisningen.
• Listen «ikke i versjon én» er det du lar være å be om ennå.

Å bygge én historie om gangen og sjekke akseptansekriteriene før du går videre, er langt mer pålitelig enn å lime inn hele PRD-en og be om alt. Slik skriver du ledetekster til AI-appbyggere dekker ledeteksthalvdelen mer i detalj.

Vanlige feil

• Å skrive løsningen som problemet. «Brukerne trenger et dashbord» er en løsning. «Eierne kan ikke se hvilke fakturaer som forfaller uten å åpne hver enkelt» er et problem.
• Ingen seksjon for det som er utenfor omfanget. Uten den åpnes omfanget på nytt i hver samtale.
• La AI-en finne opp brukere. Personaer AI-en har laget opp føles ekte, men er det ikke.
• Mål du ikke kan måle. Hvis du ikke har en måte å telle det på, er det ikke et mål.
• Aldri å oppdatere den. En PRD som ikke lenger stemmer med det du bygger, er verre enn ingen. Behold en dato for «sist oppdatert» og endre den når beslutningene endrer seg.

Bruke en PRD med Mythex

Hvis du bygger i Mythex, kan du lime PRD-en rett inn i chatten. Plan-modus passer godt til en PRD: agenten leser den, foreslår en tilnærming og en trinnliste du kan gjennomgå i en plan-fane, og starter først å endre filer når du trykker Build. Du kan også lagre det som alltid skal gjelde, som målgruppe, merkevare og regler, som prosjektkunnskap, slik at du ikke må gjenta det i hver chat. Chat-dokumentasjonen forklarer modusene Build, Plan og Ask, og malene er en rask måte å se hvordan en første versjon kan se ut før du skriver hele dokumentet.

Spørsmål