← Alle artikelen
Bouw het juiste product
Hoe je een productbrief van één pagina schrijft die echt wordt gebruikt
Door het FabricLoop Team · Mei 2026 · 4 minuten leestijd
De meeste productbriefs delen hetzelfde lot: zorgvuldig geschreven voordat een project begint, één keer besproken in een kickoffmeeting en daarna nooit meer geopend. Tegen de tijd dat het team midden in de bouw zit, is de brief een historisch artefact — af en toe aangehaald in discussies over scope, maar zelden gebruikt als levende gids voor besluitvorming.
Dat is een fout in het proces, niet in het format. De brief wordt niet gebruikt omdat hij niet is geschreven om gebruikt te worden. Hij is geschreven om aan een proces te voldoen — om het vakje "we hebben de requirements gedefinieerd" aan te vinken — en niet om het team echt te helpen betere beslissingen te nemen onder onzekerheid.
Een brief die wordt gebruikt, is kort, heeft een duidelijke mening en is opgebouwd rond de vragen die het team midden in de bouw echt stelt: wat lossen we op, voor wie, en hoe weten we of het gewerkt heeft?
"Een brief is geen requirementsdocument. Het is een naslagwerk voor besluitvorming — één pagina waar het team naar kan terugkeren wanneer het niet zeker weet of een designkeuze of een scopebeslissing klopt."
De vijf onderdelen die ertoe doen
Alles in een productbrief moet antwoord geven op een van vijf vragen. Beantwoordt een onderdeel geen van deze vragen, dan hoort het waarschijnlijk niet in een brief van één pagina — dan hoort het in een aparte, meer gedetailleerde specificatie.
Probleem
Gebruikers missen belangrijke updates omdat ze geen onderscheid kunnen maken tussen meldingen met een sterk signaal (iemand heeft hen een taak toegewezen) en meldingen met een zwak signaal (een reactie in een thread die ze volgen). Het gevolg: ze negeren alle meldingen of zetten ze helemaal uit. Supporttickets met de strekking "ik wist het niet" zijn dit kwartaal goed voor 18% van alle klachten over het product.
Gebruikers
Primair: teamleads en projecteigenaren die vaak worden genoemd en het volume niet kunnen bijhouden. Secundair: individuele bijdragers die standaard rust willen maar kritieke toewijzingen niet mogen missen. Niet gericht op beheerders — hun meldingsbehoeften worden afgedekt door het beheerpaneel.
Succesmetric
Primair Supporttickets gerelateerd aan meldingen dalen met 40% binnen 60 dagen na lancering.
Secundair Wekelijk actieve gebruikers die voorkeuren hebben aangepast, nemen toe van 12% naar 35%.
Leidende indicator Opt-outpercentage (gebruikers die alle meldingen uitschakelen) daalt van 23% naar onder 15%.
Buiten scope
- Voorkeuren voor e-mailmeldingen (apart werkitem — andere infrastructuur)
- Meldingsinstellingen per werkruimte (later; deze release is alleen per gebruiker)
- Plannen van meldingen / niet-storenuren (gevalideerde behoefte, roadmap Q3)
- Gedetailleerde instellingen voor mobiele pushmeldingen (eerst web; mobiel volgt als dit wordt gevalideerd)
Open vragen
Blokkerend Verdelen we meldingen in 2 lagen (kritiek / alles anders) of laten we granulaire per-type controle toe? Gebruikersinterviews suggereren 2 lagen, maar engineering prefereert granulaire voor flexibiliteit. Beslissing nodig voordat design begint.
Niet blokkerend Moeten voorkeurwijzigingen retroactief van toepassing zijn op bestaande meldingen? Kan beslist worden tijdens build op basis van technische kosten.
Waarom "buiten scope" het belangrijkste onderdeel is
Teams besteden veel tijd aan het opschrijven van wat ze gaan bouwen. Ze besteden heel weinig tijd aan wat ze niet gaan bouwen — en die scheefgroei veroorzaakt de meeste scope creep. Als de designer een schakelaar voor "stille uren" toevoegt omdat dat logisch lijkt, of de engineer instellingen per werkruimte toevoegt omdat hij toch al in dat deel van de code zit, komt dat meestal doordat niemand expliciet heeft besloten dat dit buiten scope viel.
Items buiten scope opschrijven dwingt een gesprek over grenzen af dat anders midden in de bouw zou plaatsvinden, wanneer koerswijzigingen veel duurder zijn. Het geeft de PM ook een duidelijke, gedocumenteerde basis om nee te zeggen tegen toevoegingen: "We hebben in de brief besloten dat dit buiten scope valt — dit is waarom."
Zo schrijf je goede items voor buiten scope
Som niet alleen op wat je niet bouwt — noteer ook kort waarom. "E-mailvoorkeuren (aparte infrastructuur)" vertelt de lezer dat het besluit bewust en beredeneerd is genomen en geen vergissing was. Zo voorkom je dat dezelfde scopevraag tijdens de sprint drie keer terugkomt.
Open vragen: het onderdeel dat de meeste briefs weglaten
Elk project begint met onbeantwoorde vragen. De meeste briefs doen alsof dat niet zo is — ze zijn geschreven alsof alle beslissingen al zijn genomen, ook als de auteur weet dat dat niet zo is. Het gevolg is dat teams de open vragen pas midden in de bouw ontdekken, wanneer ze het meest verstorend zijn.
Open vragen expliciet benoemen doet twee dingen. Ten eerste maakt het zichtbaar welke vragen moeten worden beantwoord voordat het werk begint (blokkerend) en welke tijdens de bouw kunnen worden beslist (niet blokkerend). Ten tweede laat het het team weten dat de brief een werkdocument is en geen afgeronde specificatie — wat de kans vergroot dat ze erop terugkomen en hem bijwerken naarmate er besluiten worden genomen.
De valkuil van de lengte
Een brief die langer wordt dan één pagina is geen brief meer — het is een specificatiedocument. Specificaties hebben hun plaats, maar ze dienen een ander doel. Merk je dat je meer dan één pagina nodig hebt, haal de details dan eruit, zet ze in een gekoppelde bijlage en houd de brief bij de vijf kernonderdelen.
Hoe FabricLoop de brief levend houdt
Een brief blijft alleen nuttig als het team hem kan vinden en bijwerken. FabricLoop pint de brief vast in de projectthread, zodat hij altijd één klik weg is — en het gesprek eromheen (genomen besluiten, beantwoorde open vragen, scopewijzigingen) staat precies daar in de context, in plaats van verspreid over e-mail en Slack.
10 dingen om uit dit artikel mee te nemen
- De meeste productbriefs worden geschreven om aan een proces te voldoen, niet om teams te helpen betere beslissingen te nemen. Daarom worden ze nooit meer gebruikt.
- Een brief is een naslagwerk voor besluitvorming, geen requirementsdocument. Hij moet de vragen beantwoorden die midden in de bouw opkomen.
- De vijf onderdelen die ertoe doen: Probleem, Gebruikers, Succesmetric, Buiten scope, Open vragen. Al het andere is een specificatie.
- Het onderdeel Probleem moet de pijn van de gebruiker concreet beschrijven — waar mogelijk met data — en niet alleen het aan te pakken gebied noemen.
- Benoemen voor wie je níet bouwt is even belangrijk als benoemen voor wie je wel bouwt. Onduidelijkheid over gebruikers veroorzaakt scope creep in het design.
- Succesmetrics moeten meetbaar en tijdgebonden zijn en vóór de start van de bouw zijn afgesproken — niet achteraf worden afgeleid uit gebruiksdata.
- Het onderdeel Buiten scope is het belangrijkste. Scopegrenzen die niet zijn opgeschreven, schuiven tijdens de bouw vrijwel zeker op.
- Geef items buiten scope een korte reden, zodat dezelfde vragen niet tijdens de sprint opnieuw opduiken.
- Open vragen moeten expliciet worden gelabeld als blokkerend (beslissen vóór de bouw) of niet blokkerend (beslissen tijdens de bouw).
- Een brief die langer is dan één pagina is een specificatie geworden. Haal de details eruit, zet ze in een bijlage en houd de brief strak.
