Definisjon
Minimum Viable Product er det minste du kan lansere som gir ekte verdi til en virkelig kunde og genererer data du kan lære fra uten ekstra funksjoner.
Hvorfor det er viktig
MVP-en er hvor de fleste gründere mister seks måneder. De legger til "bare en funksjon til" i stedet for å lansere. I mellomtiden endres markedet, teamet blir utslitt, og ingen læring skjer. Drew Houstons opprinnelige Dropbox MVP var en 3-minutters videodemo av et produkt som ikke eksisterte - 75 000 mennesker registrerte seg på ventelisten på en helg, noe som beviste etterspørsel før en eneste synkroniseringskodlinje ble skrevet. Leksjonen er ikke at alle MVP-er bør være videoer; leksjonen er at alle MVP-er bør besvare et spesifikt spørsmål raskere enn noen annen versjon.
Hvordan det gjelder
Du bygger et AI-verktøy for advokater for å oppsummere kontrakter. Et fullstendig produkt ville trenge OCR, et brukergrensesnitt, et dokumentbibliotek, versjonskontroll, teamsamarbeid og integrasjoner. MVP i stedet: et Google-skjema der en advokat limer inn en kontrakt og klikker send, du kjører det gjennom Claude over natten, og sender tilbake et sammendrag innen 09:00. Intet grensesnitt, ingen backend. Første 10 kunder får det gratis i bytte mot tilbakemelding. Innen to uker vet du om sammendraget faktisk er nyttig, hvilke 2 seksjoner som betyr mest, og hva advokaten ville betale. Det er nok til å bestemme om du skal bygge et ekte produkt.
Vanlige feil
- Å forveksle MVP med beta - et MVP er det første som skaper verdi, ikke beta med polert utseende.
- Å lansere et MVP uten instrumentering - du brukte uker på å bygge det og lærer ingenting.
- Å legge til funksjoner som "alle forventer" før testing - brukere forventer mange ting de ikke trenger.
- Å behandle MVP-en som permanent - et MVP er kassabel; det eksisterer for å lære deg, ikke for å skalere.
Klar til å sette dette på et Lean Canvas?
Generer mitt gratis Lean Canvas →