Een productbrief schrijven waarmee teams op één lijn blijven

Belangrijke leerpunten

• Een productbrief is een kort planningsdocument waarin staat wat een team overweegt te bouwen, waarom dat belangrijk is, voor wie het bedoeld is en wat nog moet worden uitgezocht.

• Productbriefs zijn het nuttigst aan het begin van productplanning of productontdekking. 

• Een goede productbrief beantwoordt niet elke vraag. Deze creëert een gedeeld begrip voor belanghebbenden om kansen te bespreken en te beslissen wat er vervolgens moet gebeuren.

• De beste productbriefs koppelen een duidelijk klantprobleem aan meetbare bedrijfsresultaten.

• Centrale tools geven alle belanghebbenden één plek om de productbrief te bekijken, opmerkingen te plaatsen en gedurende het hele proces op één lijn te blijven.

Het verkeerde bouwen is duur. Het juiste bouwen voor de verkeerde doelgroep is dat ook, net als bouwen zonder een duidelijk beeld van hoe succes eruitziet. 

Een productbrief helpt teams die situaties te voorkomen door al afstemming te creëren voordat iemand ook maar één regel code schrijft of één scherm ontwerpt. Dit is in de vroege fasen van productplanning absoluut cruciaal en werkt het best als startpunt voor teams.

In dit artikel lees je wat een productbrief is, wat erin moet staan, waarin deze verschilt van andere planningsdocumenten en hoe je er een schrijft die je team echt vooruithelpt.

Wat is een productbrief?

Een productbrief is een beknopt planningsdocument waarin wordt uitgelegd wat een team overweegt te bouwen, waarom dat belangrijk is, voor wie het bedoeld is, welke resultaten het moet ondersteunen en welke informatie nog moet worden gevalideerd. 

Het document wordt opgesteld aan het begin van de productplanning of productontdekking, vaak voordat er überhaupt een formele beslissing is genomen om iets te bouwen. Een goed geschreven productbrief is nuttig voor product, ontwerp, engineering, marketing, sales, support en leiderschap. 

De productbrief hoeft niet alle technische details te bevatten of elke open vraag te beantwoorden. Het doel is om voldoende overeenstemming te creëren, zodat belanghebbenden kunnen bepalen welke kansen er zijn en welke vervolgstappen nodig zijn.

Wat is het doel van een productbrief?

Met een productbrief kunnen teams betere productbeslissingen nemen voordat ze resources inzetten. Dit is waar aannames aan het licht komen, vragen worden gesteld en iedereen het erover eens wordt, of juist niet, of een idee het waard is om verder te onderzoeken.

Dit zijn de belangrijkste doelen van een productbrief:

• Brengt belanghebbenden op één lijn over het probleem en de kans: voordat iemand begint met ontwerpen of bouwen, geeft een productbrief het hele team een gezamenlijk beeld van welk probleem het product moet oplossen en waarom dat juist nu belangrijk is.

• Verduidelijkt wat het team bouwt en waarom: een productbrief maakt van een vaag idee iets concreets genoeg om het te bespreken, te beoordelen en er actie op te ondernemen.

• Legt aannames, openstaande vragen en risico's vast: opschrijven wat je nog niet weet is net zo belangrijk als opschrijven wat je wel weet. Een productbrief maakt onzekerheden zichtbaar en geeft het team iets om aan te pakken voordat het werk begint.

• Creëert een gezamenlijk referentiepunt voor prioritering: wanneer meerdere ideeën om aandacht strijden, biedt een productbrief belanghebbenden een consistente basis om ze met elkaar te vergelijken. Teams kunnen Jira Product Discovery gebruiken om ideeën, inzichten en feedback op één plek te verzamelen voordat ze beslissen wat verder moet worden uitgewerkt.

• Helpt teams te bepalen wat de volgende stap is: een productbrief moet het makkelijker maken om te bepalen of een idee in een productbacklog, in een roadmap of in een volledig PRD (product requirement document) moet worden opgenomen.

Wat moet er in een productbrief staan?

Een sterke productbrief behandelt de juiste onderwerpen zonder uit te groeien tot een volledig PRD. Hier volgt een overzicht van elke sectie, welke vraag die moet beantwoorden en hoe dat er in de praktijk uitziet:

Productbrief versus PRD versus productbacklog versus roadmap

Teams gebruiken veel verschillende planningsdocumenten die deels overlappen, waardoor je ze gemakkelijk door elkaar haalt. Zo verhoudt een productbrief zich tot de andere documenten:

Een productbrief schrijven in 6 stappen

