Van idee naar MVP: hoe structureer je een sprint van 8 weken

Acht weken. Voor veel teams voelt dat te kort. Maar in onze ervaring bij Livewall is de tijdsduur zelden het echte probleem. Het probleem is scope-drift, onduidelijke besluitvorming en te late feedback van echte gebruikers.

Een sprint van 8 weken werkt als je hem bewust inricht. Niet als een race waarbij je halverwege realiseert dat je de verkeerde kant op bent gerend, maar als een strak gestructureerd traject van idee naar werkend product dat je bij echte gebruikers kunt testen.

Hieronder leggen we uit hoe wij dat aanpakken bij MVP-ontwikkeling, wat elke fase oplevert en waar teams het meest de mist in gaan.

Week 1 en 2: scope vaststellen, niet uitbreiden

De eerste twee weken gaan over één ding: bepalen wat je niet bouwt. Elke sprint begint met een verlanglijst. Teams willen dashboards, notificaties, gebruikersrollen, exportfuncties. Allemaal begrijpelijk. Maar een MVP dat alles probeert, valideert niets.

We starten altijd met één kernvraag: wat is de één aanname die, als die niet klopt, het hele product overbodig maakt? Dat is wat je valideert. De rest volgt later.

In week 1 voer je gebruikersgesprekken, definieer je de kernfunctie en schrijf je de productbrief. In week 2 sluit je scope definitief af. Geen nieuwe wensen meer daarna, tenzij iets fundamenteel is veranderd in het begrip van het probleem. Dit klinkt rigide, maar het is wat de sprint mogelijk maakt.

Week 3 en 4: ontwerp als beslissing, niet als decoratie

Ontwerp in een MVP-sprint is geen verflaag achteraf. Het is de plek waar je productbeslissingen neemt. Welke stroom is de kern? Hoeveel stappen heeft de onboarding? Wat ziet een gebruiker als eerste?

Bij UX/UI-ontwerp werken we in deze fase met clickable prototypes, geen statische schetsen. Dat dwingt het team om echte beslissingen te nemen over interactie, niet alleen over uiterlijk. Een prototype dat je kunt aanklikken brengt meningsverschillen naar boven die je nooit had ontdekt in een Word-document.

Aan het einde van week 4 heb je een gevalideerd ontwerp dat door development kan worden opgepakt. Geen open vragen meer over de kernfunctie. Details mag je later oplossen. De structuur niet.

Week 5 en 6: bouwen met focus

Dit is de bouwfase. En dat klinkt vanzelfsprekend, maar de discipline hier is: bouw alleen wat in scope zit. Geen kleine uitbreidingen, geen "dit kost toch maar een uurtje". Iedere afwijking kost meer dan het uur zelf, want het trekt de aandacht weg van wat telt.

We werken in deze fase met korte daily check-ins, niet als ritueel, maar als mechanisme om blokkades vroeg te signaleren. Als een technische keuze risico oplevert, wil je dat weten op dag drie van week 5, niet op de laatste dag van week 6.

Het doel aan het einde van week 6 is simpel: een werkend product dat de kernfunctie bedient. Niet mooi afgewerkt, wel functioneel en stabiel genoeg om te testen.

Week 7 en 8: testen met echte mensen

Hier gaat het mis bij veel teams: ze plannen de gebruikerstest in de laatste drie dagen en gaan dan verder met bouwen gebaseerd op hun eigen aannames. Dat is geen test, dat is afsluiting.

Wij reserveren twee volledige weken voor testing. Niet om alles te herschrijven, maar om te valideren. Je zoekt naar patronen, niet naar perfectie. Als vijf van de zes testgebruikers vastlopen op dezelfde plek, is dat een signaal. Als één iemand iets onverwachts doet, is dat interessant maar niet definitief.

De uitkomst van week 8 is niet een afgewerkt product. Het is een gevalideerde basis met een helder beeld van wat werkt, wat niet werkt en wat de volgende iteratie nodig heeft. Dat is wat webapplicatieontwikkeling op deze schaal oplevert: niet het eindproduct, maar de zekerheid om verder te bouwen.

Wat de sprint mogelijk maakt

Een sprint van 8 weken is geen methode, het is een discipline. Het werkt alleen als een aantal dingen kloppen:

Één beslisser. Niet een commissie, niet een team van vijf dat consensus zoekt. Eén persoon die eindverantwoordelijk is en snel beslist.

Vaste scope. Na week 2 gaan er geen nieuwe wensen in. Wat er na de sprint bovenkomt, gaat op de backlog.

Wekelijkse alignment. Niet als controle, maar als kans om missers vroeg te zien.

Bij Livewall werken we met geïntegreerde teams van strategen, ontwerpers en developers die samen aan één product werken. Geen handoffs, geen wachtmomenten. Dat maakt het tempo van 8 weken haalbaar, ook voor complexere producten.