Zo schrijf je een productbrief voor een digitaal bureau

Een slechte brief kost meer tijd dan geen brief. Dat klinkt misschien vreemd, maar we zien het regelmatig bij Livewall: een document vol aannames en vage doelen dat een bureau drie weken in de verkeerde richting stuurt. Vervolgens begint het hele traject opnieuw.

Een goede productbrief is geen functioneel ontwerp. Het is geen lijst met features. Het is een heldere uiteenzetting van het probleem dat je wilt oplossen, voor wie, en hoe succes eruitziet. Hoe specifieker je bent over het probleem en het gewenste resultaat, hoe meer ruimte je een bureau geeft om de beste oplossing te bedenken.

Dit artikel legt uit hoe je een brief schrijft die werkt, wat je erin opneemt, en wat je beter weg kunt laten.

Begin met het probleem, niet de oplossing

De meest voorkomende fout in een productbrief: de opdrachtgever beschrijft al een oplossing voordat het probleem duidelijk is. 'We willen een app bouwen waarmee gebruikers X kunnen doen' is geen probleemstelling. Het is een aanname.

Begin in plaats daarvan met de situatie. Wat gebeurt er nu? Wat werkt er niet? Wie ervaart dat probleem, en in welke context? Hoe weet je dat dit daadwerkelijk een probleem is en niet een aanname van intern?

Een goede probleemstelling klinkt zo: 'Nieuwe medewerkers starten zonder context over hun rol en hun team. Dat leidt tot hogere uitval in de eerste maand en meer druk op leidinggevenden.' Vanuit die beschrijving kan een bureau zoals Livewall relevante oplossingen voorstellen. Soms is dat een preboarding-tool, soms is het iets heel anders.

Beschrijf je doelgroep concreet

Niet 'consumenten tussen 25 en 45 jaar'. Beschrijf de mensen voor wie je bouwt zo precies mogelijk. Welk apparaat gebruiken ze? Wanneer en waarom komen ze in aanraking met het product? Wat weten ze al, en wat verwachten ze?

Bij het Sportvisunie platform was de doelgroep heel specifiek: sportvissers die kennis wilden delen en lokale clubs online met elkaar wilden verbinden. Dat stuurde elke UX-beslissing. Algemene persona's helpen niet. Concrete gedragsbeschrijvingen wel.

Definieer succes meetbaar

Wat is het gewenste resultaat van dit digitale product? Wees hier zo concreet mogelijk. 'Meer engagement' is geen doel. 'Terugkerende gebruikers binnen zeven dagen na eerste bezoek' is dat wel.

Goede succescriteria zijn:

• Gedragsmatig: wat doen gebruikers die het product goed gebruiken?
• Meetbaar: kunnen we dit bijhouden na livegang?
• Realistisch: gebaseerd op een aanname die we kunnen testen

Het helpt ook om te beschrijven wat falen eruitziet. Als gebruikers na één keer afhaken, of als de doorlooptijd voor taak X langer is dan Y seconden, dan weten we dat het product niet werkt. Deze anti-criteria zijn even waardevol als de positieve KPI's.

Schets de technische context

Een digitaal bureau kan geen goede schatting maken zonder te weten met welke systemen het product moet samenwerken. Beschrijf de bestaande stack: welke CMS, CRM, of ander systeem moet het nieuwe product aan koppelen? Zijn er restricties rondom hosting, beveiliging, of authenticatie?

Dit hoeft geen technisch document te zijn. Een zin als 'het product moet aansluiten op ons Salesforce CRM en Single Sign-On via Azure AD ondersteunen' geeft al enorm veel context. Het vermijdt verrassingen halverwege het traject.

Bij de KLM scalable growth case was de integratie met bestaande systemen over 50+ markten een bepalende factor in de architectuurkeuzes. Dat soort context hoort thuis in de brief, niet pas in week vier van de samenwerking.

Budget en doorlooptijd: wees eerlijk

Veel opdrachtgevers houden hun budget bewust vaag in de hoop een lagere prijs te krijgen. Dat werkt averechts. Een bureau dat het budget niet kent, ontwerpt een oplossing die misschien twee keer zo duur is als wat je kunt uitgeven, of juist te eenvoudig voor wat je nodig hebt.

Vermeld een bandbreedte. 'We denken aan een initiële investering tussen €40.000 en €70.000' geeft een bureau genoeg ruimte om een passende aanpak voor te stellen. Zonder dat kader is elk voorstel een gok.

Ditzelfde geldt voor doorlooptijd. Is er een harde deadline, bijvoorbeeld een evenement of seizoen? Is er ruimte om stapsgewijs te bouwen? Wanneer wil je live gaan met een eerste versie? Hoe eerder je dit deelt, hoe beter een bureau de planning kan inrichten.

Wat je buiten de brief laat

Een productbrief is geen functioneel ontwerp. De volgende zaken horen er niet in thuis:

• Wireframes of schermschetsen die de oplossing al vastleggen
• Technische specificaties die nog niet vaststaan
• Uitgebreide samenvatting van interne discussies
• Wensen van stakeholders die niet het primaire doel raken

Hoe korter en helderder de brief, hoe beter. Vijf pagina's die het probleem, de doelgroep, de succescriteria, de technische context en het budget beschrijven werken beter dan twintig pagina's met achtergrondinformatie.

Een checklist voor je brief

Voor je de brief verstuurt, doorloop je deze vragen:

Probleemstelling

• Is het probleem beschreven vanuit de gebruiker, niet vanuit een gewenste feature?
• Hebben we bewijs dat dit probleem daadwerkelijk bestaat?

Doelgroep

• Is de doelgroep concreet genoeg om UX-beslissingen op te baseren?
• Zijn er meerdere gebruikerstypen met verschillende behoeften?

Succes

• Zijn de succescriteria meetbaar en gedragsmatig?
• Hebben we ook beschreven wat falen eruitziet?

Technische context

• Zijn alle relevante systeemintegraties benoemd?
• Zijn er restricties rond hosting, beveiliging, of authenticatie?

Randvoorwaarden

• Is er een budget bandbreedte vermeld?
• Is de gewenste doorlooptijd en eventuele harde deadline duidelijk?

Als je op alle vragen een goed antwoord hebt, is je brief klaar. Niet eerder.