Een productbrief schrijven hoeft geen lang proces te zijn. Het doel is om genoeg informatie vast te leggen zodat de juiste mensen een goed onderbouwd gesprek kunnen voeren over de vraag of en hoe ze verder willen gaan. 

Zo pak je het aan: 

Stap 1: Definieer het productidee

Begin met een beschrijving in gewone taal van wat het team overweegt: een nieuw product, een functie, een verbetering of een experiment. Dit hoeft geen gelikte pitch te zijn. De beschrijving moet alleen duidelijk genoeg zijn zodat iedereen die deze leest, de algemene richting begrijpt.

Een gedeelde Confluence-pagina biedt teams een centrale plek om het idee vast te leggen, context toe te voegen en gedachten verder uit te werken naarmate feedback en nieuwe informatie binnenkomen. 

Dit zijn een aantal prompts om je op weg te helpen:

• Wat overwegen we te bouwen?

• Is dit een nieuw product, een functie, een verbetering of een experiment?

• Op welke klant of zakelijke kans sluit dit aan?

• Waar komt het idee vandaan?

Stap 2: Verduidelijk het probleem en de doelgroep

Sterke productbriefs beginnen met het probleem, niet met de oplossing. Voordat het team bepaalt wat het gaat bouwen, moet het duidelijk kunnen beschrijven wie een probleem ervaart en wat dat probleem kost in tijd, geld, tevredenheid of een andere meetbare waarde.

Dit zijn de typen input die doorgaans als basis dienen voor deze sectie:

• Klantgesprekken

• Supporttickets

• Feedback van sales

• Productanalyses

• Concurrentieonderzoek

• Verzoeken van interne belanghebbenden

Daarom moet je kansen, feedback en verzoeken op één plek vastleggen, zodat er niets verloren gaat voordat er een beslissing wordt genomen.

Stap 3: Bepaal doelen en successtatistieken

Doelen moeten het productidee koppelen aan resultaten die het bedrijf echt belangrijk vindt. Vage doelen zijn lastig te evalueren en moeilijk om naar te handelen. 

Specifieke, meetbare doelen geven het team iets om naartoe te werken en een manier om te weten of het heeft gewerkt. Dit zijn enkele voorbeelden van resultaatgerichte doelen:

• Het activeringspercentage verbeteren

• Aantal supporttickets verminderen

• Meer gebruik van functie realiseren

• Behoud verbeteren

• Tijd verkorten om een taak te voltooien

Stap 4: Omschrijf de scope, aannames en openstaande vragen

Een van de nuttigste dingen die een productbrief doet, is onzekerheid zichtbaar maken. Teams gaan vaak aan de slag op basis van veel onuitgesproken aannames. Door deze te noteren, krijgen belanghebbenden de kans om ze ter discussie te stellen voordat het werk begint. 

Een gedeelde documentpagina houdt deze context op één plek, zodat teams opnieuw ernaar kunnen kijken en hem kunnen bijwerken naarmate beslissingen worden genomen. Hier is een eenvoudige structuur voor deze sectie:

• In scope: waartoe het team zich verbindt om het te onderzoeken of samen te stellen

• Buiten scope: wat expliciet is uitgesloten van deze inspanning

• Aannames: wat het team denkt dat waar is, maar nog niet heeft gecontroleerd

• Openstaande vragen: wat nog moet worden beantwoord voordat het proces kan doorgaan

Stap 5: Geef de prioriteit van het idee aan ten opzichte van ander werk

Een productbriefing moet het team helpen beslissen of een idee aandacht verdient in vergelijking met al het andere dat om tijd en middelen concurreert. Die beslissing moet zijn gebaseerd op duidelijke criteria, niet wie het hardst roept tijdens een bijeenkomst.

Veelgebruikte criteria zijn onder meer: impact op de klant, waarde voor het bedrijf, inspanning, risico, vertrouwen en strategische aansluiting. Daarom heb je flexibele frameworks voor productprioritering, aangepaste velden en scores nodig, zodat teams ideeën kunnen vergelijken met behulp van consistente criteria.

Met deze tools kun je een productroadmap opstellen die de werkelijke prioriteiten weerspiegelt. Teams die agile projectmanagement toepassen, kunnen deze criteria ook gebruiken om sprintprioriteiten af te stemmen op bredere productdoelen. 

Stap 6: Deel en herzie de briefing, en koppel haar aan leveringswerk

