Sådan skrives det perfekte PRD (dokument med produktkrav)

Hvis du er en produktansvarlig, er chancerne for, at du skriver PRD'er (produktkravdokumenter) regelmæssigt. Du ville bruge en god tid på at smadre PRD'erne ud og undfange dem på en sådan måde, at det rammer perfektion.

Og hvis du er en håbefuld produktleder, så er det at vide, hvordan du laver en perfekt PRD noget, du bestemt skal have i dit repertoire.

Så hvad skal der til for at skrive den perfekte PRD? En PRD, der let kan forstås af alle interessenter? Poornima J (associeret direktør for betalingsprodukter, RedBus) tog noget tid ud og delte sine tanker om denne, især for medlemmer af CohortPlus-samfundet.

Inden vi går i detaljer, vil vi lade vores læsere vide, at CohortPlus er det største og det mest aktive samfund for produktledere i Indien og et af de største sådanne samfund i verden. Rige og spam-gratis diskussioner finder sted på platformen hver dag. Derudover har vi lanceret et specielt produktstyringsværktøjssæt, der indeholder links til topbøger, rapporter, artikler, casestudier og produktstyringssamtalsspørgsmål (med svar fra medlemmer af samfundet).

Link til at registrere dig på vores Android-app - https://goo.gl/7yz7E4

Link til registrering på CohortPlus-webstedet - https://cohortplus.com/

Uden videre, her er alle de detaljer, du gerne vil vide om, hvordan du retter den perfekte PRD -

Hvad er en PRD?

En PRD fastlægger funktionaliteten af ​​et produkt sammen med de krævede design / wireframes, forskellige stadier af frigivelse / tilgængelighed af produktet; erklærer også visse antagelser på både kunde- og produktudviklingsfronter.

Jeg hader dokumenter. Kan jeg skrive en e-mail eller holde dem mere samtale? Mit Engg-team synes det alligevel kedeligt at læse disse sagaer!

Formålet med PRD er at gøre udviklingsprocessen meget glattere. Kommunikationsmediet kan være en e-mail eller et dokument eller noget andet, der fungerer for dig og dit team.

I sidste ende er det et produktpersons ansvar at bringe alle interessenter om bord og dermed gøre dit indhold til at være interessant at læse.

Men husk, en god start er halvt færdig!

Hvad er fordelene ved at udarbejde et dokument?

- For modne organisationer med flere systemer og teams hjælper det med at løse tekniske og operationelle afhængigheder.

- Skøn over omkostningerne baseret på det definerede omfang

- Spor forskellige stadier i projektet baseret på frigivelsesversioner: ex MVP (Minimum levedygtigt produkt)

- Minimum overraskelser i slutningen (forhåbentlig)

Er det forskelligt fra tekniske specifikationer og projektdokumenter?

Ja

1. Den præsenterer løsningen for slutkunden og ikke implementeringsdetaljerne. Engg. holdet ville forstå dette og fordele sig til implementering - sekvensdiagrammer, løse afhængigheder osv.

2. Det sporer ikke frigørelsestidslinjerne. Jeg er ikke tilhænger af forretninger, der giver frister for projekter. Tidslinjer skal gives af Engg-teamet i henhold til kompleksitet, og premierministerne skal hente historierne pr. Prioriteter (det berømte interviewspørgsmål om, hvordan prioriterer du!)

Før du skriver:

Har en workshop med forskellige interessenter, og brainstorm det, så alle strømme er klare for dig.

Mange gange kunne det hjælpe at diskutere projektet med en anden produktchef, der er fra en anden lodret.

Hvilke er de værktøjer, der skal bruges til at skrive PRD?

Google-dokumenter fungerer bedst for mig.

1. Alle interessenter kan gennemgå og tilføje kommentarer

2. Kommentarer kan løses og drøftes i selve dokumentet.

3. Går ikke gennem versionering på en traditionel måde. Du kan sende opdateringer til relevant målgruppe, når du foretager ændringer.

4. Du kan vælge at give forskellige niveauer af adgang: redigere, kommentere, kun læse osv. (Jeg giver normalt kun kommentarer-tilladelse til publikum).

Hvad består PRD af?

1. Mål:

Definer et opnåeligt / implementerbart mål, der kan måles (Husk - hvad der bliver målt bliver styret).

- Undgå generiske sætninger som "At opbygge den bedste kundeoplevelse"

-Når vi alle taler om kundeoplevelse pålydende, ville der være en underliggende forretningsværdi for hvert projekt.

- Fremhæv de interesserede parter, der ville få gavn af det: det være sig forbedring af en beregning, introduktion af en ny funktion, procesforbedring eller automatisering

Eksempel: Indfør relevante tilføjelser sammen med regelmæssig booking af busbilletter for at få yderligere indtægter.

2. Krævet måling:

Selvom du kan være objektiv, kræves der en kvantitativ måling for at overvåge fremskridtene.

I ovenstående eksempel kan indtægterne være X crores pr. Kvartal (forkert / praktisk metrisk, hvis du bare vil markere dine mål: antallet af indførte Addons).

