Definition
Ett MVP är den minsta produkt som levererar verkligt värde och genererar lärsam data genom att lösa problemet väl nog att någon betalar eller använder det seriöst.
Varför det spelar roll
MVP är där de flesta grundare förlorar sex månader. De lägger till "bara en feature till" istället för att lansera. Medan det, ändras marknaden, teamet blir utbränt och ingen lärdom sker. Drew Houstons ursprungliga Dropbox MVP var en 3-minuters videodemo av en produkt som inte ens fanns - 75 000 människor registrerade sig för väntelistan på en helg, vilket bevisade efterfrågan innan en enda rad synkkod skrevs. Lärdomen är inte att alla MVP:er bör vara videoklipp; lärdomen är att alla MVP:er bör svara på en specifik fråga snabbare än någon annan version.
Hur det tillämpas
Du bygger ett AI-verktyg för advokater för att sammanfatta kontrakt. En fullständig produkt skulle behöva OCR, ett UI, ett dokumentbibliotek, versionskontroll, teamsamarbete och integrationer. MVP istället: ett Google-formulär där en advokat klistrar in ett kontrakt och klickar på skicka, du kör det genom Claude över natten och mejlar tillbaka en sammanfattning innan 9 på morgonen. Ingen UI, inget backend. De första 10 kunderna får det gratis i utbyte mot feedback. Inom två veckor vet du om sammanfattningen faktiskt är användbar, vilka 2 avsnitt som spelar mest roll, och vad advokaten skulle betala. Det räcker för att bestämma om du ska bygga en riktigt produkt.
Vanliga misstag
- Att blanda ihop MVP med beta - ett MVP är det första som skapar värde, inte den polerade betaversionen.
- Lansera ett MVP utan instrumentering - du spenderade veckor på att bygga det och lär dig ingenting.
- Lägga till features som "alla förväntar sig" innan testning - användare förväntar sig många saker de faktiskt inte behöver.
- Behandla MVP:et som permanent - ett MVP är slängbar; det finns för att lära dig, inte för att skala.
Redo att lägga detta på ett Lean Canvas?
Generera mitt gratis Lean Canvas →