Een productbriefing moet worden beoordeeld door belanghebbenden van Product, Ontwerp, Engineering en Go-to-market, voordat het werk doorgaat. Deze beoordeling brengt hiaten aan het licht, maakt meningsverschillen vroegtijdig zichtbaar en zorgt voor een gedeelde verantwoordelijkheid voor de richting.

Nadat afstemming is bereikt en toezeggingen zijn gedaan, kan de productbriefing input geven voor gesprekken over de productstrategie, updates van de roadmap, items in de productbacklog, PRD's en leveringstickets. De productbriefing verdwijnt niet zodra het werk begint. 

In plaats daarvan wordt ze een overzicht van waarover het team het eens was en waarom.

Voorbeeld van productbriefing

Hier is een kort voorbeeld van hoe een productbriefing in de praktijk uitziet:

• Productidee: een selfservice-onboardingchecklist voor nieuwe gebruikers

• Probleem: nieuwe gebruikers haken af voordat ze het instellen van het product voltooien. Supporttickets laten zien dat de meeste vragen in een vroeg stadium voorspelbaar en repetitief zijn, wat erop wijst dat gebruikers de begeleiding die ze nodig hebben, niet zelf vinden.

• Doelgroep: beheerders bij kleine bedrijven die het product voor het eerst configureren zonder speciale IT-support

• Doel: het verhogen van het activeringspercentage met 15% binnen 90 dagen na introductie

• Voorgestelde oplossing: een begeleide checklist in het product die nieuwe beheerders door aanbevolen configuratiestappen leidt met links naar relevante documentatie

• Successtatistieken: activeringspercentage, voltooiingspercentage van checklist, volume van supporttickets in de eerste 30 dagen

• In scope: checklist-MVP met aanbevolen configuratiestappen en links naar documentatie

• Buiten scope: volledig herontwerp van onboarding, geautomatiseerde e-mailreeksen of support van in-app chat

• Openstaande vragen: zullen gebruikers gebruikmaken van prompts in het product of vinden gebruikers ze storend? Is er een versie hiervan die werkt voor verschillende beheerderpersona's?

5 handige sjablonen om een productbriefing op te stellen

Aan de slag gaan met een productbriefing is gemakkelijker met de juiste sjabloon. Hier zijn vijf Confluence-sjablonen die support bieden voor verschillende fasen van het proces voor productbriefings:

Stel betere producten samen met een duidelijker pad van idee naar actie

Met een productbriefing kunnen teams op één lijn komen voordat ze zich te veel vastpinnen op een bepaalde oplossing. Het is een manier om te zorgen dat iedereen het probleem begrijpt, het eens is over de doelen en weet welke vragen nog moeten worden beantwoord voordat het werk begint. 

De beste briefings verbinden klantproblemen, zakelijke doelen, successtatistieken en vervolgstappen in een document dat iedereen in het team kan lezen en gebruiken.

Jira Product Discovery helpt teams ideeën vast te leggen en te prioriteren, zodat de beste ideeën verder komen. Jira zet vastgelegde ideeën om in leverbaar werk dat je kunt volgen. En Confluence geeft teams een plek om beslissingen, productvereisten en ondersteunende context te documenteren, zodat niets verloren gaat tussen ontdekking en oplevering.

Probeer Jira Product Discovery vandaag nog, gratis!

Veelgestelde vragen over productbriefings

Hoe lang moet een productbriefing zijn?

Een productbriefing moet lang genoeg zijn om iedereen op één lijn te krijgen en kort genoeg dat mensen hem daadwerkelijk lezen. In de meeste gevallen betekent dat: één tot twee pagina's. Een briefing langer dan dat, is waarschijnlijk eerder een PRD. 

Als je gedetailleerde vereisten, userstory's of UX-specificaties opneemt, horen die in een apart document dat wordt opgesteld nadat de briefing is beoordeeld en het team heeft besloten om door te gaan.

Wie schrijft een productbriefing?

Productbriefings worden meestal geschreven door een productmanager, maar de input moet uit het hele team komen. Teams voor ontwerp, engineering, verkoop, support en klantsucces hebben vaak context die de probleembeschrijving, doelgroepdefinitie of risicoanalyse vormgeeft. 

Wanneer moet je een projectbriefing maken?

Een productbriefing is het nuttigst aan het begin van productontdekking of in de vroege fase van productplanning, voordat het team zich al in belangrijke mate ertoe heeft verbonden om iets te realiseren. 

Als je nog evalueert of een idee de moeite waard is om na te streven, is een briefing het juiste hulpmiddel. Zodra het team heeft besloten om door te gaan, vormt de briefing de basis voor de roadmap, de backlog en uiteindelijk het PRD.