Du kan have undermetriks, som hjælper dig med at nå det vigtigste mål.

Eks: Arbejd med den vedhæftede sats for tilføjelser med hver transaktion. X% af transaktionerne skal have ordrer sammen med det.

3. Hvem bygger du dette til (Kunder, brugerstrømme og opgaver - hjælper med at se produktet fra slutkundeperspektivet):

Hvem er denne kunde?

Hvad er handlingen?

For at opfylde “Hvilket / Hvornår i” behov.

Afhængigt af dit segment kan du definere kundens alder, køn, miljø osv.

En enkelt proces kan identificere flere kunder. For eventuelle refusionsfejl gennem betalingsportaler ønskede vi for eksempel at automatisere NEFT-overførslen til slutkunden i tilfælde af, at automatisk tilbageføring af midler mislykkes.

Dette er en intern proces, der har forskellige brugerpersoner.

Jeg er en kundebehandlingschef, der prøvede at behandle en ekstraordinær refusion for forsinkelse af bussen til slutkunden og derfor rejste en anmodning om overførsel via bank.

Jeg er en finansieringsperson, der modtog anmodningen, downloadede rapporten og har brug for at markere denne billet som løst / fejlagtig pr. Overførselsstatus.

Jeg er en slutkund Redbus-kunde, der venter på refusion på en forsinket bus.

4. Forskellige faser i frigivelsen, der dækker det nuværende og fremtidige omfang (præsenter prioriteterne, hvis det er muligt og ikke tidslinjerne):

Opdel dine projekter i forskellige opnåelige moduler. Når vi bevæger os hen imod en smidig udviklingsform, er det godt at have disse diskussioner med forskellige interessenter, inden vi starter et projekt og ændrer modulerne i henhold til kundens svar.

5. Medtag supportstrømmene:

Kundepleje er et vigtigt aspekt af enhver produktudgivelse. Sørg for, at plejeteamet har adgang til alle nødvendige informationer, selvom det ikke er inkluderet for slutkunden.

Eks: tegnebog, hvilken slutkund kan bruge til at betale og købe forskellige produkter. Punghistorikken som en funktion er muligvis ikke tilgængelig i first cut (MVP) for slutkunden, men supportteam skal have adgang til dette for at besvare kundeforespørgsler som ”Hvorfor debiteres dette beløb? Hvad er balancen nu? Jeg har ikke foretaget denne transaktion - der fandt noget svindel op! ”

6. Design:

Prototype knyttet til PRD til hver brugerhistorie ville være en stor hjælp for Engg.

Det hjælper dem med at visualisere kunderejsen og gør dit liv også let.

Begrænset med designbåndbredde, før du deler PRD'er? Du kan gå efter prototyper ved hjælp af enkle trådrammer.

Nogle af værktøjerne til prototypinh: Zeplin, Invision osv.

7. Rapporter / sporing:

Den spænding ved at overvåge forbedringen i salg / konverteringer / sideklik, når du starter en ny funktion - hvordan kan du gå glip af hvilken metrics du vil spore?

Engg. og Analytics-teams er nødt til at definere attributterne og ændre dashboards i overensstemmelse hermed. Husk tværfunktionelle interessenter, mens du definerer disse beregninger.

Eks: Du bygger en funktion til at målrette de kunder, der mislykkedes ved bookinger. Hvis du ikke mærker den nye reservation, der er foretaget til den oprindelige mislykkede transaktion, vil du ikke vide, hvilken procentdel af mislykkede transaktioner / kunder, du har konverteret med de nye målretningstrømme.

8. Opskalering:

Fortæl teamet om det fremtidige omfang, mængder og tilføjelser, som du forudser senere. Dette hjælper dem med at designe systemerne i overensstemmelse hermed. Lad os sige, at de bygger for et Addon nu, og senere siger du, at kunden kan købe to-tre Adons i en enkelt transaktion.

Ordrestyringssystemet skal imødekomme dette i selve indledende indkøbsordredesign.

Overdriv ikke dette - Hvad er irrelevant? Du ønsker, at en bot skal foreslå en kontekstfølsom tilføjelse fremover baseret på ML.

Men hvad der er relevant: Hver kunde får vist en anden tilføjelse fremover som pr. Kundesegment

9. Lidt hygiejne ved dokumentation:

Da dokumenter hjælper til henvisninger i fremtiden, hvor nedenunder nævnes, ville detaljer hjælpe

• Titel og en taglinie

• En lille beskrivelse, der kan fange fordelene ved projektet

• Forfatter / produkt ejer

• Dato for skrivning af dokumentet

• Version: der kan være flere revisioner, så en nummertildeling hjælper med at sikre, at alle er på samme indhold

10. Endelig er her et eksempel på en skabelon til tilføjelser:

Prøve PRD er vedhæftet nedenfor -

Håber du kunne lide artiklen. Tak igen til Poornima J (associeret direktør, betalingsprodukter RedBus) for denne indsigtsfulde opskrivning!