Ontwikkelsnelheid is een frictieprobleem, geen inspanningsprobleem
Tien jaar lang was het mijn werk om de frictie in een funnel te vinden, weg te halen en de winst te meten. Het duurde gênant lang voordat ik diezelfde methode op mijn eigen ontwikkelproces richtte — dat natuurlijk óók een funnel is: idee erin, opgeleverde wijziging eruit. Toen ik het eindelijk deed, zat de bottleneck niet waar ik hem verwachtte.
"Sneller werken" wordt bijna altijd opgevat als "sneller bouwen" — vlotter typen, meer uren maken. Maar ontwikkelsnelheid is geen typsnelheid. Het is de doorvoer van gevalideerde wijzigingen per week. En de snelheidsremmers zitten vrijwel nooit in het bouwen. Ze zitten in de gaten eromheen: de tijd die je vastzit om een vaag idee concreet te maken, de tijd die je wacht om erachter te komen of het werkte, de tijd die je kwijt bent aan het herbouwen van het verkeerde ding. Bouwen is het snelle deel. De mist rond het bouwen is het trage deel.
De structuur die de hoogste snelheid oplevert, is dus de structuur die de afstand van idee tot bewijs minimaliseert — en je op elk moment één concrete, opleverbare, meetbare volgende actie in handen houdt. Je zit nooit in de mist. Ik noem het de kortste weg naar bewijs.
De grootste hefboom is degene die de meeste mensen wegzetten als "soft skill": algemeen onderzoek en een ruw idee omzetten in een concrete actie. Die omzetting — van een vage "we zouden de onboarding moeten verbeteren" naar "bouw X, verwacht Y, meet met Z, deze week op te leveren" — is precies waar teams in stilte de meeste tijd verliezen. Maak het systematisch en alles wat erna komt gaat sneller. Hier is de structuur, vijf stappen, elk met een test zodat het concreet blijft en niet verandert in een poster aan de muur:
- Signaal erin, geen mening. Begin vanuit iets echts — onderzoek, data, een klacht van support, een ruw idee. Test: kun je de bron aanwijzen? Als het eerlijke antwoord "Ik denk…" is, ga dan eerst een signaal halen voordat je bouwt.
- Comprimeer tot de kleinste falsifieerbare actie. Herschrijf het vage idee als één zin: bouw X, verwacht Y, meet met Z, deze week op te leveren. Test: als je die zin niet kunt opschrijven, is het nog niet concreet — verklein de scope tot het wel lukt. Snelheid komt voort uit het klein maken van de eenheid.
- Lever op achter guardrails. Omkeerbaar en begrensd, zodat snel bewegen veilig is. Test: kun je het binnen een minuut ongedaan maken? Omkeerbaarheid is wat snelheid toestaat — je beweegt snel omdat fouten goedkoop zijn, niet omdat je voorzichtig doet.
- Meet op twee manieren, snel. Een A/B- of voor/na-meting voor wat werkte; één kwalitatieve blik voor waarom. Test: de succesmetric werd al in stap twee gedefinieerd, vóór je bouwde — je verzint hem nooit achteraf om het resultaat er goed uit te laten zien.
- Laat het resultaat de volgende actie voortbrengen. Een succes schaal je op; een mislukking gaf je net de volgende hypothese. Test: je verlaat elke loop al met de volgende concrete actie in handen — je hoeft de mist nooit opnieuw in.
Snelheid is niet harder werken. Het is nooit in ambiguïteit zitten — altijd één concrete, omkeerbare, meetbare volgende actie in handen houden.
Wat het tot een structuur maakt die snelheid veroorzaakt in plaats van alleen maar "hard je best doen", is dat elke loop de volgende verkort. Je defaults worden scherper, je guardrails worden hergebruikt, je vertaling van ruw idee naar concrete actie gaat sneller. Het systeem versnelt zichzelf. Het is geen theorie — het is de loop die AcePilot onbeheerd draait over meer dan veertig van mijn eigen projecten, en dezelfde discipline achter tien jaar conversiewerk: vertrouw nooit wat je niet kunt meten, en blijf nooit stilzitten in de mist.
