Definition
Minimum Viable Product er det mindste du kan sende ud som løser problemet nok til at nogen bruger eller betaler for det seriøst og genererer data du kan lære fra.
Hvorfor det betyder noget
MVP'et er hvor de fleste iværksættere mister seks måneder. De tilføjer "bare endnu en feature" i stedet for at sende det ud. I mellemtiden ændrer markedet sig, teamet bliver udmattet, og der sker ingen læring. Drew Houstons oprindelige Dropbox MVP var en 3-minutters videodemo af et produkt, der ikke engang eksisterede - 75.000 mennesker tilmeldte sig ventelisten på en weekend, hvilket beviste efterspørgsel før en eneste linje synkroniseringskode var skrevet. Lektionen er ikke, at hvert MVP skulle være en video; lektionen er, at hvert MVP skal besvare et specifikt spørgsmål hurtigere end enhver anden version.
Hvordan det anvendes
Du bygger et AI-værktøj til advokater til at opsummere kontrakter. Et fuldt produkt ville have brug for OCR, et UI, et dokumentbibliotek, versionskontrol, teamsamarbejde og integrationer. MVP i stedet: en Google Form, hvor en advokat indsætter en kontrakt og trykker send, du kører den gennem Claude natten over, og sender et resumé tilbage inden 9 AM. Intet UI, ingen backend. De første 10 kunder får det gratis til gengæld for feedback. Inden for to uger ved du, om opsummeringen faktisk er brugbar, hvilke 2 sektioner betyder mest, og hvad advokaten ville betale. Det er nok til at beslutte, om du skal bygge et rigtigt produkt.
Almindelige fejl
- At forveksle MVP med beta - et MVP er det første, der skaber værdi, ikke den polerede beta.
- At sende et MVP uden instrumentering - du brugte uger på at bygge det og lærte intet.
- At tilføje features, som "alle forventer" før test - brugere forventer mange ting, de faktisk ikke har brug for.
- At behandle MVP'et som permanent - et MVP er disposabelt; det eksisterer for at lære dig, ikke for at skaleres.
Klar til at lægge det på et Lean Canvas?
Generer mit gratis Lean Canvas →