MVP-omfang: hvad du IKKE skal bygge, er vigtigere

Begrebet MVP – minimum viable product – kom fra Frank Robinson og blev mainstream med Eric Ries' bog "The Lean Startup" (2011). Det bærende ord er minimum. Det er også det ord, begyndere hører dårligst: efter „ingen har brug for det“ er den største dræber af lanceringer „det blev aldrig sendt afsted“ – produktet svulmede med funktioner og kom aldrig ud af døren. Denne lektion handler om kniven, du bruger til at skære omfanget ned med.

Det centrale brugerloop

Beskriv DEN ENESTE vej, folk betaler for: ankommer → gør det vigtigste → får værdien → kommer tilbage. Eksempel (en opkaldsresumé-tjeneste): upload en optagelse → få noter med handlingspunkter → send dem til teamet. Alt, der ikke er på det loop, er ikke et MVP.

Det klassiske eksempel: den første version af Instagram hed Burbn og håndterede check-ins, mødeplaner, point og fotos. Brugere rørte kun ved fotos. Kevin Systrom skar alt andet væk og beholdt ét loop: tag billede → filtrer → post. To år senere købte Facebook det for en milliard dollars. Loopet bærer produktet; det ekstra får det til at synke.

Omfangskniven: tre lister

1. Nu (loopet + login + betaling): uden dette er der intet produkt.
2. Senere (når du har rigtige brugere): temaer, integrationer, teams, indstillinger.
3. Ikke-nu (fristelserne): en mobilapp, en API, en markedsplads. Skriv det ned, og glem det så, indtil du har hundrede kunder.

Testen for hver funktion: „Ville en bruger forlade produktet i den første måned, hvis dette manglede?“ Nej – så ryger det på liste to. Det ene spørgsmål sparer uger.

En sokratisk pause

Du er ved at tilføje „notifikationsindstillinger“ til MVP'et. Stop dig selv og spørg: ville en eneste person forlade produktet i den første måned, hvis notifikationer bare fungerede med fornuftige standardindstillinger, uden indstillinger? Svaret er næsten altid nej. Hvilket betyder: „senere“-liste.

Begyndermyter

• „Et MVP er et dårligt produkt.“ Nej. Det er et smalt, men godt produkt: én ting gjort godt, ikke ti gjort dårligt.
• „Det vil ikke fungere uden social login / dark mode / en mobilapp.“ Ting fungerer på det bare loop. Poleringen tilføjes oven på rigtige brugere.
• „Jeg tilføjer det bare for en sikkerheds skyld.“ „Bare for en sikkerheds skyld“ er den dyreste sætning i software. Hver funktion er kode, bugs og vedligeholdelse – for evigt.

Produktbeskrivelsen til AI

Vi tager briefen fra vibe coding-kurset og udvider den til en produktbeskrivelse:

Product: [navn] — [til hvem] — [kerneværdi].
Loop: [brugerens trin].
Pages: landing, sign-in, appen (én fungerende skærm!), minimale indstillinger.
Data: [entiteter og felter — som undervist i databasen lektionen].
Not in the MVP: [„senere“-listen — sæt den direkte i briefen, så AI ikke bygger ekstra].
Style: [reference + palette].

Den linje „Not in the MVP“ er den hemmelige ingrediens. En AI-assistent (en model, der skriver kode ud fra din beskrivelse) elsker at være hjælpsom og udfylde hullerne: bed om en loginformular, og du får adgangskodegendannelse, tofaktorautentificering og en profilindstillingsside smidt med i købet. Et eksplicit forbud holder omfanget i snor.

Tempo og diagnose

Et MVP bygget ud fra denne brief i Lovable/Replit tager 2–4 ugers aftener. Hvis dit estimat er længere, er omfanget stadig for stort: skær loopet ned til ét enkelt scenarie. Reglen er enkel – spørgsmålet er ikke „hvad mere kunne jeg tilføje“, det er „hvad kan jeg ellers smide ud, mens jeg holder loopet intakt?“. Hver kasseret ting er en dag, du ikke spildte.

Hvor det går galt: „Jeg kan ikke skære noget væk, det er alt sammen vigtigt“

Den mest almindelige indvending i denne lektion lyder: „men alt i mit produkt hænger sammen, intet kan fjernes.“ Det er næsten altid illusionen om at stå for tæt på din egen idé. Test det ærligt: tag den funktion, du „ikke kan fjerne“, og forestil dig en bruger, der aldrig åbner den i den første måned. Får de stadig værdi? Hvis ja, er den funktion ikke på loopet – den kan og bør vente. Du skærer ned på omfanget, ikke fordi funktionerne er dårlige, men fordi de lige nu forhindrer produktet i at blive sendt afsted. Udskudt er ikke kasseret; det venter på sin tur på „senere“-listen.

Hvordan dette hænger sammen med andre kurser

Data og entiteter til briefen (hvad der skal gemmes og hvordan) får deres egen lektion om konti og data senere i dette kursus, og den grundlæggende bygge-ud-fra-en-brief-teknik findes i vibe coding-kurset. Her forvandles briefen fra teknisk til produktformet – med den eksplicitte linje „not in the MVP“.

Gør dette nu (5 minutter)

Tag din idé fra sidste lektion og skriv loopet som én linje med pile. List derefter alt, hvad der skal med i produktet, og sorter det ærligt i de tre lister. Hvis „Nu“ har mere end 5 punkter, så bliv ved med at skære ned.