Hoe je dingen echt gebouwd krijgt
Ik heb op 8 mei 2025 wat aanpassingen gedaan om een paar punten te verduidelijken. Ik was bang dat ik het harde werk achter het bouwen van producten te kort had gedaan en wilde daar duidelijk over zijn. Mijn oorspronkelijke formulering staat er nog bij ter referentie. Ik wil niemand beledigen, maar ik wil eerlijk zijn over de uitdagingen waar we mee te maken hebben. Misschien deed ik dat onbedoeld wel. Mijn excuses. Ik heb mijn tekst aangepast om het helderder te maken.
Productteams maken dingen vaak te ingewikkeld.
Ze schrijven uitgebreide PRD’s, doen uitputtend gebruikersonderzoek en volgen Agile tot op de letter. Maar ergens onderweg verliezen ze het eigenlijke doel uit het oog: waarde leveren aan gebruikers.
Die overcomplicatie komt voort uit zorg. Mensen willen goed werk leveren, dus stapelen ze proces en documentatie op. Maar meer lagen betekent niet meer duidelijkheid. Vaak vertraagt het alleen alles.
Productteams gebruiken PRD’s vaak als de definitieve kaart voor oplevering: gedetailleerd, doordacht en gebaseerd op klantonderzoek. En terecht.
Maar vanuit engineeringperspectief voelen deze documenten soms alsof ze zijn geoptimaliseerd voor herleidbaarheid en context, niet voor duidelijkheid bij de uitvoering.
Dit is geen kritiek op de zorgvuldigheid of aanpak. Het zegt eerder iets over hoe complex productontwikkeling tegenwoordig is. Maar als ik aan het bouwen ben, heb ik een blauwdruk nodig. Een heldere, vereenvoudigde weergave van wat er wordt verwacht, hoe het werkt en hoe succes eruitziet in code.
Dan komt daar nog de haperende communicatie bij. Teams werken op verschillende manieren. Zonder gedeelde taal of afstemming ontstaan er gaten door die verschillen. En die gaten zorgen voor vertraging.
Dan is er de MVP, die verkeerd wordt begrepen en misbruikt. Het gaat er niet om een half afgemaakte versie van het product te lanceren. Het is een minimaal op te leveren weddenschap: een toetsbare hypothese met net genoeg gebouwd om iets te bewijzen of te weerleggen. Landt het niet? Gooi het weg en ga verder.
“Keep It Simple, Stupid”, het oude KISS-principe, geldt nog steeds. Eenvoud wordt onderschat. Zeker als je snel iets wilt bouwen met een team van slimme mensen die allemaal anders denken.
Dave Thomas, een van de auteurs van het Agile Manifesto, zei het goed:
“Agile has become a noun, and that’s the problem. We need to focus on agility.”
Wendbaarheid is het doel. Geen regels, geen rituelen, gewoon snel kunnen reageren. Je wilt van richting kunnen veranderen zonder wrijving.
De weg vooruit is doodsimpel: minder opgeblazenheid, meer duidelijkheid.
Begin met blauwdrukken van één pagina. Alleen de essentie:
- Gebruikersreizen: wie probeert wat te doen?
- MoSCoW-prioriteiten: wat moet er gebeuren en wat valt buiten scope?
Behandel dit als levende documenten. Bewaar ze in Notion of waar je ook samenwerkt. Verandert er iets, werk dan de blauwdruk bij. Ping het team. Is het een grote verschuiving, plan dan tijd in om weer op één lijn te komen.
Dat is je bron van waarheid, geen PM-tool en geen Jira-bord.
Gebruik Linear (of Jira als je jezelf haat) om bij te houden wat er moet gebeuren. Niet om randgevallen of de geschiedenis van beslissingen in te loggen. Als een randgeval ertoe doet, voeg het dan toe aan de acceptatiecriteria of leg het vast in de blauwdruk. Anders vervuil je het bord alleen maar.
Bij de technische uitwerking kunnen engineers terugvallen op UML’s, ERD’s, sequence diagrams en alle andere gebruikelijke middelen. Dat is hun wereld. Maar de rest van het document? Dat is een brief van Product aan Engineering. En zo moet het ook lezen.
Helder. Gefocust. Geen poespas.
En als iets eenmaal gebouwd is, is testen niet alleen iets voor developers. Product is eigenaar van de hypothese. Je hebt met gebruikers gesproken. Je hebt het afgebakend. Ga nu terug en valideer. Werkte het? Loste het echt het probleem op?
Dit hele proces is een prachtige machine als het soepel draait. Als dat niet zo is, is het een puinhoop. Maar de oplossing is niet meer proces. Het is minder. Precies genoeg. Genoeg om mensen op één lijn te krijgen, niet om ze te verlammen.
Wil je er dieper in duiken: