MVP scope: wat je NIET bouwt is belangrijker

De term MVP — minimum viable product — komt van Frank Robinson en werd mainstream met Eric Ries's boek "The Lean Startup" (2011). Het belangrijkste woord is minimum. Het is ook het woord dat beginners het slechtst horen: na "niemand heeft het nodig", is de grootste killer van lanceringen "het is nooit gelanceerd" — het product zwol op met functies en kwam nooit uit. Deze les gaat over het mes waarmee je de scope snijdt.

De belangrijkste gebruikersloop

Beschrijf het ÉNE pad waar mensen voor betalen: komt aan → doet het belangrijkste → krijgt de waarde → komt terug. Voorbeeld (een gespreks-samenvattingsdienst): upload een opname → krijg notities met actiepunten → stuur ze naar het team. Alles wat niet in die loop zit, is geen MVP.

Het klassieke voorbeeld: de eerste versie van Instagram heette Burbn en deed check-ins, afspraakplannen, punten en foto's. Gebruikers raakten alleen de foto's aan. Kevin Systrom sneed al het andere weg en hield één loop over: maken → filteren → plaatsen. Twee jaar later kocht Facebook het voor een miljard dollar. De loop draagt het product; de extra's laten het zinken.

Het scope-mes: drie lijsten

1. Nu (de loop + inloggen + betaling): zonder dit is er geen product.
2. Later (zodra je echte gebruikers hebt): thema's, integraties, teams, instellingen.
3. Niet-voor-nu (de verleidingen): een mobiele app, een API, een marktplaats. Schrijf het op, en vergeet het dan totdat je honderd klanten hebt.

De test voor elke functie: "Zou een gebruiker in de eerste maand weglopen als dit ontbreekt?" Nee — dan gaat het naar lijst twee. Die ene vraag bespaart weken.

Een Socratische pauze

Je staat op het punt om "notificatie-instellingen" toe te voegen aan de MVP. Stop jezelf en vraag: zou één persoon in de eerste maand weggaan als notificaties gewoon werkten met verstandige standaardinstellingen, zonder opties? Het antwoord is bijna altijd nee. Wat betekent: "later" lijst.

Beginnersmythes

• "Een MVP is een slecht product." Nee. Het is een smal maar goed product: één ding goed gedaan, niet tien slecht.
• "Het werkt niet zonder social login / dark mode / een mobiele app." Producten werken met de kale loop. De 'polish' komt bovenop echte gebruikers.
• "Ik voeg het voor de zekerheid toe." "Voor de zekerheid" is de duurste zin in software. Elke functie is code, bugs en onderhoud — voor altijd.

De productbrief voor AI

We nemen de brief uit de vibe coding cursus en laten die uitgroeien tot een productbrief:

Product: [name] — [for whom] — [core value].
Loop: [the user's steps].
Pages: landing, sign-in, the app (one working screen!), minimal settings.
Data: [entities and fields — as taught in the database lesson].
Not in the MVP: [the "later" list — put it right in the brief so the AI doesn't build extras].
Style: [reference + palette].

Die "niet in de MVP" regel is het geheime ingrediënt. Een AI-assistent (een model dat code schrijft op basis van jouw beschrijving) helpt graag en vult de gaten op: vraag om een inlogformulier en je krijgt wachtwoordherstel, tweefactorauthenticatie en een profielinstellingenpagina erbij. Een expliciet verbod houdt de scope aan de lijn.

Tempo en diagnose

Een MVP gebouwd met deze brief in Lovable/Replit kost 2–4 weken avonden. Als je schatting langer uitvalt, is de scope nog te breed: snijd de loop terug tot één scenario. De regel is simpel — de vraag is niet "wat kan ik nog meer toevoegen", maar "wat kan ik weggooien terwijl de loop intact blijft". Elk weggelaten ding is een dag die je niet hebt verspild.

Waar het misgaat: "Ik kan niets weglaten, alles is belangrijk"

De meest voorkomende tegenwerping in deze les klinkt als: "maar alles in mijn product is verbonden, er kan niets weg." Dat is bijna altijd de illusie van te dicht bij je eigen idee staan. Test het eerlijk: neem de functie die je "niet kunt verwijderen" en stel je een gebruiker voor die deze in de eerste maand nooit opent. Krijgen ze dan nog steeds waarde? Zo ja, dan zit die functie niet in de loop — het kan en moet wachten.

Je snijdt de scope niet omdat de functies slecht zijn, maar omdat ze nu voorkomen dat het product wordt gelanceerd. Uitgesteld is niet weggegooid; het wacht op zijn beurt op de "later" lijst.

Hoe dit aansluit op andere cursussen

De data en entiteiten voor de brief (wat op te slaan en hoe) krijgen later in deze cursus een eigen les over accounts en data, en de basis 'build-from-a-brief' techniek vind je in de vibe coding cursus. Hier verandert de brief van technisch naar productgericht — met die expliciete "niet in de MVP" regel.

Doe dit nu (5 minuten)

Neem je idee van de vorige les en schrijf de loop als één lijn van pijlen. Maak vervolgens een lijst van alles wat in het product moet komen en sorteer het eerlijk in de drie lijsten. Als "Nu" meer dan 5 items heeft, blijf dan snijden.